Kill-switch efter skift fra Wi-Fi til mobildata: hvad der brækker

I det ene øjeblik er bærbaren på kontorets Wi-Fi, i det næste er den koblet til en telefon, og tunnelindikatoren er grøn igen, før du er færdig med at skifte vinduer. Et grønt lys fortæller kun, at tunnelen er genoprettet; hvad routing- og blokeringspolitikken gjorde i mellemtiden, er et andet spørgsmål. Den politik er et sæt matchbetingelser, der blev kompileret ved sidste installation, og som navngiver et interface, en adresse og en adressefamilie, som overdragelsen netop har fjernet. Det samme skift giver derfor tre udfald, der ser ens ud: blokeringen fortsætter, politikken blokerer sin egen genopretning, eller der åbnes en vej, som intet dækker.

Intet på skærmen adskiller de tre tilstande, så spørg hvilke identifikatorer reglerne var bundet til i stedet for hvilken farve indikatoren viser. På Linux kan en regel navngive et interface eller et ipset fyldt fra et; på Android kan en VpnService få at vide, hvilke underliggende netværk den skal følge, via setUnderlyingNetworks. Hver binding peger på et link, der er ved at blive erstattet, og hver skal genvurderes bagefter.

Hvad overdragelsen faktisk skriver om

Når det gamle link forsvinder, fjerner kernen dets adresser, trækker de ruter tilbage, der pegede gennem det, og genopbygger kildeadressevalget ud fra det, der er tilbage. Standardruten flytter til den nye gateway, og det interfaceindeks, som de gamle regler refererede, er væk eller genbrugt til en anden enhed. Resolvere pr. link opdateres også, dog ikke i samme øjeblik som ruterne. Alt dette sker under VPN-klienten, så en klient, der kun overvåger sin egen tunnels tilstand, ser intet af det.

Problemet er, at en regel indkoder en bestemt identifikator i stedet for hensigten bag den. En regel, der dropper alt, som ikke forlader gennem tunnelinterfacet, indkoder et interfacenavn; en regel, der tillader endepunktet, indkoder en adresse, som det nye netværk måske ruter andre steder hen. Når identifikatoren forsvinder, bliver reglen ikke synligt forkert; den holder enten op med at matche noget eller begynder at matche det forkerte.

Genopbyg den ydre tunnel uden at slå hul

Den ydre transport var bundet til den gamle kildeadresse, så den skal åbne en ny socket fra den nye. Når endepunktet er et værtsnavn og ikke en bogstavelig adresse, skal et opslag lykkes, mens blokeringen stadig er i kraft. Det er rækkefølgefælden: en politik, der er streng nok til at droppe alt undtagen endepunktet, dropper også det opslag, der skal til for at finde det, medmindre opløsningen sker, før blokeringen hæves, eller bæres gennem en tunnel, der stadig er i live. Begge rækkefølger kan fungere, men kun hvis klienten ved, hvilken den er i.

Klienter adskiller sig her på en måde, der betyder noget, når du diagnosticerer. Nogle opløser først og installerer regler bagefter, så en overdragelse koster et synligt afbrud og genopretter derefter sig selv; andre holder blokeringen oppe og afhænger af den overlevende tunnel til at bære opslaget, hvilket fejler helt, når tunnelen døde med linket. At tilføje en bred direkte standardrute for at genskabe forbindelsen får altid testen til at bestå og efterlader altid den lækage, du forhindrede.

En rute, der stadig peger på den gamle gateway, giver den samme fastlåste genopretning af en anden årsag, så læs tabellen, før du bebrejder klienten. Kommandoerne nedenfor navngiver det interface og den kildeadresse, som kernen reelt ville bruge, og det afgør på én linje, om den gamle vej stadig er installeret.

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

Når det nye link bringer IPv6, og reglerne ikke gør

Mobil- og gæstenetværk uddeler ofte et globalt IPv6-præfiks, selv når kontorets kablede LAN aldrig gjorde det. En politik skrevet som kun IPv4-regler, den typiske form for de fleste håndlavede iptables- og nftables-opskrifter, dækker intet af det. Tunnelen forbliver forbundet, applikationer med IPv6-rækkevidde forlader den uden om, og indikatoren kan ikke vise forskellen, fordi tunnelen virkelig er oppe. Spejltilfældet er lige så almindeligt: et regelsæt kun for IPv6 gør slet intet på et netværk, der ikke tilbyder v6.

Sammenlign, hvad linket tilbyder, med hvad politikken nævner, på begge sider af overdragelsen. Disse kommandoer udskriver de samme fakta, som klienten arbejder ud fra:

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

Hvis den anden kommando udskriver en standardrute, mens den tredje returnerer nul, kan det nye link føre maskinen ud over IPv6 uden nogen regel, der holder øje. Kør alle tre igen efter skiftet, for det interessante tal er forskellen mellem de to kørsler. Hvis den anden ikke udskriver noget, gælder det omvendte tilfælde, og enhver v6-tung politik er der blot dekoration.

Resolveren skifter hænder midt i sessionen

På moderne systemer er resolvere knyttet til links, så et nyt link ankommer med et nyt sæt resolvere og muligvis en anden split-DNS-visning. systemd-resolved holder et scope pr. link og vælger imellem dem efter rute, mens macOS læser scoped resolvere fra det dynamiske lager og respekterer interface-rækkefølgen. En klient, der installerer sin egen resolver, konkurrerer med linkets, og prioritetsregler, som ingen overvåger, afgør vinderen. Navneopløsningen kan så brække, mens pakkefiltreringen gør præcis det, den blev skrevet til.

Læs den resolver, der er aktiv, i stedet for den, der er konfigureret. På en systemd-vært viser underkommandoen status, hvilket link hvert scope kom fra, og om et private-DNS-navn er i kraft:

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

Hvis forespørgslen forlader gennem det fysiske link i stedet for tunnelen, har klienten tabt prioritetskonkurrencen, og ingen firewall-finjustering vil rette navngivningen. Sammenlign forespørgslens vej på begge sider af overdragelsen for at se, hvilken der flyttede sig. Et navn, der opløses til en privat adresse, som det nye netværk ikke kan rute, er et tredje tilfælde, og det viser sig som en timeout snarere end en fejl.

Træn overdragelsen og gem protokollen

Genskab ændringen med vilje i stedet for at vente på den. Rejs tunnelen på det første link, start en langvarig overførsel og et gentaget opslag, skift så linket og se, hvilken der overlever. Notér intervallet mellem det gamle links forsvinden og tunnelens melding om, at den er forbundet, for i det vindue holdt politikken enten eller holdt ikke. Kør sekvensen i den anden retning også, så resultatet ikke er ensidigt.

Undtagelser skal have deres egen gennemgang, for en omvej, der var berettiget på det gamle netværk, er ikke automatisk berettiget på det nye. En printer, en NAS eller en captive portal på hjemmets LAN har ingen modpart på mobilnettet, og den undtagelse, der nåede den, bliver en regel uden modpart.

Skriv interfacenavnene, de tilbudte familier, den gældende resolver og afbruddets længde ned for hver retning. En genopkobling beviser, at transporten kom sig, ikke at blokeringen holdt i mellemtiden, og det er separate påstande til en sag. Med den protokol sammenlignes den næste overdragelse med en kendt tilstand i stedet for med hukommelsen.