Какой интерфейс получает внутреннюю, а какой внешнюю роль NAT на выходе IOS VPN

Маршрутизаторы, обеспечивающие выход в интернет через полный туннель, выполняют две работы, которые выглядят как одна. Он завершает туннель и передаёт расшифрованный пакет клиента в интернет. Трансляция нужна только второй работе, и она должна соответствовать внутреннему потоку. Это различие определяет, какие интерфейсы несут роли NAT и какой диапазон адресов фигурирует в правиле.

Проследите один пакет через маршрутизатор

Возьмите клиент с адресом 10.90.0.25, открывающий публичную службу HTTPS. Попадёт ли это назначение в туннель вообще, решает политика самого клиента. Как только оно туда попадает, маршрутизатор расшифровывает пакет и доставляет его на виртуальный интерфейс, откуда пакет маршрутизируется в публичный вышестоящий канал.

Этот виртуальный интерфейс — внутренняя сторона трансляции. Публичный вышестоящий канал — внешняя сторона. Если роли перепутаны или отсутствуют, пакет либо уходит с частным источником, либо отбрасывается до трансляции.

Согласуйте политику трансляции с пулом клиентов

Правило NAT должно называть диапазон, который клиенты действительно получают, а не офисную LAN, которая случайно делит вышестоящий канал. Правило, охватывающее только локальную подсеть, пропускает удалённых клиентов, даже когда оба выходят через один и тот же интерфейс.

ip access-list extended NAT-TUNNEL
 permit ip 10.90.0.0 0.0.0.255 any
ip nat inside source list NAT-TUNNEL interface GigabitEthernet0/0/0 overload

Исключения для частных сайтов держите отдельно. Трафик к внутренним назначениям должен сохранять свой исходный источник, иначе назначение ответит на адрес, до которого не может добраться, и обратное плечо откажет так, что это будет выглядеть как петля маршрутизации.

Примените роли к реальным интерфейсам в развёрнутом проекте. Фрагмент Virtual-Template, скопированный из старого ответа про Easy VPN, не является полной актуальной конфигурацией, а используемый тип туннеля определяет, какой интерфейс принимает расшифрованный пакет.

Держите внешний транспорт и внутреннюю трансляцию раздельно

Трансляция расшифрованного источника приложения — не та же операция, что проталкивание IKE или защищённых пакетов через устройство NAT выше по пути. Первая меняет то, что интернет видит как источник запроса клиента; вторая поддерживает туннель живым сквозь промежуточное устройство.

Их смешение даёт два классических отказа. Маршрутизатор, транслирующий собственный транспорт туннеля, ломает отношения с пиром, а маршрутизатор, который никогда не транслирует внутренний поток, отправляет частные адреса в интернет. Прочитайте, на какой поток вы смотрите, прежде чем править правило, и проверьте, поднялся ли туннель после изменения. Правило, которое чинит просмотр, но роняет туннель, перенесло проблему, а не решило её.

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

Проверьте на обеих границах

Прочитайте источник приложения на границе интернета и восстановленное назначение на обратном плече. Первое говорит, произошла ли трансляция; второе говорит, вернулось ли обратное отображение к нужному клиенту.

Затем проверьте клиента, использующего одобренный путь раздельного туннелирования. Этот клиент никогда не задействует интернет-трансляцию этого маршрутизатора, поэтому должен вести себя иначе, и разница подтверждает, каким путём пошёл трафик.

Если оба клиента ведут себя одинаково, политика раздельного туннелирования делает не то, что заявлено в проекте. Исправьте это, прежде чем добавлять новые правила трансляции, потому что правило, написанное для неиспользуемого пути, скрывает настоящую проблему.