Miksi kill switch pudottaa liikenteen, kun vaihdat palvelinta
Miksi kill switch estää liikenteen palvelinvaihdon aikana, mitä asiakas tekee siinä ikkunassa ja miten erottaa tavallinen tauko jumiutuneesta estosta.
Valitset palvelimen, joka näyttää lähemmältä, painat yhdistä, ja selain lakkaa lataamasta ennen kuin uusi tunneli on pystyssä. Kuvake vaihtuu yhdistämistilaan ja jää siihen, kunnes jokainen välilehti aikakatkaistaan. Tauko on yleensä kill switch, joka toimii suunnitellusti: liikenne on estetty, kun asiakkaalla ei ole tunnelia, jonka kautta sen lähettää. Onko tauko hyväksyttävä, riippuu siitä, mitä asiakas noiden sekuntien aikana tekee, ja siitä, poistetaanko esto silloin, kun se sanoo poistavansa.
Mitä asiakas tekee kahden palvelimen välissä
Päätepisteen vaihto on useita vaiheita, ei yksi kytkin. Asiakas purkaa nykyisen tunnelin, päivittää estosääntönsä, selvittää uuden päätepisteen ja tavoittaa sen tunnelin ulkopuolelta, asentaa sitten uudet reitit ja poistaa eston. Kokemasi aukko on ensimmäisen ja viimeisen vaiheen välissä.
Järjestys on tässä tärkeämpi kuin nopeus. Jos estosäännöt tulevat voimaan ennen uuden päätepisteen poikkeusta, asiakas ei voi saattaa kättelyä loppuun ja jää yhdistämistilaan aikakatkaisuun asti. Jos poikkeus on kopio vanhan palvelimen osoitteesta, uusi kättely näyttää miltä tahansa lähtevältä paketilta ja pudotetaan. Molemmat tapaukset näyttävät selaimesta samalta, minkä vuoksi kuuden sekunnin kuluttua toipuva vaihto ja koskaan toipumaton voivat jakaa saman syyn.
Uusi päätepiste tarvitsee reiän estoon
Rakentaakseen tunnelin asiakkaan on lähetettävä paketteja uuden palvelimen osoitteeseen ja porttiin fyysisen liitännän kautta, esimerkiksi UDP 51820 tyypillisessä WireGuard-profiilissa tai 1194 ja 443 OpenVPN:ssä, mitä oma profiilisi sitten määrääkin. Tämä liikenne ei ole siinä tunnelissa, jota ollaan juuri luomassa, joten koko laitteen esto nielee sen, ellei vastaavaa sallintasääntöä ole.
Isäntänimeen perustuvat profiilit lisäävät toisen vaatimuksen: itse haku. Jos asiakas selvittää päätepisteen ennen eston nousua, se voi käyttää välimuistiin tallennettua osoitetta, mutta kun profiili vaihtaa osoitteita tai välimuistimerkintä vanhenee, kättely suuntautuu osoitteeseen, jota sallintasääntö ei kata. IPv6 tekee tämän näkyväksi, koska kaksoispinon päätepiste voi julkaista sekä A- että AAAA-tietueen, ja vain v4-osoitteen kattava sallintasääntö jättää asiakkaan yrittämään uudelleen estettyä v6-osoitetta vasten.
Asetusten nimet ja oletusarvot vaihtelevat asiakkaan ja version mukaan, joten lue oman asiakkaasi dokumentoitu luettelo sen sijaan, että arvailisit kuvakaappauksista. OpenVPN Connectin asetusviite osoitteessa openvpn.net/connect-docs/app-settings-windows on yksi esimerkki siitä, miten asiakas kuvaa esto- ja jaetun tunnelin asetuksensa.
Fail-closed on tilakone, ei kytkin
Useimmat asiakkaat ilmaisevat eston palomuurikäytäntönä kolmessa tilassa: tunneli ylhäällä, liikenne kulkee tunnelin kautta eikä estoa ole; tunneli alhaalla, esto on aktiivinen; ja siirtymä, jossa esto on aktiivinen sekä väliaikaiset poikkeukset päätepisteelle. Juuri kolmannessa tilassa viat asuvat, koska sen on vaihduttava kahdesti parin sekunnin sisällä, ja siitä poistumatta jääminen näyttää täsmälleen pysyvältä estolta.
Mekanismi vaihtelee alustan mukaan, ja niin myös vika. Windows Filtering Platformin suodattimilla on painot, joten sallintasi ohittava estosuodatin pudottaa paketteja edelleen, vaikka sallinta olisi olemassa, ja tapetun asiakasprosessin jälkeensä jättämät suodattimet voivat pitää koneen offline-tilassa sen jälkeen, kun sovellus on poissa. macOS-asiakkaat kirjoittavat pf-säännöt yleensä ankkuriin, jossa sääntöjärjestys ja nopeat päätökset ratkaisevat, mikä sääntö pätee. Linux-asiakkaat hallitsevat yleensä nftables- tai iptables-ketjua drop-käytännöllä ja nimenomaisilla sallinnoilla päätepisteelle, tunnelin liitännälle ja loopbackille. Androidin always-on VPN ja asetus yhteyksien estämisestä ilman VPN:ää on ryhmän tiukin, koska käyttöjärjestelmä soveltaa estoa koko laitteeseen eikä sovelluskohtaisesti.
WireGuard ansaitsee oman huomautuksensa, koska AllowedIPs on reitityksen valitsin, ei estäjä. Se päättää, mitkä kohteet menevät tunneliin; se ei tee mitään estääkseen tunnelitonta pakettia lähtemästä Wi-Fi-verkon kautta. Pelkkään WireGuardiin ja ilman palomuurisääntöä perustuvassa kokoonpanossa kill switch on oikeastaan reitin puuttuminen, ja pudotettua kättelyä voi seurata todellinen paketti, joka lähtee fyysisen liitännän kautta.
Mittaa aukko sen sijaan, että katsot kuvaketta
Seuraa paketteja, älä tilavaloa. Käynnistä Linuxissa hidas ping julkiseen osoitteeseen yhdessä päätteessä ja kaappaa tunnelin kuljetusportti fyysiseltä liitännältä toisessa:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Vaihda palvelinta asiakkaassa, kun molemmat ovat käynnissä. Kolme asiaa ratkaisee: kuinka kauan pingit pysähtyvät, näkyykö kaappauksesta kättelyn saapuvan uudelle päätepisteelle ja palautuuko liikenne ennen vai jälkeen sen, että asiakkaan tila vaihtuu yhdistetyksi. Jos ping-aukko päättyy ensin, esto on joko poistettu liian aikaisin tai tunneli on pystyssä ennen kuin ilmaisin myöntää sen. Jos aukko päättyy myöhemmin, ilmaisin on liian optimistinen.
Windowsissa netsh wfp show state kirjoittaa tilannekuvan, josta voit etsiä estosuodattimia, jotka ovat yhä olemassa asiakkaan väittäessä olevansa irrotettu. macOS:ssä sudo pfctl -sr luettelee ladatut säännöt ja niiden järjestyksen. Yhdistä kumpi tahansa tilannekuva asiakkaan omaan lokiin; pingisi aikajana kertoo, päättyikö esto myöhään vai eikö koskaan.
Tavallinen pimeneminen vastaan jumiutunut esto
Jokin keskeytys on koko ominaisuuden tarkoitus, joten arvioi tilanne ennen kuin muutat mitään asetusta:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Jos päädyt toiselle tai viidennelle riville, älä kytke kill switchiä pois testataksesi, sillä se muuttaa reititysvirheen vuodoksi. Käynnistä asiakkaan palvelu uudelleen tai käynnistä kone uudelleen siellä, missä suodattimet kestävät prosessin tappamisen, ja katso, häviääkö esto. Jos häviää, vika on vaihdon aikaisessa siivouksessa eikä itse estossa.
Varmista ennen seuraavaa vaihtoa neljä asiaa: päätepisteen sallinta kattaa jokaisen osoiteperheen, jonka profiilisi selvittää, asiakkaan loki näyttää siirtymän valmistuneen, ping-testisi mittaa aukkoa eikä kuvaketta, ja asiakkaan sulkeminen palauttaa normaalin yhteyden. Kill switch, joka pitää vaihdon aikana ja vapauttaa sen jälkeen, tekee työnsä. Se, joka vapauttaa aikaisin tai ei koskaan, kannattaa debugata.