Kill-switch po perjungimo iš Wi-Fi į mobilųjį tinklą: kas lūžta

Vieną akimirką nešiojamasis kompiuteris yra biuro Wi-Fi tinkle, kitą – prijungtas prie telefono, o tunelio indikatorius vėl žalias dar nebaigus keisti langų. Žalia šviesa praneša tik tai, kad tunelis vėl prisijungė; ką per tą spragą veikė maršrutizavimo ir blokavimo politika, yra kitas klausimas. Ta politika yra sutapimo sąlygų rinkinys, sukompiliuotas paskutinio įdiegimo metu, ir įvardija sąsają, adresą bei adresų šeimą, kuriuos perėjimas ką tik pašalino. Todėl tas pats perjungimas duoda tris vienodai atrodančius rezultatus: blokavimas tęsiasi, politika užblokuoja savo paties atkūrimą arba atsiveria kelias, kurio niekas neapima.

Ekrane niekas neatskiria tų trijų būsenų, todėl klauskite, prie kokių identifikatorių buvo prisegtos taisyklės, o ne kokią spalvą rodo indikatorius. Linuxe taisyklė gali įvardyti sąsają arba iš jos užpildytą ipset; Androide VpnService galima pasakyti, kurių pagrindinių tinklų laikytis, naudojant setUnderlyingNetworks. Kiekviena sąsaja nurodo jungtį, kuri tuoj bus pakeista, ir kiekviena turi būti įvertinta iš naujo po to.

Ką perėjimas iš tikrųjų perrašo

Kai senoji jungtis išnyksta, branduolys pašalina jos adresus, atšaukia maršrutus, ėjusius per ją, ir iš naujo sudėlioja šaltinio adreso pasirinkimą iš to, kas liko. Numatinis maršrutas persikelia į naująją tinklų sietuvą, o sąsajos indeksas, į kurį nurodė senosios taisyklės, išnyko arba buvo perdirbtas kitam įrenginiui. Ryšio sprendikliai taip pat atnaujinami, nors ne tą pačią akimirką kaip maršrutai. Visa tai vyksta žemiau VPN kliento, todėl klientas, stebintis tik savo tunelio būseną, nieko to nepastebi.

Bėda ta, kad taisyklė užkoduoja konkretų identifikatorių, o ne už jo slypinčią intenciją. Taisyklė, kuri išmeta viską, kas neišeina per tunelio sąsają, užkoduoja sąsajos pavadinimą; taisyklė, leidžianti galinį tašką, užkoduoja adresą, kurį naujasis tinklas gali nukreipti kitur. Kai identifikatorius išnyksta, taisyklė netampa akivaizdžiai klaidinga: ji arba nustoja su kuo nors sutapti, arba pradeda sutapti su netinkamu dalyku.

Atstatyti išorinį tunelį neišmušant skylės

Išorinis transportas buvo susietas su senuoju šaltinio adresu, todėl turi atidaryti naują lizdą iš naujojo. Kai galinis taškas yra prieglobos vardas, o ne pažodinis adresas, paieška turi pavykti, kol blokavimas dar galioja. Tai eilės spąstai: politika, pakankamai griežta išmesti viską, išskyrus galinį tašką, išmes ir paiešką, reikalingą jam rasti, nebent sprendimas įvyksta prieš pakeliant blokavimą arba yra pernešamas dar gyvu tuneliu. Abi eilės gali veikti, bet tik jei klientas žino, kurioje yra.

Klientai čia skiriasi taip, kaip svarbu diagnozuojant. Vieni pirmiausia išsprendžia, o paskui įdiegia taisykles, todėl perėjimas kainuoja matomą pertrauką ir po to pats atsistato; kiti laiko blokavimą ir pasikliauja išlikusiu tuneliu, kad perneštų paiešką, o tai visiškai nepavyksta, kai tunelis mirė kartu su jungtimi. Plačiai tiesioginio numatytojo maršruto pridėjimas ryšiui atkurti visada praleidžia testą ir visada palieka nutekėjimą, kurį stabdėte.

Maršrutas, vis dar nurodantis į senąją tinklų sietuvą, duoda tą patį įstrigusį atkūrimą dėl kitos priežasties, todėl perskaitykite lentelę prieš kaltindami klientą. Toliau pateikti komandai įvardija sąsają ir šaltinio adresą, kuriuos branduolys tikrai naudotų, ir tai viena eilute nusprendžia, ar senasis kelias dar įdiegtas.

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

Kai naujoji jungtis atneša IPv6, o taisyklės ne

Mobiliojo ir svečių tinklai dažnai išduoda globalų IPv6 priešdėlį, net kai biuro laidinis LAN to niekada nedarė. Politika, parašyta tik kaip IPv4 taisyklės, įprasta daugumos rankiniu būdu sukurtų iptables ir nftables receptų forma, nieko to neapima. Tunelis lieka prijungtas, programos su IPv6 pasiekiamumu išeina už jo, o indikatorius negali parodyti skirtumo, nes tunelis tikrai veikia. Veidrodinis atvejis taip pat įprastas: taisyklių rinkinys tik IPv6 nieko neveikia tinkle, kuris nesiūlo v6.

Palyginkite, ką siūlo jungtis, su tuo, ką mini politika, abiejose perėjimo pusėse. Šie komandai atspausdina tuos pačius faktus, su kuriais dirba klientas:

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

Jei antrasis komandas atspausdina numatytąjį maršrutą, o trečiasis grąžina nulį, naujoji jungtis gali išvesti mašiną per IPv6 be jokios taisyklės priežiūros. Paleiskite visus tris dar kartą po perjungimo, nes įdomus skaičius yra dviejų paleidimų skirtumas. Jei antrasis nieko nespausdina, galioja atvirkštinis atvejis ir bet kokia v6 sunki politika ten tėra puošmena.

Sprendiklis persiduoda sesijos viduryje

Šiuolaikinėse sistemose sprendikliai pririšti prie jungčių, todėl nauja jungtis ateina su nauju sprendiklių rinkiniu ir galbūt kitokiu split-DNS vaizdu. systemd-resolved laiko po vieną sritį kiekvienai jungčiai ir renkasi tarp jų pagal maršrutą, o macOS skaito sritinius sprendiklius iš dinaminės saugyklos ir gerbia sąsajų tvarką. Klientas, įdiegiantis savo sprendiklį, konkuruoja su jungties sprendikliu, o nugalėtoją nusprendžia prioritetų taisyklės, kurių niekas neprižiūri. Tada vardų sprendimas gali sulūžti, nors paketų filtravimas daro būtent tai, kam buvo parašytas.

Skaitykite aktyvų sprendiklį, o ne sukonfigūruotąjį. systemd priegloboje pakomandė status rodo, iš kurios jungties atėjo kiekviena sritis ir ar galioja private-DNS vardas:

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

Jei užklausa išeina per fizinę jungtį, o ne per tunelį, klientas pralaimėjo prioriteto varžybas ir jokia ugniasienės derinimas nepataisys vardijimo. Palyginkite užklausos kelią abiejose perėjimo pusėse, kad pamatytumėte, kuri pasislinko. Vardas, kuris sprendžiamas į privatų adresą, kurio naujasis tinklas negali maršrutizuoti, yra trečias atvejis, ir jis pasireiškia kaip skirtasis laikas, o ne kaip klaida.

Praktikuokite perėjimą ir saugokite įrašą

Atkurkite pokytį tyčia, o ne laukite jo. Pakelkite tunelį pirmoje jungtyje, pradėkite ilgai trunkantį perdavimą ir kartotinę paiešką, tada perjunkite jungtį ir stebėkite, kuri išlieka. Užsirašykite intervalą tarp senosios jungties išnykimo ir tunelio pranešimo, kad jis prijungtas, nes tame lange politika arba išlaikė, arba ne. Paleiskite seką ir priešinga kryptimi, kad rezultatas nebūtų vienpusis.

Išimtims reikia atskiro praėjimo, nes senajame tinkle pateisintas apėjimas naujajame automatiškai nepateisinamas. Namų LAN spausdintuvas, NAS ar captive portal neturi atitikmens mobiliajame tinkle, o išimtis, kuri juos pasiekdavo, tampa taisykle be atitikmens.

Užrašykite sąsajų pavadinimus, siūlomas šeimas, galiojantį sprendiklį ir pertraukos trukmę kiekvienai krypčiai. Prisijungimas iš naujo įrodo, kad transportas atsistatė, o ne kad blokavimas išlaikė per spragą, ir tai atskiri teiginiai bilietui. Su tuo įrašu kitas perėjimas lyginamas su žinoma būsena, o ne su atmintimi.