Kill-switch Wi-Fistä mobiiliin siirtymisen jälkeen: mikä hajoaa

Yhtenä hetkenä kannettava on toimiston Wi-Fissä, seuraavana se on kytketty puhelimeen, ja tunnelin ilmaisin on taas vihreä ennen kuin ehdit vaihtaa ikkunaa. Vihreä valo kertoo vain, että tunneli yhdistettiin uudelleen; mitä reititys- ja estopolitiikka teki aukon aikana, on toinen kysymys. Tämä politiikka on joukko täsmäytysehtoja, jotka käännettiin viimeisimmän asennuksen yhteydessä, ja se nimeää liitännäisen, osoitteen ja osoiteperheen, jotka siirtymä juuri poisti. Sama vaihto tuottaa siis kolme lopputulosta, jotka näyttävät samalta: esto jatkuu, politiikka estää oman palautumisensa, tai avautuu polku, jota mikään ei kata.

Mikään ruudulla ei erota näitä kolmea tilaa, joten kysy, mihin tunnisteisiin säännöt oli kiinnitetty, sen sijaan mitä väriä ilmaisin näyttää. Linuxissa sääntö voi nimetä liitännäisen tai siitä täytetyn ipsetin; Androidissa VpnServicelle voidaan kertoa setUnderlyingNetworksin kautta, mitä taustaverkkoja seurata. Jokainen sidonta osoittaa linkkiin, joka on juuri korvautumassa, ja jokainen on arvioitava uudelleen jälkeenpäin.

Mitä siirtymä oikeastaan kirjoittaa uudelleen

Kun vanha linkki katoaa, ydin poistaa sen osoitteet, vetää takaisin sen kautta kulkeneet reitit ja rakentaa lähdeosoitteen valinnan uudelleen siitä, mitä jäljelle jäi. Oletusreitti siirtyy uudelle yhdyskäytävälle, ja liitännäisindeksi, johon vanhat säännöt viittasivat, on poissa tai kierrätetty toiselle laitteelle. Linkkikohtaiset resolverit päivitetään myös, joskaan ei samalla hetkellä kuin reitit. Kaikki tämä tapahtuu VPN-asiakkaan alapuolella, joten asiakas, joka seuraa vain oman tunnelinsa tilaa, ei näe siitä mitään.

Ongelmana on, että sääntö koodaa tietyn tunnisteen eikä sen takana olevaa aikomusta. Sääntö, joka pudottaa kaiken, mikä ei lähde tunnelin liitännäisen kautta, koodaa liitännäisen nimen; sääntö, joka sallii päätepisteen, koodaa osoitteen, jonka uusi verkko voi reitittää muualle. Kun tunniste katoaa, säännöstä ei tule näkyvästi väärää: se joko lakkaa täsmäämästä mihinkään tai alkaa täsmätä väärään asiaan.

Ulkoisen tunnelin rakentaminen uudelleen reikää tekemättä

Ulkoinen kuljetus oli sidottu vanhaan lähdeosoitteeseen, joten sen on avattava uusi socket uudesta. Kun päätepiste on isäntänimi eikä kirjaimellinen osoite, haku on onnistuttava, kun esto on vielä voimassa. Tässä on järjestyksen ansa: politiikka, joka on tarpeeksi tiukka pudottamaan kaiken paitsi päätepisteen, pudottaa myös sen löytämiseen tarvittavan haun, ellei nimien selvitys tapahdu ennen eston nostamista tai kulje vielä elossa olevan tunnelin läpi. Kumpikin järjestys voi toimia, mutta vain jos asiakas tietää, kummassa se on.

Asiakkaat eroavat tässä tavalla, jolla on merkitystä diagnosoidessa. Toiset selvittävät ensin ja asentavat säännöt vasta sitten, jolloin siirtymä maksaa näkyvän katkoksen ja palautuu sitten itsestään; toiset pitävät eston päällä ja luottavat henkiin jääneeseen tunneliin haun kuljettamisessa, mikä epäonnistuu täysin, kun tunneli kuoli linkin mukana. Laajan suoran oletusreitin lisääminen yhteyden palauttamiseksi päästää testin aina läpi ja jättää aina sen vuodon, jota olit estämässä.

Reitti, joka osoittaa yhä vanhaan yhdyskäytävään, antaa saman jumissa olevan palautumisen toisesta syystä, joten lue taulukko ennen kuin syytät asiakasta. Alla olevat komennot nimeävät liitännäisen ja lähdeosoitteen, joita ydin todella käyttäisi, ja se ratkaisee yhdellä rivillä, onko vanha polku yhä asennettuna.

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

Kun uusi linkki tuo IPv6:n eivätkä säännöt

Mobiili- ja vierasverkot jakavat usein globaalin IPv6-etuliitteen, vaikka toimiston kaapeloitu LAN ei koskaan tehnyt niin. Politiikka, joka on kirjoitettu vain IPv4-säännöiksi, useimpien käsin tehtyjen iptables- ja nftables-reseptien oletusmuoto, ei kata siitä mitään. Tunneli pysyy yhdistettynä, IPv6-tavoitettavuuden omaavat sovellukset lähtevät sen ulkopuolelle, eikä ilmaisin voi näyttää eroa, koska tunneli todella on pystyssä. Peilikuvatapaus on yhtä yleinen: vain IPv6:lle tarkoitettu sääntöjoukko ei tee mitään verkossa, joka ei tarjoa v6:ta.

Vertaile, mitä linkki tarjoaa, siihen, mitä politiikka mainitsee, siirtymän molemmin puolin. Nämä komennot tulostavat samat tosiasiat, joiden kanssa asiakas työskentelee:

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

Jos toinen komento tulostaa oletusreitin ja kolmas palauttaa nollan, uusi linkki voi viedä koneen ulos IPv6:n kautta ilman, että yksikään sääntö vahtii sitä. Aja kaikki kolme uudelleen vaihdon jälkeen, koska kiinnostava luku on kahden ajon ero. Jos toinen ei tulosta mitään, päinvastainen tapaus pätee ja mikä tahansa v6-painotteinen politiikka on siellä pelkkää koristetta.

Resolver vaihtaa omistajaa kesken istunnon

Nykyaikaisissa järjestelmissä resolverit on sidottu linkkeihin, joten uusi linkki saapuu uuden resolverijoukon ja mahdollisesti erilaisen split-DNS-näkymän kanssa. systemd-resolved pitää yhden laajuuden per linkki ja valitsee niiden välillä reitin mukaan, kun taas macOS lukee rajattuja resolvereita dynaamisesta varastosta ja kunnioittaa liitännäisten järjestystä. Asiakas, joka asentaa oman resolverinsa, kilpailee linkin oman kanssa, ja prioriteettisäännöt, joita kukaan ei seuraa, ratkaisevat voittajan. Silloin nimien selvitys voi hajota, vaikka pakettisuodatus tekee täsmälleen sen, mihin se kirjoitettiin.

Lue resolveri, joka on aktiivinen, älä sitä, joka on määritetty. systemd-isännässä alikomento status näyttää, miltä linkiltä kukin laajuus tuli ja onko private-DNS-nimi voimassa:

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

Jos kysely lähtee fyysisen linkin kautta eikä tunnelin, asiakas hävisi prioriteettikilpailun, eikä mikään palomuurin säätö korjaa nimeämistä. Vertaa kyselyn polkua siirtymän molemmin puolin nähdäksesi, kumpi siirtyi. Nimi, joka selviää yksityiseksi osoitteeksi, jota uusi verkko ei osaa reitittää, on kolmas tapaus, ja se näyttäytyy aikakatkaisuna eikä virheenä.

Harjoittele siirtymä ja pidä kirjaa

Toista muutos tarkoituksella sen sijaan, että odottaisit sitä. Nosta tunneli ensimmäisellä linkillä, käynnistä pitkäkestoinen siirto ja toistuva haku, vaihda sitten linkkiä ja katso, kumpi säilyy. Kirjaa väli vanhan linkin katoamisen ja tunnelin yhteydessä-ilmoituksen välillä, sillä juuri siinä ikkunassa politiikka joko piti tai ei. Aja sarja myös toiseen suuntaan, jotta tulos ei ole yksipuolinen.

Poikkeukset tarvitsevat oman kierroksensa, sillä vanhassa verkossa perusteltu ohitus ei ole automaattisesti perusteltu uudessa. Kotiverkon LAN:in tulostimella, NAS:lla tai captive portalilla ei ole vastinetta mobiiliverkossa, ja poikkeuksesta, joka niihin pääsi, tulee sääntö ilman vastinetta.

Kirjoita muistiin liitännäisten nimet, tarjotut perheet, voimassa oleva resolveri ja katkoksen pituus kullekin suunnalle. Uudelleenyhdistäminen todistaa, että kuljetus palautui, ei sitä että esto piti aukon aikana, ja ne ovat erillisiä väitteitä tikettiin. Tämän kirjan avulla seuraavaa siirtymää verrataan tunnettuun tilaan eikä muistiin.