Bakit huminto sa pagtugma sa isang serbisyo ang iyong split-tunnel rule

Karaniwang nabigo ang split tunneling sa isa sa dalawang paraan. Maaring lumalabas sa tunnel ang trapik na dapat nasa loob nito, o nahihila sa loob ang trapik na dapat manatili sa labas. Ang pagkabigo dahil sa lumang rule ang unang uri, at ito ang mas nakakalito, dahil ipinatutupad ang rule nang eksakto ayon sa pagkakasulat. Ang nagbago ay ang destinasyon: sumasagot na ngayon ang serbisyo sa isang address na hindi kailanman pinangalanan ng rule, at walang mali sa tunnel.

Ano ang naka-pin sa rule at ano ang ibinabalik ng DNS

Ang split-tunnel rule ay isang static na pahayag tungkol sa mga destinasyon, karaniwang nakasaad bilang prefix, ruta o listahan ng address. Sinusuri ito laban sa destinasyon ng packet sa oras ng pagpapadala. Ang hostname ay isang paghahanap na nagbabalik ng set ng mga address na may lifespan at cache, at ang sagot ay maaaring magkaiba ayon sa resolver, uri ng query at minuto.

Kailanman ay hindi nag-uusap ang dalawang bagay na iyon. Patuloy na tumutugma ang rule sa prefix na ibinigay dito, patuloy na binabago ng serbisyo ang address na ibinibigay nito, at tahimik na lumalawak ang agwat sa pagitan nila. Kaya lumilitaw ang sintomas pagkatapos ng migrasyon ng provider o pag-renew ng certificate at hindi pagkatapos ng pagbabago ng configuration. Walang nag-edit ng tunnel, kaya walang tumitingin sa tunnel, at dumadausdos ang diagnosis patungo sa app sa halip na sa patakaran.

Tatlong paraan na nasisira ang pagtutugma

Ang malinaw na kaso ay isang serbisyong lumipat: binigyan ito ng operator ng bagong address, sumunod ang DNS, at hindi sumunod ang eksepsiyon. Ang pangalawa ay isang pamilya ng address na hindi kailanman sinaklaw ng rule, na nangyayari kapag nagsimulang magbalik ang isang pangalan ng mga AAAA record na binabalewala ng eksepsiyon para sa IPv4 lamang. Ang pangatlo ay pagkakaiba ng resolver: ang panloob at pampublikong pananaw ay maaaring magbalik ng magkaibang address para sa parehong pangalan, kaya ang address na ginagamit ng iyong app ay hindi ang sinubukan mo.

Ang naka-cache na koneksiyon ay ikaapat na variant at madaling makaligtaan. Maaaring kausap pa rin ng app ang isang address na niresolba nito isang oras na ang nakalipas, na nangangahulugang hindi nagkakasundo ang bago mong paghahanap at ang bukas nitong socket tungkol sa kung saan nakatira ang serbisyo.

Basahin ang destinasyong aktuwal na ginagamit ng app

Tanungin ang operating system at ang socket table, hindi ang tab ng browser. Sinasagot ng paghahanap kung ano ang niresolba ng pangalan ngayon, at ipinapakita ng socket table ang address na konektado ang proseso, na maaaring mas luma. Patakbuhin ang dalawa bago bumuo ng teorya, dahil ang pagkakaiba ng mga ito ay mismong sagot sa halos kalahati ng mga kaso.

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

Pagkatapos ihambing sa saklaw ng rule. Kung ang kasalukuyang address ay nasa labas ng eksepsiyon at nabibigo pa rin ang kahilingan, natagpuan mo ang dahilan nang hindi hinahawakan ang configuration ng tunnel. Kung nakakonekta ang app sa address na tumutugma sa rule at nabibigo pa rin ang kahilingan, ang problema ay nasa kabila ng tunnel at mali ang imbestigasyong ito.

Ayusin ang mekanismo, hindi ang sintomas

Kung sinusuportahan ng produkto ang maintained na domain-based na paggabay, gamitin ito at sundin ang dokumentadong pag-uugali nito sa pag-refresh at saklaw. Pinapalitan nito ang static na hula ng maintained na sagot, kapalit ng pag-asa na gumana ang feature ayon sa dokumentado.

Kung umaasa ang disenyo sa isang static na listahan, bigyan ito ng may-ari at plano sa pag-update. Dapat sabihin ng plano kung paano natutuklasan ang address, sino ang nag-aapruba ng pagbabago at gaano kabilis inaasahang susunod ang listahan sa migrasyon ng provider. Ang listahang walang may-ari ay isang hinaharap na pagkawala ng serbisyo na may alam na dahilan.

Huwag palawakin ang eksepsiyon sa isang malaking kalapit na network para lang mahuli ang bawat address na nakita mo sa isang maikling test. Hindi iyon pag-aayos; iyon ay permanenteng pagbabago sa hangganan ng seguridad, at tahimik nitong hahayaang laktawan ng mga walang kaugnayang serbisyo ang tunnel habang umiiral ang rule.

I-verify ang dalawang kalahati ng layunin

Ang disenyo ng split tunnel ay may dalawang layunin, at dapat panatilihin ng pag-aayos ang dalawa. Dapat dumaan sa tunnel ang protektadong serbisyo, at dapat ipagpatuloy ng mga ibinukod na kategorya ang pagliligid dito. Subukan ang bagong koneksiyon sa naayos na destinasyon, pagkatapos ay subukan ang isang bagay na dapat manatili sa labas.

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'

Itala ang bagong address, ang mekanismong pinili at ang petsa. Ang tala na iyon ang pumipigil sa susunod na tao na maghinuha na basta-basta binalewala ng VPN ang sarili nitong configuration.