Sobrevive un interruptor de emerxencia de VPN a un reinicio? Como comprobalo

Reiniciar é a forma máis común en que a xente proba un interruptor de emerxencia, e é a proba que mente con máis frecuencia. A caixa do cliente é unha preferencia; o que importa é se algo impón un bloqueo entre o momento en que a pila de rede sobe e o momento en que o túnel está realmente establecido. En Windows ese algo adoita ser un filtro en Windows Filtering Platform, en Linux un conxunto de regras cargado por unha unidade, en macOS unha áncora de pf, en Android os indicadores propios do sistema de always-on e bloqueo. Estes arranxos compórtanse de forma moi distinta ao longo dun reinicio, e só os de nivel de plataforma están no seu sitio antes de que ninguén poida iniciar sesión.

Un reinicio formula tres preguntas separadas

Divida a pregunta. Primeiro, existe a política no disco nunha forma que algo lea ao arrincar? Segundo, execútase ese lector antes de que poida saír calquera tráfico? Terceiro, cobre a política o tráfico que lle importa, é dicir, cada proceso, as dúas familias de enderezos e DNS. Un si á primeira e un non á segunda producen exactamente o fallo que a xente informa como un interruptor de emerxencia que non sobrevive a un reinicio: o tráfico escapa durante uns segundos ao arrincar, e ninguén se decata ata que alguén vai mirar.

Manteña as capas separadas. Un conxunto de regras de devasado gardado, un servizo que arrinca co sistema e unha preferencia do cliente son tres obxectos distintos con tres vidas distintas. A preferencia sobrevive aos reinicios porque é un valor dun ficheiro de configuración. As regras son o único que bloquea paquetes, e desaparecen co núcleo que as sostiña.

Atope o obxecto que restablece o bloqueo

En Linux as regras de netfilter viven no núcleo. Nada as reescribe ao arrincar salvo que vostede o dispuxese: iptables-save máis netfilter-persistent, nftables.service carga /etc/nftables.conf, ou unha unidade de systemd que executa o seu propio script. Comprobe que está habilitado en lugar do que recorda ter configurado.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Un conxunto de regras baleiro uns segundos despois de arrincar é a resposta á pregunta do título. En Windows pregunte ao servizo do cliente como arrinca e logo volque o estado do filtro de plataforma mentres o túnel está baixo.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

O segundo comando escribe wfpstate.xml no directorio actual. Busque filtros cunha acción de bloqueo que xa existan antes de que o cliente se conecte. Base Filtering Engine arrinca cedo e restaura os filtros engadidos coa marca persistente, por iso algúns interruptores de emerxencia bloquean o tráfico antes de que exista calquera xanela de cliente e outros non. En macOS, sudo pfctl -s info informa de se pf está habilitado, sudo pfctl -s rules mostra que hai cargado, e os clientes de VPN adoitan asociar as súas regras a unha áncora en lugar do conxunto principal. Unha regra que nomea utun3 pode apuntar a outra interface tras o seguinte arrinque, porque ese número asígnase en tempo de execución.

Vixíe o oco entre a subida da rede e a do túnel

O intervalo perigoso non é todo o reinicio, é o oco. A interface recibe un arrendamento e unha ruta predeterminada nun momento, o servizo de VPN arrinca noutro, e o túnel autentícase aínda máis tarde, ás veces só despois de que un usuario inicie sesión e se execute un axente de credenciais. Se o bloqueo se aplica ao final, todo o que hai no oco sae en claro.

En equipos con systemd, lea a orde en lugar de adiviñala. Execute systemctl cat nas unidades de VPN e de devasado e busque After= ou Before= fronte a network-pre.target e network-online.target. Unha unidade de devasado ordenada despois de network-online.target perde contra a interface; a que é requirida por e ordenada antes de network-pre.target gaña. En Windows as preguntas equivalentes son o tipo de inicio do servizo e as súas dependencias, porque un servizo posto en Manual non pode bloquear un proceso de arrinque. Se o seu requisito inclúe tráfico antes de iniciar sesión, só o satisface un arranxo a nivel de dispositivo: un túnel de dispositivo Always On VPN autentícase cun certificado de máquina e conéctase antes de que o usuario inicie sesión, e Microsoft documenta a configuración do túnel de dispositivo por separado do túnel de usuario. Android toma a outra vía, impoñendo a VPN always-on e bloqueando as conexións sen ela desde o sistema e non desde un proceso de aplicación.

Execute a proba e logo compare dúas cronoloxías

Reinicie con un destino que non custa nada se se filtra, e capture o estado durante o oco en lugar de despois. O método máis limpo é unha sonda de arrinque: unha unidade oneshot ou unha tarefa programada que arrinca tan pronto como a plataforma o permite, rexistra a ruta predeterminada e o estado do devasado, tenta unha petición cun tempo de espera curto e engade unha liña a un ficheiro local. Compare ese rexistro coa hora de inicio do servizo de VPN de journalctl -b -u ou do rexistro do sistema.

Despois faga a proba habitual: túnel arriba, corte a conexión, observe se o tráfico directo queda bloqueado, restaure. Pasar a segunda e fallar a primeira é o resultado normal, e significa que a imposición é do lado do cliente, aplicada cando o cliente se conecta e non ao arrincar. Na última máquina que auditei, o bloqueo viña dun script despachador de NetworkManager: presente e correcto e inútil para os segundos antes de que a interface subise. Anote ambos os resultados, porque sobrevivir a un reinicio só significa algo cando di que capa sobreviviu e desde que momento.

Pecha o oco sen cortar o seu camiño de volta

Se falta o bloqueo ao arrincar, baixe a imposición unha capa en lugar de engadir unha segunda regra de cliente. Garde o conxunto de regras e cárgueo desde unha unidade ordenada antes de que a rede sexa utilizable, e asegúrese de que esa unidade non necesita unha consulta DNS nin unha montaxe de rede que se supón que protexe. O alcance importa tanto como o momento: as regras que coinciden cun ID de usuario ou un cgroup deixan fóra do bloqueo a todos os daemons do sistema, e un conxunto de regras que só trata IPv4 deixa IPv6 e DNS accesibles.

Déixese un camiño de volta. Unha máquina que bloquea todo ao arrincar e logo non pode autenticarse non ten rede algunha, e a solución non é borrar o bloqueo senón reparar a credencial ou a orde. Manteña un procedemento documentado de consola local e unha excepción estreita e deliberada para o que o túnel necesita de verdade, como o enderezo do servidor e o resolutor usado antes de que exista o túnel.

Antes de confiar na configuración, confirme catro cousas por orde. A política está almacenada onde o arrinque le. Ese lector execútase antes de que a interface sexa utilizable. O bloqueo cobre as dúas familias de enderezos e DNS. A VPN aínda pode autenticarse mentres o bloqueo está activo. Cando as catro se cumpren, un reinicio non cambia nada.