VPN malkonektita, interreto ankoraŭ blokita: ŝaltilo aŭ malnova regulo?

La tunelo fermiĝas, la retumilo haltas, kaj ĉiu alia aparato en la sama Wi-Fi ankoraŭ funkcias, kio ekskludas la enkursigilon. Tiu ŝablono havas tri verŝajnajn posedantojn: kill-ŝaltilon, al kiu oni ordonis bloki, staton lasitan de forigita kliento, kaj solvilon aŭ itineron, kiuj neniam estis restarigitaj. Ili aspektas identaj el retumila fenestro kaj bezonas malsamajn riparojn. Decidu, kiun vi havas, antaŭ ol lanĉi retan restarigon.

Du tre malsamaj blokitaj interretoj

Intenca blokado estas funkcio: dum neniu tunelo aktivas, la kliento faligas trafikon por ke nenio liku ekster la protektita vojo. Akcidenta blokado estas restinta regulo, aparata aŭ solvila agordo, kiu postvivis la eliron de la kliento. Unu ripariĝas per konekto aŭ per intenca malŝalto de la politiko, la alia per purigado de tio, kio restis.

La diferenco montriĝas en la eraro, ne en la retumilo. Intenca blokado kutime produktas tujan rifuzon aŭ silentan haltiĝon, dum restinta solvilo produktas nomrezolvan fiaskon, kiu daŭras eĉ kiam ping al laŭvorta adreso funkcias. Neniu el ili samas al rompita Wi-Fi-konekto, kiu efikus ankaŭ la aliajn aparatojn. Ordigu la kontrolojn laŭ tiu diferenco: unue laŭvorta adreso, poste nomo.

Kion la kliento promesis ĉe malkonekto

Legu la proprajn agordojn de la kliento por la signifo de malkonekto, ĉar multaj produktoj apartigas paŭzon disde plena halto. Paŭzo tenas la blokadon laŭplane, dum halto povas forigi ĝin. Iuj poŝaj platformoj esprimas la saman ideon kiel ĉiam-ena regulo, kiu blokas trafikon kiam ajn VPN ne estas konektita.

Kie la organizo postulas protekton, la riparo estas rekonekti la ĝustan profilon anstataŭ ĉirkaŭiri la blokadon. Kontrolu, ke la servila nomo ankoraŭ solviĝas kaj ke la finpunkto estas atingebla tra la esceptoj, kiujn la deplojo dokumentas, ĉar malsukcesa rekonekto aspektas ĝuste kiel persista blokado.

Malnova stato de interrompita forigo

Interrompita malinstalo, aŭ pako forigita dum la tunelo estis aktiva, povas lasi malantaŭe fajroŝirma ĉenon, enkursigan regulon, solvilan eron aŭ virtualan adaptilon. La procezo foriris kaj la efikoj ne.

Komencu per la subtenata puriga kaj ripara vojo de la aplikaĵo, poste, antaŭ ol forigi, identigu kiu komponanto instalis ĉiun restantan objekton. Malŝalti la gastigan fajroŝirmon restarigas retumadon kaj samtempe forigas ne rilatan protekton. Tutmonda reta restarigo estas pli malbona, ĉar ĝi forĵetas funkciantajn oficejajn aŭ Wi-Fi-agordojn sen nomi la kaŭzon.

Se du klientoj estas instalitaj, decidu, kiu posedas la politikon. Du posedantoj estas kial blokado postvivas la forigon de ambaŭ.

Kontrolu la malkonektitan staton, ne nur retumadon

Retumado denove funkcianta estas malforta akcepta testo. Kontrolu, ke la postulata politiko estas sendifekta kaj ke nenio alia estis silente malfortigita.

ip rule show
ip route show table all | grep -v '^default'
resolvectl status | head -n 20
sudo nft list ruleset | grep -A 6 'chain output'

Komparu la enkursigajn regulojn, la solvilon kaj la fajroŝirman politikon kun tio, kiel aspektas pura malkonektita maŝino. Poste rekonektu kaj malkonektu tra la normala laborfluo kaj ripetu la legaĵojn, por ke la atendata stato estu skribita anstataŭ memorita.

Konservu tiun antaŭ-post-paron en la bileto. La sekva persono, kiu vidos blokitan retumilon, bezonos ĝin pli ol ankoraŭ unu opinion pri tio, kiu kliento estas la plej bona.