Kill-switch pärast üleminekut Wi-Filt mobiilivõrgule: mis katki läheb

Ühel hetkel on sülearvuti kontori Wi-Fis, järgmisel on see telefoni küljes, ja tunnelinäidik on jälle roheline, enne kui jõuate aknaid vahetada. Roheline tuli teatab ainult seda, et tunnel ühendati uuesti; mida marsruutimis- ja blokeerimispoliitika selle vahe ajal tegi, on hoopis teine küsimus. See poliitika on viimasel paigaldamisel kompileeritud vastavustingimuste hulk, mis nimetab liidest, aadressi ja aadressiperekonda, mille üleminek just eemaldas. Seetõttu annab sama lülitus kolm tulemust, mis näevad ühesugused välja: blokeerimine jätkub, poliitika blokeerib omaenda taastumise või avaneb tee, mida miski ei kata.

Ekraanil ei erista neid kolme olekut miski, seega küsige pigem, milliste identifikaatorite külge reeglid kinnitati, mitte mis värvi näidik näitab. Linuxis võib reegel nimetada liidest või sellest täidetud ipseti; Androidis saab VpnService'ile öelda, milliseid alusvõrke järgida, kasutades setUnderlyingNetworks. Iga side osutab lingile, mida hakatakse asendama, ja igaüht tuleb hiljem uuesti hinnata.

Mida üleminek tegelikult ümber kirjutab

Kui vana link kaob, eemaldab kernel selle aadressid, tõmbab tagasi marsruudid, mis selle kaudu läksid, ja ehitab allikaaadressi valiku järelejäänust uuesti üles. Vaikimisi marsruut liigub uue lüüsini ja vanade reeglite viidatud liideseindeks on kadunud või teise seadme jaoks ringlusse võetud. Lingipõhised resolverid värskendatakse samuti, kuigi mitte samal hetkel marsruutidega. Kõik see toimub VPN-kliendi all, nii et klient, kes jälgib ainult oma tunneli olekut, ei näe sellest midagi.

Häda on selles, et reegel kodeerib konkreetse identifikaatori, mitte selle taga oleva kavatsuse. Reegel, mis viskab välja kõik, mis ei lahku tunneli liidese kaudu, kodeerib liidese nime; reegel, mis lubab lõpp-punkti, kodeerib aadressi, mille uus võrk võib mujale suunata. Kui identifikaator kaob, ei muutu reegel nähtavalt valeks: see kas lakkab millegagi sobimast või hakkab sobima vale asjaga.

Välimise tunneli ülesehitamine augu tegemata

Välimine transport oli seotud vana allikaaadressiga, seega peab see avama uue soketi uuest. Kui lõpp-punkt on hostinimi, mitte sõnasõnaline aadress, peab otsing õnnestuma, kuni blokaad veel kehtib. See on järjekorra lõks: poliitika, mis on piisavalt range, et visata välja kõik peale lõpp-punkti, viskab välja ka selle leidmiseks vajaliku otsingu, kui lahendamine ei toimu enne blokaadi tõstmist või ei kandu veel elusa tunneli kaudu. Mõlemad järjekorrad võivad töötada, aga ainult siis, kui klient teab, millises ta on.

Kliendid erinevad siin viisil, mis diagnoosimisel loeb. Mõned lahendavad kõigepealt ja paigaldavad reeglid hiljem, nii et üleminek maksab nähtava katkestuse ja taastub seejärel ise; teised hoiavad blokaadi üleval ja loodavad ellujäänud tunnelile, et see otsingu kannaks, mis ebaõnnestub täielikult, kui tunnel koos lingiga suri. Laia otsese vaikimisi marsruudi lisamine ühenduvuse taastamiseks laseb testi alati läbi ja jätab alati alles selle lekke, mida te ära hoidsite.

Marsruut, mis osutab endiselt vanale lüüsile, annab sama takerdunud taastumise teisel põhjusel, seega lugege tabelit enne, kui klienti süüdistate. Allolevad käsud nimetavad liidese ja allikaaadressi, mida kernel tegelikult kasutaks, ja see otsustab ühe reaga, kas vana tee on veel paigaldatud.

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

Kui uus link toob IPv6, aga reeglid mitte

Mobiili- ja külalisvõrgud annavad sageli globaalse IPv6-prefiksi isegi siis, kui kontori juhtmega LAN ei teinud seda kunagi. Ainult IPv4-reeglitena kirjutatud poliitika, mis on enamiku käsitsi tehtud iptables- ja nftables-retseptide vaikevorm, ei kata sellest midagi. Tunnel jääb ühendatuks, IPv6 kättesaadavusega rakendused väljuvad sellest väljapoole ja näidik ei saa erinevust näidata, sest tunnel on tõesti üleval. Peegeljuhtum on sama tavaline: ainult IPv6 jaoks mõeldud reeglistik ei tee võrgus, mis v6 ei paku, üldse midagi.

Võrrelge, mida link pakub, sellega, mida poliitika mainib, ülemineku mõlemal poolel. Need käsud trükivad samu fakte, millega klient töötab:

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

Kui teine käsk trükib vaikimisi marsruudi, samal ajal kui kolmas tagastab nulli, võib uus link masina IPv6 kaudu välja viia, ilma et ükski reegel seda jälgiks. Käivitage kõik kolm pärast lülitust uuesti, sest huvitav arv on kahe käivituse vahe. Kui teine ei trüki midagi, kehtib vastupidine juhtum ja igasugune v6-rõhuline poliitika on seal vaid ehteks.

Resolver vahetab omanikku keset seanssi

Kaasaegsetes süsteemides on resolverid linkidega seotud, nii et uus link saabub uue resolverite komplektiga ja võib-olla erineva split-DNS-vaatega. systemd-resolved hoiab ühe skoobi lingi kohta ja valib nende vahel marsruudi järgi, macOS aga loeb skoobitud resolvereid dünaamilisest poest ja austab liideste järjekorda. Klient, kes paigaldab oma resolveri, võistleb lingi omaga ja võitja otsustavad prioriteedireeglid, mida keegi ei jälgi. Siis võib nimede lahendamine katki minna, samal ajal kui paketifiltreerimine teeb täpselt seda, milleks see kirjutati.

Lugege resolverit, mis on aktiivne, mitte seda, mis on seadistatud. systemd-hostis näitab alamkäsk status, milliselt lingilt iga skoop tuli ja kas private-DNS-i nimi kehtib:

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

Kui päring lahkub füüsilise lingi kaudu, mitte tunneli kaudu, kaotas klient prioriteedivõistluse ja ükski tulemüüri häälestus ei paranda nimetamist. Võrrelge päringu teed ülemineku mõlemal poolel, et näha, milline liikus. Nimi, mis lahendub privaatseks aadressiks, mida uus võrk ei suuda marsruutida, on kolmas juhtum ja see ilmneb aegumisena, mitte veana.

Harjutage üleminekut ja pidage protokolli

Reprodutseerige muudatust meelega, mitte oodake seda. Tõstke tunnel üles esimesel lingil, käivitage pikaajaline ülekanne ja korduv otsing, seejärel lülitage linki ja vaadake, milline jääb ellu. Märkige üles intervall vana lingi kadumise ja tunneli ühendatud-teate vahel, sest just selles aknas pidas poliitika vastu või mitte. Käivitage jada ka vastupidises suunas, et tulemus ei oleks ühekülgne.

Erandid vajavad omaette läbivaatust, sest vanas võrgus õigustatud möödasõit ei ole uues automaatselt õigustatud. Koduse LAN-i printeril, NAS-il või captive portal'il pole mobiilivõrgus vastet ja erand, mis nendeni jõudis, muutub reegliks, millel pole vastet.

Kirjutage üles liidesenimed, pakutavad perekonnad, kehtiv resolver ja katkestuse pikkus iga suuna kohta. Taasühendus tõestab, et transport taastus, mitte et blokaad vahe ajal vastu pidas, ja need on eraldi väited pileti jaoks. Selle protokolli abil võrreldakse järgmist üleminekut teadaoleva olekuga, mitte mäluga.