Клиент L2TP неправильно получает сетевые настройки от VPN-сервера — маршрутизация не работает.

Кто-нибудь из сотрудников Mikrotik здесь? Всё ещё жду ответа…

Отправьте письмо на support@mikrotik.com

Я вернулся, так что опишу всё снова. Я поставил RouterOS на виртуальную машину, чтобы протестировать интересующую меня функцию — L2TP клиент. Схема такая: на стороне клиента у нас есть виртуальная машина с двумя сетевыми интерфейсами. Первый — для «LAN» (на предварительном тестировании не нужен), второй — для «WAN» (подключён к NAT и имеет интернет-соединение). На стороне сервера у нас VPS в дата-центре хостинг-провайдера под управлением Ubuntu Server с настроенным SoftEther VPN сервером. Там включена функция L2TP сервера, и у меня нет проблем подключиться к нему с помощью встроенного L2TP клиента Windows, всё работает как нужно, в том числе доступ к удалённому шлюзу и прочее.

Так что я настроил L2TP клиент RouterOS следующими командами:  
/interface l2tp-client add name=l2tp-test connect-to=y.y.y.y user=xxxx password=xxxxx profile=default  
/interface l2tp-client enable  

После этого соединение устанавливается, и я вижу его также в логах SoftEther сервера. Более того, когда я пытаюсь пинговать IP-адрес, назначенный RouterOS клиенту со стороны VPN сервера, вижу, что ICMP пакеты доходят до RouterOS согласно логам сниффера пакетов. Но соединение не работает, как должно (например, не могу пропинговать адрес удалённого шлюза) — думаю, потому что сразу после установления подключения интерфейс получает неправильные сетевые настройки:  

[admin@MikroTik] > /ip address print detail
Flags: X - отключён, I - неверный, D - динамический  
0   address=192.168.0.1/24 network=192.168.0.0 interface=ether1 actual-interface=ether1  
1 D address=10.0.3.15/24 network=10.0.3.0 interface=ether2 actual-interface=ether2  
2 D address=10.7.0.100/32 network=1.0.0.1 interface=l2tp-test actual-interface=l2tp-test  

Могли бы объяснить, что я делаю не так?  
С уважением, Константин

Какие именно пакеты вам нужны — то есть сессия, которую нужно захватить? Как я уже писал выше, соединение установлено успешно, и ICMP-пакеты приходят на сторону RouterOS, когда я пытаюсь пропинговать назначенный IP с VPN-сервера. С уважением, Константин

Ситуация следующая: когда я пытаюсь пинговать с VPN-сервера, пакеты ICMP-запроса поступают на сторону RouterOS согласно журналу захвата пакетов, но на интерфейсе l2tp-test не генерируются ICMP-ответы, потому что, как я писал выше, там неправильные сетевые настройки. Вот журнал пакетов:  
[admin@MikroTik] > /tool sniffer packet print
#    TIME IN.. SRC-ADDRESS                                 DST-ADDRESS                                 IP-..  SIZE CPU  
0   9.371 l2.. 10.7.0.1                                    10.7.0.100                                  icmp     84   0  
1   10.37 l2.. 10.7.0.1                                    10.7.0.100                                  icmp     84   0  
2   11.37 l2.. 10.7.0.1                                    10.7.0.100                                  icmp     84   0  

10.7.0.100 — это адрес, назначенный интерфейсу l2tp-test, а 10.7.0.1 — это удалённый VPN-шлюз.  
С уважением, Константин

Я сделал захват на интерфейсе l2tp-test — вот .pcap файл: http://rghost.net/8Dq2HWFW2 С уважением, Константин

Ок, вот ссылка: https://drive.google.com/file/d/0Byvx0_28qNWhb3Z3bGRRRFhYNUE/view?usp=sharing С наилучшими пожеланиями, Константин

Об этом я уже говорил — удалённый VPN-шлюз недоступен из-за неправильных сетевых настроек, которые интерфейс l2tp-test получает после подключения (посмотрите поле Network для интерфейса l2tp-test):  
[admin@MikroTik] > /ip address print
Flags: X - отключен, I - недействителен, D - динамический  
#   ADDRESS            NETWORK         INTERFACE  
0   192.168.0.1/24     192.168.0.0     ether1  
1 D 10.0.3.15/24       10.0.3.0        ether2  
2 D 10.7.0.100/32      1.0.0.1         l2tp-test  

Я это уже понял, мой вопрос был — почему L2TP интерфейс получает неправильные сетевые настройки при подключении и как это исправить? Как я написал ранее — Windows-клиент работает отлично, никаких проблем.  

С уважением, Константин

Ок, вот захват трафика для всех интерфейсов с фильтром по адресу=10.7.0.0/24: https://drive.google.com/file/d/0Byvx0_28qNWhUmdpdmdXWmJ5Wms/view?usp=sharing

И дополнительно лог сниффера для этой сессии:

[admin@MikroTik] > /tool sniffer packet print detail
0 time=37.756 num=1 direction=rx interface=l2tp-test src-address=10.7.0.1 dst-address=10.7.0.100 protocol=ip  
  ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=1811 fragment-offset=0  
  ttl=64  

1 time=37.756 num=2 direction=tx interface=ether2 src-address=10.7.0.100 dst-address=10.7.0.1 protocol=ip  
  ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=54076 fragment-offset=0  
  ttl=64  

2 time=38.764 num=3 direction=rx interface=l2tp-test src-address=10.7.0.1 dst-address=10.7.0.100 protocol=ip  
  ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=1999 fragment-offset=0  
  ttl=64  

3 time=38.764 num=4 direction=tx interface=ether2 src-address=10.7.0.100 dst-address=10.7.0.1 protocol=ip  
  ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=54077 fragment-offset=0  
  ttl=64  

4 time=39.77 num=5 direction=rx interface=l2tp-test src-address=10.7.0.1 dst-address=10.7.0.100 protocol=ip  
  ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=2210 fragment-offset=0  
  ttl=64  

5 time=39.77 num=6 direction=tx interface=ether2 src-address=10.7.0.100 dst-address=10.7.0.1 protocol=ip  
  ip-protocol=icmp size=84 cpu=0 ip-packet-size=84 ip-header-size=20 dscp=0 identification=54078 fragment-offset=0  
  ttl=64  

6 time=40.71 num=7 direction=tx interface=l2tp-test src-address=10.7.0.100:5678 (discovery)  
  dst-address=255.255.255.255:5678 (discovery) protocol=ip ip-protocol=udp size=112 cpu=0 ip-packet-size=112  
  ip-header-size=20 dscp=0 identification=0 fragment-offset=0 ttl=64  

С уважением, Константин