Sekureca ŝaltilo ankoraŭ blokas trafikon post la malkonekto de la VPN

La tunelo malaperis, la reta ikono aspektas normale, kaj nenio ŝargiĝas. Vi malkonektis la VPN-on, malinstalis ĝin aŭ restartigis la komputilon, kaj la blokado, kiu devis protekti vin dum interrompo, ankoraŭ staras. La fenestro de la kliento ne povas klarigi tion, ĉar ne la kliento blokas vin: la decido estis skribita en la kernon laŭ via nomo, kaj nenio restis por forigi ĝin. En Windows tiu stato loĝas en la Windows Filtrila Platformo; en Linux ĝi estas regularo en iptables aŭ nftables, ofte kun momenta kopio, kiu re-ludiĝas dum ŝargado. Jen la ordo, kiun mi uzas: legu la staton, forigu la plej mallarĝan objekton, kiu klarigas la fiaskon, poste trovu ĉion, kio daŭre remetas ĝin.

Sekureca ŝaltilo estas kernstato, ne agordo

Labortablaj klientoj efektivigas blokadon aldonante filtrilojn, kiuj rifuzas trafikon ekster la tunelo. En Windows tiuj estas WFP-filtriloj ĉe la tavoloj de konekta alidirektado kaj transporto, kaj iuj el ili estas persistentaj: ili registriĝas en la politika konservejo de Base Filtering Engine kaj restarigatas kiam la maŝino ŝargiĝas, antaŭ ol ajna VPN-programaro ruliĝas. Klientoj malsamas pri tio, kiam ili purigas. Iuj forigas filtrilojn ĉe malkonekto, iuj nur ĉe pura eliro, kaj iuj nur kiam la sekureca ŝaltilo unue malŝaltiĝas. Malinstalu dum la blokado estas aktiva, aŭ mortigu la procezon, kaj la filtriloj restas.

La Linuxa ekvivalento estas forĵeta aŭ rifuza regulo en la eliga vojo, foje alidirekta regulo, foje ŝanĝita ĉena politiko. Tiuj reguloj postvivas la procezon, kiu aldonis ilin, ĉar ili estas kernstato: mortigu la klienton, kraŝigu ĝin aŭ fortranĉu la potencon, kaj la kerno daŭre forĵetas pakaĵojn, sen ke restu io por malfari tion. Persisteca pako aldonas duan tavolon de daŭro per momenta kopio de la nuna regularo kaj restarigo dum ŝargado, do la sekva starto komenciĝas kun la blokado jam instalita.

Legu la staton de WFP antaŭ ol forigi ion

Windows venas kun la iloj, kiujn vi bezonas. Rulu altigitan prompton kaj elprenu la staton de la platformo; la elprenaĵo konserviĝas kiel wfpstate.xml en la labordosierujo.

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

Serĉu en la XML la nomon de la foririnta vendisto, agon Block kaj la tavolon. Filtriloj ĉe konekta alidirektado kaj transporto estas tiuj, kiuj rompas ordinaran trafikon; filtrilo ĉe akcepta riceva tavolo kutime ne estas via kaŭzo. Se Base Filtering Engine tute ne funkcias, serĉu aliloke, ĉar nenio alia povas trudi tiujn filtrilojn.

Kontrolu ankaŭ la ordinaran vidon de la fajroŝirmilo, ĉar plej multaj homoj inspektas nur unu el la du:

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

Kiam la enkonstruitaj profiloj estas ŝaltitaj kaj neniu regulo kongruas kun la fiaska trafiko, la blokado venas de triaparta provizanto, ne de la Windows-fajroŝirmilo. Tiu distingo decidas, kiun ilon vi uzos por la riparo.

Legu la regulojn de Linux en la sintakso, per kiu vi forigos

iptables -S presas regulojn en la sama formo uzata por aldoni ilin, kio igas la eligon rekte reuzebla por forigo. iptables -L -v -n aldonas pakaĵajn nombrilojn, kaj tiuj nombriloj diras al vi, ĉu regulo vere kongruas kun viaj fiaskaj petoj aŭ simple sidas en la ĉeno.

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

Legu la ĉenajn politikojn, ne nur la regulojn: -P OUTPUT DROP blokas trafikon eĉ kiam neniu regulo kongruas. Inspektu IPv6 aparte, ĉar kliento, kiu instalas ambaŭ familiojn, povas lasi la IPv6-blokadon surloke post kiam la IPv4-reguloj malaperis, kaj la simptomo tiam dependas de tio, kiun familion aplikaĵo preferas. Kie nftables estas uzata, rulu ankaŭ nft list ruleset; la du iloj kunekzistas per kongrueca tavolo, kaj unu listo ne nepre montras ĉiun regulon, kiu povas forĵeti pakaĵon.

Forigu la plej mallarĝan objekton, kiu klarigas la fiaskon

En Windows la unua paŝo ankoraŭ estas la propra foriga vojo de la vendisto: rerulu la instalilon kaj uzu riparon aŭ malinstalon, aŭ rulu la purigan ilon se la vendisto publikigas unu. Restintaj servoj kaj planitaj taskoj oftas, kaj tasko, kiu startigas la klienton ĉe ensaluto, reinstalas ĝiajn filtrilojn ĉe la sekva ŝargado. Malinstalo, kiu fiaskas dum legado de la registra ŝlosilo de la kliento, kutime signifas, ke servo aŭ tasko ankoraŭ tenas ĝin, ne ke la registro estas difektita.

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

Persistemaj filtriloj estas la lasta rimedo. Ili loĝas sub HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, unu valoro por filtrilo ŝlosita per GUID. Unue eksportu la ŝlosilon, notu la GUID-ojn, kiujn vi forigas, forigu nur la valorojn apartenantajn al la foririnta kliento, poste restartigu, por ke la motoro rekonstruu sian staton. Ne forigu la tutan ŝlosilon kaj ne malŝaltu Base Filtering Engine: la Windows-fajroŝirmilo kaj Defender dependas de ĝi, kaj vi interŝanĝus unu paneon kontraŭ pli malbona.

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

En Linux prenu la linion presitan de iptables -S kaj anstataŭigu -A per -D. Forigi la unu regulon, kiun vi identigis, superas malplenigi ĉenon, ĉar ĝi lasas vian propran politikon sendifekta.

sudo iptables -D OUTPUT -p udp -j REJECT

Se la forĵeto loĝas en uzant-difinita ĉeno, unue forigu la salton al tiu ĉeno kaj poste forigu la ĉenon per -X. Meti ĉenan politikon al ACCEPT dum forĵetaj reguloj ankoraŭ ĉeestas nur helpas pakaĵojn, kiuj entute atingas la politikan decidon. Malplenigi ĉiun tabelon estas lasta rimedo: ĝi ankaŭ forigas regulojn, kiujn vi aldonis pro aliaj kialoj, kaj kun ufw ŝaltita ĝi lasas la servon kredi, ke ĝi posedas ĉenojn, kiuj ne plu ekzistas.

Trovu la posedanton, kiu remetas ĝin

Post la tuja riparo, serĉu ion ajn, kio restarigus la staton. En Linux kontrolu, ĉu persisteca unuo estas ŝaltita, ĉu la kliento havas agordon por restarigi la fajroŝirmilon ĉe ensaluto, kaj ĉu ekzistas konservita regula dosiero sub /etc. En Windows kontrolu denove startajn enskribojn, servojn kaj planitajn taskojn, poste restartigu kaj relegu la staton per la samaj komandoj kiel antaŭe.

Se la blokado revenas, la forigo ne estis la solvo; la posedanto estis. Notu, kiu kliento aŭ servo instalas ĝin, kaj malŝaltu la funkcion tie, anstataŭ batali kontraŭ ĝi ĉe la fajroŝirmila tavolo post ĉiu malkonekto.

Kontrolu per reala trafiko, ne per unu ping

Testu nomserĉon, TCP-konekton kaj freŝan retumilan seancon, poste restartigu kaj ripetu la samajn tri kontrolojn. Ping, kiu funkcias dum HTTPS fiaskas, montras al transporttavola filtrilo, ne al la reto, kaj blokado, kiu reaperas nur post la restartigo, montras al posedanto, kiun vi ankoraŭ ne trovis.

Konservu la pruvojn: la eksportitan BFE-ŝlosilon, aŭ la eligon de iptables -S kaptitan antaŭ la ŝanĝo. Antaŭ ol nomi ĝin riparita, konfirmu la tavolon, de kiu vi forigis la objekton, la posedanton, kiu povus reinstali ĝin, la staton post unu pura restartigo, kaj ke ordinara retumado funkcias sen ajna ruliĝanta VPN-procezo. La paĝo de la manlibro iptables(8) havas la ĝustan sintakson por forigo kaj politiko, se vi skriptas la purigadon.