Feilichheidsskeakel blokkearret noch hieltyd ferkear nei it ôfbrekken fan de VPN

De tunnel is fuort, it netwurk-ikoan sjocht der normaal út en der ladeet neat. Jo hawwe de VPN ôfbrutsen, of it deinstallearre, of op ’e nij opstarten, en de blokkade dy’t jo by in ûnderbrekking beskermje moast, stiet noch. It finster fan ’e klient kin dat net ferklearje, want de klient is net wat jo blokkearret: it beslút waard yn jo namme yn ’e kernel skreaun, en der is neat efterbleaun om it fuort te heljen. Yn Windows sit dy steat yn it Windows Filtering Platform; yn Linux is it in regelset yn iptables of nftables, faak mei in snapshot dy’t by it opstarten op ’e nij spile wurdt. Wat folget is de oarder dy’t ik brûk: lês de steat, wiskje it smelste objekt dat de flater ferklearret, en fyn dan alles wat it hieltyd werom set.

In feilichheidsskeakel is kernelsteat, gjin ynstelling

Desktop-klanten fiere blokkade út troch filters ta te foegjen dy’t ferkear bûten de tunnel wegerje. Yn Windows binne dat WFP-filters op ’e ferbining-omliedings- en transportlagen, en guon dêrfan binne permanint: se wurde yn ’e beliedsopslach fan ’e Base Filtering Engine fêstlein en by it opstarten fan ’e masine werombrocht, foardat hokker VPN-software dan ek rint. Klanten ferskille yn wannear’t se skjinmeitsje. Guon helje filters fuort by it ôfbrekken, oaren allinnich by in skjinne ôfsluting, en oaren allinnich as de feilichheidsskeakel earst út set wurdt. Deinstallearje wylst de blokkade aktyf is, of deadzje it proses, en de filters bliuwe.

It Linux-ekwivalent is in drop- of reject-regel yn it útgongspaad, soms in trochstjoerregel, soms in feroare keatlingbelied. Dy regels oerlibje it proses dat se tafoege hat, om’t se kernelsteat binne: deadzje de klient, lit him crashe, of snij de stroom ôf, en de kernel bliuwt pakketten falle litten sûnder dat der eat oerbliuwt om it werom te draaien. In permaninsjepakket foeget in twadde laach permaninsje ta troch in snapshot fan ’e hjoeddeiske regelset te meitsjen en dy by it opstarten werom te bringen, sadat de folgjende start begjint mei de blokkade al ynstallearre.

Lês de WFP-steat foardat jo eat wiskje

Windows leveret it ark dat jo nedich hawwe. Rinner in ferhege opdrachtprompt en dump de steat fan it platfoarm; de dump lansearret as wfpstate.xml yn ’e wurkmap.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Sykje yn ’e XML nei de namme fan ’e fuortgiene leveransier, nei in Block-aksje en nei de laach. Filters op ferbining-omlieding en transport binne dejingen dy’t gewoan ferkear brekke; in filter op in receive-accept-laach is meastentiids net jo oarsaak. As de Base Filtering Engine hielendal net rint, sykje dan earne oars, want neat oars kin dy filters ôftwinge.

Kontrolearje ek de gewoane firewall-werjefte, want de measte minsken ûndersykje mar ien fan ’e beide:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

As de ynboude profilen oan binne en gjin regel past by it mislearjende ferkear, komt de blokkade fan in tredde-partij-oanbieder en net fan ’e Windows Firewall. Dat ûnderskie bepaalt hokker ark jo foar de reparaasje brûke sille.

Lês Linux-regels yn ’e syntaksis dêr’t jo mei wiskje sille

iptables -S prints regels yn deselde foarm as dy’t brûkt wurdt om se ta te foegjen, wat de útfier direkt werbrûkber makket foar in wiskjen. iptables -L -v -n foeget pakkettellers ta, en dy tellers fertelle jo oft in regel echt by jo mislearre oanfragen past of gewoan yn ’e keatling sit.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Lês de keatlingbelieden, net allinnich de regels: -P OUTPUT DROP blokkearret ferkear sels as gjin regel past. Undersykje IPv6 apart, want in klient dy’t beide famyljes ynstallearret, kin de IPv6-blokkade stean litte neidat de IPv4-regels fuort binne, en it symptoom hinget dan ôf fan hokker famylje in applikaasje foarkar jout. Wêr’t nftables brûkt wurdt, rinner ek nft list ruleset; de twa ark besteane njonken inoar fia in kompatibiliteitslaach, en ien oersjoch toant net needsaaklik elke regel dy’t in pakket falle litte kin.

Wiskje it smelste objekt dat de flater ferklearret

Yn Windows is de earste stap noch hieltyd it eigen fuortheljen fan ’e leveransier: rinner de ynstallearder op ’e nij en brûk reparaasje of deinstallaasje, of rinner it skjinmeitsjark as de leveransier ien publisearret. Oerbliuwende tsjinsten en plande taken binne gewoan, en in taak dy’t de klient by it oanmelden startet, ynstallearret syn filters by de folgjende opstart op ’e nij. In deinstallaasje dy’t mislearret by it lêzen fan ’e registerkaai fan ’e klient betsjut meastentiids dat in tsjinst of taak dy noch hâldt, net dat it register skansearre is.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Permaninte filters binne it lêste middel. Se wenje ûnder HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, ien wearde per filter mei in GUID as kaai. Eksportearje earst de kaai, skriuw de GUID’s op dy’t jo fuorthelje, wiskje allinnich de wearden dy’t by de fuortgiene klient hearre, en start dan op ’e nij sadat de motor syn steat wer opbout. Wiskje net de hiele kaai en skeakelje de Base Filtering Engine net út: de Windows Firewall en Defender binne derfan ôfhinklik, en jo soene ien ûnderbrekking foar in slimmere ruilje.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Yn Linux nimme jo de rigel dy’t iptables -S print, en ferfange -A troch -D. It wiskjen fan ’e iene regel dy’t jo identifisearre hawwe is better as it leegjen fan in keatling, om’t it jo eigen belied yntakt lit.

sudo iptables -D OUTPUT -p udp -j REJECT

As de drop yn in troch de brûker definiearre keatling sit, wiskje dan earst de sprong nei dy keatling en helje de keatling dêrnei fuort mei -X. In keatlingbelied op ACCEPT sette wylst drop-regels noch oanwêzich binne, helpt allinnich pakketten dy’t hielendal by it beliedsbeslút komme. Alle tabellen leegje is in lêste middel: it hellet ek regels fuort dy’t jo om oare redenen tafoege hawwe, en mei ufw oan lit it de tsjinst leauwe dat er keatlingen besit dy’t net mear besteane.

Fyn de eigner dy’t it werom set

Nei de direkte reparaasje, sykje alles wat de steat werombringe soe. Yn Linux, kontrolearje oft in permaninsje-ienheid oan is, oft de klient in ynstelling hat om de firewall by it oanmelden werom te bringen, en oft der in bewarre regelfile ûnder /etc bestiet. Yn Windows, kontrolearje startynfieringen, tsjinsten en plande taken nochris, start dan op ’e nij en lês de steat mei deselde opdrachten as earder.

As de blokkade weromkomt, wie it wiskjen net de oplossing; de eigner wie it. Skriuw op hokker klient of tsjinst it ynstallearret en skeakelje de funksje dêr út, ynstee fan der nei elke ûnderbrekking op ’e firewall-laach tsjin te fjochtsjen.

Ferifiearje mei echt ferkear, net mei ien ping

Test in nammsykjen, in TCP-ferbining en in nije browser-sesje, start dan op ’e nij en werhelje deselde trije kontrôles. In ping dy’t wurket wylst HTTPS mislearret, wiist op in transportlaachfilter en net op it netwurk, en in blokkade dy’t allinnich nei it opstarten weromkomt, wiist op in eigner dy’t jo noch net fûn hawwe.

Bewarje it bewiis: de eksportearre BFE-kaai, of de iptables -S-útfier dy’t foar de feroaring fêstlein is. Foardat jo it reparearre neame, befêstigje de laach dêr’t jo it objekt fuorthelle hawwe, de eigner dy’t it wer ynstallearje koe, de steat nei ien skjinne opstart, en dat gewoan browsen wurket sûnder in rinnend VPN-proses. De hânliedingside iptables(8) hat de krekte wisk- en beliedssyntaksis as jo de skjinmeitsjen skripte.