Sobrevviu un interruptor d’emergència de VPN a un reinici? Com comprovar-ho

Reiniciar és la manera més habitual com la gent prova un interruptor d’emergència, i és la prova que menteix més sovint. La casella del client és una preferència; el que importa és si alguna cosa imposa un bloqueig entre el moment en què la pila de xarxa s’aixeca i el moment en què el túnel queda realment establert. A Windows aquesta cosa sol ser un filtre al Windows Filtering Platform, a Linux un conjunt de regles carregat per una unitat, a macOS una àncora de pf, a Android els indicadors propis del sistema d’always-on i de bloqueig. Aquests arranjaments es comporten molt diferentment al llarg d’un reinici, i només els de nivell de plataforma són al seu lloc abans que ningú pugui iniciar sessió.

El reinici planteja tres preguntes separades

Dividiu la pregunta. Primer, la política existeix al disc en una forma que alguna cosa llegeixi en arrencar? Segon, aquest lector s’executa abans que cap trànsit pugui sortir? Tercer, la política cobreix el trànsit que us importa, és a dir cada procés, les dues famílies d’adreces i DNS. Un sí a la primera i un no a la segona produeixen exactament la fallada que la gent descriu com un interruptor d’emergència que no sobreviu al reinici: el trànsit s’escapa durant uns segons en arrencar, i ningú no se n’adona fins que algú va a mirar.

Manteniu les capes separades. Un conjunt de regles de tallafoc desat, un servei que arrenca en engegar i una preferència del client són tres objectes diferents amb tres vides diferents. La preferència sobreviu als reinicis perquè és un valor d’un fitxer de configuració. Les regles són l’única cosa que bloqueja paquets, i desapareixen amb el nucli que les tenia.

Trobeu l’objecte que restaura el bloqueig

A Linux, les regles de netfilter viuen al nucli. Res no les torna a escriure en arrencar tret que ho hàgiu disposat: iptables-save més netfilter-persistent, nftables.service carrega /etc/nftables.conf, o una unitat de systemd que executa el vostre propi script. Comproveu què està habilitat en lloc del que recordeu haver configurat.

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

Un conjunt de regles buit uns segons després d’arrencar és la resposta a la pregunta del títol. A Windows, pregunteu al servei del client com arrenca i després aboqueu l’estat del filtre de plataforma mentre el túnel està baix.

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

La segona ordre escriu wfpstate.xml al directori actual. Cerqueu filtres amb una acció de bloqueig que ja existeixin abans que el client es connecti. El Base Filtering Engine arrenca aviat i restaura els filtres afegits amb l’indicador persistent, per això alguns interruptors bloquegen el trànsit abans que existeixi cap finestra de client i d’altres no. A macOS, sudo pfctl -s info informa si pf està habilitat, sudo pfctl -s rules mostra què hi ha carregat, i els clients de VPN solen adjuntar les seves regles a una àncora en lloc del conjunt principal. Una regla que anomena utun3 pot apuntar a una interfície diferent després del següent arrencada, perquè aquest número s’assigna en temps d’execució.

Vigileu l’escletxa entre l’aixecament de la xarxa i el del túnel

L’interval perillós no és tot el reinici, sinó l’escletxa. La interfície rep un arrendament i una ruta per defecte en un moment, el servei de VPN arrenca en un altre, i el túnel s’autentica encara més tard, de vegades només després que un usuari iniciï sessió i s’executi un agent de credencials. Si el bloqueig s’aplica l’últim, tot el que hi ha a l’escletxa surt en clar.

Als amfitrions amb systemd, llegiu l’ordenació en lloc d’endevinar-la. Executeu systemctl cat a les unitats de VPN i de tallafoc i busqueu After= o Before= respecte de network-pre.target i network-online.target. Una unitat de tallafoc ordenada després de network-online.target perd contra la interfície; la que és requerida per i ordenada abans de network-pre.target guanya. A Windows les preguntes equivalents són el tipus d’inici del servei i les seves dependències, perquè un servei posat a Manual no pot bloquejar un procés d’arrencada. Si el vostre requisit inclou trànsit abans d’iniciar sessió, només ho satisfà un arranjament a nivell de dispositiu: un túnel de dispositiu Always On VPN s’autentica amb un certificat de màquina i es connecta abans que l’usuari iniciï sessió, i Microsoft documenta la configuració del túnel de dispositiu per separat del túnel d’usuari. Android pren l’altra via, imposa la VPN always-on i bloqueja les connexions sense ella des del sistema i no des d’un procés d’aplicació.

Executeu la prova i després compareu dues cronologies

Reinicieu amb una destinació que no costa res si es filtra, i captureu l’estat durant l’escletxa en lloc de després. El mètode més net és una sonda d’arrencada: una unitat oneshot o una tasca programada que arrenca tan aviat com la plataforma ho permet, enregistra la ruta per defecte i l’estat del tallafoc, intenta una petició amb un temps d’espera curt i afegeix una línia a un fitxer local. Compareu aquest registre amb l’hora d’inici del servei de VPN de journalctl -b -u o del registre del sistema.

Després feu la prova habitual: túnel aixecat, talleu la connexió, mireu si el trànsit directe queda bloquejat, restaureu. Passar la segona i fallar la primera és el resultat normal, i significa que l’aplicació és al costat del client, aplicada quan el client es connecta i no en arrencar. A l’última màquina que vaig auditar, el bloqueig venia d’un script despatxador de NetworkManager: present i correcte i inútil per als segons abans que la interfície s’aixequés. Anoteu tots dos resultats, perquè sobreviure a un reinici només vol dir alguna cosa quan dieu quina capa ha sobreviscut i des de quin moment.

Tanqueu l’escletxa sense trencar el camí de tornada

Si el bloqueig falta en arrencar, baixeu l’aplicació una capa en lloc d’afegir una segona regla de client. Deseu el conjunt de regles i carregueu-lo des d’una unitat ordenada abans que la xarxa sigui utilitzable, i assegureu-vos que aquesta unitat no necessita una consulta DNS ni un muntatge de xarxa que hauria de protegir. L’abast importa tant com el moment: les regles que coincideixen amb un ID d’usuari o un cgroup deixen fora del bloqueig tots els dimonis del sistema, i un conjunt de regles que només tracta IPv4 deixa IPv6 i DNS accessibles.

Deixeu-vos un camí de tornada. Una màquina que bloqueja tot en arrencar i després no pot autenticar-se no té cap xarxa, i la solució no és esborrar el bloqueig sinó reparar la credencial o l’ordenació. Mantingueu un procediment documentat de consola local i una excepció estreta i deliberada per al que el túnel necessita de debò, com ara l’adreça del servidor i el resolutor usat abans que el túnel existeixi.

Abans de confiar en la configuració, confirmeu quatre coses per ordre. La política s’emmagatzema en un lloc que l’arrencada llegeix. Aquest lector s’executa abans que la interfície sigui utilitzable. El bloqueig cobreix les dues famílies d’adreces i DNS. La VPN encara pot autenticar-se mentre el bloqueig és actiu. Quan les quatre es compleixen, un reinici no canvia res.