Отгадка про NAT
Вот ответ:
1. на Асусе настраиваем маршрут по-умолчанию на Цыску
2. на Цыске прописываем маршрут: ip route 172.16.0.0 0.0.0.255 A.B.C.D+2
3. на Цыске создаём ACL для NAT'а (который динамический, оверлоад и in2out):
ip access-list extended NAT-ACL
deny ip 192.168.105.0 0.0.0.255 host A.B.C.D+2
permit ip 192.168.105.0 0.0.0.255 any
Сама строка для NAT'а выглядит так:
ip nat inside source list NAT-ACL interface GigabitEthernet0/0 overload
4. на Цыске прописываем out2in NAT: ip nat outside source static A.B.C.D+2 192.168.105.99 add-route
IP 192.168.105.99 - неиспользуемый IP в сети. Без ключа add-route пакет out2in натится, а обратно нет. Почему - не знаю. На сайте Цыски не нашёл ответа ни почему без ключа не натится, ни почему с ключом натится. Думал сначала, что дело в Proxy ARP, но и с отключённой настройкой всё работало. )
Что мы получилось:
1. Если из-за цыски идёт инициирование в сторону клиентов Асуса, то происходит NAT на Цыске (обычный оверлоад в айпишник интерфейса "WAN"), а Асус пропускает пакет нетронутым (доп. условие 2 - ну так работает Асус, я тут не при чём). В обратную сторону пакеты ходят без проблем (conntrack в Асусе и запись про NAT на Цыске).
2. При инициации из-за Асуса в сеть за Цыской пакеты натятся на Асусе, а Цыска согласно своей логике натит out2in (заменяет во входящих src A.B.C.D+2 на 192.168.105.99). В обратную сторону пакеты тоже ходят без проблем.
3. Если пакету нужно добраться до сервера 192.168.100.101, то происходит всё согласно пункту 2, и пакет через VPN уходит до сервера, а ответы возвращаются.
Вот на то, чтобы понять, что ключик add-route решает мои проблемы, ушло часов 6 рабочего времени.
Надеюсь, всё более-менее внятно описал.
Случай, конечно, извратный. Но что не сделаешь, чтобы клиент оказался доволен. )
1. на Асусе настраиваем маршрут по-умолчанию на Цыску
2. на Цыске прописываем маршрут: ip route 172.16.0.0 0.0.0.255 A.B.C.D+2
3. на Цыске создаём ACL для NAT'а (который динамический, оверлоад и in2out):
ip access-list extended NAT-ACL
deny ip 192.168.105.0 0.0.0.255 host A.B.C.D+2
permit ip 192.168.105.0 0.0.0.255 any
Сама строка для NAT'а выглядит так:
ip nat inside source list NAT-ACL interface GigabitEthernet0/0 overload
4. на Цыске прописываем out2in NAT: ip nat outside source static A.B.C.D+2 192.168.105.99 add-route
IP 192.168.105.99 - неиспользуемый IP в сети. Без ключа add-route пакет out2in натится, а обратно нет. Почему - не знаю. На сайте Цыски не нашёл ответа ни почему без ключа не натится, ни почему с ключом натится. Думал сначала, что дело в Proxy ARP, но и с отключённой настройкой всё работало. )
Что мы получилось:
1. Если из-за цыски идёт инициирование в сторону клиентов Асуса, то происходит NAT на Цыске (обычный оверлоад в айпишник интерфейса "WAN"), а Асус пропускает пакет нетронутым (доп. условие 2 - ну так работает Асус, я тут не при чём). В обратную сторону пакеты ходят без проблем (conntrack в Асусе и запись про NAT на Цыске).
2. При инициации из-за Асуса в сеть за Цыской пакеты натятся на Асусе, а Цыска согласно своей логике натит out2in (заменяет во входящих src A.B.C.D+2 на 192.168.105.99). В обратную сторону пакеты тоже ходят без проблем.
3. Если пакету нужно добраться до сервера 192.168.100.101, то происходит всё согласно пункту 2, и пакет через VPN уходит до сервера, а ответы возвращаются.
Вот на то, чтобы понять, что ключик add-route решает мои проблемы, ушло часов 6 рабочего времени.
Надеюсь, всё более-менее внятно описал.
Случай, конечно, извратный. Но что не сделаешь, чтобы клиент оказался доволен. )