Kill-switch pēc pārejas no Wi-Fi uz mobilo tīklu: kas salūzt

Vienā mirklī klēpjdators ir biroja Wi-Fi tīklā, nākamajā tas ir pieslēgts telefonam, un tuneļa indikators atkal ir zaļš, pirms esat pabeidzis logu pārslēgšanu. Zaļa gaisma tikai ziņo, ka tunelis atkal ir pieslēdzies; ko starplaikā darīja maršrutēšanas un bloķēšanas politika, ir cits jautājums. Šī politika ir saskaņošanas nosacījumu kopa, kas kompilēta pēdējās instalēšanas laikā, un tā nosauc interfeisu, adresi un adrešu saimi, ko pāreja tikko ir noņēmusi. Tāpēc viena un tā pati pārslēgšanās dod trīs vienādi izskatīgus iznākumus: bloķēšana turpinās, politika bloķē savu atjaunošanos, vai atveras ceļš, ko nekas neaptver.

Ekrānā nekas nešķir šos trīs stāvokļus, tāpēc jautājiet, pie kuriem identifikatoriem noteikumi bija piesprausti, nevis kādu krāsu rāda indikators. Linux noteikums var nosaukt interfeisu vai no tā piepildītu ipset; Android VpnService var pateikt, kuriem pamata tīkliem sekot, izmantojot setUnderlyingNetworks. Katrs piesaistes punkts norāda uz saiti, kas tūlīt tiks nomainīta, un katrs ir jāizvērtē no jauna pēc tam.

Ko pāreja patiešām pārraksta

Kad vecā saite pazūd, kodols noņem tās adreses, atsauc maršrutus, kas gāja caur to, un no jauna veido avota adreses izvēli no tā, kas palicis. Noklusējuma maršruts pāriet uz jauno vārteju, un interfeisa indekss, uz kuru atsaucās vecie noteikumi, ir pazudis vai pārstrādāts citai ierīcei. Arī saites atrisinātāji tiek atsvaidzināti, lai gan ne tajā pašā mirklī kā maršruti. Tas viss notiek zem VPN klienta, tāpēc klients, kas vēro tikai sava tuneļa stāvokli, neko no tā neredz.

Problēma ir tā, ka noteikums kodē konkrētu identifikatoru, nevis aiz tā esošo nodomu. Noteikums, kas izmet visu, kas neiziet caur tuneļa interfeisu, kodē interfeisa nosaukumu; noteikums, kas atļauj galapunktu, kodē adresi, ko jaunais tīkls var maršrutēt citur. Kad identifikators pazūd, noteikums nepaliek redzami nepareizs: tas vai nu pārstāj ar kaut ko saskanēt, vai sāk saskanēt ar nepareizo lietu.

Ārējā tuneļa pārbūve, neizsitot caurumu

Ārējais transports bija piesaistīts vecajai avota adresei, tāpēc tam ir jāatver jauns ligzda no jaunās. Kad galapunkts ir resursdatora nosaukums, nevis burtiska adrese, meklēšanai jāizdodas, kamēr bloķēšana vēl ir spēkā. Tās ir secības slazdi: politika, kas ir pietiekami stingra, lai izmestu visu, izņemot galapunktu, izmetīs arī meklēšanu, kas nepieciešama tā atrašanai, ja vien atrisināšana nenotiek pirms bloķēšanas pacelšanas vai netiek pārnesta caur vēl dzīvu tuneli. Abas secības var darboties, bet tikai tad, ja klients zina, kurā tas atrodas.

Klienti šeit atšķiras tā, kam ir nozīme diagnostikā. Daži vispirms atrisina un pēc tam instalē noteikumus, tāpēc pāreja izmaksā redzamu pārtraukumu un pēc tam pati atjaunojas; citi tur bloķēšanu un paļaujas uz pārdzīvojušo tuneli, lai pārnestu meklēšanu, kas pilnībā neizdodas, ja tunelis nomira kopā ar saiti. Plaša tieša noklusējuma maršruta pievienošana savienojamības atjaunošanai vienmēr ļauj testam iziet un vienmēr atstāj to noplūdi, ko jūs novērsāt.

Maršruts, kas joprojām norāda uz veco vārteju, dod tādu pašu iestrēgušu atjaunošanos cita iemesla dēļ, tāpēc izlasiet tabulu, pirms vainojat klientu. Tālāk minētās komandas nosauc interfeisu un avota adresi, ko kodols patiešām izmantotu, un tas vienā rindā izšķir, vai vecais ceļš vēl ir instalēts.

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

Kad jaunā saite atnes IPv6, bet noteikumi ne

Mobilo un viesu tīkli bieži izsniedz globālu IPv6 prefiksu, pat ja biroja vadu LAN to nekad nav darījis. Politika, kas rakstīta tikai kā IPv4 noteikumi, vairuma ar roku veidotu iptables un nftables recepšu noklusējuma forma, neko no tā neaptver. Tunelis paliek pieslēgts, lietojumprogrammas ar IPv6 sasniedzamību iziet ārpus tā, un indikators nevar parādīt atšķirību, jo tunelis tiešām ir augšā. Spoguļgadījums ir tikpat izplatīts: noteikumu kopa tikai IPv6 neko nedara tīklā, kas nepiedāvā v6.

Salīdziniet, ko piedāvā saite, ar to, ko piemin politika, abās pārejas pusēs. Šīs komandas izdrukā tos pašus faktus, ar kuriem strādā klients:

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

Ja otrā komanda izdrukā noklusējuma maršrutu, bet trešā atgriež nulli, jaunā saite var izvest mašīnu ārpusē pa IPv6 bez neviena noteikuma uzraudzības. Palaidiet visas trīs vēlreiz pēc pārslēgšanās, jo interesantais skaitlis ir divu palaišanu starpība. Ja otrā neizdrukā neko, ir spēkā pretējais gadījums, un jebkura ar v6 smaga politika tur ir tikai dekorācija.

Atrisinātājs sesijas vidū maina rokas

Mūsdienu sistēmās atrisinātāji ir piesaistīti saitēm, tāpēc jauna saite nāk ar jaunu atrisinātāju kopu un varbūt citu split-DNS skatu. systemd-resolved tur vienu tvērumu katrai saitei un izvēlas starp tiem pēc maršruta, bet macOS lasa tvēruma atrisinātājus no dinamiskās krātuves un respektē interfeisu kārtību. Klients, kas instalē savu atrisinātāju, konkurē ar saites atrisinātāju, un uzvarētāju izšķir prioritātes noteikumi, kurus neviens neuzrauga. Tad nosaukumu atrisināšana var salūzt, kamēr pakešu filtrēšana dara tieši to, kam tā bija rakstīta.

Lasiet atrisinātāju, kas ir aktīvs, nevis to, kas ir konfigurēts. systemd resursdatorā apakškomanda status parāda, no kuras saites nāca katrs tvērums un vai ir spēkā private-DNS nosaukums:

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

Ja vaicājums iziet pa fizisko saiti, nevis pa tuneli, klients zaudēja prioritātes sacensībās, un nekāda ugunsmūra regulēšana nelabos nosaukšanu. Salīdziniet vaicājuma ceļu abās pārejas pusēs, lai redzētu, kura pārvietojās. Nosaukums, kas atrisinās uz privātu adresi, kuru jaunais tīkls nevar maršrutēt, ir trešais gadījums, un tas izpaužas kā noildze, nevis kā kļūda.

Praktizējiet pāreju un saglabājiet pierakstu

Atveidojiet izmaiņas tīši, nevis gaidiet tās. Paceliet tuneli pirmajā saitē, sāciet ilgstošu pārraidi un atkārtotu meklēšanu, pēc tam pārslēdziet saiti un vērojiet, kura izdzīvo. Pierakstiet intervālu starp vecās saites pazušanu un tuneļa ziņojumu, ka tas ir pieslēgts, jo tieši šajā logā politika izturēja vai neizturēja. Palaidiet secību arī pretējā virzienā, lai rezultāts nebūtu vienpusējs.

Izņēmumiem vajadzīga sava pārbaude, jo vecajā tīklā attaisnota apiešana jaunajā nav automātiski attaisnota. Mājas LAN printerim, NAS vai captive portal nav ekvivalenta mobilajā tīklā, un izņēmums, kas tiem ļāva piekļūt, kļūst par noteikumu bez ekvivalenta.

Pierakstiet interfeisu nosaukumus, piedāvātās saimes, spēkā esošo atrisinātāju un pārtraukuma ilgumu katram virzienam. Atkārtota pieslēgšanās pierāda, ka transports atjaunojās, nevis to, ka bloķēšana izturēja starplaikā, un tie ir atsevišķi apgalvojumi biļetei. Ar šo pierakstu nākamā pāreja tiek salīdzināta ar zināmu stāvokli, nevis ar atmiņu.