Stenst neyðarrof VPN endurræsingu? Hvernig á að staðfesta það

Endurræsing er algengasta leiðin sem fólk notar til að prófa neyðarrof, og það er prófið sem lýgur oftast. Gátreiturinn í biðlarar er val; það sem skiptir máli er hvort eitthvað þvingi lokun milli augnabliksins þegar netstaflinn rís og augnabliksins þegar göngin eru í raun komin á. Í Windows er það eitthvað yfirleitt sía í Windows Filtering Platform, í Linux reglusett sem eining hleður, í macOS pf-akkeri, í Android eigin fánar kerfisins fyrir alltaf-á og læsingu. Þessar ráðstafanir hegða sér mjög ólíkt í gegnum endurræsingu, og aðeins þær á vettvangstigi eru til staðar áður en nokkur getur skráð sig inn.

Endurræsing setur þrjár aðskildar spurningar

Skiptu spurningunni. Í fyrsta lagi, er stefnan á diskinum í formi sem eitthvað les við ræsingu? Í öðru lagi, keyrir sá lesandi áður en nokkur umferð getur farið út? Í þriðja lagi, nær stefnan yfir umferðina sem þér er annt um, það er hvert ferli, báðar vistfangafjölskyldur og DNS. Já við þeirri fyrstu og nei við þeirri annarri framleiða nákvæmlega þá bilun sem fólk tilkynnir sem neyðarrof sem stenst ekki endurræsingu: umferð sleppur út í nokkrar sekúndur við ræsingu, og enginn tekur eftir því fyrr en einhver fer að skoða.

Haltu lögunum aðskildum. Vistað reglusett eldveggs, þjónusta sem byrjar við ræsingu og val biðlarans eru þrjú ólík hlutir með þrjú ólík líftíma. Valið stenst endurræsingar vegna þess að það er gildi í stillingaskrá. Reglurnar eru það eina sem lokar pakkana, og þær hverfa með kjarnanum sem hélt þeim.

Finndu hlutinn sem endurheimtir lokunina

Í Linux búa netfilter-reglur í kjarnanum. Ekkert skrifar þær til baka við ræsingu nema þú hafir komið því við: iptables-save plús netfilter-persistent, nftables.service hleður /etc/nftables.conf, eða systemd-eining sem keyrir þitt eigið skript. Athugaðu hvað er virkt í stað þess sem þú manst að þú stilltir.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Tómt reglusett nokkrum sekúndum eftir ræsingu er svarið við spurningunni í titlinum. Í Windows skaltu spyrja biðlaraþjónustuna hvernig hún byrjar og dumpa síðan stöðu vettvangssíunnar meðan göngin eru niðri.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Önnur skipunin skrifar wfpstate.xml í núverandi möppu. Leitaðu að síum með lokunaraðgerð sem eru þegar til áður en biðlarinn tengist. Base Filtering Engine byrjar snemma við ræsingu og endurheimtir síur sem bætt var við með varanlega fánanum, þess vegna loka sum neyðarrof á umferð áður en nokkur biðlaragluggi er til og önnur ekki. Í macOS segir sudo pfctl -s info til um hvort pf sé virkt, sudo pfctl -s rules sýnir hvað er hlaðið, og VPN-biðlarar festa reglur sínar yfirleitt við akkeri í stað aðalreglupakans. Regla sem nefnir utun3 getur eftir næstu ræsingu bent á annað viðmót, því sú tala er úthlutuð á keyrslutíma.

Fylgstu með bilinu milli netupps og gönguupps

Hættulega bilið er ekki öll endurræsingin, heldur bilið. Viðmótið fær leigu og sjálfgefna leið á einum tímapunkti, VPN-þjónustan byrjar á öðrum, og göngin auðkenna sig enn síðar, stundum aðeins eftir að notandi skráir sig inn og auðkennisumboðsmaður hefur keyrt. Ef lokuninni er beitt síðast fer allt í bilinu út óvarið.

Á systemd-hýslum skaltu lesa röðina í stað þess að giska á hana. Keyrðu systemctl cat á VPN- og eldveggseiningarnar og leitaðu að After= eða Before= gagnvart network-pre.target og network-online.target. Eldveggseining sem er raðað eftir network-online.target tapar fyrir viðmótinu; sú sem network-pre.target krefst og er raðað á undan henni vinnur. Í Windows eru samsvarandi spurningar ræsingartegund þjónustunnar og háð hennar, því þjónusta stillt á Manual getur ekki lokað ræsingarferli. Ef krafan þín nær yfir umferð fyrir innskráningu, fullnægir aðeins fyrirkomulag á tækjastigi henni: Always On VPN tækjagöng auðkenna sig með vélarvottorði og tengjast áður en notandinn skráir sig inn, og Microsoft skjalfestir stillingu tækjaganganna aðskilið frá notandagöngunum. Android fer aðra leið, þvingar alltaf-á VPN og lokar tengingum án þess frá kerfinu en ekki frá ferli forrits.

Keyrðu prófið og berðu síðan saman tvær tímalínur

Endurræstu með áfangastað sem kostar ekkert ef hann lekur, og fangaðu stöðuna í bilinu í stað þess eftir það. Hreinasta aðferðin er ræsingarskynjari: oneshot-eining eða tímasett verk sem byrjar eins snemma og vettvangurinn leyfir, skráir sjálfgefnu leiðina og stöðu eldveggsins, reynir eina beiðni með stuttum tímanum og bætir línu við staðbundið skrá. Berðu þá skrá saman við byrjunartíma VPN-þjónustunnar úr journalctl -b -u eða kerfislogginu.

Keyrðu síðan venjulega prófið: göng uppi, rofa tenginguna, fylgstu með hvort bein umferð sé lokuð, endurheimtu. Að standast hið síðara og falla á hinu fyrra er eðlileg niðurstaða, og það þýðir að framfylgdin er á biðlarahlið, beitt þegar biðlarinn tengist en ekki við ræsingu. Á síðustu vélinni sem ég skoðaði kom lokunin frá sendiskripti NetworkManager: til staðar og rétt og gagnslaust fyrir sekúndurnar áður en viðmótið rís. Skrifaðu báðar niðurstöður niður, því að standast endurræsingu þýðir aðeins eitthvað þegar þú segir hvaða lag stóðst og frá hvaða augnabliki.

Lokaðu bilinu án þess að brjóta leiðina til baka

Ef lokunin vantar við ræsingu skaltu færa framfylgdina eitt lag niður í stað þess að bæta við annarri biðlarareglu. Vistaðu reglusettið og hlaðið því úr einingu sem er raðað áður en netið verður nothæft, og gakktu úr skugga um að sú eining þurfi hvorki DNS-uppflettingu né netuppsetningu sem hún á að verja. Umfangið skiptir jafn miklu og tímasetningin: reglur sem passa við notandaauðkenni eða cgroup skilja hvern kerfisdæma eftir utan lokunarinnar, og reglusett sem meðhöndlar aðeins IPv4 skilur IPv6 og DNS eftir aðgengileg.

Skildu eftir þér leið til baka. Vél sem lokar öllu við ræsingu og getur síðan ekki auðkennt sig hefur ekkert net yfirleitt, og lagfæringin er ekki að eyða lokuninni heldur að laga auðkennið eða röðina. Hafðu skjalfesta aðferð fyrir staðbundna stjórnborð og þrönga, viljandi undantekningu fyrir það sem göngin þurfa raunverulega, svo sem vistfangið á netþjóninum og uppflettirinn sem notaður er áður en göngin eru til.

Áður en þú treystir fyrirkomulaginu skaltu staðfesta fjóra hluti í röð. Stefnan er geymd þar sem ræsingin les. Sá lesandi keyrir áður en viðmótið er nothæft. Lokunin nær yfir báðar vistfangafjölskyldur og DNS. VPN getur enn auðkennt sig meðan lokunin er virk. Þegar allir fjórir standast breytir endurræsing engu.