Kill-switch etter bytte fra Wi-Fi til mobildata: hva som knekker

I det ene øyeblikket er laptopen på kontorets Wi-Fi, i det neste er den koblet til en telefon, og tunnelindikatoren er grønn igjen før du er ferdig med å bytte vinduer. Et grønt lys melder bare at tunnelen er koblet til på nytt; hva rutings- og blokkeringspolicyen gjorde i mellomtiden, er et annet spørsmål. Den policyen er et sett matchbetingelser som ble kompilert ved forrige installasjon, og den navngir et grensesnitt, en adresse og en adressefamilie som overgangen nettopp fjernet. Den samme overgangen gir derfor tre utfall som ser like ut: blokkeringen fortsetter, policyen blokkerer sin egen gjenoppretting, eller det åpnes en vei som ingenting dekker.

Ingenting på skjermen skiller de tre tilstandene, så spør hvilke identifikatorer reglene var festet til i stedet for hvilken farge indikatoren viser. På Linux kan en regel navngi et grensesnitt eller et ipset fylt fra det; på Android kan en VpnService få beskjed om hvilke underliggende nettverk den skal følge via setUnderlyingNetworks. Hver binding peker på en lenke som er i ferd med å bli erstattet, og hver av dem må vurderes på nytt etterpå.

Hva overgangen faktisk skriver om

Når den gamle lenken forsvinner, fjerner kjernen adressene dens, trekker tilbake rutene som pekte gjennom den, og bygger kildeadressevalget på nytt fra det som er igjen. Standardruten flytter til den nye gatewayen, og grensesnittindeksen de gamle reglene refererte til, er borte eller gjenbrukt for en annen enhet. Resolvere per lenke oppdateres også, men ikke i samme øyeblikk som rutene. Alt dette skjer under VPN-klienten, så en klient som bare overvåker sin egen tunnels tilstand, ser ingenting av det.

Problemet er at en regel koder en bestemt identifikator i stedet for hensikten bak den. En regel som slipper alt som ikke går ut gjennom tunnelgrensesnittet, koder et grensesnittnavn; en regel som tillater endepunktet, koder en adresse som det nye nettverket kan rute et annet sted. Når identifikatoren forsvinner, blir regelen ikke synlig feil: den slutter enten å matche noe eller begynner å matche det gale.

Bygge den ytre tunnelen på nytt uten å slå hull

Den ytre transporten var bundet til den gamle kildeadressen, så den må åpne en ny socket fra den nye. Når endepunktet er et vertsnavn og ikke en bokstavelig adresse, må et oppslag lykkes mens blokkeringen fortsatt gjelder. Det er ordensfellen: en policy som er streng nok til å slippe alt unntatt endepunktet, slipper også oppslaget som trengs for å finne det, med mindre oppløsningen skjer før blokkeringen heves eller bæres gjennom en tunnel som fortsatt lever. Begge rekkefølgene kan fungere, men bare hvis klienten vet hvilken den er i.

Klienter er forskjellige her på en måte som betyr noe når du diagnostiserer. Noen løser opp først og installerer reglene etterpå, så en overgang koster et synlig avbrudd og gjenoppretter seg selv etterpå; andre holder blokkeringen oppe og er avhengige av den overlevende tunnelen for å bære oppslaget, noe som feiler helt når tunnelen døde med lenken. Å legge til en bred direkte standardrute for å gjenopprette tilkoblingen får alltid testen til å bestå og etterlater alltid lekkasjen du forhindret.

En rute som fortsatt peker på den gamle gatewayen gir den samme fastlåste gjenopprettingen av en annen årsak, så les tabellen før du klandrer klienten. Kommandoene nedenfor navngir grensesnittet og kildeadressen kjernen faktisk ville brukt, og det avgjør på én linje om den gamle veien fortsatt er installert.

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

Når den nye lenken bringer IPv6 og reglene ikke

Mobil- og gjestenettverk deler ofte ut et globalt IPv6-prefiks selv når kontorets kablede LAN aldri gjorde det. En policy skrevet bare som IPv4-regler, den vanlige formen for de fleste håndlagde iptables- og nftables-oppskriftene, dekker ingenting av dette. Tunnelen forblir tilkoblet, applikasjoner med IPv6-tilgjengelighet går utenfor den, og indikatoren kan ikke vise forskjellen fordi tunnelen virkelig er oppe. Speiltilfellet er like vanlig: et regelsett bare for IPv6 gjør ingenting i det hele tatt på et nettverk som ikke tilbyr v6.

Sammenlign hva lenken tilbyr med hva policyen nevner, på begge sider av overgangen. Disse kommandoene skriver ut de samme fakta som klienten arbeider med:

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

Hvis den andre kommandoen skriver ut en standardrute mens den tredje returnerer null, kan den nye lenken føre maskinen ut over IPv6 uten at noen regel passer på. Kjør alle tre på nytt etter byttet, for det interessante tallet er forskjellen mellom de to kjøringene. Hvis den andre ikke skriver ut noe, gjelder det motsatte tilfellet, og enhver v6-tung policy er der bare dekorasjon.

Resolveren skifter hender midt i økten

På moderne systemer er resolvere knyttet til lenker, så en ny lenke kommer med et nytt sett resolvere og kanskje en annen split-DNS-visning. systemd-resolved holder ett scope per lenke og velger mellom dem etter rute, mens macOS leser scopede resolvere fra det dynamiske lageret og respekterer grensesnittrekkefølgen. En klient som installerer sin egen resolver, konkurrerer med lenkens, og prioritetsregler som ingen overvåker, avgjør vinneren. Da kan navneoppslag knekke mens pakkefiltreringen gjør nøyaktig det den ble skrevet for.

Les resolveren som er aktiv i stedet for den som er konfigurert. På en systemd-vert viser underkommandoen status hvilken lenke hvert scope kom fra, og om et private-DNS-navn er i kraft:

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

Hvis spørringen går ut gjennom den fysiske lenken i stedet for tunnelen, har klienten tapt prioritetskonkurransen, og ingen brannmurjustering vil reparere navngivningen. Sammenlign spørringens vei på begge sider av overgangen for å se hvilken som flyttet seg. Et navn som løses til en privat adresse som det nye nettverket ikke kan rute, er et tredje tilfelle, og det viser seg som en tidsavbrudd og ikke som en feil.

Øv på overgangen og ta vare på loggen

Reproduser endringen med vilje i stedet for å vente på den. Rejs tunnelen på den første lenken, start en langvarig overføring og et gjentatt oppslag, bytt så lenke og se hvilken som overlever. Noter intervallet mellom at den gamle lenken forsvinner og at tunnelen melder at den er tilkoblet, for i det vinduet holdt policyen eller ikke. Kjør sekvensen i den andre retningen også, så resultatet ikke blir ensidig.

Unntak trenger sin egen gjennomgang, for en omvei som var berettiget på det gamle nettverket, er ikke automatisk berettiget på det nye. En skriver, en NAS eller en captive portal på hjemme-LAN-et har ingen motpart på mobilnettet, og unntaket som nådde dem, blir en regel uten motpart.

Skriv ned grensesnittnavnene, familiene som tilbys, den gjeldende resolveren og lengden på avbruddet for hver retning. En gjentilkobling beviser at transporten kom seg, ikke at blokkeringen holdt i mellomtiden, og det er separate påstander for en sak. Med den loggen sammenlignes neste overgang med en kjent tilstand i stedet for med hukommelsen.