ASA VPN hairpin: rute to tunneler gjennom ett grensesnitt

En ekstern bruker kobler til ASA-en, ber om en vert bak en filial, og ASA-en sender den forespørselen ut gjennom nøyaktig det grensesnittet brukeren kom inn på. Ingenting ved det krever en andre fysisk port. Det som kreves, er fire uavhengige beslutninger som folk har en tendens til å slå sammen til én: tillatelse til å gjøre hairpin, en tunnel som beskytter de riktige adressene, en NAT-policy som bevarer kilden du lovet, og en tilgangspolicy som autoriserer tjenesten.

Én pakke, to tunneler

Følg flyten, og rekkefølgen av operasjoner slutter å være mystisk. Pakken ankommer inne i fjernaksess-tunnelen, dekrypteres og blir en vanlig IP-pakke med kilde fra klientpoolen. Deretter ruter ASA-en den, matcher den mot crypto ACL-en fra område til område, krypterer den på nytt og sender den ut gjennom det ytre grensesnittet mot filialen.

Adressene nedenfor er illustrative, men formen er viktig: kilden er poolen, ikke ASA-ens interne LAN.

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ølger. Klienten trenger en rute til filialprefikset via sin fjernaksessforbindelse, noe som betyr at split-tunnel eller den dyttede ruttelisten må inneholde den. Og filialen må vite hvordan den returnerer trafikk til 10.77.0.20 eller til den adressen NAT-designet ditt erstattet den med.

Hairpin-tillatelse er global

Kommandoen folk griper til, er same-security-traffic permit intra-interface. Den lar trafikk gå inn og ut gjennom det samme grensesnittet, som er nøyaktig det denne veien trenger. Den er også en global innstilling: å aktivere den endrer oppførselen til andre flyter som tilfeldigvis passerer det samme grensesnittet to ganger.

Derfor hører den hjemme i en endringslogg og ikke i en feilsøkingsøkt. Spør hva annet på boksen som nå kan ta en vei gjennom det samme grensesnittet, og om noe av det burde gjøre det. På en travel kant med gjestenettverk eller overlappende partnertunneler er svaret ikke automatisk nei. Skriv begrunnelsen ved siden av innstillingen, for den neste ingeniøren finner kommandoen og ikke samtalen.

Beskyttelsesomfang og NAT er atskilt

Tunnelen fra område til område beskytter det crypto ACL-en velger. Hvis den ACL-en navngir ASA-ens interne subnett som kilde, er fjernaksesspoolen ikke beskyttet, og pakken vil enten bli droppet eller sendt i klartekst, avhengig av plattformens oppførsel for trafikk som ikke matcher. Legg poolen til den beskyttede flyten når designet bevarer pooladresser.

Deretter avgjør NAT om pooladressen overlever. Identity NAT beholder den, og filialen ser 10.77.0.20 som kilde. Oversetting endrer kontrakten: filialen returnerer nå trafikk til den oversatte adressen, og dens egen policy må godta det. Regelrekkefølgen avgjør om crypto ACL-en matcher før eller etter oversettingen, så les den effektive flyten i stedet for å anta hvilken som vinner.

Ikke slett de generelle internett-PAT-reglene for å få ett transittilfelle til å fungere. Et målrettet unntak eller en bevisst identity-regel er lettere å forklare og å reversere enn et hull i den utgående policyen.

Kryptering er ikke autorisasjon

En fungerende tunnel beviser bare at to parter er enige om nøkler og selektorer. Den sier ingenting om hvorvidt denne brukeren kan nå den tjenesten. VPN-filteret eller gruppepolicyen som er knyttet til fjernaksessforbindelsen, må fortsatt tillate filialens mål og port, og grensesnitt-ACL-en på den ytre veien gjelder fortsatt.

Test svaret i begge retninger. En forbindelse som lykkes mens en nabotjeneste burde feile, er mer informativ enn én vellykket ping, fordi den viser at policyen er selektiv og ikke vidåpen. Hvis testen som skulle vært nektet lykkes, er det ikke tunnelen som er skylden; det er policyen. Ta vare på begge resultatene i endringsloggen slik at neste person vet hvilken oppførsel som var tilsiktet.

Hairpin eller et andre grensesnitt

Hairpin-transitt holder designet lite og koster én global innstilling. Et separat grensesnitt, eller en rutebasert tunnel med sitt eget virtuelle grensesnitt, isolerer transittveien og gir deg policy per grensesnitt, mot kostnaden av adressering og enda et crypto map eller profil. Ingen av dem er mer riktig; de feiler på forskjellige måter.

Rutebaserte design er en annen ordning, ikke en avkrysningsboks i den samme konfigurasjonen. Hvis du går over til et slikt, slutter diskusjonen ovenfor om policybasert crypto ACL å gjelde, og rutetabellen begynner å gjøre utvelgelsesarbeidet.

Verifiser fra den virkelige klienten

En probe startet fra ASA-en har en annen kildeadresse og vil ikke gjennomgå veien fra poolen til filialen. Bruk packet-tracer for å kontrollere fem-tuppelen, og åpne deretter en ekte forbindelse fra den faktiske eksterne klienten, fordi sporingen simulerer og ikke erstatter klientens egen ruting og policy.

Etter en planlagt endring, koble til en tjeneste som burde fungere, deretter til en som burde bli nektet, og bekreft så filialens returrute. Ciscos eksempler på VPN-hairpin-NAT holder intra-interface-tillatelse, NAT og ACL-er synlig atskilt, og det er den mentale modellen som er verdt å kopiere.