O Wi-Fi de convidados segue usando a ruta principal: dálle a súa propia saída

Creaches unha rede de convidados, engadiches unha ruta para ela, e os convidados seguen saíndo pola túa conexión normal a internet. O túnel está activo, a LAN principal funciona e os dispositivos de convidados informan dun enderezo dentro do rango que asignaches, así que nada parece roto. O que adoita faltar non é unha ruta senón un selector: o router decide a ruta antes de considerar por que interface chegou o paquete, e a menos que algo coincida explicitamente co tráfico de convidados, ese tráfico herda o valor por defecto. A solución é un segmento, unha regra de política e unha ruta de resposta, nesa orde.

O síntoma: os convidados seguen saíndo pola WAN

A pista é o enderezo de saída. Un dispositivo de convidados que chega a internet polo túnel informará do enderezo do provedor do túnel, e un que herdou a ruta por defecto informará da túa conexión normal. Compara lado a lado un dispositivo de convidados e un da LAN principal, porque o caso interesante é cando difiren do que configuraches e coinciden entre si.

A segunda pista é a ausencia de tráfico na interface do túnel mentres os convidados navegan. Se os contadores non se moven, a política nunca se aplicou, e axustar o túnel en si non pode axudar.

Paso 1: un segmento real, non só un nome

Un nome de SSID non crea illamento. Comproba que a rede de convidados termina na súa propia interface, VLAN ou ponte, e que o rango de enderezos é distinto do da LAN de confianza. En moitos puntos de acceso domésticos, o SSID de convidados póntese na mesma segmento que todo o demais, o que fai imposible o resto deste traballo ata que se corrixa.

Despois confirma o rango de convidados e o seu servidor DHCP, e mantén a configuración do resolutor asociada a ese segmento en lugar de a todo o router. Unha subrede de convidados que só existe como comentario nunha regra de firewall non é un segmento, e o router non terá ningunha interface coa que coincidir.

Non pontes os convidados na LAN principal para que o VPN sexa máis fácil de configurar. Iso cambia o illamento que querías por un atallo de enrutamento, e é a razón habitual pola que unha rede de convidados acaba con acceso á impresora e ao NAS.

Paso 2: selecciona o túnel por orixe

As táboas de enrutamento elíxense por destino, así que unha regra que di «envía 0.0.0.0/0 ao túnel» se aplica a todos. O enrutamento por políticas engade unha segunda dimensión: seleccionar a táboa por enderezo de orixe. Nun router baseado en Linux, iso é unha regra adicional máis unha táboa dedicada, e a orde importa porque gaña a primeira regra que coincide:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

Ese último comando responde directamente á pregunta: que interface usará esta orixe para este destino. Execútao antes e despois do cambio e saberás se a política surtiu efecto sen tocar un navegador.

A maioría dos firmwares de router expresan o mesmo como unha regra de interface ou unha selección de pasarela baseada na orixe. Sexa cal sexa a sintaxe que use a túa plataforma, o principio é idéntico: coincide coa interface de entrada ou o prefixo de orixe e despois anula a ruta só para esa coincidencia. Unha regra que coincide por destino non pode distinguir un convidado dun dispositivo da casa.

Paso 3: a ruta de resposta e a tradución

Un paquete que sae polo túnel ten que volver. Ou o par do túnel coñece unha ruta de volta ao prefixo de convidados, ou o router traduce a orixe de convidados no enderezo do túnel. Elixe unha e anótaa, porque os modos de fallo vense distintos: unha ruta de retorno ausente dá unha conexión que se establece e nunca responde, mentres que a tradución ausente a miúdo non produce nada de nada.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Se elixes a tradución, lembra que o par agora ve un só enderezo para todos os convidados, así que calquera política por cliente no extremo remoto desaparece. Se en cambio conservas os enderezos, ambos os extremos necesitan o prefixo de convidados no seu enrutamento e na súa política, o que é máis traballo e máis previsible.

IPv6 necesita a súa propia regra. Unha política escrita para IPv4 non cobre a outra familia, e un dispositivo de convidados con IPv6 funcionando usaraa encantado mentres a túa coidadosamente enrutada ruta IPv4 queda inactiva. Enruta ambas as familias ou desactiva IPv6 no segmento de convidados, pero non supoñas que a regra combinada que escribiches cobre o que o dispositivo fai realmente. Proba cun cliente que teña ambas as familias habilitadas, porque ese é o caso que o deseño ten que resistir. Un portátil que prefire IPv6 parece correcto nunha proba só IPv4 e filtra na real.

Proba o illamento, non só a navegación

Navegar demostra que a saída cambiou. Non demostra que o segmento estea illado, e o illamento é a razón pola que existe a rede de convidados. Desde un dispositivo de convidados, intenta alcanzar a interface de administración do router, un host da LAN de confianza e un servizo que debería ser rexeitado; os tres deberían fallar, e o fallo debería ser unha decisión de política en lugar dun tempo de espera que ninguén pode explicar.

Despois proba un dispositivo da LAN principal e confirma que a súa saída non cambiou. Ese é o retroceso que este deseño causa con máis frecuencia: unha regra ampla pensada para convidados, aplicada a todas as interfaces porque a coincidencia se escribiu por destino.

Por último, decide que ocorre cando o túnel está caído. Os convidados ou quedan sen internet ou pasan a unha ruta que aprobas, e deixar iso sen decidir significa un retroceso silencioso á conexión normal, que é exactamente a fuga que a política de convidados debía evitar. A receita de enrutamento do tráfico de internet percorre a mesma selección de ruta para un router baseado en pfSense.

O DNS orixinado no router é o caso que sorprende a xente ao final. Se os convidados usan o router como o seu resolutor, as propias consultas do router seguen a ruta do router en lugar da regra de convidados, así que as buscas poden saír pola conexión normal mentres o tráfico da aplicación non. Mantén o segmento, o resolutor e a política de fallo nunha soa nota, e a seguinte persoa poderá comprobar os tres sen volver deducir o deseño.