Кой интерфейс получава вътрешната и външната роля на NAT на изход VPN с IOS

Маршрутизаторите, които осигуряват изход към интернет през пълен тунел, изпълняват две задачи, които изглеждат като една. Той прекратява тунела и препраща дешифрирания клиентски пакет към интернета. Само втората задача се нуждае от транслация и тя трябва да съответства на вътрешния поток. Това разграничение определя кои интерфейси носят ролите на 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 по-нагоре. Първото променя това, което интернет вижда като източник на заявката на клиента; второто поддържа тунела жив през междинно устройство.

Объркването им дава два класически отказа. Маршрутизатор, който транслира собствения си транспортен тунел, разваля връзката с партньора, докато маршрутизатор, който никога не транслира вътрешния поток, препраща частни адреси към интернета. Прочетете кой поток гледате, преди да редактирате правило, и проверете дали тунелът е останал активен след промяната. Правило, което оправя сърфирането, но сваля тунела, е преместило проблема, вместо да го реши.

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

Проверете на двете граници

Прочетете източника на приложението на границата с интернет и възстановената дестинация по обратния път. Първото показва дали е имало транслация; второто – дали обратното съпоставяне се е върнало при правилния клиент.

След това тествайте клиент, който използва одобрен път на разделен тунел. Този клиент никога не задейства интернет транслацията на маршрутизатора, затова трябва да се държи различно, а разликата потвърждава по кой път е минал трафикът.

Ако двата клиента се държат еднакво, политиката на разделения тунел не прави това, което дизайнът казва. Оправете го, преди да добавяте още правила за транслация, защото правило, написано за неизползван път, скрива истинския проблем.