ASA hairpin: ieșire în internet sau ramură VPN între sedii?

Doi utilizatori de acces la distanță în spatele aceluiași ASA pot trimite trafic prin aceeași interfață externă și pot primi un tratament complet diferit. Unul merge către un site web public, deci pachetul are nevoie de traducerea sursei și de o rută de internet. Celălalt merge către un server din spatele unui tunel între sedii care se termină tot pe acea interfață, deci pachetul are nevoie de identitate, de un selector de tunel potrivit și de o cale de întoarcere către pool-ul de clienți. Permisiunea pentru aceeași interfață este o condiție prealabilă pentru ambele și o soluție pentru niciuna.

Două ramuri, o interfață

Decideți ce ramură construiți înainte de a tasta o regulă NAT, pentru că regulile nu sunt interschimbabile. Ramura A este de la client la internet: adresa pool-ului intră, adresa publică tradusă iese, întoarcere prin aceeași interfață. Ramura B este de la client la un prefix privat de cealaltă parte a altui peer IPsec: adresa pool-ului este păstrată, recriptată și livrată unui peer care trebuie să știe cum să răspundă pool-ului.

Ceea ce ambele au nevoie mai întâi este permisiunea pentru aceeași interfață. Fără ea, ASA refuză să transmită un pachet prin interfața pe care a sosit, iar defecțiunea arată ca o problemă de rutare, nu ca o problemă de politică:

same-security-traffic permit intra-interface

Acea singură linie autorizează un aranjament de transmitere, așa cum descrie referința NAT a ASA pentru căile prin aceeași interfață. Nu adaugă o rută de client, nu autorizează o resursă, nu traduce o adresă și nu negociază un selector IPsec, așa că așteptați-vă să adăugați încă trei sau patru lucruri după ea și nu citiți acceptarea ei ca progres.

Ramura A: clientul vrea internetul

Pentru o ieșire în internet, adresa pool-ului trebuie să înceteze să fie privată înainte ca pachetul să părăsească echipamentul. Într-un proiect PAT obișnuit, regula traduce pool-ul în adresa interfeței externe, iar starea de întoarcere restaurează fluxul către client:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Apoi confirmați că clientul a cerut într-adevăr ASA să transporte acel trafic. O excludere din tunelul divizat trimite destinația publică prin conexiunea proprie a telefonului, care nu ajunge niciodată la ASA, și nicio regulă NAT nu repară un pachet care nu a fost trimis niciodată. Comparați lista de tunel divizat a politicii de grup cu destinația pe care o testați.

Restul ramurii este obișnuit: o rută implicită sau specifică utilizabilă din interfața externă, o politică de acces care permite fluxul și DNS tratat conform politicii de resolver alese. Adăugați route-lookup aici din același motiv ca mai jos, deoarece interfețele de intrare și de ieșire sunt identice.

Ramura B: clientul vrea un sediu privat

Această ramură eșuează în mai multe locuri, așa că scrieți-o în ordine. Mai întâi ruta clientului: prefixul de destinație trebuie să fie în lista de tunel divizat, altfel clientul nu îl va pune în tunel. Apoi selectorul de tunel: ACL-ul criptografic între sedii trebuie să acopere adresa pool-ului până la prefixul îndepărtat, nu doar LAN-ul local până la prefixul îndepărtat. În final identitatea, ca adresa pool-ului să nu fie tradusă în PAT-ul de internet în drum.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

Partea îndepărtată este cea pe care oamenii uită să o testeze. Peer-ul are nevoie de o rută înapoi la pool și de un selector care îl include, și politica sa trebuie să permită adresele sursă pe care le va vedea. Dacă sediul este folosit printr-o vedere tradusă, este un proiect valid, dar atunci ambii peers, ambii selectori și ambele tabele de rutare trebuie să fie de acord asupra adreselor traduse.

Verificați și ordinea regulilor. O regulă PAT largă deasupra regulii de identitate va traduce schimbul privat înainte ca regula de identitate să fie evaluată, iar simptomul este un tunel de sediu fără SA corespunzător, nu o eroare NAT.

Testul care vă spune ce ramură ați construit

Folosiți evaluarea de cale a ASA însuși în loc să citiți configurația și să sperați. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed arată decizia NAT, ruta și rezultatul ACL pentru un flux; repetați cu o destinație privată. Dacă faza NAT rescrie un flux privat-la-privat, ați construit ramura A pentru un pachet care avea nevoie de ramura B.

Încă două comenzi închid diferența. show nat detail afișează ordinea regulilor urmată de packet-tracer, și show crypto ipsec sa arată dacă există un selector pentru perechea așteptată. Un SA lipsă este o chestiune de configurare a selectorului sau a peer-ului, nu ceva ce regula NAT poate repara.

Verificați fiecare ramură cu traficul pe care îl deservește

Acceptați ramura A cu o cerere publică obișnuită de la client și ramura B cu o cerere către o resursă privată care există cu adevărat. Apoi repetați fiecare cu o resursă refuzată, pentru că „permis” și „aprobat de politica de acces” nu sunt aceeași dovadă, iar un ping originat în hub nu exersează niciuna dintre căile clientului.

Țineți cele două înregistrări de test separate în tichet: adresa sursă, destinația, regula NAT care s-a potrivit și rezultatul. Când următorul raport spune „VPN-ul este stricat”, acea pereche vă spune într-un minut ce ramură a regresat, iar răspunsul este de obicei o rută sau un selector, nu linia aceleiași interfețe pe care toată lumea o suspectează prima.