Kill-switch etter byte frå Wi-Fi til mobildata: kva som knekk

I det eine augneblinken er den berbare datamaskina på Wi-Fi-en til kontoret, i det neste er ho kopla til ein telefon, og tunnelindikatoren er grøn att før du er ferdig med å byte vindauge. Eit grønt lys melder berre at tunnelen er kopla til på nytt; kva ruting- og blokkeringspolitikken gjorde i mellomtida, er eit anna spørsmål. Den politikken er eit sett av matchvilkår som vart kompilerte ved førre installasjon, og han namngir eit grensesnitt, ei adresse og ein adressefamilie som overgangen nettopp fjerna. Den same overgangen gjev difor tre utfall som ser like ut: blokkeringa held fram, politikken blokkerer si eiga gjenoppretting, eller det opnar seg ein veg som ingen ting dekkjer.

Ingen ting på skjermen skil dei tre tilstandane, så spør kva identifikatorar reglane var feste til i staden for kva farge indikatoren viser. På Linux kan ein regel namngje eit grensesnitt eller eit ipset fylt frå det; på Android kan ein VpnService få beskjed om kva underliggjande nettverk han skal fylgje via setUnderlyingNetworks. Kvar binding peikar på ei lenkje som er i ferd med å verte bytt ut, og kvar av dei må vurderast på nytt etterpå.

Kva overgangen faktisk skriv om

Når den gamle lenkja forsvinn, fjernar kjernen adressene hennar, trekkjer tilbake rutene som peika gjennom henne, og byggjer kildeadressevalet på nytt frå det som er att. Standardruta flyttar til den nye gatewayen, og grensesnittindeksen dei gamle reglane refererte til, er borte eller attbrukt for ei anna eining. Resolverar per lenkje vert òg oppdaterte, men ikkje i same augneblink som rutene. Alt dette skjer under VPN-klienten, så ein klient som berre overvakar tilstanden til sin eigen tunnel, ser ingen ting av det.

Problemet er at ein regel kodar ein bestemd identifikator i staden for føremålet bak han. Ein regel som slepp alt som ikkje går ut gjennom tunnelgrensesnittet, kodar eit grensesnittnamn; ein regel som tillèt endepunktet, kodar ei adresse som det nye nettverket kan rute ein annan stad. Når identifikatoren forsvinn, vert regelen ikkje synleg feil: han sluttar anten å matche noko eller byrjar å matche det gale.

Byggje den ytre tunnelen på nytt utan å slå hol

Den ytre transporten var bunden til den gamle kildeadressa, så han må opne ein ny socket frå den nye. Når endepunktet er eit vertsnamn og ikkje ei bokstaveleg adresse, må eit oppslag lukkast medan blokkeringa framleis gjeld. Det er ordensfella: ein politikk som er streng nok til å sleppe alt utanom endepunktet, slepp òg oppslaget som trengst for å finne det, med mindre oppløysinga skjer før blokkeringa vert heva eller vert boren gjennom ein tunnel som framleis lever. Begge rekkjefylgjene kan fungere, men berre om klienten veit kva for ei han er i.

Klientar er ulike her på ein måte som har noko å seie når du diagnostiserer. Nokre løyser opp først og installerer reglane etterpå, så ein overgang kostar eit synleg avbrot og gjenopprettar seg sjølv etterpå; andre held blokkeringa oppe og er avhengige av den overlevande tunnelen for å bere oppslaget, noko som feilar heilt når tunnelen døydde med lenkja. Å leggje til ei brei direkte standardrute for å gjenopprette sambandet får alltid testen til å bestå og etterlet alltid lekkasjen du hindra.

Ei rute som framleis peikar på den gamle gatewayen gjev den same fastlåste gjenopprettinga av ein annan grunn, så les tabellen før du klandrar klienten. Kommandoane nedanfor namngir grensesnittet og kildeadressa kjernen faktisk ville brukt, og det avgjer på éi line om den gamle vegen framleis er installert.

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

Når den nye lenkja bringar IPv6 og reglane ikkje

Mobil- og gjestenettverk deler ofte ut eit globalt IPv6-prefiks sjølv når det kabelbundne LAN-et på kontoret aldri gjorde det. Ein politikk skriven berre som IPv4-reglar, den vanlege forma for dei fleste handlaga iptables- og nftables-oppskriftene, dekkjer ingen ting av dette. Tunnelen held fram med å vere tilkopla, program med IPv6-tilgjenge går utanfor han, og indikatoren kan ikkje vise skilnaden fordi tunnelen verkeleg er oppe. Spegeltilfellet er like vanleg: eit regelsett berre for IPv6 gjer ingen ting på eit nettverk som ikkje byr på v6.

Samanlikn kva lenkja byr på med kva politikken nemner, på båe sider av overgangen. Desse kommandoane skriv ut dei same fakta som klienten arbeider med:

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

Om den andre kommandoen skriv ut ei standardrute medan den tredje returnerer null, kan den nye lenkja føre maskina ut over IPv6 utan at nokon regel passar på. Køyr alle tre på nytt etter bytet, for det interessante talet er skilnaden mellom dei to køyringane. Om den andre ikkje skriv ut noko, gjeld det motsette tilfellet, og ein kvar v6-tung politikk er der berre dekorasjon.

Resolveren skiftar hender midt i økta

På moderne system er resolverar knytte til lenkjer, så ei ny lenkje kjem med eit nytt sett resolverar og kanskje ei anna split-DNS-vising. systemd-resolved held eitt scope per lenkje og vel mellom dei etter rute, medan macOS les scopede resolverar frå det dynamiske lageret og respekterer rekkjefylgja til grensesnitta. Ein klient som installerer sin eigen resolver, konkurrerer med den til lenkja, og prioritetsreglar som ingen overvakar, avgjer vinnaren. Då kan namneoppslag knekke medan pakkefiltreringa gjer nøyaktig det ho vart skriven for.

Les resolveren som er aktiv i staden for den som er konfigurert. På ein systemd-vert viser underkommandoen status kva lenkje kvart scope kom frå, og om eit private-DNS-namn er i kraft:

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

Om spørjinga går ut gjennom den fysiske lenkja i staden for tunnelen, har klienten tapt prioritetskonkurransen, og inga brannmurjustering vil bøte på namngjevinga. Samanlikn vegen til spørjinga på båe sider av overgangen for å sjå kva for ei som flytta seg. Eit namn som løyser til ei privat adresse som det nye nettverket ikkje kan rute, er eit tredje tilfelle, og det viser seg som ein tidsavbrot og ikkje som ein feil.

Øv på overgangen og ta vare på loggen

Reproduser endringa med vilje i staden for å vente på henne. Reisa tunnelen på den første lenkja, start ein langvarig overføring og eit gjenteke oppslag, byt så lenkje og sjå kva for ei som overlever. Noter intervallet mellom at den gamle lenkja forsvinn og at tunnelen melder at han er tilkopla, for i det vindauget heldt politikken eller ikkje. Køyr sekvensen i den andre retninga òg, så resultatet ikkje vert einsidig.

Unntak treng sin eigen gjennomgang, for ein omveg som var rettferdiggjord på det gamle nettverket, er ikkje automatisk rettferdiggjord på det nye. Ein skrivar, ein NAS eller ein captive portal på heime-LAN-et har ingen motpart på mobildata, og unntaket som nådde dei, vert ein regel utan motpart.

Skriv ned grensesnittnamna, familiane som vert bydde på, den gjeldande resolveren og lengda på avbrotet for kvar retning. Ei attkopling beviser at transporten kom seg, ikkje at blokkeringa heldt i mellomtida, og det er separate påstandar for ei sak. Med den loggen vert neste overgang samanlikna med ein kjend tilstand i staden for med minnet.