Kas VPN-i turvaklõps elab taaskäivituse üle? Kuidas seda kontrollida

Taaskäivitamine on kõige tavalisem viis, kuidas inimesed turvaklõpsi testivad, ja see on test, mis valetab kõige sagedamini. Kliendi märkeruut on eelistus; oluline on see, kas miski kehtestab blokeeringu hetke, mil võrgupinu tõuseb, ja hetke vahel, mil tunnel on tegelikult loodud. Windowsis on selleks miskiks tavaliselt filter Windows Filtering Platformis, Linuxis üksuse laaditud reeglistik, macOS-is pf-anker, Androidis süsteemi enda alati-sees ja lukustuse lipud. Need korraldused käituvad taaskäivituse jooksul väga erinevalt ja ainult platvormitasandi omad on paigas enne, kui keegi saab sisse logida.

Taaskäivitamine küsib kolm eraldi küsimust

Jagage küsimus. Esiteks, kas poliitika on kettal kujul, mida miski alglaadimisel loeb? Teiseks, kas see lugeja töötab enne, kui ükski liiklus saab välja minna? Kolmandaks, kas poliitika katab liikluse, mis teile loeb, see tähendab iga protsessi, mõlemad aadressiperekonnad ja DNS-i. Jah esimesele ja ei teisele annavad täpselt selle tõrke, mida inimesed teatavad turvaklõpsina, mis taaskäivitust ei ela üle: liiklus pääseb käivitumisel mõneks sekundiks välja ja keegi ei märka seda enne, kui keegi otsima läheb.

Hoidke kihid lahus. Salvestatud tulemüürireeglistik, alglaadimisel käivituv teenus ja kliendi eelistus on kolm erinevat objekti kolme erineva elueaga. Eelistus elab taaskäivitused üle, sest see on konfiguratsioonifailis olev väärtus. Reeglid on ainus asi, mis pakette blokeerib, ja need kaovad koos tuumaga, mis neid hoidis.

Leidke objekt, mis blokeeringu taastab

Linuxis elavad netfilteri reeglid tuumas. Miski ei kirjuta neid alglaadimisel tagasi, kui te pole seda korraldanud: iptables-save pluss netfilter-persistent, nftables.service laadib /etc/nftables.conf, või systemd-üksus, mis käivitab teie enda skripti. Kontrollige, mis on lubatud, mitte seda, mida te mäletate seadistanud olevat.

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

Tühi reeglistik paar sekundit pärast alglaadimist on vastus pealkirjas olevale küsimusele. Windowsis küsige klienditeenuselt, kuidas see käivitub, ja seejärel laske platvormifiltri olek välja, kui tunnel on maas.

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

Teine käsk kirjutab wfpstate.xml praegusesse kataloogi. Otsige blokeerimistoiminguga filtreid, mis on juba olemas enne, kui klient ühendub. Base Filtering Engine käivitub alglaadimise alguses ja taastab püsiva lipuga lisatud filtrid, mistõttu mõned turvaklõpsud blokeerivad liikluse enne, kui ükski kliendiaken olemas on, ja teised mitte. macOS-is sudo pfctl -s info teatab, kas pf on lubatud, sudo pfctl -s rules näitab, mis on laaditud, ja VPN-kliendid kinnitavad oma reeglid tavaliselt ankrue, mitte põhireeglistikku. Reegel, mis nimetab utun3 võib pärast järgmist alglaadimist osutada teisele liidesele, sest see number antakse tööajal.

Jälgige lünka võrgu tõusmise ja tunneli tõusmise vahel

Ohtlik intervall ei ole kogu taaskäivitamine, vaid lünk. Liides saab liisingu ja vaikimisi marsruudi ühel hetkel, VPN-teenus käivitub teisel, ja tunnel autendib veelgi hiljem, mõnikord alles pärast seda, kui kasutaja logib sisse ja mandaadiagent töötab. Kui blokeering rakendatakse viimasena, väljub kõik lüngas olev avatult.

systemd-hostides lugege järjestust, mitte ärge oletage seda. Käivitage systemctl cat VPN-i ja tulemüüri üksustel ning otsige After= või Before= suhtes network-pre.target ja network-online.target. Tulemüüriüksus, mis on järjestatud pärast network-online.target kaotab liidesele; see, mida nõuab ja mis on järjestatud enne network-pre.target võidab. Windowsis on samaväärsed küsimused teenuse käivitustüüp ja selle sõltuvused, sest Manualile seatud teenus ei saa alglaadimise protsessi blokeerida. Kui teie nõue hõlmab liiklust enne sisselogimist, rahuldab seda ainult seadmetasandi korraldus: Always On VPN seadme tunnel autendib masinasertifikaadiga ja ühendub enne, kui kasutaja sisse logib, ja Microsoft dokumenteerib seadme tunneli konfiguratsiooni kasutaja tunnelist eraldi. Android valib teise tee, kehtestades alati-ühendatud VPN-i ja blokeerides ühendused ilma selleta süsteemist, mitte rakenduse protsessist.

Käivitage test, seejärel võrrelge kahte ajajoont

Taaskäivitage sihtmärgiga, mis ei maksa midagi, kui see lekkib, ja jäädvustage olek lünga ajal, mitte pärast seda. Puhtaim meetod on alglaadimisandur: oneshot-üksus või ajastatud ülesanne, mis käivitub nii vara, kui platvorm lubab, registreerib vaikimisi marsruudi ja tulemüüri oleku, proovib ühte päringut lühikese ajalõpuga ja lisab kohalikku faili rea. Võrrelge seda kirjet VPN-teenuse algusajaga, mis on pärit journalctl -b -u või süsteemilogist.

Seejärel tehke tavaline test: tunnel üleval, katkestage ühendus, jälgige, kas otseühendus on blokeeritud, taastage. Teise läbimine ja esimese ebaõnnestumine on tavaline tulemus ja see tähendab, et jõustamine on kliendipoolne, rakendub siis, kui klient ühendub, mitte alglaadimisel. Viimasel masinal, mida ma auditeerisin, tuli blokeering NetworkManageri saatjaskriptist: olemas ja korrektne ja kasutu sekundite jaoks enne, kui liides tõusis. Kirjutage mõlemad tulemused üles, sest taaskäivituse üleelamine tähendab midagi alles siis, kui ütlete, milline kiht elas üle ja mis hetkest.

Sulgege lünk ilma tagasiteed lõikamata

Kui blokeering alglaadimisel puudub, viige jõustamine ühe kihi võrra allapoole, selle asemel et lisada teine kliendireegel. Salvestage reeglistik ja laadige see üksusest, mis on järjestatud enne, kui võrk on kasutatav, ja veenduge, et see üksus ei vaja DNS-päringut ega võrgumonteeringut, mida ta peaks kaitsma. Ulatus loeb sama palju kui ajastus: kasutaja ID või cgroupi järgi sobivad reeglid jätavad iga süsteemideemoni blokeeringust välja, ja reeglistik, mis käsitleb ainult IPv4-t, jätab IPv6 ja DNS-i kättesaadavaks.

Jätke endale tagasitee. Masinal, mis blokeerib alglaadimisel kõik ja ei suuda seejärel autentida, pole üldse võrku, ja parandus ei ole blokeeringu kustutamine, vaid mandaadi või järjestuse parandamine. Hoidke dokumenteeritud kohaliku konsooli protseduuri ja kitsast, teadlikku erandit selle jaoks, mida tunnel tõesti vajab, näiteks serveri aadress ja enne tunneli olemasolu kasutatav resolver.

Enne kui korraldust usaldate, kinnitage neli asja järjekorras. Poliitika on salvestatud sinna, kust alglaadimine loeb. See lugeja töötab enne, kui liides on kasutatav. Blokeering katab mõlemad aadressiperekonnad ja DNS-i. VPN saab blokeeringu aktiivsena veel autentida. Kui kõik neli kehtivad, ei muuda taaskäivitamine midagi.