A i mbijeton një ndërprerës sigurie VPN një rindezjeje? Si ta verifikoni

Rindezja është mënyra më e zakonshme me të cilën njerëzit testojnë një ndërprerës sigurie, dhe është testi që gënjen më shpesh. Kutia e zgjedhjes në klient është thjesht një preferencë; ajo që ka rëndësi është nëse diçka imponon një bllokim midis momentit kur stiva e rrjetit ngrihet dhe momentit kur tuneli është vërtet i vendosur. Në Windows ajo diçka është zakonisht një filtër në Windows Filtering Platform, në Linux një grup rregullash i ngarkuar nga një njësi, në macOS një ankorë pf, në Android flamujt e vetë sistemit për gjithmonë-ndezur dhe bllokim. Këto rregullime sillen shumë ndryshe gjatë një rindezjeje, dhe vetëm ato në nivel platforme janë në vendin e tyre përpara se dikush të mund të hyjë.

Rindezja shtron tri pyetje të veçanta

Ndajeni pyetjen. Së pari, a ekziston politika në disk në një formë që diçka e lexon gjatë nisjes? Së dyti, a ekzekutohet ai lexues përpara se ndonjë trafik të mund të dalë? Së treti, a e mbulon politika trafikun që ju intereson, pra çdo proces, të dy familjet e adresave dhe DNS. Një po për të parën dhe një jo për të dytën prodhojnë saktësisht atë dështim që njerëzit raportojnë si një ndërprerës sigurie që nuk i mbijeton një rindezjeje: trafiku shpëton për disa sekonda gjatë nisjes, dhe askush nuk e vëren derisa dikush shkon të shohë.

Mbani shtresat të ndara. Një grup rregullash të ruajtura të murit të zjarrit, një shërbim që nis gjatë ndezjes dhe një preferencë e klientit janë tre objekte të ndryshme me tri jetëgjatësi të ndryshme. Preferenca i mbijeton rindezjeve sepse është një vlerë në një skedar konfigurimi. Rregullat janë e vetmja gjë që bllokon paketat, dhe ato zhduken bashkë me kernelin që i mbante.

Gjeni objektin që rikthen bllokimin

Në Linux rregullat e netfilter jetojnë në kernel. Asgjë nuk i shkruan ato përsëri gjatë nisjes nëse nuk e keni rregulluar: iptables-save plus netfilter-persistent, nftables.service ngarkon /etc/nftables.conf, ose një njësi systemd që ekzekuton skriptin tuaj. Kontrolloni çfarë është aktivizuar në vend të asaj që ju kujtohet se keni konfiguruar.

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

Një grup rregullash bosh disa sekonda pas nisjes është përgjigjja e pyetjes në titull. Në Windows pyesni shërbimin e klientit si niset, pastaj nxirrni gjendjen e filtrit të platformës ndërsa tuneli është poshtë.

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

Komanda e dytë shkruan wfpstate.xml në drejtorinë aktuale. Kërkoni filtra me një veprim bllokimi që ekzistojnë tashmë përpara se klienti të lidhet. Base Filtering Engine nis herët gjatë ndezjes dhe rikthen filtrat e shtuar me flamurin e përhershëm, prandaj disa ndërprerës sigurie bllokojnë trafikun përpara se të ekzistojë ndonjë dritare klienti dhe të tjerë jo. Në macOS sudo pfctl -s info raporton nëse pf është aktivizuar, sudo pfctl -s rules tregon çfarë është ngarkuar, dhe klientët VPN zakonisht i lidhin rregullat e tyre me një ankorë në vend të grupit kryesor. Një rregull që emërton utun3 mund të tregojë një ndërfaqe tjetër pas nisjes tjetër, sepse ai numër caktohet gjatë ekzekutimit.

Vëreni hendekun midis ngritjes së rrjetit dhe ngritjes së tunelit

Intervali i rrezikshëm nuk është e gjithë rindezja, është hendeku. Ndërfaqja merr një qira dhe një rrugë të paracaktuar në një moment, shërbimi VPN nis në një tjetër, dhe tuneli autentifikohet edhe më vonë, ndonjëherë vetëm pasi një përdorues hyn dhe ekzekutohet një agjent kredencialesh. Nëse bllokimi zbatohet i fundit, gjithçka në hendek del hapur.

Në hostet systemd lexoni renditjen në vend që ta hamendësoni. Ekzekutoni systemctl cat në njësitë VPN dhe të murit të zjarrit dhe kërkoni After= ose Before= ndaj network-pre.target dhe network-online.target. Një njësi e murit të zjarrit e renditur pas network-online.target humbet ndaj ndërfaqes; ajo që kërkohet nga dhe është e renditur përpara network-pre.target fiton. Në Windows pyetjet ekuivalente janë lloji i nisjes së shërbimit dhe varësitë e tij, sepse një shërbim i vendosur në Manual nuk mund të bllokojë një proces gjatë ndezjes. Nëse kërkesa juaj përfshin trafik përpara hyrjes, vetëm një rregullim në nivel pajisjeje e plotëson: një tunel pajisjeje Always On VPN autentifikohet me një certifikatë makine dhe lidhet përpara se përdoruesi të hyjë, dhe Microsoft dokumenton konfigurimin e tunelit të pajisjes veçmas nga tuneli i përdoruesit. Android merr rrugën tjetër, imponon VPN gjithmonë-ndezur dhe bllokon lidhjet pa të nga sistemi dhe jo nga një proces aplikacioni.

Ekzekutoni testin, më pas krahasoni dy vija kohore

Rindizni me një destinacion që nuk kushton asgjë nëse rrjedh, dhe kapni gjendjen gjatë hendekut në vend të pas tij. Metoda më e pastër është një sondë gjatë nisjes: një njësi oneshot ose një detyrë e planifikuar që nis sa më herët që platforma lejon, regjistron rrugën e paracaktuar dhe gjendjen e murit të zjarrit, provon një kërkesë me një afat të shkurtër dhe shton një rresht në një skedar lokal. Krahasoni atë regjistrim me kohën e nisjes së shërbimit VPN nga journalctl -b -u ose regjistri i sistemit.

Pastaj ekzekutoni testin e zakonshëm: tuneli lart, ndërpritni lidhjen, vëreni nëse trafiku i drejtpërdrejtë bllokohet, riktheni. Kalimi i të dytit dhe dështimi në të parin është rezultati normal, dhe do të thotë që zbatimi është në anën e klientit, aplikohet kur klienti lidhet dhe jo gjatë nisjes. Në makinën e fundit që auditova, bllokimi vinte nga një skript dërguesi i NetworkManager: i pranishëm dhe i saktë dhe i padobishëm për sekondat përpara se ndërfaqja të ngrihej. Shkruani të dy rezultatet, sepse mbijetesa e një rindezjeje do të thotë diçka vetëm kur thoni cila shtresë mbijetoi dhe nga cili moment.

Mbyllni hendekun pa i prerë rrugën e kthimit

Nëse bllokimi mungon gjatë nisjes, ulni zbatimin një shtresë poshtë në vend që të shtoni një rregull të dytë klienti. Ruani grupin e rregullave dhe ngarkoni atë nga një njësi e renditur përpara se rrjeti të jetë i përdorshëm, dhe sigurohuni që ajo njësi nuk ka nevojë për një kërkim DNS ose një montim rrjeti që supozohet të mbrojë. Shtrirja ka po aq rëndësi sa koha: rregullat që përputhen me një ID përdoruesi ose një cgroup lënë çdo demon sistemi jashtë bllokimit, dhe një grup rregullash që trajton vetëm IPv4 lë IPv6 dhe DNS të arritshme.

Lini vetes një rrugë kthimi. Një makinë që bllokon gjithçka gjatë nisjes dhe pastaj nuk arrin të autentifikohet nuk ka fare rrjet, dhe rregullimi nuk është të fshini bllokimin por të riparoni kredencialin ose renditjen. Mbani një procedurë të dokumentuar për konsolën lokale dhe një përjashtim të ngushtë e të qëllimshëm për atë që tuneli ka vërtet nevojë, si adresa e serverit dhe zgjidhësi i përdorur përpara se tuneli të ekzistojë.

Përpara se t'i besoni këtij rregullimi, konfirmoni katër gjëra sipas radhës. Politika është ruajtur atje ku e lexon nisja. Ai lexues ekzekutohet përpara se ndërfaqja të jetë e përdorshme. Bllokimi mbulon të dy familjet e adresave dhe DNS. VPN-ja ende mund të autentifikohet ndërsa bllokimi është aktiv. Kur të katërt vlejnë, një rindezje nuk ndryshon asgjë.