Que interfaz recibe os papeis NAT de dentro e de fóra nunha saída VPN de IOS
Segue o paquete de cliente descifrado desde a interface virtual ata a ligazón ascendente. A tradución pertence a ese fluxo interno, non ao transporte exterior do túnel.
Os encamiñadores que ofrecen unha saída a Internet de túnel completo fan dúas tarefas que parecen unha. Rematan o túnel e reenvían o paquete de cliente descifrado cara a Internet. Só a segunda tarefa necesita tradución, e a tradución debe coincidir co fluxo interno. Esa distinción decide que interfaces levan os papeis de NAT e que rango de enderezos aparece na regra.
Segue un paquete a través do encamiñador
Toma un cliente en 10.90.0.25 que abre un servizo HTTPS público. Se ese destino entra ou non no túnel é unha decisión da política do propio cliente. Unha vez entra, o encamiñador descifra o paquete e entrégao a unha interface virtual, desde onde se encamiña cara á ligazón ascendente pública.
Esa interface virtual é o lado interno da tradución. A ligazón ascendente pública é o lado externo. Se os papeis se invirten ou faltan, o paquete ou sae cunha fonte privada ou descártase antes de ser traducido.
| 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? |
Axusta a política de tradución ao conxunto de clientes
A regra de NAT debe nomear o rango que os clientes reciben realmente, non a LAN da oficina que casualmente comparte a mesma ligazón ascendente. Unha regra que só cobre a subrede local deixa fóra os clientes remotos aínda que ambos saian pola mesma interface.
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 overloadMantén á parte as excepcións de sitios privados. O tráfico cara a destinos internos debe conservar a súa orixe orixinal, ou o destino responderá a un enderezo que non pode acadar e o tramo de volta fallará dun xeito que parece un bucle de encamiñamento.
Aplica os papeis ás interfaces reais do deseño despregado. Un fragmento de Virtual-Template copiado dunha resposta antiga de Easy VPN non é unha configuración actual completa, e o tipo de túnel empregado determina que interface recibe o paquete descifrado.
Separa o transporte exterior da tradución interna
Traducir unha orixe de aplicación descifrada non é a mesma operación que empurrar IKE ou paquetes protexidos a través dun dispositivo NAT máis arriba. A primeira cambia o que Internet ve como orixe da petición do cliente; a segunda mantén vivo un túnel a través dun elemento intermedio.
Confundilas produce dous fallos clásicos. Un encamiñador que traduce o seu propio transporte de túnel rompe a relación co par, mentres que un encamiñador que nunca traduce o fluxo interno reenvía enderezos privados a Internet. Le que fluxo estás mirando antes de editar unha regra, e comproba se o túnel quedou levantado despois do cambio. Unha regra que arranxa a navegación pero bota abaixo o túnel moveu o problema en lugar de resolvelo.
Ningún dos dous fallos se corrixe cambiando o outro. Le que fluxo estás mirando antes de editar unha regra.
Verifica nas dúas fronteiras
Le a orixe da aplicación na fronteira de Internet, e o destino restaurado no tramo de volta. A primeira di se houbo tradución; a segunda di se o mapa inverso volveu ao cliente correcto.
Despois proba un cliente que use un camiño de túnel dividido aprobado. Ese cliente nunca exerce a tradución de Internet deste encamiñador, así que debería comportarse distinto, e a diferenza confirma que camiño tomou o tráfico.
Se ambos clientes se comportan igual, a política de túnel dividido non fai o que di o deseño. Corríxeo antes de engadir máis regras de tradución, porque unha regra escrita para un camiño que non se usa esconde o problema real.