Kill-switch nei in oergong fan Wi-Fi nei mobyl: wat brekt

It iene momint is de laptop op it kantoar-Wi-Fi, it oare momint sit er oan in tillefoan, en de tunnelindikator is wer grien foardat jo klear binne mei it wikseljen fan finsters. In grien ljocht meldt allinnich dat de tunnel wer ferbûn is; wat it routing- en blokkearbelied yn 'e tuskentiid die, is in oare fraach. Dat belied is in set oerienkomstbetingsten dy't by de lêste ynstallaasje kompilearre binne, en neamt in ynterface, in adres en in adresfamylje dy't de oergong krekt fuortsmiten hat. Deselde wiksel jout dus trije útkomsten dy't gelyk lykje: de blokkade giet troch, it belied blokkearret syn eigen herstel, of der iepenet in paad dat neat dekt.

Neat op it skerm skiedt dy trije tastannen, freegje dus oan hokker identifikaasjes de regels fêstset wiene ynstee fan hokker kleur de indikator toant. Op Linux kin in regel in ynterface neame of in ipset dat fan ien folle wurdt; op Android kin oan in VpnService sein wurde hokker ûnderlizzende netwurken te folgjen fia setUnderlyingNetworks. Eltse bining wiist nei in keppeling dy't op it punt stiet ferfongen te wurden, en elk moat dêrnei opnij evaluearre wurde.

Wat de oergong eins oerskriuwt

As de âlde keppeling ferdwynt, smyt de kernel syn adressen fuort, lûkt de routes werom dy't der trochhinne gienen, en bout de boarneadreskar wer op út wat oerbliuwt. De standertroute ferhuzet nei de nije gateway, en de ynterface-yndeks dêr't de âlde regels nei ferwiisden is fuort of recyclet foar in oar apparaat. Resolvers per keppeling wurde ek ferfarske, al is dat net op itselde momint as de routes. Dit alles bart ûnder de VPN-klant, dus in klant dy't allinnich nei syn eigen tunnelstân sjocht, merkt dêr neat fan.

It probleem is dat in regel in spesifyk identifikaasje kodearret ynstee fan de bedoeling dêrefter. In regel dy't alles fuortsmiten dat net troch de tunnelinterface fuortgiet, kodearret in ynterfacenamme; in regel dy't it einpunt tastiet, kodearret in adres dat it nije netwurk earne oars hinne routedzje kin. As it identifikaasje ferdwynt, wurdt de regel net sichtber ferkeard: hy hâldt óf op mei alles te oerienkommen óf begjint mei it ferkearde ding oerien te kommen.

De bûtenste tunnel wer opbouwe sûnder in gat te slaan

It bûtenste transport wie bûn oan it âlde boarneadres, dus it moat in nije socket fan it nije iepenje. As it einpunt in hostnamme is ynstee fan in letterlik adres, moat in sykaksje slagje wylst de blokkade noch fan krêft is. Dat is de falstrik fan 'e folchoarder: in belied dat strang genôch is om alles behalve it einpunt fuort te smiten, smyt ek de sykaksje fuort dy't nedich is om it te finen, útsein as de resolúsje bart foardat de blokkade opheft wurdt of troch in tunnel droegen wurdt dy't noch libbet. Beide folchoarders kinne wurkje, mar allinnich as de klant wit yn hokker er sit.

Klanten ferskille hjir op in manier dy't by diagnoaze fan belang is. Guon resolvje earst en ynstallearje de regels dêrnei, sadat in oergong in sichtbere ûnderbrekking kostet en him dêrnei fan sels herstelt; oaren hâlde de blokkade oerein en fertrouwe op 'e oerlibjende tunnel om de sykaksje te dragen, wat folslein mislearret as de tunnel mei de keppeling stoar. In breed direkt standertpaad tafoegje om ferbining werom te krijen lit de test altyd slagje en lit altyd it lek efter dat jo foarkamen.

In route dy't noch nei de âlde gateway wiist jout itselde fêstsittende herstel fan in oare oarsaak, lês dus de tabel foardat jo de klant de skuld jouwe. De opdrachten hjirûnder neame de ynterface en it boarneadres dy't de kernel echt brûke soe, en dat beslút yn ien rigel oft it âlde paad noch ynstallearre is.

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

As de nije keppeling IPv6 bringt en de regels net

Mobyle en gastnetwurken jouwe faak in globaal IPv6-prefiks út, sels as it bekabelde LAN fan it kantoar dat nea die. In belied skreaun as allinnich IPv4-regels, de standertfoarm fan 'e measte mei de hân makke iptables- en nftables-resepten, dekt dêr neat fan. De tunnel bliuwt ferbûn, applikaasjes mei IPv6-berikberens geane der bûten, en de indikator kin it ferskil net sjen litte om't de tunnel echt oan is. It spegelgefal is like gewoan: in regelset allinnich foar IPv6 docht hielendal neat op in netwurk dat gjin v6 biedt.

Fergelykje wat de keppeling biedt mei wat it belied neamt, oan beide kanten fan 'e oergong. Dizze opdrachten printsje deselde feiten dêr't de klant mei wurket:

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

As de twadde opdracht in standertroute printet wylst de tredde nul weromjout, kin de nije keppeling de masjine oer IPv6 fuortstjoere sûnder dat in regel derop achtet. Rin alle trije wer nei de wiksel, want it nijsgjirrige getal is it ferskil tusken de twa rinnen. As de twadde neat printet, jildt it omkearde gefal en is elk v6-swier belied dêr gewoan fersiering.

De resolver wikselet midden yn 'e sesje fan hannen

Op moderne systemen binne resolvers oan keppelingen bûn, dus in nije keppeling komt mei in nije resolverset en mooglik in oare split-DNS-byld. systemd-resolved hâldt in scope per keppeling en kiest dêr tusken op basis fan 'e route, wylst macOS scoped resolvers út it dynamyske depot lêst en de oarder fan ynterfaces respektearret. In klant dy't syn eigen resolver ynstallearret, konkurrearret mei dy fan 'e keppeling, en priorititeitsregels dêr't nimmen nei sjocht beslisse de winner. Dan kin namme-resolúsje brekke wylst pakketfiltering krekt docht wêr't it foar skreaun is.

Lês de resolver dy't aktyf is ynstee fan dy't konfigurearre is. Op in systemd-host lit de subopdracht status sjen fan hokker keppeling elk scope kaam en oft in private-DNS-namme fan krêft is:

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

As de fraach oer de fysike keppeling fuortgiet ynstee fan oer de tunnel, hat de klant de prioriteitswedstriid ferlern en gjin firewall-oanpassing sil de nammejouwing reparearje. Fergelykje it paad fan 'e fraach oan beide kanten fan 'e oergong om te sjen hokker ferhuze is. In namme dy't resolvet nei in privee-adres dat it nije netwurk net routearje kin, is in tredde gefal, en it docht him foar as in time-out ynstee fan in flater.

Oefenje de oergong en hâld it rekord by

Reprodusearje de feroaring mei opsetsin ynstee fan derop te wachtsjen. Bring de tunnel omheech op 'e earste keppeling, start in langduorjende oerdracht en in werhelle sykaksje, wikselje dan de keppeling en sjoch hokker oerlibbet. Notearje it ynterval tusken it ferdwinen fan 'e âlde keppeling en it berjocht fan 'e tunnel dat er ferbûn is, want yn dat finster hold it belied it óf net. Rin de sekwinsje ek yn 'e oare rjochting, sadat it resultaat net iensidich is.

Utspinnings hawwe har eigen trochgong nedich, want in omgong dy't op it âlde netwurk rjochtfeardige wie, is op it nije net automatysk rjochtfeardige. In printer, in NAS of in captive portal op it thús-LAN hat gjin wjergader op mobyl, en de útsûndering dy't der kaam, wurdt in regel sûnder wjergader.

Skriuw de ynterfacenammen, de beanen famyljes, de jildende resolver en de lingte fan 'e ûnderbrekking foar elke rjochting op. In werferbining bewiist dat it transport him hersteld hat, net dat de blokkade yn 'e tuskentiid hold, en dat binne aparte bewearings foar in ticket. Mei dat rekord wurdt de folgjende oergong fergelike mei in bekende tastân ynstee fan mei it ûnthâld.