Ar VPN apsaugos jungiklis išlieka po perkrovimo? Kaip tai patikrinti

Perkrovimas yra dažniausias būdas, kuriuo žmonės tikrina apsaugos jungiklį, ir tai yra testas, kuris dažniausiai meluoja. Žymės langelis kliente yra tik nuostata; svarbu tai, ar kažkas primeta blokavimą tarp momento, kai pakyla tinklo kamina, ir momento, kai tunelis tikrai sudarytas. „Windows“ tai dažniausiai filtras „Windows Filtering Platform“, „Linux“ – vieneto įkeliamas taisyklių rinkinys, „macOS“ – pf inkaras, „Android“ – pačios sistemos visada įjungto ir užraktos vėliavėlės. Šios priemonės perkrovimo metu elgiasi labai skirtingai, ir tik platformos lygmens priemonės yra savo vietoje prieš kam nors prisijungiant.

Perkrovimas iškelia tris atskirus klausimus

Padalinkite klausimą. Pirma, ar politika yra diske tokia forma, kurią kažkas skaito įkrovimo metu? Antra, ar tas skaitytuvas paleidžiamas prieš bet kokiam srautui išeinant? Trečia, ar politika apima srautą, kuris jums rūpi, tai yra kiekvieną procesą, abi adresų šeimas ir DNS. „Taip“ į pirmąjį ir „ne“ į antrąjį sukuria būtent tą gedimą, kurį žmonės apibūdina kaip apsaugos jungiklį, neišliekantį po perkrovimo: paleidimo metu kelioms sekundėms srautas ištrūksta, ir niekas to nepastebi, kol kas nors nepradeda tikrinti.

Laikykite sluoksnius atskirai. Išsaugotas ugniasienės taisyklių rinkinys, įkrovimo metu paleidžiama paslauga ir kliento nuostata yra trys skirtingi objektai su trimis skirtingomis gyvavimo trukmėmis. Nuostata išlieka po perkrovimų, nes tai yra reikšmė konfigūracijos faile. Taisyklės yra vienintelis dalykas, kuris blokuoja paketus, ir jos išnyksta kartu su branduoliu, kuris jas laikė.

Raskite objektą, kuris atkuria blokavimą

„Linux“ netfilter taisyklės gyvena branduolyje. Niekas jų neperrašo įkrovimo metu, nebent jūs tai sutvarkėte: iptables-save plius netfilter-persistent, nftables.service įkelia /etc/nftables.conf, arba systemd vienetas, kuris paleidžia jūsų pačių scenarijų. Tikrinkite, kas įjungta, o ne ką prisimenate sukonfigūravę.

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

Tuščias taisyklių rinkinys praėjus kelioms sekundėms po įkrovimo yra atsakymas į pavadinime esantį klausimą. „Windows“ paklauskite kliento paslaugos, kaip ji paleidžiama, tada išveskite platformos filtro būseną, kol tunelis nuleistas.

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

Antroji komanda įrašo wfpstate.xml į dabartinį katalogą. Ieškokite filtrų su blokavimo veiksmu, kurie jau egzistuoja prieš klientui prisijungiant. „Base Filtering Engine“ paleidžiamas anksti įkrovimo metu ir atkuria filtrus, pridėtus su nuolatine vėliavėle, todėl vieni apsaugos jungikliai blokuoja srautą dar prieš atsirandant bet kokiam kliento langui, o kiti – ne. „macOS“ sudo pfctl -s info praneša, ar pf įjungtas, sudo pfctl -s rules rodo, kas įkelta, o VPN klientai paprastai pritvirtina savo taisykles prie inkaro, o ne prie pagrindinio rinkinio. Taisyklė, kuri įvardija utun3, po kito įkrovimo gali rodyti į kitą sąsają, nes tas numeris priskiriamas vykdymo metu.

Stebėkite tarpą tarp tinklo pakilimo ir tunelio pakilimo

Pavojingas intervalas yra ne visas perkrovimas, o tarpas. Sąsaja vienu momentu gauna nuomą ir numatytąjį maršrutą, VPN paslauga pradedama kitu, o tunelis autentifikuojasi dar vėliau, kartais tik po to, kai vartotojas prisijungia ir pasileidžia kredencialų agentas. Jei blokavimas taikomas paskutinis, viskas tarpe išeina atvirai.

systemd šeimininkuose skaitykite tvarką, o ne spėliokite. Paleiskite systemctl cat VPN ir ugniasienės vienetuose ir ieškokite After= arba Before= atžvilgiu network-pre.target ir network-online.target. Ugniasienės vienetas, išdėstytas po network-online.target, pralaimi sąsajai; tas, kurio reikalauja ir kuris išdėstytas prieš network-pre.target, laimi. „Windows“ atitinkami klausimai yra paslaugos paleidimo tipas ir jos priklausomybės, nes paslauga, nustatyta į Manual, negali blokuoti įkrovimo proceso. Jei jūsų reikalavimas apima srautą prieš prisijungimą, jį tenkina tik įrenginio lygmens sprendimas: „Always On VPN“ įrenginio tunelis autentifikuojasi mašinos sertifikatu ir prisijungia prieš vartotojui prisijungiant, ir „Microsoft“ dokumentuoja įrenginio tunelio konfigūraciją atskirai nuo vartotojo tunelio. „Android“ eina kitu keliu, primeta visada įjungtą VPN ir blokuoja ryšius be jo iš sistemos, o ne iš programos proceso.

Atlikite testą, tada palyginkite dvi laiko juostas

Perkraukite su paskirties vieta, kuri nieko nekainuoja, jei nuteka, ir fiksuokite būseną tarpo metu, o ne po jo. Švariausias metodas yra įkrovimo zondas: oneshot vienetas arba suplanuota užduotis, kuri paleidžiama kuo anksčiau, kiek platforma leidžia, įrašo numatytąjį maršrutą ir ugniasienės būseną, bando vieną užklausą su trumpu skirtuoju laiku ir prideda eilutę prie vietinio failo. Palyginkite tą įrašą su VPN paslaugos paleidimo laiku iš journalctl -b -u arba sistemos žurnalo.

Tada atlikite įprastą testą: tunelis pakeltas, nutraukite ryšį, stebėkite, ar tiesioginis srautas blokuojamas, atkurkite. Praeiti antrąjį ir nepasisekti pirmajame yra normalus rezultatas, ir tai reiškia, kad vykdymas yra kliento pusėje, taikomas, kai klientas prisijungia, o ne įkrovimo metu. Paskutinėje mašinoje, kurią auditojau, blokavimas kilo iš „NetworkManager“ siuntėjo scenarijaus: esamas ir teisingas ir nenaudingas toms sekundėms, kol sąsaja pakilo. Užsirašykite abu rezultatus, nes perkrovimo išgyvenimas ką nors reiškia tik tada, kai pasakote, kuris sluoksnis išgyveno ir nuo kurio momento.

Uždarykite tarpą nesulaužydami kelio atgal

Jei įkrovimo metu blokavimo nėra, perkelkite vykdymą vienu sluoksniu žemiau, o ne pridėkite antrą kliento taisyklę. Išsaugokite taisyklių rinkinį ir įkelkite jį iš vieneto, išdėstyto prieš tai, kai tinklas taps naudojamas, ir įsitikinkite, kad tam vienetui nereikia DNS užklausos ar tinklo prijungimo, kurį jis turėtų saugoti. Aprėptis svarbi taip pat kaip laikas: taisyklės, atitinkančios vartotojo ID ar cgroup, palieka kiekvieną sistemos demoną už blokavimo ribų, o rinkinys, kuris tvarko tik IPv4, palieka IPv6 ir DNS pasiekiamus.

Pasilikite kelią atgal. Mašina, kuri įkrovimo metu blokuoja viską ir paskui negali autentifikuotis, apskritai neturi tinklo, o pataisa yra ne ištrinti blokavimą, o sutaisyti kredencialus ar tvarką. Laikykite dokumentuotą vietinės konsolės procedūrą ir siaurą, sąmoningą išimtį tam, ko tuneliui tikrai reikia, pavyzdžiui, serverio adresą ir resolverį, naudojamą prieš atsirandant tuneliui.

Prieš pasitikėdami šia sąranka, patvirtinkite keturis dalykus iš eilės. Politika saugoma ten, kur skaito įkrovimas. Tas skaitytuvas veikia prieš tai, kai sąsaja tampa naudojama. Blokavimas apima abi adresų šeimas ir DNS. VPN vis dar gali autentifikuotis, kol blokavimas aktyvus. Kai visi keturi galioja, perkrovimas nieko nekeičia.