Kial via split-tunnel-regulo ĉesis kongrui kun servo

Split-tunnel kutime malsukcesas unu el du manieroj. Aŭ trafiko, kiu devus esti ene de la tunelo, iras ĉirkaŭ ĝi, aŭ trafiko, kiu devus resti ekstere, estas tirata enen. La malsukceso pro kaduka regulo estas la unua speco, kaj ĝi estas la pli konfuza, ĉar la regulo estas plenumata ĝuste tiel, kiel ĝi skribiĝis. Kio ŝanĝiĝis, estas la celo: la servo nun respondas per adreso, kiun la regulo neniam nomis, kaj nenio en la tunelo malĝustas.

Kion la regulo fiksas kaj kion DNS redonas

Split-tunnel-regulo estas statika aserto pri celoj, kutime esprimita kiel prefikso, itinero aŭ adreslisto. Ĝi estas taksata kontraŭ la celo de la paketo ĉe sendotempo. Gastnomo estas serĉo, kiu redonas aron da adresoj kun vivdaŭro kaj kaŝmemoro, kaj la respondo povas malsami laŭ resolvilo, laŭ petspeco kaj laŭ minuto.

Tiuj du objektoj neniam intertraktas unu kun la alia. La regulo daŭre kongruas la prefikson, kiun ĝi ricevis, la servo daŭre ŝanĝas la adreson, kiun ĝi donas, kaj la breĉo inter ili silente larĝiĝas. Tial la simptomo aperas post provizanto-migrado aŭ atestilo-renovigo, ne post agordo-ŝanĝo. Neniu redaktis la tunelon, do neniu rigardas la tunelon, kaj la diagnozo drivas al la aplikaĵo anstataŭ al la politiko.

Tri manieroj, kiel la kongruo rompiĝas

La evidenta kazo estas translokigita servo: la operatoro donis al ĝi novan adreson, DNS sekvis, kaj la escepto ne. La dua estas adresfamilio, kiun la regulo neniam kovris, kio okazas, kiam nomo komencas redoni AAAA-rikordojn, kiujn escepto nur por IPv4 ignoras. La tria estas resolvilo-diferenco: interna vido kaj publika vido povas redoni malsamajn adresojn por la sama nomo, do la adreso, kiun via aplikaĵo uzas, ne estas tiu, per kiu vi testis.

Kaŝmemora konekto estas kvara varianto kaj facile preteratentebla. La aplikaĵo eble ankoraŭ parolas kun adreso, kiun ĝi solvis antaŭ unu horo, kio signifas, ke via freŝa serĉo kaj ĝia malfermita soketo malkonsentas pri tio, kie la servo loĝas.

Legu la celon, kiun la aplikaĵo efektive uzas

Demandu la operaciumon kaj la soketan tabelon, ne retumilan langeton. La serĉo respondas, al kio la nomo solviĝas nun, kaj la soketa tabelo montras la adreson, al kiu la procezo estas konektita, kiu povas esti pli malnova. Rulu ambaŭ antaŭ ol formi teorion, ĉar la diferenco inter ili mem estas la respondo en proksimume duono de la kazoj.

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

Poste komparu kun tio, kion la regulo kovras. Se la nuna adreso falas ekster la escepton kaj la peto daŭre malsukcesas, vi trovis la kaŭzon sen tuŝi la tunelan agordon. Se la aplikaĵo estas konektita al adreso, kiu kongruas kun la regulo, kaj la peto daŭre malsukcesas, la problemo estas ie post la tunelo kaj ĉi tio estas la malĝusta esploro.

Riparu la mekanismon, ne la simptomon

Se la produkto subtenas prizorgatan domajnan direktadon, uzu ĝin kaj sekvu ĝian dokumentitan refreŝigan kaj ampleksan konduton. Tio anstataŭigas statikan konjekton per prizorgata respondo, je la kosto dependi de tio, ke la funkcio funkcias kiel dokumentite.

Se la dezajno baziĝas sur statika listo, donu al ĝi posedanton kaj ĝisdatigan planon. La plano devus diri, kiel la adreso estas malkovrata, kiu aprobas la ŝanĝon kaj kiel rapide la listo devus sekvi provizanto-migradon. Listo sen posedanto estas estonta paneo kun konata kaŭzo.

Ne larĝigu la escepton al granda najbara reto nur por kapti ĉiun adreson, kiun vi vidis dum mallonga testo. Tio ne estas ripari; ĝi estas permanenta ŝanĝo al la sekureca limo, kaj ĝi silente lasos nerilatajn servojn preteriri la tunelon dum la regulo ekzistas.

Kontrolu ambaŭ duonojn de la intenco

Split-tunnel-dezajno havas du intencojn, kaj riparo devus konservi ambaŭ. La protektata servo devas iri tra la tunelo, kaj la ekskluditaj kategorioj devas daŭre iri ĉirkaŭ ĝi. Testu freŝan konekton al la riparita celo, poste testu ion, kio supozeble restu ekstere.

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'

Notu la novan adreson, la elektitan mekanismon kaj la daton. Tiu noto estas tio, kio malhelpas la sekvan personon konkludi, ke la VPN hazarde ignoris sian propran agordon.