Saír ou desconectar: dous resultados distintos da VPN

O menú ofrece Desconectar, a xanela ten un botón de peche e o xestor de tarefas ofrece Finalizar tarefa. Cada unha parece unha forma de deter a VPN, e cada unha pode deixar o equipo nun estado distinto. Unha pode deter o túnel e deixar un bloqueo activo, outra pode limpar todo como parte dunha saída ordenada, e unha terceira pode só ocultar a interface mentres o compoñente en segundo plano segue executándose. Tratar todo iso como sinónimos é xustamente como unha proba de privacidade chega a unha conclusión equivocada sobre o que ocorreu.

A documentación do cliente é o único lugar fiable para saber cal é cal.

Catro controis, posiblemente catro comportamentos

Desconectar adoita desmontar o túnel mentres o cliente segue residente, o que significa que un servizo, un compoñente da bandexa ou unha regra do kill switch poden sobrevivir ao clic. Moitos clientes seguen bloqueando o tráfico porque a súa política di que o dispositivo non debe caer ao acceso directo mentres o cliente estea presente. Ese comportamento parece unha rede rota e é unha protección deliberada.

Saír está pensado para terminar a aplicación, e un cliente ben educado elimina as súas regras ao saír. Algúns deseños deixan en cambio un asistente separado que aplica a política, e iso é unha decisión, non un defecto. Pechar a xanela é unha acción da interface sen efecto definido sobre o túnel, e Pausar, cando se ofrece, é un cuarto comportamento coas súas propias regras.

Unha caída no lado do servidor é un quinto camiño completamente distinto, e é o que os usuarios atopan máis a miúdo.

Le o estado antes e despois de cada acción

Captura a lista de procesos, o estado do servizo e as regras da devasa antes da acción, e repite a captura inmediatamente despois. Comparar as dúas listas mostra que fixo realmente o control, sen depender da descrición que dá a propia interface.

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 as regras desaparecen xunto co proceso, o cliente era o seu dono. Se as regras seguen aí cando o proceso xa non está, algo máis aplica a política, e atopar ese compoñente vai antes de calquera cambio. Anota o estado do servizo no mesmo momento, porque unha interface detida non di nada sobre un servizo do sistema.

Unha desconexión manual non é un fallo

Desconectar executa a ruta de apagado prevista, e un fallo sáltase. Por iso os resultados dun non se trasladan ao outro, así que unha proba que usou unha opción do menú non pode soster unha afirmación sobre o comportamento cando o cliente morre.

Do mesmo xeito, un fallo non di nada sobre unha pausa temporal aprobada. Mantén esas tres preguntas separadas no plan de probas e en todo o que se escriba despois. A ruta de apagado tamén explica por que unha saída limpa pode eliminar regras que un fallo deixa atrás. O mesmo botón, outro código, outra evidencia.

Escolle o estado non dispoñible que realmente necesitas

Se o tráfico debe seguir bloqueado sempre que o túnel estea caído, verifica ese requisito durante a acción concreta que che importa, con tráfico inofensivo cara a un destino coñecido. Inclúe as exclusións de aplicacións e as excepcións de rede local, porque a aplicación en todo o dispositivo adoita ser máis estreita do que suxire o seu nome. Despois confirma que ocorre tras un reinicio, porque é cando adoita aparecer o estado obsoleto.

Se o obxectivo é o acceso directo normal, usa o control documentado en lugar de matar procesos ou desactivar toda a devasa. As regras obsoletas que deixa unha saída interrompida son un problema distinto dun bloqueo intencionado, e necesitan outra recuperación.

Anota que compoñente se detivo: o túnel, a aplicación visible ou a capa que aplica a política. Esa soa frase evita a maior parte da confusión que crean estes controis.