Miksi split-tunnel-sääntösi lakkasi vastaamasta palvelua

Split-tunnelointi epäonnistuu yleensä yhdellä kahdesta tavasta. Joko tunnelin sisälle kuuluva liikenne kiertää sen, tai liikenne, jonka pitäisi pysyä ulkona, vedetään sisään. Vanhentuneen säännön vika on ensimmäinen tapaus, ja se on hämmentävämpi, koska sääntöä noudatetaan täsmälleen niin kuin se on kirjoitettu. Muuttunut asia on kohde: palvelu vastaa nyt osoitteessa, jota sääntö ei koskaan nimennyt, eikä tunnelissa ole mitään vialla.

Mitä sääntö kiinnittää ja mitä DNS palauttaa

Split-tunnel-sääntö on staattinen väite kohteista, yleensä ilmaistu etuliitteenä, reittinä tai osoiteluettelona. Se arvioidaan paketin kohdetta vasten lähetyshetkellä. Isäntänimi on haku, joka palauttaa joukon osoitteita elinajan ja välimuistin kanssa, ja vastaus voi vaihdella resolverin, kyselytyypin ja minuutin mukaan.

Nämä kaksi oliota eivät koskaan neuvottele keskenään. Sääntö vastaa edelleen sille annettua etuliitettä, palvelu vaihtaa edelleen jakamaansa osoitetta, ja niiden välinen kuilu levenee hiljaa. Siksi oire ilmaantuu palveluntarjoajan migraation tai varmenteen uusimisen jälkeen eikä kokoonpanomuutoksen jälkeen. Kukaan ei muokannut tunnelia, joten kukaan ei katso tunnelia, ja diagnoosi ajautuu sovellukseen politiikan sijaan.

Kolme tapaa, joilla vastaavuus rikkoutuu

Ilmeinen tapaus on muuttanut palvelu: operaattori antoi sille uuden osoitteen, DNS seurasi, eikä poikkeus seurannut. Toinen on osoiteperhe, jota sääntö ei koskaan kattanut, mikä tapahtuu, kun nimi alkaa palauttaa AAAA-tietueita, jotka vain IPv4:n poikkeus jättää huomiotta. Kolmas on resolver-ero: sisäinen ja julkinen näkymä voivat palauttaa samalle nimelle eri osoitteita, joten sovelluksesi käyttämä osoite ei ole se, jolla testasit.

Välimuistiin tallennettu yhteys on neljäs muunnos ja se on helppo jättää huomaamatta. Sovellus saattaa yhä puhua osoitteelle, jonka se ratkaisi tunti sitten, mikä tarkoittaa, että tuore hakusi ja sen avoin socket ovat eri mieltä siitä, missä palvelu sijaitsee.

Lue kohde, jota sovellus todella käyttää

Kysy käyttöjärjestelmältä ja socket-taululta, älä selaimen välilehdeltä. Haku vastaa, mihin nimi ratkeaa juuri nyt, ja socket-taulukko näyttää osoitteen, johon prosessi on yhteydessä, ja se voi olla vanhempi. Aja molemmat ennen teorian muodostamista, koska niiden ero on itsessään vastaus noin puolessa tapauksista.

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

Vertaa sitten siihen, mitä sääntö kattaa. Jos nykyinen osoite jää poikkeuksen ulkopuolelle ja pyyntö epäonnistuu edelleen, olet löytänyt syyn koskematta tunnelin kokoonpanoon. Jos sovellus on yhteydessä osoitteeseen, joka vastaa sääntöä, ja pyyntö epäonnistuu edelleen, ongelma on jossain tunnelin tuolla puolen ja tämä on väärä tutkimus.

Korjaa mekanismi, älä oiretta

Jos tuote tukee ylläpidettyä verkkotunnuspohjaista ohjausta, käytä sitä ja noudata sen dokumentoitua päivitys- ja laajuuskäyttäytymistä. Se korvaa staattisen arvauksen ylläpidetyllä vastauksella, sen kustannuksella, että riippuu ominaisuuden toimimisesta dokumentoidusti.

Jos suunnittelu nojaa staattiseen luetteloon, anna sille omistaja ja päivityssuunnitelma. Suunnitelman tulisi kertoa, miten osoite löydetään, kuka muutoksen hyväksyy ja miten nopeasti luettelon odotetaan seuraavan palveluntarjoajan migraatiota. Luettelo ilman omistajaa on tuleva katkos, jonka syy on tiedossa.

Älä laajenna poikkeusta suureen naapuriverkkoon vain siksi, että saisit kiinni jokaisen osoitteen, jonka näit lyhyen testin aikana. Se ei ole korjaus; se on pysyvä muutos turvarajassa, ja se päästää hiljaa asiaankuulumattomat palvelut tunnelin ohi niin kauan kuin sääntö on olemassa.

Varmista aikomuksen molemmat puolet

Split-tunnel-suunnitelmalla on kaksi aikomusta, ja korjauksen pitäisi säilyttää molemmat. Suojatun palvelun on mentävä tunnelin läpi, ja poissuljettujen luokkien on jatkettava sen kiertämistä. Testaa tuore yhteys korjattuun kohteeseen ja testaa sitten jotain, jonka pitäisi pysyä ulkona.

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'

Kirjaa uusi osoite, valitsemasi mekanismi ja päivämäärä. Juuri se muistiinpano estää seuraavaa ihmistä päättelemästä, että VPN jätti satunnaisesti oman kokoonpanonsa huomiotta.