Ali varnostno stikalo VPN preživi ponovni zagon? Kako to preveriti

Ponovni zagon je najpogostejši način, kako ljudje preizkušajo varnostno stikalo, in to je test, ki najpogosteje laže. Potrditveno polje v odjemalcu je le nastavitev; pomembno je, ali nekaj vsili blokado med trenutkom, ko se omrežni sklad dvigne, in trenutkom, ko je tunel dejansko vzpostavljen. V sistemu Windows je to nekaj običajno filter v Windows Filtering Platform, v Linuxu nabor pravil, ki ga naloži enota, v macOS sidro pf, v Androidu lastne zastavice sistema za vedno-vklopljeno in zaklepanje. Te ureditve se med ponovnim zagonom vedejo zelo različno, in samo tiste na ravni platforme so na svojem mestu, preden se lahko kdor koli prijavi.

Ponovni zagon postavi tri ločena vprašanja

Razdelite vprašanje. Prvič, ali politika na disku obstaja v obliki, ki jo ob zagonu nekaj bere? Drugič, ali se ta bralnik izvaja, preden lahko odide kakršen koli promet? Tretjič, ali politika pokriva promet, ki vas zanima, torej vsak proces, obe družini naslovov in DNS. Da pri prvem in ne pri drugem ustvarita natanko tisto napako, ki jo ljudje prijavljajo kot varnostno stikalo, ki ne preživi ponovnega zagona: promet pri zagonu za nekaj sekund uide, in nihče tega ne opazi, dokler se nekdo ne gre pogledat.

Držite plasti ločene. Shranjen nabor pravil požarnega zidu, storitev, ki se zažene ob zagonu, in nastavitev odjemalca so trije različni objekti s tremi različnimi življenjskimi dobami. Nastavitev preživi ponovne zagone, ker je vrednost v konfiguracijski datoteki. Pravila so edino, kar blokira pakete, in izginejo skupaj z jedrom, ki jih je držalo.

Poiščite objekt, ki obnovi blokado

V Linuxu pravila netfilter živijo v jedru. Nič jih ob zagonu ne zapiše nazaj, razen če ste to uredili: iptables-save plus netfilter-persistent, nftables.service naloži /etc/nftables.conf, ali enota systemd, ki izvaja vašo lastno skripto. Preverite, kaj je omogočeno, namesto tega, česar se spominjate, da ste nastavili.

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

Prazen nabor pravil nekaj sekund po zagonu je odgovor na vprašanje iz naslova. V sistemu Windows vprašajte storitev odjemalca, kako se zažene, nato izvozite stanje filtra platforme, medtem ko je tunel spuščen.

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

Drugi ukaz zapiše wfpstate.xml v trenutno mapo. Iščite filtre z dejanjem blokiranja, ki že obstajajo, preden se odjemalec poveže. Base Filtering Engine se zažene zgodaj ob zagonu in obnovi filtre, dodane s trajno zastavico, zato nekatera varnostna stikala blokirajo promet, preden obstaja kakršno koli okno odjemalca, druga pa ne. V macOS sudo pfctl -s info poroča, ali je pf omogočen, sudo pfctl -s rules prikazuje, kaj je naloženo, in odjemalci VPN svoja pravila običajno pritrdijo na sidro namesto na glavni nabor. Pravilo, ki poimenuje utun3, lahko po naslednjem zagonu kaže na drug vmesnik, ker se ta številka dodeli med izvajanjem.

Opazujte vrzel med dvigom omrežja in dvigom tunela

Nevarni interval ni celoten ponovni zagon, to je vrzel. Vmesnik v enem trenutku dobi zakup in privzeto pot, storitev VPN se začne v drugem, tunel pa se overi še pozneje, včasih šele potem, ko se uporabnik prijavi in se izvede agent poverilnic. Če se blokada uporabi zadnja, gre vse v vrzeli ven odkrito.

Na gostiteljih systemd berite vrstni red, namesto da bi ga ugibali. Zaženite systemctl cat na enotah VPN in požarnega zidu ter poiščite After= ali Before= glede na network-pre.target in network-online.target. Enota požarnega zidu, razvrščena po network-online.target, izgubi proti vmesniku; tista, ki jo zahteva in je razvrščena pred network-pre.target, zmaga. V sistemu Windows sta enakovredni vprašanji vrsta zagona storitve in njene odvisnosti, ker storitev, nastavljena na Manual, ne more blokirati procesa ob zagonu. Če vaša zahteva vključuje promet pred prijavo, jo zadovolji samo ureditev na ravni naprave: tunel naprave Always On VPN se overi s strojnim potrdilom in se poveže, preden se uporabnik prijavi, in Microsoft dokumentira konfiguracijo tunela naprave ločeno od uporabniškega tunela. Android gre po drugi poti, vsili vedno-vklopljen VPN in blokira povezave brez njega iz sistema in ne iz procesa aplikacije.

Izvedite test in nato primerjajte dve časovnici

Znova zaženite s ciljem, ki ne stane nič, če uide, in zajemite stanje med vrzeljo, ne po njej. Najčistejša metoda je sonda ob zagonu: enota oneshot ali načrtovana naloga, ki se zažene čim prej, kot platforma dovoli, zabeleži privzeto pot in stanje požarnega zidu, poskusi eno zahtevo s kratkim časovnim limitom in doda vrstico v lokalno datoteko. Primerjajte ta zapis s časom začetka storitve VPN iz journalctl -b -u ali sistemskega dnevnika.

Nato izvedite običajni test: tunel gor, prekinite povezavo, opazujte, ali je neposreden promet blokiran, obnovite. Preiti drugega in pasti pri prvem je običajen rezultat in pomeni, da je izvajanje na strani odjemalca, uporabljeno ob povezavi odjemalca in ne ob zagonu. Na zadnjem stroju, ki sem ga revidiral, je blokada prišla iz skripta razpošiljatelja NetworkManager: prisoten in pravilen in neuporaben za sekunde, preden se je vmesnik dvignil. Zapišite oba rezultata, ker preživetje ponovnega zagona nekaj pomeni šele, ko rečete, katera plast je preživela in od kdaj.

Zaprite vrzel, ne da bi si prerezali pot nazaj

Če blokade ob zagonu ni, premaknite izvajanje plast nižje, namesto da dodate drugo pravilo odjemalca. Shranite nabor pravil in ga nalagajte iz enote, razvrščene preden je omrežje uporabno, in poskrbite, da ta enota ne potrebuje poizvedbe DNS ali omrežne priklopitve, ki naj bi jo varovala. Obseg je prav tako pomemben kot čas: pravila, ki se ujemajo z ID uporabnika ali cgroup, pustijo vsakega sistemskega demona zunaj blokade, nabor pravil, ki obravnava le IPv4, pa pusti IPv6 in DNS dosegljiva.

Pustite si pot nazaj. Stroj, ki ob zagonu blokira vse in se nato ne more overiti, nima omrežja sploh, in popravek ni brisanje blokade, ampak popravilo poverilnice ali vrstnega reda. Vzdržujte dokumentiran postopek za lokalno konzolo in ozko, namerno izjemo za tisto, kar tunel res potrebuje, na primer naslov strežnika in razreševalnik, ki se uporablja, preden tunel obstaja.

Preden zaupate tej ureditvi, potrdite štiri stvari po vrsti. Politika je shranjena tam, kjer jo zagon bere. Ta bralnik se izvaja, preden je vmesnik uporaben. Blokada pokriva obe družini naslovov in DNS. VPN se lahko še overi, medtem ko je blokada aktivna. Ko veljajo vse štiri, ponovni zagon ne spremeni ničesar.