Ĉesi aŭ malkonekti: du malsamaj VPN-rezultoj

La menuo proponas Malkonekti, la fenestro havas butonon por fermi, kaj la taskmastrumilo proponas Finigi taskon. Ĉiu el ili aspektas kiel maniero haltigi la VPN, kaj ĉiu povas lasi la maŝinon en malsama stato. Unu povas haltigi la tunelon dum blokado restas en loko, alia povas purigi ĉion kiel parton de senproblema eliro, kaj tria povas nur kaŝi la interfacon dum la fona komponanto daŭre funkcias. Trakti ilin kiel sinonimojn estas la vojo, per kiu privateca testo alvenas al malĝusta konkludo pri tio, kio okazis.

La dokumentaro de la kliento estas la sola fidinda loko por lerni, kiu estas kiu.

Kvar regiloj, eble kvar kondutoj

Malkonekti kutime dismuntas la tunelon dum la kliento restas en memoro, kio signifas, ke servo, komponanto en la sistemopleto aŭ regulo de kill switch povas postvivi la klakon. Poste multaj klientoj daŭre blokas trafikon, ĉar ilia politiko diras, ke la aparato ne rajtas reiri al rekta aliro dum la kliento ĉeestas. Tiu konduto aspektas kiel rompita reto kaj estas intenca protekto.

Ĉesi celas fini la aplikaĵon, kaj bone kondutanta kliento forigas siajn regulojn dum la eliro. Kelkaj dezajnoj anstataŭe lasas apartan helpanton, kiu plenumas la politikon, kaj tio estas elekto, ne difekto. Fermi la fenestron estas ago de la interfaco sen difinita efiko al la tunelo, kaj Paŭzi, kie ĝi estas proponata, estas kvara konduto kun propraj reguloj.

Interrompo ĉe la servila flanko estas tute kvina vojo, kaj ĝi estas tiu, kiun uzantoj efektive plej ofte renkontas.

Legu la staton antaŭ kaj post ĉiu ago

Registru la procezan liston, la staton de la servo kaj la regulojn de la fajroŝirmilo antaŭ la ago, poste ripetu la registradon tuj poste. Kompari la du listojn montras, kion la regilo vere faris, sen fidi la priskribon de la interfaco mem.

systemctl status wg-quick@wg0 --no-pager
pgrep -a -f 'openvpn|wireguard|vpnagent'
ip link show | grep -E 'tun|wg'
nft list ruleset | grep -E 'drop|reject' | head -20
scutil --nc list

Se la reguloj malaperas kune kun la procezo, la kliento posedis ilin. Se la reguloj restas dum la procezo foriris, io alia plenumas la politikon, kaj trovi tiun komponanton venas antaŭ iu ajn ŝanĝo. Registru la staton de la servo en la sama momento, ĉar haltigita interfaco diras nenion pri sistema servo.

Manuala malkonekto ne estas paneo

Malkonekto rulas la intencitan haltigan vojon, kaj paneo preterlasas ĝin. Rezultoj de unu do ne transiĝas al la alia, do testo, kiu uzis eron de la menuo, ne povas subteni aserton pri konduto, kiam la kliento mortas.

Same, paneo diras nenion pri aprobita provizora paŭzo. Tenu tiujn tri demandojn aparte en la testplano kaj en ĉio, kio estos skribita poste. La haltiga vojo ankaŭ klarigas, kial pura eliro povas forigi regulojn, kiujn paneo lasas. Sama butono, malsama kodo, malsamaj pruvoj.

Elektu la neatingeblan staton, kiun vi vere bezonas

Se trafiko devas resti blokita ĉiam, kiam la tunelo estas malŝaltita, kontrolu tiun postulon dum la konkreta ago, kiu gravas al vi, uzante sendanĝeran trafikon al konata celo. Inkluzivu esceptojn por aplikaĵoj kaj esceptojn por la loka reto, ĉar plenumado por la tuta aparato ofte estas pli mallarĝa, ol ĝia nomo sugestas. Poste konfirmu, kio okazas post restartiĝo, ĉar tiam kutime aperas kaduka stato.

Se la celo estas ordinara rekta aliro, uzu la dokumentitan regilon anstataŭ mortigi procezojn aŭ malŝalti la tutan fajroŝirmilon. Kadukaj reguloj lasitaj de interrompita eliro estas malsama problemo ol intenca blokado, kaj ili postulas malsaman riparon.

Skribu, kiu komponanto haltis: la tunelo, la videbla aplikaĵo, aŭ la tavolo, kiu plenumas la politikon. Tiu unu frazo malhelpas la plejparton de la konfuzo, kiun ĉi tiuj regiloj kreas.