Kill-switch pas kalimit nga Wi-Fi në rrjet cellular: çfarë thyhet

Në një çast laptopi është në Wi-Fi-n e zyrës, në çastin tjetër është i lidhur me një telefon, dhe treguesi i tunelit është përsëri i gjelbër përpara se të mbarosh ndryshimin e dritareve. Drita e gjelbër raporton vetëm se tuneli u rilidh; çfarë bëri politika e rrugëzimit dhe e bllokimit gjatë boshllëkut është pyetje tjetër. Ajo politikë është një grup kushtesh përputhjeje të kompiluara në instalimin e fundit, dhe emërton një ndërfaqe, një adresë dhe një familje adresash që kalimi sapo i hoqi. Prandaj i njëjti ndryshim prodhon tre rezultate që duken njësoj: bllokimi vazhdon, politika bllokon rikuperimin e vet, ose hapet një rrugë që asgjë nuk e mbulon.

Asgjë në ekran nuk i ndan këto tre gjendje, prandaj pyet se në cilët identifikues ishin fiksuar rregullat, jo çfarë ngjyre tregon treguesi. Në Linux një rregull mund të emërtojë një ndërfaqe ose një ipset të mbushur prej saj; në Android një VpnService mund të njoftohet se cilat rrjete bazë duhet të ndjekë përmes setUnderlyingNetworks. Çdo lidhje tregon një lidhje që do të zëvendësohet, dhe secila duhet të rivlerësohet më pas.

Çfarë rishkruan në të vërtetë kalimi

Kur lidhja e vjetër zhduket, kernel-i heq adresat e saj, tërheq rrugët që kalonin nëpër të dhe rindërton zgjedhjen e adresës burimore nga ajo që mbetet. Rruga e paracaktuar kalon te porta e re, dhe indeksi i ndërfaqes të cilit i referoheshin rregullat e vjetra ka humbur ose është ricikluar për një pajisje tjetër. Edhe resolver-ët për çdo lidhje rifreskohen, ndonëse jo në të njëjtin çast me rrugët. E gjithë kjo ndodh nën klientin VPN, prandaj një klient që vëzhgon vetëm gjendjen e tunelit të vet nuk sheh asgjë nga kjo.

Problemi është se një rregull kodon një identifikues të caktuar në vend të qëllimit pas tij. Rregulli që hedh çdo gjë që nuk del përmes ndërfaqes së tunelit kodon një emër ndërfaqeje; rregulli që lejon pikën fundore kodon një adresë që rrjeti i ri mund ta rrugëzojë diku tjetër. Kur identifikuesi zhduket, rregulli nuk bëhet dukshëm i gabuar: ose pushon së përputhuri me çdo gjë ose fillon të përputhet me gjënë e gabuar.

Rindërtimi i tunelit të jashtëm pa hapur një vrimë

Transporti i jashtëm ishte i lidhur me adresën burimore të vjetër, prandaj duhet të hapë një socket të re nga ajo e reja. Kur pika fundore është emër hosti dhe jo adresë fjalë për fjalë, një kërkim duhet të ketë sukses ndërsa bllokimi është ende në fuqi. Ky është kurthi i rendit: një politikë mjaft e rreptë për të hedhur çdo gjë përveç pikës fundore do të hedhë edhe kërkimin e nevojshëm për ta gjetur, përveç nëse zgjidhja ndodh përpara se bllokimi të hiqet ose transportohet përmes një tuneli ende të gjallë. Të dy rendet mund të funksionojnë, por vetëm nëse klienti e di në cilin ndodhet.

Klientët ndryshojnë këtu në një mënyrë që ka rëndësi gjatë diagnostikimit. Disa zgjidhin së pari dhe instalojnë rregullat më pas, kështu që kalimi kushton një ndërprerje të dukshme dhe pastaj rikuperohet vetë; të tjerët e mbajnë bllokimin lart dhe mbështeten te tuneli i mbijetuar për të mbajtur kërkimin, gjë që dështon plotësisht kur tuneli vdiq me lidhjen. Shtimi i një rruge të drejtpërdrejtë të paracaktuar të gjerë për të rikthyer lidhshmërinë gjithmonë e kalon testin dhe gjithmonë lë rrjedhjen që po parandalonit.

Një rrugë që ende tregon portën e vjetër jep të njëjtin rikuperim të bllokuar nga një shkak tjetër, prandaj lexo tabelën përpara se të fajësosh klientin. Komandat më poshtë emërtojnë ndërfaqen dhe adresën burimore që kernel-i do të përdorte vërtet, dhe kjo vendos në një rresht nëse rruga e vjetër është ende e instaluar.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Kur lidhja e re sjell IPv6 dhe rregullat jo

Rrjetet celulare dhe ato të mysafirëve shpesh japin një prefiks IPv6 global edhe kur LAN-i me kabllo i zyrës nuk e ka bërë kurrë. Një politikë e shkruar vetëm si rregulla IPv4, forma e paracaktuar e shumicës së recetave të bëra me dorë të iptables dhe nftables, nuk mbulon asgjë nga kjo. Tuneli mbetet i lidhur, aplikacionet me arritshmëri IPv6 dalin jashtë tij, dhe treguesi nuk mund ta tregojë ndryshimin sepse tuneli vërtet është lart. Rasti pasqyrë është po aq i zakonshëm: një grup rregullash vetëm për IPv6 nuk bën asgjë në një rrjet që nuk ofron v6.

Krahaso atë që ofron lidhja me atë që përmend politika, në të dyja anët e kalimit. Këto komanda shtypin të njëjtat fakte me të cilat punon klienti:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

Nëse komanda e dytë shtyp një rrugë të paracaktuar ndërsa e treta kthen zero, lidhja e re mund ta nxjerrë makinën jashtë përmes IPv6 pa asnjë rregull që e mbikëqyr. Ekzekuto përsëri të treja pas ndryshimit, sepse numri interesant është diferenca midis dy ekzekutimeve. Nëse e dyta nuk shtyp asgjë, zbatohet rasti i kundërt dhe çdo politikë e rëndë në v6 atje është vetëm zbukurim.

Resolver-i ndërron duar në mes të sesionit

Në sistemet moderne resolver-ët janë të lidhur me lidhjet, kështu që një lidhje e re vjen me një grup të re resolver-ësh dhe ndoshta me një pamje tjetër split-DNS. systemd-resolved mban një scope për çdo lidhje dhe zgjedh midis tyre sipas rrugës, ndërsa macOS lexon resolver-ë me scope nga depoja dinamike dhe respekton rendin e ndërfaqeve. Një klient që instalon resolver-in e vet konkurron me atë të lidhjes, dhe rregullat e përparësisë që askush nuk i vëzhgon vendosin fituesin. Atëherë zgjidhja e emrave mund të thyhet ndërsa filtrimi i paketave bën pikërisht atë për të cilën u shkrua.

Lexo resolver-in që është aktiv dhe jo atë të konfiguruar. Në një host systemd nënkomanda status tregon nga cila lidhje erdhi çdo scope dhe nëse një emër private-DNS është në fuqi:

resolvectl status --no-pager
resolvectl query intranet.example.com

Nëse kërkimi del përmes lidhjes fizike dhe jo përmes tunelit, klienti ka humbur garën e përparësisë dhe asnjë rregullim i firewall-it nuk do t'i rregullojë emërtimet. Krahaso rrugën e kërkesës në të dyja anët e kalimit për të parë cila lëvizi. Një emër që zgjidhet në një adresë private që rrjeti i ri nuk mund ta rrugëzojë është rasti i tretë, dhe shfaqet si skadim kohe dhe jo si gabim.

Ushtro kalimin dhe mbaj shënimin

Riprodho ndryshimin me qëllim në vend që ta presësh. Ngri tunelin në lidhjen e parë, nis një transferim të gjatë dhe një kërkim të përsëritur, pastaj ndërro lidhjen dhe shiko cila mbijeton. Shëno intervalin midis zhdukjes së lidhjes së vjetër dhe raportimit të tunelit se është i lidhur, sepse në atë dritare politika ose qëndroi ose nuk qëndroi. Ekzekuto sekuencën edhe në drejtimin tjetër, që rezultati të mos jetë i njëanshëm.

Përjashtimet kanë nevojë për kalimin e vet, sepse një anashkalim i justifikuar në rrjetin e vjetër nuk justifikohet automatikisht në atë të re. Një printer, një NAS ose një portal robërues në LAN-in e shtëpisë nuk ka homolog në rrjetin celular, dhe përjashtimi që arrinte deri atje bëhet rregull pa homolog.

Shëno emrat e ndërfaqeve, familjet e ofruara, resolver-in në fuqi dhe kohëzgjatjen e ndërprerjes për çdo drejtim. Rilidhja provon se transporti u rikuperua, jo se bllokimi qëndroi gjatë boshllëkut, dhe këto janë pretendime të ndara për një tiketë. Me atë shënim kalimi i ardhshëm krahasohet me një gjendje të njohur dhe jo me kujtesën.