Quina interfície rep el NAT intern i extern en una sortida VPN d'IOS

Els encaminadors que ofereixen una sortida a Internet de túnel complet fan dues feines que semblen una. Acaben el túnel i reenvien el paquet de client desxifrat cap a Internet. Només la segona feina necessita traducció, i la traducció ha de coincidir amb el flux intern. Aquesta distinció decideix quines interfícies porten els papers del NAT i quin rang d'adreces apareix a la regla.

Seguiu un paquet a través de l'encaminador

Agafeu un client a 10.90.0.25 que obre un servei HTTPS públic. Si aquesta destinació entra o no al túnel és una decisió de la política del mateix client. Un cop hi entra, l'encaminador desxifra el paquet i el lliura a una interfície virtual, des d'on s'encamina cap a l'enllaç ascendent públic.

Aquesta interfície virtual és la part interior de la traducció. L'enllaç ascendent públic és la part exterior. Si els papers s'inverteixen o falten, el paquet o surt amb una font privada o es descarta abans de ser traduït.

Adapteu la política de traducció al conjunt de clients

La regla de NAT ha de nomenar el rang que els clients reben realment, no la LAN de l'oficina que casualment comparteix l'enllaç ascendent. Una regla que només cobreix la subxarxa local deixa fora els clients remots encara que tots dos surtin per la mateixa interfície.

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

Manteniu les excepcions de llocs privats a part. El trànsit cap a destinacions internes ha de conservar la seva font original, o la destinació respondrà a una adreça que no pot assolir i el tram de tornada fallarà d'una manera que sembla un bucle d'encaminament.

Apliqueu els papers a les interfícies reals del disseny desplegat. Un fragment de Virtual-Template copiat d'una resposta antiga d'Easy VPN no és una configuració actual completa, i el tipus de túnel emprat determina quina interfície rep el paquet desxifrat.

Separeu el transport exterior de la traducció interna

Traduir una font d'aplicació desxifrada no és la mateixa operació que empènyer IKE o paquets protegits a través d'un dispositiu NAT més amunt. La primera canvia què veu Internet com a font de la petició del client; la segona manté un túnel viu a través d'un element intermedi.

Confondre-les produeix dues fallades clàssiques. Un encaminador que tradueix el seu propi transport de túnel trenca la relació amb el peer, mentre que un encaminador que no tradueix mai el flux intern reenvia adreces privades a Internet. Llegiu quin flux esteu mirant abans d'editar una regla, i comproveu si el túnel ha quedat aixecat després del canvi. Una regla que arregla la navegació però tomba el túnel ha mogut el problema en lloc de resoldre'l.

Cap de les dues fallades no es corregeix canviant l'altra. Llegiu quin flux esteu mirant abans d'editar una regla.

Verifiqueu a les dues fronteres

Llegiu la font de l'aplicació a la frontera d'Internet, i la destinació restaurada al tram de tornada. La primera diu si hi ha hagut traducció; la segona diu si el mapatge invers ha tornat al client correcte.

Després proveu un client que faci servir un camí de túnel dividit aprovat. Aquest client no executa mai la traducció d'Internet d'aquest encaminador, així que hauria de comportar-se diferent, i la diferència confirma quin camí ha seguit el trànsit.

Si tots dos clients es comporten igual, la política de túnel dividit no fa el que diu el disseny. Corregiu-ho abans d'afegir més regles de traducció, perquè una regla escrita per a un camí que no s'usa amaga el problema real.