Túléli a VPN vészkapcsolója az újraindítást? Így ellenőrizheti

Az újraindítás a leggyakoribb módja annak, ahogy az emberek a vészkapcsolót tesztelik, és ez az a teszt, amelyik a legtöbbször hazudik. Az ügyfél jelölőnégyzete csak egy beállítás; az számít, hogy valami kikényszeríti-e a blokkolást a hálózati verem felemelkedésének pillanata és az alagút tényleges létrejöttének pillanata között. Windows alatt ez a valami általában egy szűrő a Windows Filtering Platformban, Linux alatt egy egység által betöltött szabálykészlet, macOS alatt egy pf-horgony, Android alatt a rendszer saját mindig-be és zárolás jelzői. Ezek az elrendezések nagyon eltérően viselkednek egy újraindítás során, és csak a platformszintűek vannak a helyükön, mielőtt bárki bejelentkezhetne.

Az újraindítás három külön kérdést tesz fel

Bontsa szét a kérdést. Először, létezik-e a házirend a lemezen olyan formában, amelyet valami olvas a rendszerindításkor? Másodszor, fut-e ez az olvasó, mielőtt bármilyen forgalom kimehetne? Harmadszor, lefedi-e a házirend az Önt érdeklő forgalmat, azaz minden folyamatot, mindkét címcsaládot és a DNS-t. Az elsőre adott igen és a másodikra adott nem pontosan azt a hibát hozza létre, amelyet az emberek úgy jelentenek, mint az újraindítást túl nem élő vészkapcsolót: a forgalom indításkor néhány másodpercig kiszökik, és senki sem veszi észre, amíg valaki utánanézni nem megy.

Tartsa külön a rétegeket. A mentett tűzfalszabály-készlet, az indításkor elinduló szolgáltatás és az ügyfélbeállítás három különböző objektum három különböző élettartammal. A beállítás azért éli túl az újraindításokat, mert egy érték egy konfigurációs fájlban. A szabályok az egyetlen dolog, ami blokkolja a csomagokat, és azok eltűnnek a kernellel együtt, amely megtartotta őket.

Keresse meg azt az objektumot, amely visszaállítja a blokkolást

Linux alatt a netfilter szabályok a kernelben élnek. Semmi nem írja vissza őket indításkor, hacsak nem rendezte így: iptables-save plusz netfilter-persistent, a nftables.service betölti a /etc/nftables.conf fájlt, vagy egy systemd-egység, amely a saját parancsfájlját futtatja. Azt ellenőrizze, mi van engedélyezve, ne pedig azt, amire emlékszik, hogy beállította.

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

Egy üres szabálykészlet néhány másodperccel az indítás után a válasz a címben feltett kérdésre. Windows alatt kérdezze meg az ügyfélszolgáltatást, hogyan indul, majd mentse ki a platformszűrő állapotát, amíg az alagút le van.

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

A második parancs az aktuális könyvtárba írja a wfpstate.xml fájlt. Keressen blokkoló műveletű szűrőket, amelyek már léteznek, mielőtt az ügyfél csatlakozna. A Base Filtering Engine korán elindul az indításkor, és visszaállítja a tartós jelzővel hozzáadott szűrőket, ezért egyes vészkapcsolók blokkolják a forgalmat, mielőtt bármilyen ügyfélablak létezne, mások nem. macOS alatt a sudo pfctl -s info jelenti, hogy a pf engedélyezve van-e, a sudo pfctl -s rules megmutatja, mi van betöltve, és a VPN-ügyfelek általában egy horgonyhoz csatolják a szabályaikat a fő szabálykészlet helyett. Egy szabály, amely a utun3 nevet említi, a következő indítás után más interfészre mutathat, mert azt a számot futásidőben osztják ki.

Figyelje a rést a hálózat felemelkedése és az alagút felemelkedése között

A veszélyes intervallum nem a teljes újraindítás, hanem a rés. Az interfész az egyik pillanatban bérletet és alapértelmezett útvonalat kap, a VPN-szolgáltatás egy másikban indul, az alagút pedig még később hitelesít, néha csak azután, hogy egy felhasználó bejelentkezett és egy hitelesítőadat-ügynök lefutott. Ha a blokkolást utolsóként alkalmazzák, minden, ami a résben van, nyíltan kimegy.

systemd-gazdagépeken olvassa el a sorrendet, ne találgassa. Futtassa a systemctl cat parancsot a VPN- és tűzfal-egységeken, és keresse a After= vagy a Before= előfordulását a network-pre.target és a network-online.target vonatkozásában. Egy tűzfal-egység, amely a network-online.target után van sorolva, veszít az interfésszel szemben; az, amelyet a network-pre.target megkövetel és amely előtte van sorolva, nyer. Windows alatt a megfelelő kérdések a szolgáltatás indítási típusa és függőségei, mert a Manual értékre állított szolgáltatás nem tud blokkolni egy indítási folyamatot. Ha a követelménye bejelentkezés előtti forgalmat is tartalmaz, csak egy eszközszintű elrendezés elégíti ki: az Always On VPN eszközalagút gépi tanúsítvánnyal hitelesít, és a felhasználó bejelentkezése előtt csatlakozik, és a Microsoft dokumentálja az eszközalagút konfigurációját a felhasználói alagúttól elkülönítve. Az Android a másik utat választja, kikényszeríti a mindig bekapcsolt VPN-t, és az enélküli kapcsolatokat a rendszerből blokkolja, nem egy alkalmazásfolyamatból.

Futtassa a tesztet, majd hasonlítson össze két idővonalat

Indítsa újra egy olyan céllal, amely semmibe nem kerül, ha kiszivárog, és a rés alatt rögzítse az állapotot, nem utána. A legtisztább módszer egy indítási szonda: egy oneshot-egység vagy egy ütemezett feladat, amely a legkorábban indul, amit a platform enged, rögzíti az alapértelmezett útvonalat és a tűzfal állapotát, megpróbál egy kérést rövid időkorláttal, és egy sort fűz egy helyi fájlhoz. Hasonlítsa össze ezt a feljegyzést a VPN-szolgáltatás indulási idejével, amely a journalctl -b -u vagy a rendszernapló alapján áll rendelkezésre.

Aztán futtassa a szokásos tesztet: alagút fent, szakítsa meg a kapcsolatot, nézze meg, blokkolódik-e a közvetlen forgalom, állítsa helyre. A második átmenése és az első elbukása a normális eredmény, és azt jelenti, hogy a kikényszerítés ügyféloldali, az ügyfél csatlakozásakor érvényesül, nem indításkor. Az utolsó gépen, amelyet auditáltam, a blokkolás egy NetworkManager-dispatcher parancsfájlból jött: jelen volt és helyes és haszontalan azokra a másodpercekre, mielőtt az interfész felemelkedett. Írja fel mindkét eredményt, mert az újraindítás túlélése csak akkor jelent valamit, ha megmondja, melyik réteg élte túl, és melyik pillanattól.

Zárja be a rést anélkül, hogy elvágná a visszautat

Ha a blokkolás hiányzik indításkor, vigye lejjebb a kikényszerítést egy réteggel, ahelyett hogy egy második ügyfélszabályt adna hozzá. Mentse el a szabálykészletet, és töltsön be egy olyan egységből, amely a hálózat használhatóvá válása előtt van sorolva, és győződjön meg róla, hogy annak az egységnek nincs szüksége DNS-lekérdezésre vagy hálózati csatolásra, amelyet védenie kellene. A hatókör ugyanolyan fontos, mint az időzítés: a felhasználói azonosítóra vagy cgroupra illeszkedő szabályok minden rendszerdémont a blokkoláson kívül hagynak, és egy csak IPv4-et kezelő szabálykészlet elérhetővé hagyja az IPv6-ot és a DNS-t.

Hagyjon magának visszautat. Egy gép, amely indításkor mindent blokkol, majd nem tud hitelesíteni, egyáltalán nem rendelkezik hálózattal, és a javítás nem a blokkolás törlése, hanem a hitelesítő adat vagy a sorrend rendbetétele. Tartson fenn dokumentált helyi konzol-eljárást és egy szűk, szándékos kivételt azért, amire az alagútnak valóban szüksége van, például a kiszolgáló címét és az alagút létezése előtt használt feloldót.

Mielőtt megbízik az elrendezésben, sorrendben erősítsen meg négy dolgot. A házirend ott van tárolva, ahonnan az indítás olvas. Az az olvasó az interfész használhatóvá válása előtt fut. A blokkolás mindkét címcsaládot és a DNS-t lefedi. A VPN a blokkolás aktív állapotában is tud hitelesíteni. Ha mind a négy teljesül, az újraindítás semmit nem változtat.