Miks teie split-tunneli reegel lakkas teenusega sobimast

Split-tunnel ebaõnnestub tavaliselt ühel kahest viisist. Kas tunnelisse kuuluv liiklus läheb sellest mööda, või tõmmatakse väljapoole jääma pidanud liiklus sisse. Aegunud reegli viga on esimene liik ja see on segadust tekitavam, sest reeglit rakendatakse täpselt nii, nagu see kirja pandi. Muutus sihtkoht: teenus vastab nüüd aadressil, mida reegel kunagi ei nimetanud, ja tunnelis endas pole midagi valesti.

Mida reegel kinnitab ja mida DNS tagastab

Split-tunneli reegel on staatiline väide sihtkohtade kohta, tavaliselt väljendatud eesliite, marsruudi või aadressiloendina. Seda hinnatakse paketi sihtkoha vastu saatmise hetkel. Hostinimi on päring, mis tagastab hulga aadresse koos eluea ja vahemäluga, ning vastus võib erineda resolveri, päringutüübi ja minuti kaupa.

Need kaks objekti ei pea kunagi omavahel läbirääkimisi. Reegel jätkab talle antud eesliitega sobimist, teenus jätkab väljastatava aadressi muutmist ja nendevaheline lünk laieneb vaikselt. Seetõttu ilmneb sümptom pärast teenusepakkuja migratsiooni või sertifikaadi uuendamist, mitte pärast konfiguratsiooni muutmist. Keegi ei muutnud tunnelit, nii et keegi ei vaata tunnelit, ja diagnoos triivib rakenduse, mitte poliitika poole.

Kolm viisi, kuidas sobivus katkeb

Ilmne juhtum on kolinud teenus: operaator andis sellele uue aadressi, DNS järgis ja erand ei järginud. Teine on aadressiperekond, mida reegel kunagi ei katnud, mis juhtub siis, kui nimi hakkab tagastama AAAA-kirjeid, mida ainult IPv4 jaoks mõeldud erand eirab. Kolmas on resolveri erinevus: sisemine ja avalik vaade võivad sama nime jaoks tagastada erinevaid aadresse, nii et teie rakenduse kasutatav aadress ei ole see, millega te testisite.

Vahemällu salvestatud ühendus on neljas variant ja seda on lihtne vahele jätta. Rakendus võib endiselt rääkida aadressiga, mille see tund aega tagasi lahendas, mis tähendab, et teie värske päring ja selle avatud socket ei ole ühel meelel, kus teenus asub.

Lugege sihtkohta, mida rakendus tegelikult kasutab

Küsige operatsioonisüsteemilt ja socket-tabelilt, mitte brauseri vahekaardilt. Päring vastab, milleks nimi praegu laheneb, ja socket-tabel näitab aadressi, millega protsess on ühendatud, mis võib olla vanem. Käivitage mõlemad enne teooria kujundamist, sest nendevaheline erinevus on umbes pooltel juhtudel ise vastus.

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

Seejärel võrrelge sellega, mida reegel katab. Kui praegune aadress jääb erandist välja ja päring ikka ebaõnnestub, olete põhjuse leidnud ilma tunnelikonfiguratsiooni puutumata. Kui rakendus on ühendatud reegliga sobiva aadressiga ja päring ikka ebaõnnestub, on probleem kusagil väljaspool tunnelit ja see on vale uurimine.

Parandage mehhanismi, mitte sümptomit

Kui toode toetab hooldatavat domeenipõhist suunamist, kasutage seda ja järgige selle dokumenteeritud värskendus- ja ulatuskäitumist. See asendab staatilise oletuse hooldatava vastusega, hinnaga, et sõltute funktsiooni dokumenteeritud toimimisest.

Kui disain toetub staatilisele loendile, andke sellele omanik ja värskendusplaan. Plaan peaks ütlema, kuidas aadress avastatakse, kes muudatuse heaks kiidab ja kui kiiresti peaks loend teenusepakkuja migratsioonile järgnema. Omanikuta loend on tulevane katkestus teadaoleva põhjusega.

Ärge laiendage erandit suurele naabervõrgule ainult selleks, et tabada iga aadress, mida lühikese testi käigus nägite. See ei ole parandus; see on püsiv muudatus turbepiiris ja laseb vaikselt mitteseotud teenustel tunnelist mööda minna seni, kuni reegel kehtib.

Kontrollige mõlemat kavatsuse poolt

Split-tunneli disainil on kaks kavatsust ja parandus peaks mõlemad säilitama. Kaitstud teenus peab tunnelist läbi minema ja välistatud kategooriad peavad jätkama sellest mööda minemist. Testige värsket ühendust parandatud sihtkohaga, seejärel testige midagi, mis peaks väljapoole jääma.

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'

Kirjutage üles uus aadress, valitud mehhanism ja kuupäev. Just see märkus takistab järgmisel inimesel järeldamast, et VPN eiras juhuslikult omaenda konfiguratsiooni.