ASA VPN hairpin: routa två tunnlar genom ett enda gränssnitt

En fjärranvändare ansluter till ASA:n, begär en värd bakom en filial, och ASA:n skickar den begäran ut genom exakt det gränssnitt som användaren kom in på. Inget av det kräver en andra fysisk port. Det som krävs är fyra oberoende beslut som människor tenderar att slå ihop till ett: tillstånd att göra hairpin, en tunnel som skyddar rätt adresser, en NAT-princip som bevarar den källa du lovade, och en åtkomstprincip som auktoriserar tjänsten.

Ett paket, två tunnlar

Följ flödet och ordningen på operationerna slutar vara mystisk. Paketet anländer inne i fjärråtkomsttunneln, dekrypteras och blir ett vanligt IP-paket med källa från klientpoolen. ASA:n routar det sedan, matchar det mot crypto ACL:n från plats till plats, krypterar det igen och skickar det ut genom det yttre gränssnittet mot filialen.

Adresserna nedan är illustrativa, men formen spelar roll: källan är poolen, inte ASA:ns interna 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

Två saker följer. Klienten behöver en rutt för filialprefixet via sin fjärråtkomstanslutning, vilket betyder att split-tunnel eller den pushade ruttlistan måste innehålla den. Och filialen måste veta hur den returnerar trafik till 10.77.0.20 eller till den adress som din NAT-design ersatte den med.

Hairpin-tillståndet är globalt

Kommandot folk sträcker sig efter är same-security-traffic permit intra-interface. Det låter trafik gå in och ut genom samma gränssnitt, vilket är precis vad den här vägen behöver. Det är också en global inställning: att aktivera det ändrar beteendet för andra flöden som råkar passera samma gränssnitt två gånger.

Därför hör det hemma i ett ändringsprotokoll och inte i en felsökningssession. Fråga vad annat på enheten som nu kan ta en väg genom samma gränssnitt, och om något av det borde. På en trafikerad kant med gästnätverk eller överlappande partnertunnlar är svaret inte automatiskt nej. Skriv skälet bredvid inställningen, för nästa ingenjör hittar kommandot och inte samtalet.

Skyddsomfång och NAT är åtskilda

Tunneln från plats till plats skyddar det som dess crypto ACL väljer. Om den ACL:n anger ASA:ns interna subnät som källa är fjärråtkomstpoolen inte skyddad och paketet kommer antingen att släppas eller skickas i klartext, beroende på plattformens beteende för trafik som inte matchar. Lägg till poolen i det skyddade flödet när designen bevarar pooladresser.

Sedan avgör NAT om pooladressen överlever. Identity NAT behåller den, och filialen ser 10.77.0.20 som källa. Översättning ändrar kontraktet: filialen returnerar nu trafik till den översatta adressen, och dess egen princip måste acceptera det. Regelordningen avgör om crypto ACL:n matchar före eller efter översättningen, så läs det faktiska flödet i stället för att anta vilken som vinner.

Ta inte bort de allmänna internet-PAT-reglerna för att få ett enda transitfall att fungera. Ett riktat undantag eller en medveten identity-regel är lättare att förklara och att återställa än ett hål i den utgående principen.

Kryptering är inte auktorisering

En fungerande tunnel bevisar bara att två parter är överens om nycklar och selektorer. Den säger ingenting om huruvida den här användaren får nå den tjänsten. VPN-filtret eller grupprincipen som är kopplad till fjärråtkomstanslutningen måste fortfarande tillåta filialens destination och port, och gränssnittets ACL på den yttre vägen gäller fortfarande.

Testa svaret i båda riktningarna. En anslutning som lyckas medan en närliggande tjänst borde misslyckas är mer informativ än en enda lyckad ping, eftersom den visar att principen är selektiv och inte vidöppen. Om testet som borde nekas lyckas är det inte tunneln som är skyldig, utan principen. Spara båda resultaten i ändringsprotokollet så att nästa person vet vilket beteende som var avsiktligt.

Hairpin eller ett andra gränssnitt

Hairpin-transit håller designen liten och kostar en global inställning. Ett separat gränssnitt, eller en ruttbaserad tunnel med sitt eget virtuella gränssnitt, isolerar transitvägen och ger dig princip per gränssnitt, till priset av adressering och ännu en crypto map eller profil. Ingen av dem är mer korrekt; de misslyckas olika.

Ruttbaserade designer är ett annat arrangemang, inte en kryssruta i samma konfiguration. Om du byter till en sådan slutar diskussionen ovan om principbaserad crypto ACL att gälla och routingtabellen börjar göra urvalsarbetet.

Verifiera från den riktiga klienten

En probe som startas från ASA:n har en annan källadress och kommer inte att genomlöpa vägen från poolen till filialen. Använd packet-tracer för att kontrollera fem-tuppeln och öppna sedan en riktig anslutning från den faktiska fjärrklienten, eftersom spåraren simulerar och inte ersätter klientens egen routing och princip.

Efter en planerad ändring, anslut till en tjänst som borde fungera, sedan till en som borde nekas, och bekräfta därefter filialens returväg. Ciscos exempel på VPN-hairpin-NAT håller intra-interface-tillstånd, NAT och ACL:er synligt åtskilda, och det är den mentala modell som är värd att kopiera.