Який інтерфейс отримує внутрішню та зовнішню роль NAT на виході IOS VPN
Простежте розшифрований пакет клієнта від віртуального інтерфейсу до висхідного каналу. Трансляція стосується цього внутрішнього потоку, а не зовнішнього транспорту тунелю.
Маршрутизатори, що забезпечують вихід в інтернет через повний тунель, виконують дві роботи, які виглядають як одна. Він завершує тунель і передає розшифрований пакет клієнта в інтернет. Трансляція потрібна лише другій роботі, і вона має відповідати внутрішньому потоку. Ця різниця визначає, які інтерфейси несуть ролі NAT і який діапазон адрес фігурує в правилі.
Простежте один пакет через маршрутизатор
Візьміть клієнт з адресою 10.90.0.25, який відкриває публічну службу HTTPS. Чи це призначення взагалі потрапляє в тунель, вирішує політика самого клієнта. Щойно воно потрапляє, маршрутизатор розшифровує пакет і доставляє його на віртуальний інтерфейс, звідки той маршрутизується у публічний висхідний канал.
Цей віртуальний інтерфейс — внутрішній бік трансляції. Публічний висхідний канал — зовнішній бік. Якщо ролі переплутані або відсутні, пакет або виходить із приватним джерелом, або відкидається до трансляції.
| Stage | Question to answer |
|---|---|
| VPN client | Does the client's policy put this destination inside the tunnel? |
| Decrypted ingress | Which virtual interface receives the inner packet? |
| Internet egress | Which route, access policy and source translation apply? |
| Reply | Is the client's flow translated back before it is delivered over the tunnel? |
Узгодьте політику трансляції з пулом клієнтів
Правило 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 вище. Перша змінює те, що інтернет бачить як джерело запиту клієнта; друга підтримує тунель живим крізь проміжний пристрій.
Їхнє змішування дає дві класичні відмови. Маршрутизатор, що транслює власний транспорт тунелю, ламає стосунки з піром, а маршрутизатор, який ніколи не транслює внутрішній потік, надсилає приватні адреси в інтернет. Прочитайте, на який потік ви дивитеся, перш ніж редагувати правило, і перевірте, чи тунель залишився піднятим після зміни. Правило, яке виправляє перегляд, але валить тунель, перемістило проблему, а не вирішило її.
Жодна з відмов не виправляється зміною іншої. Прочитайте, на який потік ви дивитеся, перш ніж редагувати правило.
Перевірте на обох межах
Прочитайте джерело застосунку на межі інтернету та відновлене призначення на зворотній частині. Перше каже, чи сталася трансляція; друге каже, чи повернулося зворотне відображення до потрібного клієнта.
Потім перевірте клієнта, який використовує схвалений шлях роздільного тунелювання. Цей клієнт ніколи не задіює інтернет-трансляцію цього маршрутизатора, тож має поводитися інакше, і різниця підтверджує, яким шляхом пішов трафік.
Якщо обидва клієнти поводяться однаково, політика роздільного тунелювання робить не те, що заявлено в проєкті. Виправте це, перш ніж додавати нові правила трансляції, бо правило, написане для невикористовуваного шляху, приховує справжню проблему.