Ce interfață primește rolul NAT interior și exterior pe o ieșire VPN IOS

Routerele care oferă o ieșire spre internet prin tunel complet fac două treburi care arată ca una singură. Încheie tunelul și trimite pachetul clientului decriptat către internet. Doar a doua treabă are nevoie de traducere, iar traducerea trebuie să corespundă fluxului interior. Această distincție decide care interfețe poartă rolurile NAT și ce interval de adrese apare în regulă.

Urmăriți un pachet prin router

Luați un client la 10.90.0.25 care deschide un serviciu HTTPS public. Dacă destinația intră sau nu în tunel este o decizie a politicii clientului însuși. Odată intrat, routerul decriptează pachetul și îl livrează unei interfețe virtuale, de unde este rutat către legătura superioară publică.

Acea interfață virtuală este partea interioară a traducerii. Legătura superioară publică este partea exterioară. Dacă rolurile sunt inversate sau lipsesc, pachetul fie pleacă cu o sursă privată, fie este aruncat înainte de a fi tradus.

Potriviți politica de traducere cu grupul de clienți

Regula NAT trebuie să numească intervalul pe care clienții îl primesc efectiv, nu LAN-ul de birou care se întâmplă să partajeze legătura superioară. O regulă care acoperă doar subrețeaua locală ratează clienții la distanță chiar și atunci când ambele ies prin aceeași interfață.

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

Țineți separat excepțiile pentru site-urile private. Traficul către destinații interne trebuie să-și păstreze sursa originală, altfel destinația răspunde la o adresă la care nu poate ajunge, iar segmentul de retur eșuează într-un mod care seamănă cu o buclă de rutare.

Aplicați rolurile interfețelor reale din proiectul implementat. Un fragment de Virtual-Template copiat dintr-un răspuns vechi Easy VPN nu este o configurație actuală completă, iar tipul de tunel folosit determină ce interfață primește pachetul decriptat.

Țineți transportul exterior și traducerea interioară separate

Traducerea unei surse de aplicație decriptate nu este aceeași operație cu împingerea pachetelor IKE sau protejate printr-un dispozitiv NAT din amonte. Prima schimbă ce vede internetul ca sursă a cererii clientului; a doua menține un tunel viu printr-un dispozitiv intermediar.

Confundarea lor produce două eșecuri clasice. Un router care își traduce propriul transport al tunelului rupe relația de peer, în timp ce un router care nu traduce niciodată fluxul interior trimite adrese private către internet. Citiți ce flux priviți înainte de a edita o regulă și verificați dacă tunelul a rămas ridicat după modificare. O regulă care repară navigarea dar doboară tunelul a mutat problema în loc să o rezolve.

Niciunul dintre eșecuri nu se rezolvă schimbându-l pe celălalt. Citiți ce flux priviți înainte de a edita o regulă.

Verificați la ambele granițe

Citiți sursa aplicației la granița internetului și destinația restaurată pe segmentul de retur. Prima spune dacă traducerea a avut loc; a doua spune dacă maparea inversă s-a întors la clientul corect.

Apoi testați un client care folosește o cale de tunel divizat aprobată. Acel client nu folosește niciodată traducerea de internet a acestui router, așa că ar trebui să se comporte diferit, iar diferența confirmă ce cale a urmat traficul.

Dacă ambii clienți se comportă identic, politica de tunel divizat nu face ce spune proiectul. Remediați asta înainte de a adăuga mai multe reguli de traducere, pentru că o regulă scrisă pentru o cale nefolosită ascunde problema reală.