Hvorfor split-tunnel-regelen din sluttet å matche en tjeneste

Regelen låser et prefiks, og tjenesten har flyttet seg. Les destinasjonen appen faktisk bruker, og reparer deretter mekanismen i stedet for å utvide unntaket.

Split-tunneling feiler vanligvis på en av to måter. Enten går trafikk som skal være inne i tunnelen utenom den, eller trafikk som skal holde seg utenfor blir trukket inn. Feilen med den utdaterte regelen er den første typen, og den er den mest forvirrende, fordi regelen håndheves nøyaktig som skrevet. Det som har endret seg, er destinasjonen: tjenesten svarer nå på en adresse regelen aldri navnga, og ingenting i tunnelen er galt.

Hva regelen låser og hva DNS returnerer

En split-tunnel-regel er en statisk uttalelse om destinasjoner, vanligvis uttrykt som et prefiks, en rute eller en adresseliste. Den vurderes mot pakkens destinasjon ved sending. Et vertsnavn er et oppslag som returnerer et sett med adresser med levetid og cache, og svaret kan variere etter resolver, etter spørringstype og etter minutt.

Disse to objektene forhandler aldri med hverandre. Regelen fortsetter å matche prefikset den fikk, tjenesten fortsetter å endre adressen den deler ut, og gapet mellom dem vokser stille. Derfor dukker symptomet opp etter en leverandørmigrering eller en sertifikatfornyelse og ikke etter en konfigurasjonsendring. Ingen redigerte tunnelen, så ingen ser på tunnelen, og diagnosen driver mot applikasjonen i stedet for policyen.

Tre måter matchen brytes på

Det åpenbare tilfellet er en flyttet tjeneste: operatøren ga den en ny adresse, DNS fulgte etter, og unntaket gjorde det ikke. Det andre er en adressefamilie regelen aldri dekket, noe som skjer når et navn begynner å returnere AAAA-poster som et unntak kun for IPv4 ignorerer. Det tredje er en resolverforskjell: en intern visning og en offentlig visning kan returnere forskjellige adresser for samme navn, så adressen appen din bruker er ikke den du testet med.

En bufret tilkobling er en fjerde variant, og den er lett å overse. Applikasjonen kan fortsatt snakke med en adresse den slo opp for en time siden, noe som betyr at det ferske oppslaget ditt og dens åpne socket er uenige om hvor tjenesten bor.

Les destinasjonen appen faktisk bruker

Spør operativsystemet og socket-tabellen, ikke en nettleserfane. Oppslaget svarer på hva navnet løses til akkurat nå, og socket-tabellen viser adressen prosessen er koblet til, som kan være eldre. Kjør begge før du danner en teori, fordi forskjellen mellom dem i seg selv er svaret i omtrent halvparten av tilfellene.

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 deretter med det regelen dekker. Hvis gjeldende adresse faller utenfor unntaket og forespørselen fortsatt feiler, har du funnet årsaken uten å røre tunnelkonfigurasjonen. Hvis appen er koblet til en adresse som samsvarer med regelen og forespørselen fortsatt feiler, ligger problemet et sted forbi tunnelen, og dette er feil undersøkelse.

Reparer mekanismen, ikke symptomet

Hvis produktet støtter vedlikeholdt domenebasert styring, bruk det og følg den dokumenterte oppdaterings- og omfangsatferden. Det erstatter en statisk gjetning med et vedlikeholdt svar, mot prisen av å avhenge av at funksjonen virker som dokumentert.

Hvis designet hviler på en statisk liste, gi den en eier og en oppdateringsplan. Planen bør si hvordan adressen oppdages, hvem som godkjenner endringen og hvor raskt listen forventes å følge en leverandørmigrering. En liste uten eier er et framtidig avbrudd med en kjent årsak.

Ikke utvid unntaket til et stort nabonett bare for å fange hver adresse du så under en kort test. Det er ikke en reparasjon; det er en permanent endring av sikkerhetsgrensen, og den vil stille la urelaterte tjenester omgå tunnelen så lenge regelen finnes.

Bekreft begge halvdeler av intensjonen

Et split-tunnel-design har to intensjoner, og en reparasjon bør bevare begge. Den beskyttede tjenesten må gå gjennom tunnelen, og de utelukkede kategoriene må fortsette å gå utenom den. Test en fersk tilkobling til den reparerte destinasjonen, og test deretter noe som skal holde seg utenfor.

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'

Noter den nye adressen, mekanismen du valgte og datoen. Det notatet er det som hindrer neste person i å konkludere med at VPN-en tilfeldigvis ignorerte sin egen konfigurasjon.

Relaterte artikler