La VPN-aplikacio kraŝis: ĉu la sekureca ŝaltilo ankoraŭ funkcias?

Komencu tie, kie komencas uzanto: la klienta fenestro mankas, la piktogramo en la systema pleto malaperis, kaj la retumilo aŭ ŝargas aŭ ne. Tiu observo sola ne povas diri al vi, ĉu la blokado pluvivis. La respondo dependas de tio, kiu komponanto tenas la regulojn, ĉu tiu komponanto mortis kun la fenestro, kaj ĉu la platformo tenas la plenumadon ekster la aplikaĵo. Iru eksteren de la fenestro al la procezo, poste al la fajroŝirmilo, poste al la reala vojo.

Ne restarigu unue; restarigo kutime detruas la pruvojn.

Komencu per tio, kio ankoraŭ funkcias

Malfermu la procezan liston antaŭ ol tuŝi ion ajn. Labortabla kliento kutime dividiĝas en uzantinterfacan procezon kaj servon aŭ demonon, kaj kraŝo en la unua ne nepre haltigas la duan. En Windows la servo eble ankoraŭ estas listigita, en Linux la unuo eble ankoraŭ estas aktiva, kaj en Android la tunelo apartenas al la sistemo post kiam konsento estas donita. Legu tiujn tri faktojn en tiu ordo.

Se la demono vivas, la tunelo verŝajne ankaŭ vivas, kaj la mankanta fenestro estas nur kosmetika.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Legu la blokadon ĉe la plenumanto, ne ĉe la aplikaĵo

Se la kliento plenumas sian sekurecan ŝaltilon enmetante fajroŝirmilajn regulojn, tiuj reguloj apartenas al la operaciumo kaj pluvivas la procezon, kiu kreis ilin. Kraŝo tiam lasas vin blokita sen ajna interfaco por malŝalti ĝin, kio aspektas kiel rompita reto prefere ol kiel protekto. Se male la blokado vivas interne de la propra paketvojo de la kliento, mortigi la procezon forigas la blokadon en la sama momento.

Android traktas tion denove alie: always-on VPN kun lockdown estas platforma agordo, do la blokado daŭras sendepende de la procezo de la aplikaĵo, kaj la sistemo povas restartigi la servon. Konsultu la platforman dokumentaron pri la preciza konduto anstataŭ supozi, ke ĝi kongruas kun labortabla kliento.

Distingi puran finiĝon de kraŝo

Normala Quit kutime rulas la elŝaltan vojon de la kliento, kiu forigas regulojn kaj fermas la tunelon intence. Kraŝo preterpasas tiun vojon kaj lasas ĉion, kion la plenumanto jam instalis. La diferenco vidiĝas en la tempomarkoj de la reguloj rilate al la eliro de la procezo, kaj en tio, ĉu malnova tunela interfaco ankoraŭ ekzistas sen posedanto.

Tiu distingo decidas vian restarigon: pura finiĝo eble bezonas novan konekton, dum kraŝo eble bezonas, ke la restintaj reguloj foriĝu per la subtenata riparilo de la kliento.

Restarigu sen rompi aliajn kontrolojn

Restartigu la klienton per ties dokumentita laborfluo, poste kontrolu ambaŭ duonojn de la postulo: la tunelo portas trafikon, kaj la blokado ankoraŭ validas kiam ĝi devas. Elflui la tutan fajroŝirmilon por reaki ligon ankaŭ forigas ne rilatajn kontrolojn, kaj tiu interŝanĝo malofte valoras.

Por ripeta kraŝo, kolektu la klientan version, la platforman konstruon kaj la limigitajn protokolojn, kiujn la vendanto petas. Klienta profilo, privata ŝlosilo aŭ plena konekta protokolo por alia konto ne necesas por kraŝa raporto, kaj ilia aldono transformas subtenan kazon en datuman problemon.

Unu kraŝo ne estas pruvo de liko. Pruvo estas observita paketo, kiu eliras per vojo, kiun la politiko devintus malhelpi, kaptita en la momento, kiam la kliento estis malŝaltita. Testu tion intence, kun sendanĝera celo, kaj skribu, kiu plenumtavolo tenis.