O kill switch bloquea o servidor VPN antes de que circule calquera tráfico
Que etapa bloquea un kill switch: a busca do extremo, a ruta exterior, o camiño de volta e as excepcións obsoletas de pares, con contadores en lugar de conxecturas.
Os kill switch fallan nunha dirección que a xente non espera: están feitos para bloquear o tráfico mentres o túnel está caído, e os paquetes que constrúen o túnel son eles mesmos tráfico. Ese é o erro completo. Un conxunto de regras que descarta todo o que non sae polo túnel tamén descarta o apretón de mans que debería levantalos, así que o cliente reintenta en bucle e o erro atribúese á etapa que se comproba primeiro. Antes de ampliar unha devasa, averigüe cal das tres etapas se está denegando: a busca do nome, o paquete exterior cara ao par ou a resposta que volve.
Como dependen o un do outro o túnel e o seu propio transporte
Lea un cliente VPN como dous estados de rede que comparten unha soa ruta de socket. Antes de que exista o túnel, o cliente abre un socket no adaptador físico e envía tramas cifradas ao enderezo e ao porto do par. Só cando ese intercambio ten éxito crea o dispositivo de túnel e instala as rutas. Un kill switch é unha política sobre o segundo estado, escrita con tal amplitude que se aplica a ambos.
As regras baseadas na interface son a forma habitual: acepte o que sae por tun0 ou wg0, descarte o resto do camiño de saída. Esa formulación non pode eximir a propia conexión do cliente co servidor, así que unha implementación correcta engade esa excepción de forma explícita, e vostede tamén o fai cando escribe regras á man. As regras por aplicación en Windows e macOS evitan parte disto ao coincidir cun proceso en lugar dunha interface, pero o proceso segue tendo que saír antes de que exista o túnel.
Tres etapas, na orde en que ocorren
A primeira etapa é a resolución. Cando o perfil garda un nome de host en lugar dun enderezo literal, o cliente necesita unha resposta DNS antes de poder enviar nada. Un perfil que apunta o DNS ao resolutor do túnel crea un bloqueo: só se pode chegar ao resolutor a través do túnel que a consulta debería habilitar. Resolver fóra do túnel, ou fixar o extremo a un enderezo, elimina a ambigüidade.
A segunda etapa é o paquete exterior, que ten que sobrevivir primeiro ao encamiñamento e despois á devasa, nesa orde. wireguard-tools encárgase da metade de encamiñamento para WireGuard marcando os seus propios paquetes e engadindo unha regra de política para que salten a ruta por defecto que acaba de instalar; a páxina de manual de wg-quick describe esa regra e a táboa que utiliza. Reconstruía ese encamiñamento á man, ou deixe que unha segunda ferramenta reescriba as regras, e os paquetes marcados poden enviarse de volta ao túnel que deben establecer.
A terceira etapa é o camiño de volta. Un apretón de mans sen resposta non é proba dun descarte de saída; é igual de compatible cunha regra de entrada do servidor ou cun dispositivo NAT que esqueceu a correspondencia. Separe iso antes de tocar o cliente.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Os clientes rexistran o síntoma que detectan, non a etapa que fallou, así que a táboa adoita ser máis rápida que o rexistro.
Os contadores deciden máis rápido que os rexistros
En Linux, nft list ruleset ou iptables -vnL OUTPUT imprime un contador de paquetes por regra. Conéctese unha vez, déixeo fallar e volva ler os contadores. Unha regra cuxo contador se moveu é unha regra que golpeou o apretón de mans; se non se moveu nada en ningún sitio, o paquete nunca chegou á devasa. Vin un conxunto de regras descartar o seu propio apretón de mans, e só os contadores o dixeron.
Para separar nunca chegou á devasa de nunca saíu do host, observe a propia interface. ip -s link show dev wlan0 informa dos paquetes enviados, e tcpdump -ni wlan0 udp port 51820 mostra as tramas. Se queda plano mentres o cliente reintenta, a avaría está por riba de netfilter: falta unha ruta do par, unha regra de política apunta a un dispositivo que aínda non existe, ou hai un erro de socket que o cliente traga.
Probe as excepcións contra enderezos de documentación como 203.0.113.10, para que un descoido non poida sondar o host doutra persoa.
Unha excepción de extremo obsoleta lese como unha caída do servidor
A versión máis enganosa aparece despois de que cambie o enderezo do par: un servizo de enderezos dinámicos moveuno, o host reconstruíuse ou o enderezo de saída da súa rede é distinto. A excepción segue nomeando o enderezo antigo, así que os paquetes cara ao novo caen na regra de descarte. A mesma configuración funcionaba onte, e por iso a xente comeza diagnosticando o servidor.
Un nome de host dentro dunha regra de devasa non o salva. En nftables o nome resólvese ao cargar o conxunto de regras, así que fixa o enderezo que existía nese momento e vólvese obsoleto como un literal. A solución duradeira é actualizar a excepción cando cambia o extremo e mantela estreita: un enderezo de par, un porto de transporte. Un rango o bastante amplo para sobrevivir a un cambio de enderezo tamén o é para deixar saír tráfico non relacionado.
Cando o kill switch se executa no host do servidor
A mesma dependencia existe no outro extremo, e alí é máis fácil pasala por alto. Se a máquina que actúa como o seu servidor VPN tamén executa un cliente de escritorio con kill switch, ou un perfil de devasa copiado dun portátil, as súas regras de descarte aplícanse ao servizo que termina os túneles. As respostas ao apretón de mans dun cliente descártanse, así que todos os clientes non poden conectar mentres o servidor parece san e a súa interface de túnel queda sen uso.
Ese host necesita tres aceptacións estreitas antes do descarte: o porto de escoita na interface física, a interface de túnel para o tráfico descifrado e o reenvío desde o túnel cara ao que os clientes deben alcanzar. Lea o conxunto instalado con nft list ruleset, iptables -S, ou pfctl -sr antes de cambiar nada, e lembre que un conxunto de regras gardado sobrevive a un reinicio, así que un erro alí sobrevive ao proceso que o fixo.
Orde de recuperación que mantén a máquina pechada
Traballa de dentro cara a fóra desde o perfil. Lea o enderezo e o porto do par que usa o cliente, confirme que o nome de host se resolve sen o túnel e despois engada unha excepción para ese enderezo e porto só no adaptador físico. Vólvase conectar e observe o contador de envío; un apretón de mans completado é o sinal de que a segunda etapa está arranxada.
Deixe o resto da política de descarte no seu sitio mentres proba. Unha comprobación inocua é tentar unha conexión a un enderezo de documentación non relacionado e confirmar que segue caducando, o que mostra que o kill switch funciona e non que está desactivado. Aperte a excepción cando o túnel sexa estable, e non deixe un permiso permanente de todo para o binario do cliente só porque é cómodo.
Se o túnel sobe e a aplicación segue fallando, as etapas restantes non son esta: o DNS dividido, a MTU e o encamiñamento por aplicación producen cada un un túnel conectado con tráfico roto, e cada un ten unha primeira comprobación distinta.