L2TP между белым MT и заNATным MT

Здравствуйте!

Пожалуйста помогите разобраться в схеме подключения.



Соединение L2TP устанавливается. Пингуются интерфейсы шлюзов(в т.ч. L2TP), а в сети друг к другу не ходят.
Из сети со стороны сервера Winbox не подключается ни на 6.1 ни на 88.18.

Что-то с маршрутами напортачил или может MTU... Заковырялся уже. Пролейте свет, пожалуйста!

SRV:
chain=srcnat action=masquerade to-addresses=0.0.0.0 out-interface=ether5-WAN log=no log-prefix=""
chain=srcnat action=masquerade out-interface=office log=no log-prefix=""

chain=input action=drop src-address-list=BOGON in-interface=ether5-WAN log=no log-prefix=""
chain=input action=accept protocol=udp dst-port=1701 log=no log-prefix=""
chain=input action=accept protocol=tcp dst-port=8291 log=no log-prefix=""
chain=input action=accept connection-state=established,related log=no log-prefix=""
chain=input action=accept protocol=icmp log=no log-prefix=""
chain=input action=accept protocol=tcp dst-port=1723 log=no log-prefix=""
chain=input action=drop in-interface=ether5-WAN log=no log-prefix=""
chain=forward action=accept protocol=icmp log=no log-prefix=""
chain=forward action=accept connection-state=established,related log=no log-prefix=""
chain=forward action=drop connection-state=invalid log=no log-prefix=""
chain=forward action=drop connection-state=new connection-nat-state=dstnat in-interface=ether5-WAN log=no log-prefix=""
chain=forward action=accept in-interface=!ether5-WAN out-interface=ether5-WAN log=no log-prefix=""
chain=forward action=drop log=no log-prefix=""

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 46.175.xxx.1 0
1 ADC 46.175.xxx.0/24 46.175.xxx.146 ether5-WAN 0
2 A S 192.168.6.0/28 192.168.88.17 192.168.88.18 1
3 ADC 192.168.88.0/28 192.168.88.1 bridge-local 0
4 ADC 192.168.88.16/28 192.168.88.17 bridge-local 0
5 ADC 192.168.88.18/32 192.168.88.17 office 0

CLIENT:
chain=srcnat action=masquerade out-interface=WAN log=no log-prefix=""
chain=srcnat action=masquerade out-interface=office log=no log-prefix=""

chain=input action=accept protocol=udp dst-port=1701 log=no log-prefix=""
chain=input action=accept protocol=tcp dst-port=8291 log=no log-prefix=""
chain=input action=accept connection-state=established,related log=no log-prefix=""
chain=input action=accept protocol=icmp log=no log-prefix=""
chain=input action=drop in-interface=WAN log=no log-prefix=""
chain=forward action=accept protocol=icmp log=no log-prefix=""
chain=forward action=accept connection-state=established,related log=no log-prefix=""
chain=forward action=drop connection-state=invalid log=no log-prefix=""

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 10.133.8.1 1
1 ADC 10.133.8.0/24 10.133.8.107 WAN 0
2 ADC 192.168.6.0/28 192.168.6.1 LAN 0
3 A S 192.168.88.16/28 192.168.88.18 office 2
4 ADC 192.168.88.17/32 192.168.88.18 office 0

 

У интерфейса VPN сделайте другую подсеть, назначать на разные интерфейсы адреса из одной подсети - это не гуд..

 

Так ведь из разных подсетей же - 192.168.88.0/28 | 192.168.88.16/28

 

ну да что-то протупил..

 

Нет. Никак. Если маршрут через secret добавить то traceroute пакеты через основной интерфейс МТ отправляет, а если вручную добавить, то хотя бы через интерфейс туннеля отправляет. Один пакет пролазит, а дальше timeout.
Кроме того схема по ссылке подразумевает два белых адреса.

 

Настройки сервера:
/ppp secret
add comment="blabla" local-address=192.168.88.17 name=office password=\
blabla profile=remote-office remote-address=192.168.88.18 \
routes="192.168.6.0/28 192.168.88.18 1" service=l2tp

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 46.175.xxx.1 0
1 ADC 46.175.xxx.0/24 46.175.xxx.146 ether5-WAN 0
2 ADS 192.168.6.0/28 192.168.88.18 1
3 ADC 192.168.88.0/28 192.168.88.1 bridge-local 0
4 ADC 192.168.88.18/32 192.168.88.17 office-l2tp 0

Настройки клиента:
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 10.133.8.1 1
1 ADC 10.133.8.0/24 10.133.8.107 WAN 0
2 ADC 192.168.6.0/28 192.168.6.1 LAN 0
3 A S 192.168.88.0/28 192.168.88.18 192.168.88.17 1
4 ADC 192.168.88.17/32 192.168.88.18 l2tp to Server 0

Мне необходимо попасть в сеть 192.168.6.0/28
Что я делаю не правильно? И чем принципиально отличается метод обозначения маршрута в secret от явного в ip routes? Лично я разницы не вижу.

 

Настройки сервера:
/ppp secret
add comment="blabla" local-address=172.31.255.1 name=office password=\
blabla profile=remote-office remote-address=172.31.255.2 routes=\
"192.168.6.0/28 172.31.255.2 1" service=l2tp

# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADS 0.0.0.0/0 46.175.xxx.1 0
1 ADC 46.175.xxx.0/24 46.175.xxx.146 ether5-WAN 0
2 ADC 172.31.255.2/32 172.31.255.1 office-l2tp 0
3 ADS 192.168.6.0/28 172.31.255.2 1
4 ADC 192.168.88.0/28 192.168.88.1 bridge-local 0

Настройки клиента:
# DST-ADDRESS PREF-SRC GATEWAY
0 ADS 0.0.0.0/0 10.133.8.1
1 ADC 10.133.8.0/24 10.133.8.107 WAN
2 ADC 172.31.255.1/32 172.31.255.2 l2tp to Server
3 ADC 192.168.6.0/28 192.168.6.1 LAN
4 A S 192.168.88.0/28 172.31.255.2 172.31.255.1

Ситуация аналогичная. Но...
Случайно заметил странную особенность на клиенте - при подключении по IP 192.168.6.1 через WinBox не отображает в окне Firewall\NAT правила и выкидывает через несколько секунд. Если не заходить в окно Firewall мышкой, то не выкидывает, а правила видны через терминал. При подключении по MAC проблемы не наблюдается. Интернет работает исправно - отображает, качает, тоннель не рвёт. Не знаю связано это как-то с основным вопросом или нет, но тем не менее попробую поменять сетевую карту.
Ваши комментарии, коллеги?

 

Я бы WinBox для начала обновил/заменил

 

И надо же было манглить все итерации пакетов, что бы разбиться об настроенный должным образом фаервол Windows 10 на dst-машине...
Настройка была верна с самого начала, за исключением глупых NAT-ов на туннельных интерфейсах с обеих сторон и, как верно подметил Илья, сиамских маршрутов. После отключения фаервола icmp-пакеты достигли узла и вернулись через тоннель.
Спасибо за участие и выдержку!
Теперь дело за пробросом из-за NAT-а, через L2TP туннель, FTP-сервера... весьма занятное дело, доложу я Вам