NAT de identitate în ASA față de excepția NAT din IOS pentru traficul VPN

Pe gateway-urile Cisco, atât NAT-ul de identitate din ASA, cât și excepția clasificatorului NAT din IOS păstrează adresele VPN. Regulile diferă prin locul unde traducerea este omisă.

O sucursală rulează PAT pentru internet și un VPN site-to-site pe același gateway Cisco, iar VPN-ul nu mai funcționează în momentul în care se adaugă NAT. Adresele din tunel nu mai corespund cu ceea ce protejează crypto ACL, sau partenerul vede adrese traduse pentru care nu are rută. Cisco rezolvă asta în două locuri: ASA selectează o regulă NAT care mapează adresa la ea însăși, iar IOS ține fluxul în afara unei reguli de traducere printr-un deny din ACL. Ambele păstrează adresele originale și niciuna nu este o ocolire a procesării NAT.

Înregistrați fluxul înainte de a alege o regulă

Începeți prin a scrie fluxul pe care intenționați să îl protejați: sursa LAN, destinația îndepărtată și perechea exactă de adrese protejată de politica IPsec. Faceți asta înainte de a edita o regulă, pentru că tuplul arată care clasificator sau regulă NAT ar fi trebuit să se potrivească.

Apoi găsiți regula care s-a potrivit efectiv, nu cea pe care intenționați. Pe ambele platforme NAT este evaluat într-o ordine, iar o regulă anterioară poate câștiga înainte ca excepția dvs. să fie analizată. O excepție care pare corectă dar pierde în fața altei reguli nu livrează niciodată pachetul așteptat politicii de protecție. Simptomul este identic cu o excepție lipsă, de aceea ordinea regulilor trebuie citită înainte de a schimba configurația.

NAT-ul de identitate din ASA este o regulă, nu o ocolire

În ASA, NAT-ul de identitate este o regulă NAT a cărei adresă tradusă este egală cu cea originală. Este selectată ca orice altă regulă și tot instalează o intrare de traducere, deci pachetul nu sare peste procesarea NAT. Ceea ce se schimbă este că adresele din rețea rămân aceleași, iar de asta are nevoie politica IPsec.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Interfețele regulii și setarea route-lookup trebuie să corespundă proiectului de forwarding. O regulă care mapează corect adresa dar este aplicată pe perechea greșită de interfețe nu va fi selectată pentru fluxul dvs. Route-lookup decide dacă pachetul tradus este rutat sau se folosește destinația originală, iar asta determină dacă traficul de retur revine prin tunel.

Accesul de administrare la ASA însuși este un caz separat. Dacă folosiți NAT de identitate pentru traficul de administrare, se aplică cerința route-lookup specifică versiunii, iar o excepție largă copiată dintr-un exemplu VPN nu va repara SSH.

Un deny în ACL-ul NAT din IOS înseamnă nu este selectat aici

În IOS, NAT-ul de internet este condus de o listă de surse, iar acea ACL este un clasificator, nu un filtru. O linie permit selectează trafic pentru traducere; o linie deny înseamnă că pachetul nu este selectat aici. Acel deny nu este o instrucțiune de a arunca pachetul cum este un deny într-o ACL de interfață.

Nu este selectat aici este și mai îngust decât niciodată tradus nicăieri. O altă regulă NAT, altă interfață sau un route-map pot încă traduce fluxul, așa că trebuie citită toată tabela NAT. Pachetul are în continuare nevoie de o rută, de un crypto ACL potrivit și de permisiune la limitele reale de control al accesului.

O aranjare minimă în IOS pune deny deasupra permit în aceeași listă și îndreaptă regula overload spre acea listă. Atunci crypto ACL protejează aceeași pereche pe care deny o exclude de la traducere.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

O întrebare verificabilă pentru ambele modele

Ambele modele răspund la aceeași întrebare: care regulă s-a potrivit acestui flux și ce adrese au părăsit interfața? Capturați pe interfața externă și comparați adresa sursă înainte și după gateway. Apoi verificați viziunea partenerului asupra tunelului, pentru că SA poate fi ridicat în timp ce fluxul protejat este tradus altundeva.

În ASA afișați nat detail și tabela de traduceri; în IOS afișați ip nat translations și contoarele ACL corespunzătoare. O regulă care nu crește niciodată nu a fost niciodată selectată, iar asta indică ordinea, interfața sau direcția, nu configurația crypto.

Unde configurația greșește de obicei

Defecțiunile obișnuite sunt mecanice. Deny stă sub permit și nu se potrivește niciodată. Clasificatorul este aplicat în direcția greșită, așa că fluxul de retur este tradus. Regula de identitate acoperă adresele corecte dar perechea greșită de interfețe. Crypto ACL protejează o subrețea care nu mai corespunde cu ce prezintă regula NAT.

Înregistrați perechea de adrese originală și prezentată lângă proprietarul regulii, ca următorul inginer să vadă de ce un clasificator refuză traducerea în timp ce firewall-ul permite aplicația. Păstrați asta în tichetul de schimbare, nu într-o notă personală. Apoi rulați din nou fluxul după orice modificare NAT, pentru că ordinea regulilor face parte din configurație chiar și când textul regulii nu s-a schimbat. Un tunel care urcă nu dovedește că adresele au supraviețuit; doar pachetul capturat și viziunea decapsulată a partenerului o fac.

Articole similare