Cortacircuítos ou acceso á LAN? Dúas respostas para WireGuard

O saúdo inicial complétase, a navegación funciona e a impresora, o NAS e os hosts SSH locais desaparecen. No cliente de Windows isto normalmente non é un fallo de enrutamento en absoluto: un par cuxos prefixos permitidos inclúen o valor predeterminado literal activa Bloquear o tráfico non tunelizado, e esa opción implántase como regras de firewall que descartan os paquetes que saen por calquera outra interface. A táboa de rutas segue mostrando a subrede local como enlace directo, e por iso o síntoma parece unha mentira. Tres condicións deciden que facer ao respecto, e só unha ten que ver co enrutamento.

Dous fallos levan o mesmo síntoma

O primeiro fallo é o modo de peche seguro do cliente, e a súa sinatura é que todo o que está fóra do túnel se detén mentres o túnel funciona perfectamente. O segundo é un problema real de accesibilidade: unha ruta que falta, unha entrada que falta no servidor para unha subrede detrás do cliente, ou dúas redes que comparten o mesmo rango de enderezos. Ambos producen unha máquina que pode navegar e non pode imprimir, e as súas solucións son opostas, así que o diagnóstico debe chegar antes da configuración.

A observación decisiva é se a subrede local segue presente na táboa de rutas mentres se descarta o tráfico cara a ela.

Tres condicións deciden a resposta

Primeiro, necesita esta máquina o peche seguro? Se a resposta é si, un túnel que caia debe deter o tráfico en lugar de deixalo volver á interface física, e ese requisito pesa máis que a comodidade local. Segundo, deben os dispositivos locais seguir sendo accesibles mentres o túnel está activo? A impresión, o almacenamento en rede e as consolas de xestión locais son os motivos habituais, e son requisitos lexítimos, non excepcións polas que desculparse. Terceiro, expresa o perfil o valor predeterminado como o literal 0.0.0.0/0? Ese detalle é o que activa as regras do cliente, e é editable.

Responda esas tres preguntas por escrito antes de tocar un perfil, porque cada resposta apunta a unha configuración distinta.

Escolla o peche seguro e renuncie á LAN

Se as fugas importan máis que a accesibilidade local, conserve o valor predeterminado literal e deixe Bloquear o tráfico non tunelizado activado. É unha posición coherente: a máquina trátase como un dispositivo que ou está dentro do túnel ou está sen conexión, e os servizos locais alcanzanse desde outro dispositivo ou a través do túnel se o servidor os enruta. O custo é real e debería figurar nas notas de despregamento, en lugar de que o descubra a persoa que necesita imprimir.

Esta é a elección correcta para máquinas que manexan traballo que non debe aparecer nunha rede de cafetería cando o túnel cae. É un mal valor predeterminado para un portátil doméstico que tamén necesita o escáner.

Escolla o acceso á LAN e exprese o valor predeterminado doutro xeito

Se os dispositivos locais deben seguir sendo accesibles, exprese a mesma cobertura sen o prefixo predeterminado literal. Dous medios prefixos cobren todos os enderezos IPv4, o par equivalente cobre IPv6, e o cliente xa non insire as regras de bloqueo porque falta a cadea que busca.

[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820

Desmarcar esa caixa fai que o cliente escriba os mesmos dous pares no perfil, así que comparar o ficheiro xerado co bloque de arriba é unha forma rápida de confirmar o mecanismo en lugar de adiviñalo. Derívanse dúas consecuencias. A cobertura é idéntica, así que nada máis do túnel cambia. A protección non é idéntica: sen as regras, un túnel que cae deixa a máquina usando a súa interface física, que é precisamente o que evitaba o peche seguro.

Comprobe os outros dous sospeitosos de todos os xeitos

Unha vez resolvida a cuestión do firewall, confirme que a subrede local está realmente enrutada e que o extremo remoto coñece todo o que hai detrás deste cliente. Un servidor que debe alcanzar unha LAN detrás dun cliente necesita ese prefixo na lista permitida do cliente no concentrador; se o omite, o concentrador non pode elixir un par para eses enderezos, e ningunha cantidade de configuración do cliente crea un.

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0

A categoría de rede importa máis do que a xente espera: un adaptador de túnel recentemente creado clasificado como público cambia que regras se lle aplican, e o resultado pode parecer un bloqueo de firewall no extremo remoto. A impresión de rutas mostra se hai un valor predeterminado en absoluto, o que separa un problema de política dunha ruta que falta.

Logo probe tres cousas nunha soa sesión: internet, un host local por enderezo e un host a través do túnel. O saúdo inicial só demostra que as chaves coinciden, así que as tres probas son o que demostra a política. Se o host local segue negándose coa opción desactivada, os sospeitosos restantes son a ruta, a lista permitida do extremo remoto e a subrede duplicada, nesa orde.