Varför din split-tunnel-regel slutade matcha en tjänst

Split-tunneling misslyckas vanligtvis på ett av två sätt. Antingen går trafik som borde vara inne i tunneln runt den, eller så dras trafik som borde stanna utanför in. Felet med den inaktuella regeln är den första sorten, och det är den mer förvirrande, eftersom regeln tillämpas exakt som den är skriven. Det som ändrades är destinationen: tjänsten svarar nu på en adress som regeln aldrig namngav, och ingenting i tunneln är fel.

Vad regeln låser och vad DNS returnerar

En split-tunnel-regel är ett statiskt påstående om destinationer, vanligtvis uttryckt som ett prefix, en rutt eller en adresslista. Den utvärderas mot paketets destination vid sändning. Ett värdnamn är en uppslagning som returnerar en uppsättning adresser med en livstid och en cache, och svaret kan variera beroende på resolver, frågetyp och minut.

Dessa två objekt förhandlar aldrig med varandra. Regeln fortsätter att matcha prefixet den fick, tjänsten fortsätter att ändra adressen den delar ut, och gapet mellan dem växer tyst. Det är därför symptomet dyker upp efter en leverantörsmigrering eller en certifikatförnyelse och inte efter en konfigurationsändring. Ingen redigerade tunneln, så ingen tittar på tunneln, och diagnosen glider mot applikationen i stället för policyn.

Tre sätt som matchningen går sönder

Det uppenbara fallet är en flyttad tjänst: operatören gav den en ny adress, DNS följde efter, och undantaget gjorde det inte. Det andra är en adressfamilj som regeln aldrig täckte, vilket händer när ett namn börjar returnera AAAA-poster som ett undantag bara för IPv4 ignorerar. Det tredje är en resolver-skillnad: en intern och en offentlig vy kan returnera olika adresser för samma namn, så adressen som din app använder är inte den du testade med.

En cachad anslutning är en fjärde variant och den är lätt att missa. Applikationen kan fortfarande tala med en adress som den löste för en timme sedan, vilket innebär att din färska uppslagning och dess öppna socket inte är överens om var tjänsten bor.

Läs destinationen som appen faktiskt använder

Fråga operativsystemet och socket-tabellen, inte en webbläsarflik. Uppslagningen svarar på vad namnet löses till just nu, och socket-tabellen visar adressen som processen är ansluten till, som kan vara äldre. Kör båda innan du bildar en teori, eftersom skillnaden mellan dem i sig är svaret i ungefär hälften av fallen.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Jämför sedan med vad regeln täcker. Om den aktuella adressen faller utanför undantaget och begäran fortfarande misslyckas, har du hittat orsaken utan att röra tunnelkonfigurationen. Om appen är ansluten till en adress som matchar regeln och begäran fortfarande misslyckas, ligger problemet någonstans bortom tunneln och detta är fel utredning.

Reparera mekanismen, inte symptomet

Om produkten stöder underhållen domänbaserad styrning, använd den och följ dess dokumenterade uppdaterings- och omfångsbeteende. Det ersätter en statisk gissning med ett underhållet svar, till priset av att bero på att funktionen fungerar som dokumenterat.

Om designen vilar på en statisk lista, ge den en ägare och en uppdateringsplan. Planen bör säga hur adressen upptäcks, vem som godkänner ändringen och hur snabbt listan förväntas följa en leverantörsmigrering. En lista utan ägare är ett framtida avbrott med en känd orsak.

Utöka inte undantaget till ett stort närliggande nätverk bara för att fånga varje adress du såg under ett kort test. Det är inte en reparation; det är en permanent ändring av säkerhetsgränsen, och den kommer tyst att låta orelaterade tjänster kringgå tunneln så länge regeln finns.

Verifiera båda halvorna av avsikten

En split-tunnel-design har två avsikter, och en reparation bör bevara båda. Den skyddade tjänsten måste gå genom tunneln, och de uteslutna kategorierna måste fortsätta gå runt den. Testa en färsk anslutning till den reparerade destinationen och testa sedan något som ska stanna utanför.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Anteckna den nya adressen, mekanismen du valde och datumet. Den anteckningen är det som hindrar nästa person från att dra slutsatsen att VPN:en slumpmässigt ignorerade sin egen konfiguration.