Split-tunnel befriar inte en offentlig värd från ASA:ns NAT-regler

Split-tunnel beskrivs vanligtvis som ett sätt att hålla företagstrafik inne i tunneln och resten av internet utanför brandväggen. Båda halvorna av den beskrivningen är fel på samma sätt. Split-tunnel är ett routingsbeslut som klienten fattar, och ett routingsbeslut säger ingenting om vad som händer med paketet efter att det når headend.

En enda partnertjänst på en offentlig adress, som insisterar på att se adressen till ditt huvudkontor, räcker för att välta historien.

Myten: split-tunnel tar bort brandväggen från vägen

Tron är att varje destination utanför de privata områdena stannar på den lokala internetanslutningen, så brandväggen ser den aldrig och behöver aldrig en regel för den. Det gäller bara så länge destinationen inte står i tunnellistan. I samma stund som en operatör lägger till en offentlig värd i split-include-ACL:n skickar klienten trafiken in i tunneln, och ASA:n måste routa, filtrera och översätta den som vilket annat dekrypterat flöde som helst. På klienten har ingenting ändrats utom destinationslistan.

Klienten blev inte en router. Den följde policyn du gav den.

Vad en split-include-rutt faktiskt gör

I en Cisco ASA-installation för fjärråtkomst bär gruppolicyn split-tunnel-policy tunnelspecified och en split-tunnel-network-list som namnger en standard-ACL. Varje permit-rad i den ACL:n är en destination som klienten ska skicka in i tunneln, och allt annat fortsätter använda den lokala standardrutten.

Att lägga till en värd är en enda rad, och det är den enda delen av ändringen som klienten kan se: access-list RA-SPLIT standard permit host 203.0.113.20.

Anslut klienten igen efteråt. Policyn byts ut vid anslutning, så en etablerad session behåller den gamla listan och får ändringen att se ut som om den inte gjorde något.

Paketet kommer in och går ut på samma gränssnitt

Följ nu flödet efter dekryptering. Paketet kom in på det yttre gränssnittet genom VPN-tunneln, dess destination är en offentlig adress, och routingtabellen skickar ut det igen genom samma yttre gränssnitt mot internet. Trafik som kommer in och går ut på ett gränssnitt släpps om ASA:n inte får tillåta det, och det är vad same-security-traffic permit intra-interface gör. Utan det misslyckas anslutningen på ett sätt som ser ut som ett routingproblem men inte är det.

Den inställningen är global. Den tillåter hairpinning för varje flöde som behöver det, inte bara för den här partnervärden, så den hör hemma i en granskad ändring och inte i ett snabbtest.

Varför en destinationsbegränsad PAT inte är valfri

Källadressen på det dekrypterade paketet är fortfarande klientens VPN-adress, vanligtvis från en pool som 10.77.0.0/24. Den adressen har ingen rutt på det offentliga internet, så partnern svarar antingen aldrig eller svarar i tomma intet.

Översättningen rättar källan och lämnar destinationen orörd. Eftersom objekten redan är definierade någon annanstans har en manuell regel begränsad till den här destinationen den här formen:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

Delen destination static spelar roll. Om du utelämnar den blir regeln en bred översättning som kan matcha långt mer trafik än avsett, och en bred identity-regel tidigare i ordningen kan slå den helt. Kontrollera show nat detail och ordningen på avsnitten innan du antar att din regel är den som matchar.

Interface-PAT innebär också att partnern ser ASA:ns gränssnittsadress, som kan översättas igen längre upp. Om avtalet namnger en adress, bekräfta den från ände till ände i stället för vid ett enda hopp.

Bevisa det med rätt testdestination

Använd partnervärden själv, inte en generisk what-is-my-ip-sida. Den sidan ligger nästan säkert utanför split-listan, så den rapporterar din lokala internetadress och säger ingenting om den här vägen. Öppna en ny anslutning till partnertjänsten och fråga vilken källa de såg, eller kör packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed och läs NAT- och routingstegen rad för rad. En traceroute från klienten är en svagare kontroll, eftersom den visar vägen som redan har hänt och inte policyn som valde den.

Kontrollera sedan vad som inte får ändras. En vanlig webbplats måste fortfarande gå ut över den lokala anslutningen, och en privat resurs i tunnellistan måste fortfarande vara nåbar. En ändring som lagar partnern och bryter något av de två är en annan bugg.

Den fungerande versionen av den här designen är kort: en värd i split-ACL:n, hairpin-tillstånd, en destinationsbegränsad PAT-regel. Allt annat i historien är myten.