Kvifor split-tunnelregelen din slutta å samsvara med ei teneste

Regelen låser eit prefiks, og tenesta har flytt seg. Les destinasjonen appen faktisk brukar, og reparer deretter mekanismen i staden for å utvide unntaket.

Split-tunneling feilar vanlegvis på ein av to måtar. Anten går trafikk som skal vere inne i tunnelen utanom han, eller trafikk som skal halde seg utanfor blir dregen inn. Feilen med den utdaterte regelen er den første typen, og han er den mest forvirrande, fordi regelen blir handheva nøyaktig som skriven. Det som har endra seg, er destinasjonen: tenesta svarar no på ei adresse regelen aldri namngav, og ingenting i tunnelen er gale.

Kva regelen låser og kva DNS returnerer

Ein split-tunnelregel er ei statisk utsegn om destinasjonar, vanlegvis uttrykt som eit prefiks, ei rute eller ei adresseliste. Han blir vurdert mot pakken sin destinasjon ved sending. Eit vertsnamn er eit oppslag som returnerer eit sett med adresser med levetid og cache, og svaret kan variere etter resolver, etter spørjingstype og etter minutt.

Desse to objekta forhandlar aldri med kvarandre. Regelen held fram med å matche prefikset han fekk, tenesta held fram med å endre adressa ho deler ut, og gapet mellom dei veks stille. Derfor dukkar symptomet opp etter ei leverandørmigrering eller ei sertifikatfornying og ikkje etter ei konfigurasjonsendring. Ingen redigerte tunnelen, så ingen ser på tunnelen, og diagnosen driv mot applikasjonen i staden for policyen.

Tre måtar matchen bryt saman på

Det openberre tilfellet er ei flytta teneste: operatøren gav henne ei ny adresse, DNS følgde etter, og unntaket gjorde det ikkje. Det andre er ein adressefamilie regelen aldri dekte, noko som skjer når eit namn byrjar å returnere AAAA-poster som eit unntak berre for IPv4 ignorerer. Det tredje er ein resolverforskjell: ein intern og ein offentleg vising kan returnere ulike adresser for same namn, så adressa appen din brukar er ikkje den du testa med.

Ei bufd tilkobling er ein fjerde variant, og han er lett å oversjå. Applikasjonen kan framleis snakke med ei adresse han slo opp for ein time sidan, noko som betyr at det ferske oppslaget ditt og den opne socketen hans er usamde om kvar tenesta bur.

Les destinasjonen appen faktisk brukar

Spør operativsystemet og socket-tabellen, ikkje ei nettlesarfane. Oppslaget svarar på kva namnet blir løyst til akkurat no, og socket-tabellen viser adressa prosessen er kopla til, som kan vere eldre. Køyr begge før du dannar ein teori, fordi skilnaden mellom dei i seg sjølv er svaret i omtrent halvparten av tilfella.

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

Samanlikn deretter med det regelen dekkjer. Viss gjeldande adresse fell utanfor unntaket og førespurnaden framleis feilar, har du funne årsaka utan å røre tunnelkonfigurasjonen. Viss appen er kopla til ei adresse som svarar til regelen og førespurnaden framleis feilar, ligg problemet ein stad forbi tunnelen, og dette er feil undersøking.

Reparer mekanismen, ikkje symptomet

Viss produktet støttar vedlikehalden domenebasert styring, bruk det og følg den dokumenterte oppdaterings- og omfangsåtferda. Det erstattar ei statisk gissing med eit vedlikehalde svar, mot prisen av å avhenge av at funksjonen verkar som dokumentert.

Viss designet kviler på ei statisk liste, gje henne ein eigar og ein oppdateringsplan. Planen bør seie korleis adressa blir oppdaga, kven som godkjenner endringa og kor raskt lista blir venta å følgje ei leverandørmigrering. Ei liste utan eigar er eit framtidig avbrot med ei kjend årsak.

Ikkje utvid unntaket til eit stort nabonett berre for å fange kvar adresse du såg under ein kort test. Det er ikkje ein reparasjon; det er ei varig endring av tryggingsgrensa, og ho vil stille late urelaterte tenester omgå tunnelen så lenge regelen finst.

Stadfest begge halvdelane av intensjonen

Eit split-tunneldesign har to intensjonar, og ein reparasjon bør ta vare på begge. Den verna tenesta må gå gjennom tunnelen, og dei utelukka kategoriane må halde fram med å gå utanom han. Test ei fersk tilkobling til den reparerte destinasjonen, og test deretter noko som skal halde seg utanfor.

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 adressa, mekanismen du valde og datoen. Det notatet er det som hindrar neste person i å konkludere med at VPN-en tilfeldigvis ignorerte sin eigen konfigurasjon.

Relaterte artiklar