Os túneles que soben mentres o SSH á dirección pública do servidor deixa de funcionar parecen un servidor que rexeita a conexión. En Windows a causa máis probable é local: un AllowedIPs de túnel completo con /0 activa regras de cortalumes restritivas que permiten o transporte propio do túnel e moi pouco máis. Os paquetes cifrados que chegan a esa dirección non din nada sobre se unha conexión TCP aparte á mesma dirección pode saír.

Separa a dirección pública do extremo da súa dirección interna de túnel antes de tocar a lista de pares. Case todos os intentos de arranxar isto editando AllowedIPs fan a política máis feble en lugar da ruta correcta.

O permiso de encamiñamento e o permiso do cortalumes son distintos

Unha ruta decide a onde se enviaría un paquete, e unha regra de cortalumes decide se se pode enviar. Por iso engadir unha ruta para o IP público do extremo produce un camiño que o filtro aínda pode bloquear, e esa é xustamente a confusión que crea este síntoma. En Windows o filtro forma parte da implementación e non é un complemento, así que ningunha entrada de ruta o cambia. As dúas decisións tamén están separadas noutros sitios, aínda que os valores por defecto difiren.

Por iso un traceroute ao extremo pode ter éxito mentres un intento de SSH falla. O primeiro lévao o servizo que posúe a excepción, e o segundo non.

Que fai /0 en Windows

Cun só par cuxas direccións permitidas cobren todo o espazo IPv4, WireGuard for Windows aplica unha postura de cortalumes restritiva que bloquea o tráfico que doutro xeito sairía fóra do túnel. O transporte propio do servizo do túnel si se permite, porque a VPN non podería funcionar doutro xeito. Outra aplicación á mesma dirección pública non recibe ese permiso, xa que a excepción pertence ao transporte e non á dirección. Notas de rede de Windows describen este comportamento e o control correspondente do editor.

Eses regras son o mecanismo detrás da expresión kill switch. Actívanse pola forma da configuración e non por unha caixa con ese nome.

As excepcións cambian o modelo de protección

Substituír /0 por dous prefixos medio por defecto é a forma documentada de manter un encamiñamento amplo sen a semántica restritiva, e é un modelo de protección distinto, non unha escritura máis curta. Restar a dirección do extremo dos prefixos permitidos é o outro apaño habitual, que alonga a lista e tamén cambia que regras se activan. Ningún é unha edición local con efecto local. Cada un move o límite para todos os fluxos da máquina, non só para a conexión que reparabas.

Onde o SSH público directo é realmente necesario, o propietario do perfil debe deseñar tanto a ruta exterior como o seu permiso de cortalumes, e decidir que acontece co tráfico non relacionado cando o túnel cae. Revisar IPv4 e IPv6 por separado forma parte diso, xa que as regras se expresan por familia. Unha excepción ampla engadida para rescatar unha soa sesión de xestión adoita expor máis que a sesión.

Proba o camiño de xestión que escolliches

Decide primeiro se a xestión debe viaxar dentro do túnel ou fóra del, e despois proba esa opción en lugar das dúas á vez. Os comandos seguintes comproban as direccións do cliente, o estado do par e unha conexión a cada obxectivo. Execútaos desde o cliente Windows mentres o túnel está levantado.

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

Un SSH correcto á dirección interna demostra que o túnel transporta o tráfico de xestión e que o cortalumes propio do servidor o acepta desde o rango de pares. Un fallo en ambos os dous obxectivos é un problema do servidor ou da clave, non de encamiñamento de Windows. Se a dirección interna funciona e a exterior non, a postura local do cortalumes fai exactamente aquilo para o que foi deseñada. Le os tres resultados nesa orde antes de editar un perfil.

Anota o camiño de xestión, a dirección utilizada e o comportamento cando o túnel está caído. Esa nota é o que impide que a seguinte persoa amplíe a excepción para aforrar cinco minutos.

Artigos relacionados