Pse rregulli juaj i split tunnel nuk përputhej më me një shërbim

Split tunneling zakonisht dështon në njërën nga dy mënyrat. Ose trafiku që duhet të jetë brenda tunelit e anashkalon atë, ose trafiku që duhet të mbetet jashtë tërhiqet brenda. Dështimi për shkak të rregullit të vjetruar është lloji i parë, dhe është ai më konfuz, sepse rregulli zbatohet saktësisht ashtu siç është shkruar. Ajo që ndryshoi është destinacioni: shërbimi tani përgjigjet në një adresë që rregulli nuk e ka emërtuar kurrë, dhe në tunel nuk ka asgjë të gabuar.

Çfarë fikson rregulli dhe çfarë kthen DNS

Një rregull split tunnel është një deklarim statik për destinacionet, zakonisht i shprehur si parashtesë, rrugë ose listë adresash. Vlerësohet kundrejt destinacionit të paketës në momentin e dërgimit. Emri i hostit është një kërkim që kthen një grup adresash me një jetëgjatësi dhe një cache, dhe përgjigja mund të ndryshojë sipas resolver, sipas llojit të kërkesës dhe sipas minutës.

Këto dy objekte nuk negociojnë kurrë me njëri-tjetrin. Rregulli vazhdon të përputhet me parashtesën që iu dha, shërbimi vazhdon të ndryshojë adresën që lëshon, dhe hendeku mes tyre zgjerohet në heshtje. Kjo është arsyeja pse simptoma shfaqet pas një migrimi të ofruesit ose një rinovimi certifikate dhe jo pas një ndryshimi konfigurimi. Askush nuk redaktoi tunelin, prandaj askush nuk shikon tunelin, dhe diagnoza rrjedh drejt aplikacionit në vend të politikës.

Tre mënyra se si thyhet përputhja

Rasti i dukshëm është një shërbim i zhvendosur: operatori i dha një adresë të re, DNS e ndoqi, dhe përjashtimi nuk e ndoqi. I dyti është një familje adresash që rregulli nuk e mbuloi kurrë, gjë që ndodh kur një emër fillon të kthejë regjistrime AAAA që një përjashtim vetëm për IPv4 i injoron. I treti është një ndryshim resolver: një pamje e brendshme dhe një pamje publike mund të kthejnë adresa të ndryshme për të njëjtin emër, kështu që adresa që përdor aplikacioni juaj nuk është ajo me të cilën testuat.

Një lidhje e ruajtur në cache është varianti i katërt dhe është e lehtë të humbasë. Aplikacioni mund të vazhdojë të flasë me një adresë që e zgjidhi një orë më parë, që do të thotë se kërkimi juaj i freskët dhe socket-i i tij i hapur nuk bien dakord se ku jeton shërbimi.

Lexoni destinacionin që aplikacioni përdor vërtet

Pyetni sistemin operativ dhe tabelën e socket-eve, jo një skedë shfletuesi. Kërkimi përgjigjet se çfarë zgjidh emri tani, dhe tabela e socket-eve tregon adresën me të cilën është lidhur procesi, e cila mund të jetë më e vjetër. Ekzekutoni të dyja përpara se të formoni një teori, sepse ndryshimi mes tyre është vetë përgjigja në rreth gjysmën e rasteve.

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

Pastaj krahasoni me atë që mbulon rregulli. Nëse adresa aktuale bie jashtë përjashtimit dhe kërkesa vazhdon të dështojë, keni gjetur shkakun pa prekur konfigurimin e tunelit. Nëse aplikacioni është i lidhur me një adresë që përputhet me rregullin dhe kërkesa vazhdon të dështojë, problemi është diku përtej tunelit dhe ky është hetimi i gabuar.

Riparoni mekanizmin, jo simptomën

Nëse produkti mbështet drejtim të mirëmbajtur bazuar në domaine, përdoreni dhe ndiqni sjelljen e dokumentuar të rifreskimit dhe të shtrirjes. Kjo zëvendëson një hamendje statike me një përgjigje të mirëmbajtur, me koston e varësisë nga fakti që funksioni punon siç është dokumentuar.

Nëse dizajni mbështetet në një listë statike, jepini një pronar dhe një plan përditësimi. Plani duhet të thotë si zbulohet adresa, kush e miraton ndryshimin dhe sa shpejt pritet që lista të ndjekë një migrim të ofruesit. Një listë pa pronar është një ndërprerje e ardhshme me një shkak të njohur.

Mos e zgjeroni përjashtimin në një rrjet fqinj të madh vetëm për të kapur çdo adresë që patë gjatë një testi të shkurtër. Kjo nuk është riparim; është një ndryshim i përhershëm i kufirit të sigurisë, dhe do të lejojë në heshtje shërbime të palidhura të anashkalojnë tunelin për sa kohë ekziston rregulli.

Verifikoni të dyja gjysmat e qëllimit

Një dizajn split tunnel ka dy qëllime, dhe një riparim duhet t'i ruajë të dyja. Shërbimi i mbrojtur duhet të kalojë nëpër tunel, dhe kategoritë e përjashtuara duhet të vazhdojnë ta anashkalojnë. Testoni një lidhje të re me destinacionin e riparuar, pastaj testoni diçka që supozohet të mbetet jashtë.

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'

Shënoni adresën e re, mekanizmin e zgjedhur dhe datën. Është pikërisht ai shënim që e pengon personin tjetër të konkludojë se VPN-ja injoroi rastësisht konfigurimin e vet.