Kill switch de l’aplicació contra kill switch del tallafoc: què bloqueja cadascun

Un kill switch a la llista de funcions no diu gairebé res sobre què passa quan el túnel cau. Una implementació tanca processos seleccionats, una altra instal·la filtres de paquets a la frontera del sistema operatiu, i una tercera simplement prova de tornar-se a connectar. La diferència es veu als segons posteriors a una fallada, no a la pantalla de configuració. Recorreu aquestes comprovacions en ordre i atureu-vos a la primera que no pugueu respondre amb sinceritat, perquè és on acaba la vostra cobertura real.

Primer, anomeneu el mecanisme d’aplicació

La terminació de processos és una funció del cicle de vida de l’aplicació. Troba programes seleccionats després d’una fallada del túnel detectada i els tanca. Tot el que no és el procés principal sobreviu: serveis auxiliars, sincronització en segon pla i qualsevol aplicació iniciada un segon després tenen el seu propi cicle de vida i el seu propi moment.

El filtratge de paquets és una funció del sistema operatiu. Refusa el trànsit que no segueix el camí permès, que és una promesa més forta, però només allà on la regla coincideix de veritat. La família d’adreces, la interfície, les aplicacions excloses i les excepcions ho decideixen, no l’etiqueta del client.

El bloqueig sobreviu al client?

Feu quatre preguntes en aquest ordre: què passa en una caiguda, en una sortida manual, en tancar la sessió i en reiniciar. Una regla mantinguda pel mateix client normalment s’elimina durant un tancament ordenat i sovint queda enrere després d’una caiguda. Una regla instal·lada a l’emmagatzematge de la plataforma pot comportar-se a l’inrevés: sobreviure tant al client com, de vegades, a la desinstal·lació.

Tanqueu el client al mig d’una descàrrega llarga i observeu si la transferència s’atura o continua.

Busqueu els forats habituals

IPv6 és el primer. Una regla escrita per a adreces IPv4 deixa el trànsit IPv6 sense afectar, i molts clients només escriuen la meitat v4. El segon és la interfície: l’USB tethering, un segon adaptador Wi-Fi i un mòdem cel·lular poden no estar inclosos en una regla limitada a la connexió principal. Aplicacions excloses i les excepcions de xarxa local són el tercer.

A Windows podeu llegir les regles instal·lades en lloc de confiar en l’interruptor: Get-NetFirewallRule -DisplayName '*VPN*' i netsh wfp show filters mostren què existeix. A Linux, iptables -S, ip6tables -S i nft list ruleset cobreixen els casos habituals, i comparar-ne els tres és el punt.

El DNS és la fuita habitual

Bloquejar TCP mentre UDP 53 queda obert us dona un kill switch molt convincent que encara respon a cada consulta de nom d’amfitrió. El mateix passa quan el DNS es lliura a un resolutor en una altra interfície, o quan el client només bloqueja v4 i el resolutor és accessible per v6.

Amb el túnel caigut, resolgueu un nom conegut i mireu si torna una resposta. Si torna, el trànsit no està completament bloquejat, digui el que digui la icona d’estat.

Proveu la transició, no l’interruptor

Apagar la VPN des del seu propi menú és un tancament ordenat, i l’ordenat és el cas que tota implementació gestiona bé. La transició que importa és la brusca: mateu el procés del túnel, traieu la xarxa, deixeu que el servidor deixi de respondre. Llavors inicieu una petició i observeu si falla o si fa servir en silenci l’enllaç físic.

El resultat d’un portàtil no es trasllada a un telèfon ni a un encaminador. API de plataforma diferents, valors per defecte diferents, i a Android la diferència és molt clara: l’always-on amb bloqueig l’imposa el sistema i no el client, així que continua funcionant quan el client no ho fa. La guia de VPN d’Android descriu aquesta separació.

Mantingueu una via de tornada

El bloqueig a nivell de sistema té el mode de fallada oposat. Els filtres que sobreviuen al client poden deixar una màquina sense xarxa després d’una desinstal·lació, que és una trucada a suport sense causa òbvia. Abans d’activar qualsevol kill switch que escrigui regles de plataforma, anoteu com es treu, i tingueu la via de reparació del proveïdor on la pugueu trobar.

Si no podeu respondre les comprovacions de caiguda, IPv6, DNS i transició per al vostre client, tracteu-lo com un interruptor de nivell d’aplicació amb forats coneguts i planifiqueu en conseqüència.