ASA VPN hairpin: rut to tunneler gennem én grænseflade

En fjernbruger forbinder til ASA'en, beder om en vært bag en filial, og ASA'en sender den anmodning ud ad netop den grænseflade, som brugeren ankom på. Intet ved det kræver en ekstra fysisk port. Det, der kræves, er fire uafhængige beslutninger, som folk har en tendens til at slå sammen til én: tilladelse til hairpin, en tunnel der beskytter de rigtige adresser, en NAT-politik der bevarer den kilde, du lovede, og en adgangspolitik der godkender tjenesten.

Én pakke, to tunneler

Følg flowet, og rækkefølgen af operationer holder op med at være mystisk. Pakken ankommer inde i fjernadgangstunnelen, dekrypteres og bliver en almindelig IP-pakke med kilde i klientpuljen. ASA'en ruter den derefter, matcher den mod site-til-site crypto ACL, krypterer den igen og sender den ud ad den ydre grænseflade mod filialen.

Adresserne nedenfor er illustrative, men formen er vigtig: kilden er puljen, 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 har brug for en rute til filialpræfikset gennem sin fjernadgangsforbindelse, hvilket betyder, at split-tunnel eller den skubbede rutteliste skal indeholde den. Og filialen skal vide, hvordan den returnerer trafik til 10.77.0.20 eller til den adresse, dit NAT-design har erstattet den med.

Hairpin-tilladelse er global

Den kommando, folk griber efter, er same-security-traffic permit intra-interface. Den tillader trafik at komme ind og ud ad den samme grænseflade, hvilket er præcis, hvad denne vej har brug for. Den er også en global indstilling: når du aktiverer den, ændres adfærden for andre flows, der tilfældigvis passerer den samme grænseflade to gange.

Derfor hører den til i en ændringsrecord frem for i en fejlfindingssession. Spørg, hvad der ellers på boksen nu kan tage en vej gennem den samme grænseflade, og om noget af det burde. På en travl edge med gæstenetværk eller overlappende partnertunneler er svaret ikke automatisk nej. Skriv begrundelsen ved siden af indstillingen, for den næste ingeniør finder kommandoen og ikke samtalen.

Beskyttelsesomfang og NAT er adskilte

Site-til-site-tunnelen beskytter det, som dens crypto ACL udvælger. Hvis den ACL angiver ASA'ens interne subnet som kilde, er fjernadgangspuljen ikke beskyttet, og pakken vil enten blive droppet eller sendt i klartekst, afhængigt af platformens adfærd for trafik uden match. Tilføj puljen til det beskyttede flow, når designet bevarer puljeadresser.

NAT afgør derefter, om puljeadressen overlever. Identity NAT bevarer den, og filialen ser 10.77.0.20 som kilde. Oversættelse ændrer kontrakten: filialen returnerer nu trafik til den oversatte adresse, og dens egen politik skal acceptere det. Regelrækkefølgen afgør, om crypto ACL matcher før eller efter oversættelsen, så læs det effektive flow i stedet for at antage, hvilken der vinder.

Slet ikke de generelle internet-PAT-regler for at få ét transitstilfælde til at virke. En målrettet undtagelse eller en bevidst identity-regel er lettere at forklare og at rulle tilbage end et hul i den udgående politik.

Kryptering er ikke autorisation

En fungerende tunnel beviser kun, at to parter er enige om nøgler og selektorer. Den siger intet om, hvorvidt denne bruger må nå den tjeneste. VPN-filteret eller gruppepolitikken, der er knyttet til fjernadgangsforbindelsen, skal stadig tillade filialens destination og port, og grænseflade-ACL'en på den ydre vej gælder stadig.

Test svaret i begge retninger. En forbindelse, der lykkes, mens en nabotjeneste burde fejle, er mere informativ end et enkelt vellykket ping, fordi det viser, at politikken er selektiv og ikke vidt åben. Hvis den afviste test lykkes, er det ikke tunnelen, der er skylden; det er politikken. Gem begge resultater i ændringsrecorden, så den næste person ved, hvilken adfærd der var tilsigtet.

Hairpin eller en anden grænseflade

Hairpin-transit holder designet lille og koster én global indstilling. En separat grænseflade eller en rutebaseret tunnel med sin egen virtuelle grænseflade isolerer transitvejen og giver dig politik pr. grænseflade, til gengæld for adressering og endnu et crypto map eller profil. Ingen af dem er mere korrekte; de fejler på forskellige måder.

Rutebaserede designs er et andet arrangement, ikke et afkrydsningsfelt i den samme konfiguration. Hvis du skifter til et, holder diskussionen ovenfor om politikbaseret crypto ACL op med at gælde, og rutetabellen begynder at gøre udvælgelsesarbejdet.

Verificér fra den rigtige klient

En probe startet fra ASA'en har en anden kildeadresse og vil ikke gennemløbe vejen fra puljen til filialen. Brug packet-tracer til at kontrollere fem-tuppelen, og åbn derefter en rigtig forbindelse fra den faktiske fjernklient, fordi traceren simulerer og ikke erstatter klientens egen routing og politik.

Efter en planlagt ændring, opret forbindelse til en tjeneste, der burde virke, derefter til en, der burde afvises, og bekræft så filialens returrute. Ciscos eksempler på VPN hairpin-NAT holder intra-interface-tilladelse, NAT og ACL'er synligt adskilte, og det er den mentale model, der er værd at kopiere.