Hvorfor din split-tunnel-regel holdt op med at matche en tjeneste

Split-tunneling svigter normalt på en af to måder. Enten går trafik, som burde være inde i tunnelen, uden om den, eller trafik, som skulle blive udenfor, bliver trukket ind. Fejlen med den forældede regel er den første slags, og det er den mest forvirrende, fordi reglen håndhæves præcis som skrevet. Det, der ændrede sig, er destinationen: tjenesten svarer nu på en adresse, som reglen aldrig nævnte, og der er intet galt i tunnelen.

Hvad reglen fastholder, og hvad DNS returnerer

En split-tunnel-regel er en statisk udtalelse om destinationer, normalt udtrykt som et præfiks, en rute eller en adresseliste. Den vurderes mod pakkens destination på afsendelsestidspunktet. Et værtsnavn er et opslag, der returnerer et sæt adresser med en levetid og en cache, og svaret kan variere efter resolver, forespørgselstype og minut.

De to objekter forhandler aldrig med hinanden. Reglen bliver ved med at matche det præfiks, den fik, tjenesten bliver ved med at ændre den adresse, den udleverer, og kløften mellem dem vokser lydløst. Derfor viser symptomet sig efter en udbyderflytning eller en certifikatfornyelse og ikke efter en konfigurationsændring. Ingen redigerede tunnelen, så ingen kigger på tunnelen, og diagnosen glider mod applikationen i stedet for politikken.

Tre måder, matchet brækker på

Det oplagte tilfælde er en flyttet tjeneste: operatøren gav den en ny adresse, DNS fulgte efter, og undtagelsen gjorde ikke. Det andet er en adressefamilie, som reglen aldrig dækkede, hvilket sker, når et navn begynder at returnere AAAA-poster, som en undtagelse kun for IPv4 ignorerer. Det tredje er en resolverforskel: en intern visning og en offentlig visning kan returnere forskellige adresser for samme navn, så den adresse, din app bruger, er ikke den, du testede med.

En cached forbindelse er en fjerde variant, og den er let at overse. Applikationen taler måske stadig med en adresse, den slog op for en time siden, hvilket betyder, at dit friske opslag og dens åbne socket er uenige om, hvor tjenesten bor.

Læs den destination, appen faktisk bruger

Spørg operativsystemet og socket-tabellen, ikke en browserfane. Opslaget svarer på, hvad navnet opløses til lige nu, og socket-tabellen viser den adresse, processen er forbundet til, som kan være ældre. Kør begge, før du danner en teori, fordi forskellen mellem dem i sig selv er svaret i cirka halvdelen af tilfældene.

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

Sammenlign derefter med det, reglen dækker. Hvis den aktuelle adresse falder uden for undtagelsen, og anmodningen stadig fejler, har du fundet årsagen uden at røre tunnelkonfigurationen. Hvis appen er forbundet til en adresse, der matcher reglen, og anmodningen stadig fejler, ligger problemet et sted efter tunnelen, og det er den forkerte undersøgelse.

Reparer mekanismen, ikke symptomet

Hvis produktet understøtter vedligeholdt domænebaseret styring, så brug det og følg dets dokumenterede opdaterings- og omfangsadfærd. Det erstatter et statisk gæt med et vedligeholdt svar, til prisen af at afhænge af, at funktionen virker som dokumenteret.

Hvis designet hviler på en statisk liste, så giv den en ejer og en opdateringsplan. Planen bør sige, hvordan adressen findes, hvem der godkender ændringen, og hvor hurtigt listen forventes at følge en udbyderflytning. En liste uden ejer er et fremtidigt nedbrud med en kendt årsag.

Udvid ikke undtagelsen til et stort nabonetværk bare for at fange hver adresse, du så under en kort test. Det er ikke en reparation; det er en permanent ændring af sikkerhedsgrænsen, og den vil lydløst lade uvedkommende tjenester omgå tunnelen, så længe reglen findes.

Bekræft begge halvdele af hensigten

Et split-tunnel-design har to hensigter, og en reparation bør bevare begge. Den beskyttede tjeneste skal gennem tunnelen, og de udelukkede kategorier skal fortsat gå uden om den. Test en frisk forbindelse til den reparerede destination, og test derefter en ting, der skal blive udenfor.

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'

Notér den nye adresse, den valgte mekanisme og datoen. Den note er det, der forhindrer den næste person i at konkludere, at VPN'en tilfældigt ignorerede sin egen konfiguration.