ASA VPN hairpin: rute to tunnelar gjennom eitt grensesnitt

Ein ekstern brukar koplar til ASA-en, ber om ein vert bak ei avdeling, og ASA-en sender den førespurnaden ut gjennom nøyaktig det grensesnittet brukaren kom inn på. Ingenting ved det krev ein andre fysisk port. Det som krevst, er fire uavhengige avgjerder som folk har ein tendens til å slå saman til eitt: løyve til å gjere hairpin, ein tunnel som vernar dei rette adressene, ein NAT-policy som bevarer kjelda du lova, og ein tilgangspolicy som autoriserer tenesta.

Éin pakke, to tunnelar

Følg flyten, og rekkefølgja av operasjonar sluttar å vere mystisk. Pakken kjem inn inne i fjernaksess-tunnelen, blir dekryptert og blir ein vanleg IP-pakke med kjelde frå klientbassenget. Deretter rutar ASA-en han, matchar han mot crypto ACL-en frå stad til stad, krypterer han på nytt og sender han ut gjennom det ytre grensesnittet mot avdelinga.

Adressene nedanfor er illustrative, men forma er viktig: kjelda er bassenget, ikkje det interne LAN-et til ASA-en.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

To ting følgjer. Klienten treng ei rute til avdelingsprefikset via fjernaksess-tilkoplinga si, noko som betyr at split-tunnel eller den dytta ruttelista må innehalde ho. Og avdelinga må vite korleis ho returnerer trafikk til 10.77.0.20 eller til den adressa NAT-designet ditt erstatta ho med.

Hairpin-løyve er globalt

Kommandoen folk grip til, er same-security-traffic permit intra-interface. Han lèt trafikk gå inn og ut gjennom det same grensesnittet, som er nøyaktig det denne vegen treng. Han er også ei global innstilling: å slå han på endrar åtferda til andre flytar som tilfeldigvis passerer det same grensesnittet to gonger.

Derfor høyrer han heime i ein endringslogg og ikkje i ei feilsøkingsøkt. Spør kva anna på boksen som no kan ta ein veg gjennom det same grensesnittet, og om noko av det burde gjere det. På ein travel kant med gjestenettverk eller overlappande partnartunnelar er svaret ikkje automatisk nei. Skriv grunngjevinga ved sida av innstillinga, for den neste ingeniøren finn kommandoen og ikkje samtalen.

Vernomfang og NAT er skilde

Tunnelen frå stad til stad vernar det crypto ACL-en vel. Viss den ACL-en namngjev det interne subnettet til ASA-en som kjelde, er fjernaksessbassenget ikkje verna, og pakken vil anten bli droppa eller send i klartekst, avhengig av åtferda til plattforma for trafikk som ikkje matchar. Legg bassenget til den verna flyten når designet bevarer bassengadresser.

Deretter avgjer NAT om bassengadressa overlever. Identity NAT held på ho, og avdelinga ser 10.77.0.20 som kjelde. Omsetjing endrar kontrakten: avdelinga returnerer no trafikk til den omsette adressa, og hennar eigen policy må godta det. Regelrekkefølgja avgjer om crypto ACL-en matchar før eller etter omsetjinga, så les den effektive flyten i staden for å anta kven som vinn.

Ikkje slett dei generelle internett-PAT-reglane for å få eitt transitt-tilfelle til å fungere. Eit målretta unntak eller ein medviten identity-regel er lettare å forklare og å reversere enn eit hol i den utgåande policyen.

Kryptering er ikkje autorisasjon

Ein fungerande tunnel beviser berre at to partar er samde om nøklar og selektorar. Han seier ingenting om korvidt denne brukaren kan nå den tenesta. VPN-filteret eller gruppepolicyen som er knytt til fjernaksess-tilkoplinga, må framleis tillate målet og porten til avdelinga, og grensesnitt-ACL-en på den ytre vegen gjeld framleis.

Test svaret i båe retningar. Ei tilkopling som lykkast medan ei naboteneste burde feile, er meir informativ enn ein vellykka ping, fordi ho viser at policyen er selektiv og ikkje vidopen. Viss testen som skulle vore nekta lykkast, er det ikkje tunnelen som er skulda; det er policyen. Ta vare på båe resultata i endringsloggen slik at neste person veit kva åtferd som var tilsikta.

Hairpin eller eit andre grensesnitt

Hairpin-transitt held designet lite og kostar éi global innstilling. Eit separat grensesnitt, eller ein rutebasert tunnel med sitt eige virtuelle grensesnitt, isolerer transittvegen og gjev deg policy per grensesnitt, mot kostnaden av adressering og endå eit crypto map eller profil. Ingen av dei er meir rette; dei feilar på ulike måtar.

Rutebaserte design er ei anna ordning, ikkje ein avkrysningsboks i den same konfigurasjonen. Viss du går over til eit slikt, sluttar diskusjonen ovanfor om policybasert crypto ACL å gjelde, og rutetabellen byrjar å gjere utvalsarbeidet.

Stadfest frå den verkelege klienten

Ein probe starta frå ASA-en har ei anna kjeldeadresse og vil ikkje gjennomgå vegen frå bassenget til avdelinga. Bruk packet-tracer for å kontrollere fem-tuppelen, og opne deretter ei ekte tilkopling frå den faktiske eksterne klienten, fordi sporinga simulerer og erstattar ikkje klienten si eiga ruting og policy.

Etter ei planlagd endring, kople til ei teneste som burde fungere, deretter til ei som burde bli nekta, og stadfest så returruta til avdelinga. Cisco sine døme på VPN-hairpin-NAT held intra-interface-løyve, NAT og ACL-ar synleg skilde, og det er den mentale modellen som er verd å kopiere.