Hvers vegna kill switch sleppir umferð þegar þú skiptir um netþjón

Þú velur netþjón sem virðist nær, ýtir á tengja, og vafrinn hættir að hlaða áður en nýi göngin eru komin upp. Táknið fer í tengistöðu og situr þar á meðan hver flipi rennur út á tíma. Þetta hlé er venjulega kill switch að vinna eins og hann var hannaður: umferð er lokuð á meðan biðlarinn hefur engin göng til að senda hana um. Hvort hléið er ásættanlegt fer eftir því hvað biðlarinn gerir á þessum sekúndum og hvort lokunin er afnumin þegar hann segist vera það.

Hvað biðlarinn gerir milli tveggja netþjóna

Skipti á endapunkti eru nokkur skref, ekki einn rofi. Biðlarinn rífur niður núverandi göng, uppfærir lokunarreglur sínar, leysir nýja endapunktinn og nær honum utan ganganna, setur síðan upp nýju leiðirnar og afléttir lokuninni. Bilið sem þú finnur fyrir er milli fyrsta og síðasta skrefs.

Röðin skiptir meira máli en hraðinn hér. Ef lokunarreglurnar ganga inn áður en undantekið fyrir nýja endapunktinn, getur biðlarinn ekki klárað handabandið og verður í tengistöðu þar til tíminn rennur út. Ef undantekið er afrit af vistfangi gamla netþjónsins lítur nýja handabandið út eins og hvert annað útleiðarpakki og er hent. Bæði tilvikin líta eins út frá vafranum, og þess vegna geta skipti sem jafna sig eftir sex sekúndur og þau sem jafna sig aldrei átt sömu orsök.

Nýi endapunkturinn þarf gat á lokuninni

Til að byggja göngin verður biðlarinn að senda pakka á vistfang og gátt nýja netþjónsins um líkamlega viðmótið, til dæmis UDP 51820 fyrir dæmigert WireGuard-sniðmát eða 1194 og 443 fyrir OpenVPN, hvað sem þitt eigið sniðmát segir til um. Sú umferð er ekki inni í göngunum sem eru að verða til, svo lokun fyrir allt tækið gleypir hana nema samsvarandi leyfisregla sé til.

Sniðmát sem byggja á hýsilheiti bæta við annarri kröfu: uppflettingunni sjálfri. Ef biðlarinn leysir endapunktinn áður en lokunin fer upp getur hann notað vistfang úr skyndiminni, en þegar sniðmátið skiptir um vistföng eða færslan í skyndiminninu verður gömul, stefnir handabandið á vistfang sem leyfisreglan nær ekki yfir. IPv6 gerir þetta sýnilegt, því endapunktur með tvöfaldan stafla getur birt bæði A- og AAAA-færslu, og leyfisregla sem nær aðeins yfir v4-vistfangið lætur biðlarann reyna aftur gegn lokuðu v6-vistfangi.

Nöfn valkosta og sjálfgefin gildi eru mismunandi eftir biðlara og útgáfu, svo lestu skjalfesta listann fyrir þinn í stað þess að giska út frá skjáskotum. Stillingarviðmið OpenVPN Connect á openvpn.net/connect-docs/app-settings-windows er eitt dæmi um hvernig biðlari lýsir lokunar- og klofnum gangavalkostum sínum.

Fail-closed er stöðuvél, ekki rofi

Flestir biðlarar tjá lokunina sem eldveggsstefnu í þremur stöðum: göng uppi, með umferð um göngin og enga lokun; göng niðri, með lokun virka; og umskipti, með lokun virka auk tímabundinna undanteka fyrir endapunktinn. Það er í þriðju stöðunni sem villurnar búa, því hún verður að breytast tvisvar innan nokkurra sekúndna, og að komast ekki út úr henni lítur nákvæmlega út eins og varanleg lokun.

Aðferðin er mismunandi eftir kerfum, og bilunin líka. Síur Windows Filtering Platform bera vægi, svo lokunarsía sem yfirgnæfir leyfið þitt heldur áfram að henda pökkum þótt leyfið sé til, og síur sem drepinn biðlaraferli skildi eftir geta haldið vélinni ótengdri eftir að forritið er horfið. macOS-biðlarar skrifa venjulega pf-reglur í akkeri, þar sem röð reglna og skjótar ákvarðanir ráða því hvaða regla gildir. Linux-biðlarar stýra venjulega nftables- eða iptables-keðju með drop-stefnu og skýrum leyfum fyrir endapunktinn, gangaviðmótið og loopback. Always-on VPN Android með valinu að loka tengingum án VPN er strangasta í hópnum, því stýrikerfið beitir lokuninni á allt tækið en ekki hvert forrit.

WireGuard þarf eigin athugasemd, því AllowedIPs er leiðarval, ekki lokari. Það ræður því hvaða áfangastaðir fara í göngin; það gerir ekkert til að stöðva pakka sem hefur ekki enn göng frá því að fara út um Wi-Fi. Í uppsetningu eingöngu með WireGuard og án eldveggsreglu er kill switch í raun fjarvera leiðar, og eftir að handabandi er hent getur raunverulegur pakki farið út um líkamlega viðmótið.

Mældu bilið í stað þess að horfa á táknið

Fylgstu með pökkum, ekki stöðuljósinu. Í Linux skaltu byrja hægt ping á opinbert vistfang í einni skjáhermi og grípa flutningsgátt ganganna á líkamlega viðmótinu í öðrum:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

Skiptu um netþjón í biðlaranum á meðan bæði keyra. Þrjú atriði skipta máli: hversu lengi pingin stöðvast, hvort grípunin sýnir handabandið ná nýja endapunktinum og hvort umferð kemur aftur fyrir eða eftir að staða biðlarans verður tengd. Ef pingbilið endar fyrst er lokunin annaðhvort afnumin of fljótt eða göngin eru uppi áður en vísirinn viðurkennir það. Ef bilið endar seinna er vísirinn of bjartsýnn.

Í Windows skrifar netsh wfp show state skyndimynd þar sem þú getur leitað að lokunarsíum sem enn eru til staðar á meðan biðlarinn segist vera aftengdur. Í macOS listar sudo pfctl -sr hlaðnar reglur og röð þeirra. Paraðu aðra skyndimyndina við eigin annál biðlarans; tímalínan úr pinginu þínu segir þér hvort lokunin endaði seint eða aldrei.

Eðlileg myrkvun á móti föstum lokun

Einhver truflun er tilgangurinn með eiginleikanum, svo flokkaðu áður en þú breytir einhverjum stillingum:

Ef þú lendir í annarri eða fimmtu röð skaltu ekki slökkva á kill switch til að prófa, því það breytir leiðarvillu í leka. Endurræstu þjónustu biðlarans, eða endurræstu vélina þar sem síur lifa af að ferli er drepið, og sjáðu svo hvort lokunin hverfur. Ef svo er er gallinn í hreinsuninni meðan á skiptunum stendur en ekki í lokuninni sjálfri.

Fyrir næstu skipti skaltu staðfesta fjögur atriði: leyfið fyrir endapunktinn nær yfir hvern þann vistfangafjölskyldu sem sniðmátið þitt leysir, annáll biðlarans sýnir lokið umskipti, pingprófið þitt mælir bilið en ekki táknin, og að loka biðlaranum endurheimtir eðlilega tengingu. Kill switch sem heldur út skiptin og sleppir svo eftir gerir sitt verk. Sá sem sleppir of fljótt, eða aldrei, er þess virði að kemba.