Zašto vaše pravilo split tuneliranja prestalo odgovarati usluzi

Split tuneliranje obično zataji na jedan od dva načina. Ili promet koji bi trebao biti unutar tunela ide oko njega, ili promet koji bi trebao ostati vani biva uvučen unutra. Kvar zbog zastarjelog pravila prvi je slučaj i zbunjuje više, jer se pravilo provodi točno onako kako je napisano. Ono što se promijenilo jest odredište: usluga sada odgovara na adresi koju pravilo nikad nije imenovalo, a u tunelu ništa nije pogrešno.

Što pravilo fiksira i što DNS vraća

Pravilo split tuneliranja statična je tvrdnja o odredištima, obično izražena kao prefiks, ruta ili popis adresa. Procjenjuje se prema odredištu paketa u trenutku slanja. Naziv hosta je upit koji vraća skup adresa sa životnim vijekom i predmemorijom, a odgovor se može razlikovati po resolveru, po vrsti upita i po minuti.

Ta dva objekta nikad ne pregovaraju jedan s drugim. Pravilo se nastavlja podudarati s prefiksom koji je dobilo, usluga nastavlja mijenjati adresu koju izdaje, a jaz između njih tiho se širi. Zato se simptom pojavljuje nakon migracije davatelja ili obnove certifikata, a ne nakon promjene konfiguracije. Nitko nije uređivao tunel, pa nitko ne gleda tunel, i dijagnoza skreće prema aplikaciji umjesto prema politici.

Tri načina na koja se podudaranje kvari

Očit slučaj je preseljena usluga: operater joj je dao novu adresu, DNS je slijedio, a iznimka nije. Drugi je obitelj adresa koju pravilo nikad nije pokrilo, što se događa kad naziv počne vraćati AAAA zapise koje iznimka samo za IPv4 ignorira. Treći je razlika u resolveru: interno i javno gledište mogu za isti naziv vratiti različite adrese, pa adresa koju vaša aplikacija koristi nije ona s kojom ste testirali.

Predmemorirana veza četvrta je varijanta i lako ju je previdjeti. Aplikacija možda još razgovara s adresom koju je razriješila prije sat vremena, što znači da se vaš svježi upit i njezin otvoreni socket ne slažu oko toga gdje usluga živi.

Pročitajte odredište koje aplikacija doista koristi

Pitajte operacijski sustav i tablicu socketa, a ne karticu preglednika. Upit odgovara na što se naziv trenutačno razrješava, a tablica socketa pokazuje adresu na koju je proces spojen, koja može biti starija. Pokrenite oboje prije nego stvorite teoriju, jer je razlika među njima u otprilike polovici slučajeva sama odgovor.

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

Zatim usporedite s onim što pravilo pokriva. Ako trenutačna adresa pada izvan iznimke, a zahtjev i dalje ne uspijeva, pronašli ste uzrok bez diranja konfiguracije tunela. Ako je aplikacija spojena na adresu koja odgovara pravilu, a zahtjev i dalje ne uspijeva, problem je negdje iza tunela i ovo je pogrešna istraga.

Popravite mehanizam, ne simptom

Ako proizvod podržava održavano usmjeravanje prema domenama, upotrijebite ga i slijedite njegovo dokumentirano ponašanje osvježavanja i dosega. To zamjenjuje statičnu pretpostavku održavanim odgovorom, uz cijenu ovisnosti o tome da značajka radi kako je dokumentirano.

Ako se dizajn oslanja na statični popis, dajte mu vlasnika i plan ažuriranja. Plan bi trebao reći kako se adresa otkriva, tko odobrava promjenu i koliko se brzo od popisa očekuje da slijedi migraciju davatelja. Popis bez vlasnika budući je prekid s poznatim uzrokom.

Ne širite iznimku na veliku susjednu mrežu samo da biste uhvatili svaku adresu koju ste vidjeli tijekom kratkog testa. To nije popravak; to je trajna promjena sigurnosne granice i tiho će pustiti nepovezane usluge da zaobiđu tunel dok god pravilo postoji.

Provjerite obje polovice namjere

Dizajn split tuneliranja ima dvije namjere, a popravak bi trebao sačuvati obje. Zaštićena usluga mora ići kroz tunel, a isključene kategorije moraju ga nastaviti zaobilaziti. Testirajte svježu vezu na popravljeno odredište, zatim testirajte nešto što bi trebalo ostati vani.

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'

Zabilježite novu adresu, odabrani mehanizam i datum. Ta bilješka je ono što sprječava sljedeću osobu da zaključi da je VPN nasumično ignorirao vlastitu konfiguraciju.