ASA hairpin: dalje në internet apo këmbë VPN mes faqeve?

Dy përdorues të aksesit në distancë pas të njëjtit ASA mund të dërgojnë trafik nga i njëjti ndërfaqe i jashtëm dhe të marrin trajtim krejt të ndryshëm. Njëri shkon drejt një sajti publik, kështu që paketa ka nevojë për përkthim burimi dhe një rutë interneti. Tjetri shkon drejt një serveri pas një tuneli mes faqeve që gjithashtu përfundon në atë ndërfaqe, kështu që paketa ka nevojë për identitet, një selektor tuneli që përputhet dhe një rrugë kthimi drejt grupit të klientëve. Leja për të njëjtën ndërfaqe është parakusht për të dyja dhe zgjidhje për asnjërën.

Dy këmbë, një ndërfaqe

Vendosni cilën këmbë po ndërtoni përpara se të shkruani një rregull NAT, sepse rregullat nuk janë të këmbyeshme. Këmba A është klient drejt internetit: adresa e grupit hyn, adresa publike e përkthyer del, kthehet nëpër të njëjtën ndërfaqe. Këmba B është klient drejt një prefiksi privat në anën tjetër të një partneri tjetër IPsec: adresa e grupit ruhet, rikriptohet dhe dorëzohet te një partner që duhet të dijë si t’i përgjigjet grupit.

Ajo që të dyja kanë nevojë së pari është leja për të njëjtën ndërfaqe. Pa të, ASA refuzon të përçojë një paketë nga ndërfaqja në të cilën mbërriti, dhe dështimi duket si problem rrugëtimi dhe jo si problem politike:

same-security-traffic permit intra-interface

Ajo rresht i vetëm autorizon një skemë përçimi, siç përshkruan referenca NAT e ASA për rrugët nëpër të njëjtën ndërfaqe. Nuk shton një rutë klienti, nuk autorizon një burim, nuk përkthen një adresë dhe nuk negocion një selektor IPsec, prandaj prisni të shtoni edhe tre ose katër gjëra pas saj dhe mos e lexoni pranimin e saj si përparim.

Këmba A: klienti dëshiron internetin

Për një dalje në internet, adresa e grupit duhet të pushojë së qeni private përpara se paketa të lërë pajisjen. Në një projekt PAT të zakonshëm rregulli përkthen grupin në adresën e ndërfaqes së jashtme, dhe gjendja e kthimit rikrijon rrjedhën drejt klientit:

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

Më pas konfirmoni që klienti i ka kërkuar vërtet ASA-s të mbajë atë trafik. Një përjashtim i tunelit të ndarë e dërgon destinacionin publik përmes lidhjes së vetë telefonit, e cila nuk arrin kurrë te ASA, dhe asnjë rregull NAT nuk e rregullon një paketë që nuk u dërgua kurrë. Krahasoni listën e tunelit të ndarë të politikës së grupit me destinacionin që po testoni.

Pjesa tjetër e këmbës është e zakonshme: një rutë e paracaktuar ose specifike e përdorshme nga ndërfaqja e jashtme, një politikë aksesi që lejon rrjedhën, dhe DNS i trajtuar sipas politikës së zgjidhësit që zgjodhët. Shtoni route-lookup këtu për të njëjtën arsye si më poshtë, pasi ndërfaqja e hyrjes dhe ajo e daljes janë identike.

Këmba B: klienti dëshiron një faqe private

Kjo këmbë dështon në më shumë vende, prandaj shkruajeni me radhë. Së pari ruta e klientit: prefiksi i destinacionit duhet të jetë në listën e tunelit të ndarë, përndryshe klienti nuk do ta vendosë në tunel. Së dyti selektori i tunelit: ACL kriptografik mes faqeve duhet të mbulojë adresën e grupit deri te prefiksi i largët, jo vetëm LAN-in lokal deri te prefiksi i largët. Së treti identiteti, që adresa e grupit të mos përkthehet në PAT interneti gjatë rrugës.

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

Ana e largët është pjesa që njerëzit harrojnë ta testojnë. Partneri ka nevojë për një rutë kthimi drejt grupit dhe një selektor që e përfshin, dhe politika e tij duhet të lejojë adresat burimore që do të shohë. Nëse faqja përdoret përmes një pamjeje të përkthyer, ai është një projekt i vlefshëm, por atëherë të dy partnerët, të dy selektorët dhe të dy tabelat e rrugëtimit duhet të bien dakord për adresat e përkthyera.

Kontrolloni edhe rendin e rregullave. Një rregull PAT i gjerë mbi rregullin e identitetit do të përkthejë shkëmbimin privat përpara se rregulli i identitetit të vlerësohet fare, dhe simptoma është një tunel faqeje pa SA përputhës dhe jo një gabim NAT.

Testi që ju thotë cilën këmbë ndërtuat

Përdorni vlerësimin e rrugës të vetë ASA-s në vend që të lexoni konfigurimin dhe të shpresoni. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed tregon vendimin NAT, rutën dhe rezultatin e ACL për një rrjedhë; përsëriteni me një destinacion privat. Nëse faza NAT rishkruan një rrjedhë privat-në-privat, keni ndërtuar këmbën A për një paketë që i nevojitej këmba B.

Dy komanda të tjera e mbyllin hendekun. show nat detail shtyp rendin e rregullave që ndoqi packet-tracer, dhe show crypto ipsec sa tregon nëse ekziston një selektor për çiftin që prisni. Një SA që mungon është çështje konfigurimi të selektorit ose partnerit, jo diçka që rregulli NAT mund ta rregullojë.

Verifikoni çdo këmbë me trafikun që shërben

Pranoni këmbën A me një kërkesë publike të zakonshme nga klienti, dhe këmbën B me një kërkesë drejt një burimi privat që ekziston vërtet. Më pas përsëritni secilën me një burim të refuzuar, sepse „i lejuar“ dhe „i miratuar nga politika e aksesit“ nuk janë i njëjti provë, dhe një ping që niset nga qendra nuk ushtron asnjërën nga rrugët e klientit.

Mbani dy regjistrat e testit të ndarë në tiketë: adresa burimore, destinacioni, rregulli NAT që u përputh dhe rezultati. Kur raporti tjetër thotë „VPN-ja është prishur“, ai çift ju thotë brenda një minute cila këmbë ka regresuar, dhe përgjigjja zakonisht është një rutë ose një selektor, jo rreshti i së njëjtës ndërfaqe që të gjithë dyshojnë i pari.