Os clientes do hotspot do Pi non chegan á LAN da casa por unha VPN TUN

Os clientes locais de Wi-Fi e Ethernet conéctanse ao hotspot do Pi, collen un enderezo do seu rango DHCP e cargan páxinas de internet sen queixarse. Eses mesmos clientes logo esgotan o tempo cando abren un recurso compartido de ficheiros ou unha interface web na LAN da casa, mentres que o propio Pi chega a esa LAN polo túnel. Nada na capa inalámbrica está roto. O que falta é un contrato enrutado: o prefixo do hotspot debe levarse á interface TUN, e algo no lado da casa debe saber como enviar as respostas de volta. As dúas metades deben existir antes de que un só paquete poida completar a viaxe de ida e volta.

Tres conexións con tres traballos distintos

Unha ponte Ethernet de Linux reenvía tramas segundo o enderezo MAC de destino. OpenVPN en modo TUN transporta paquetes IP e non ten ningunha capa MAC, así que engadir unha ponte local nunca inscribe o túnel como porto. A documentación do núcleo sobre TUN/TAP explica esa separación: un dispositivo TAP parece unha interface Ethernet, un TUN non. Un deseño que pon unha ponte entre dous portos locais e logo enruta é un enrutador, digan o que digan os nomes das interfaces.

Esa distinción decide a propiedade. A subrede dos clientes, a súa porta de enlace predeterminada e a autoridade DHCP dese rango pertencen ao plan local do Pi. As difusións DHCP da casa non cruzan un túnel enrutado, e ningún axuste de ponte o cambia; apuntar os clientes a un servidor DHCP da casa é un deseño de retransmisión aparte e deliberado, cos seus propios modos de fallo.

Mantén tamén o módem fóra da ponte de clientes. Unha conexión PPP non é un dispositivo Ethernet con outra etiqueta, e a lóxica documentada de ruta predeterminada de pppd execútase tras a negociación IPCP e retira a súa ruta cando ese enlace cae. Copiar un modelo DHCP e renomear cada usb0 a ppp0 non demostra nada sobre porta de enlace, métrica ou ciclo de vida.

Escolle os prefixos antes de editar calquera configuración

Os prefixos solapados gastan máis noites que as regras de cortalumes, porque un solapamento envía a busca de ruta á interface equivocada incluso cando o túnel está san. Comeza listando o que xa existe no Pi e logo le o resultado como catro grupos separados.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

O primeiro grupo é o enderezo underlay que o operador deu ao módem; debe quedar fóra de todo plan orientado aos clientes. O segundo é a subrede do túnel que escolleu o servidor, a miúdo unha /24 privada propia. O terceiro é a ponte do hotspot, e o cuarto é o prefixo da casa que queres alcanzar. Neste percorrido o hotspot recibe 172.28.90.0/24 coa ponte en 172.28.90.1, e a LAN de servizos da casa mantén 192.168.77.0/24, o que evita as predeterminadas 192.168.1.0/24 e 10.0.0.0/24 que traen os enrutadores de consumo e o rango de operador 100.64.0.0/10.

Anuncia o enderezo da ponte como porta de enlace no rango DHCP do hotspot e nada máis. Nunca lle deas aos clientes do hotspot un enderezo da casa como porta de enlace; non teñen ningún camiño a nivel de enlace cara a ese segmento.

Enruta cada dirección no lado que a posúe

O Pi necesita unha ruta para o prefixo da casa a través do túnel. Os servidores en modo servidor normalmente empurran esa ruta, así que primeiro confirma que o reenvío está activo e que o núcleo resolve un enderezo da casa desde tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Se ip route get aínda informa da interface underlay, detente aí; nada máis adiante no camiño pode reparar unha busca incorrecta.

Os dispositivos da casa non teñen ruta cara a 172.28.90.0/24, así que as súas respostas seguen a porta de enlace predeterminada e morren no enrutador. Existen dúas reparacións admitidas. Ou engades unha ruta estática no enrutador da casa que apunte o prefixo do hotspot ao enderezo LAN do servidor VPN, ou, cando o servidor é el mesmo a porta de enlace, rexistras o prefixo do cliente na táboa de enrutamento propia do servidor. No modo multicliente de OpenVPN o directorio específico do cliente leva esa asociación: un ficheiro co nome común do certificado do cliente, que contén iroute 172.28.90.0 255.255.255.0 máis a liña route correspondente que a instala no núcleo do servidor. Unha ruta de núcleo suposta no servidor non é a mesma declaración que dicirlle ao servidor que cliente posúe o prefixo.

Non movas o servizo DHCP da rede da casa ao servidor VPN para que isto funcione. Substituír a porta de enlace predeterminada dunha casa enteira é un cambio moito maior que engadir unha ruta de retorno privada, e arrastra DNS, reservas de enderezos e cada dispositivo que ignora o novo arrendamento cara ao fallo.

Abre o reenvío sen adiviñar o cortalumes

Que o reenvío estea activado non significa que o paquete teña permiso para pasar. O tráfico da ponte ao túnel segue batendo nas regras de filtrado, e unha política de reenvío predeterminada drop descarta o tráfico do hotspot mentres o tráfico propio do Pi segue funcionando, o que produce exactamente o síntoma dividido de arriba.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Busca unha regra de aceptación de br0 a tun0 e a dirección de resposta correspondente, e unha regra postrouting que poida reescribir a orixe. Se a política da cadea é drop e ningunha regra coincide, engade as aceptacións estreitas e volve probar en vez de virar a política a accept.

A tradución é unha elección de política, non un requisito. O NAT de orixe cara á LAN da casa fai que cada cliente do hotspot pareza o enderezo do túnel do Pi, o que perde a atribución por cliente nos rexistros da casa e rompe servizos que esperan a orixe orixinal. O enrutamento sen NAT mantén visibles os enderezos dos clientes pero depende da ruta de retorno de arriba. Escolle unha e trata DNS e IPv6 do mesmo xeito, porque un camiño IPv4 que funciona xunto a un camiño IPv6 roto segue lendo como medio roto nun navegador.

Verifica a viaxe de ida e volta e logo rómpela a propósito

Proba desde un cliente do hotspot, nunca desde o Pi, porque o tráfico propio do Pi evita tanto o camiño de ida como o de volta. Observa as dúas interfaces mentres un cliente tenta alcanzar un servizo da casa.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Le as dúas capturas xuntas. As peticións en br0 que nunca aparecen en tun0 significan que o Pi non reenvía ou que a ruta apunta a outro sitio. As peticións en tun0 sen respostas significan que o lado da casa non ten ruta de retorno ou que o servidor filtrou o paquete. As respostas en tun0 que nunca reaparecen en br0 significan que falta a regra de filtrado inversa, onde o túnel parece perfecto e o cliente segue sen ver nada.

Logo rompe o camiño deliberadamente. Baixa a conexión do módem e vólvea subir e executa de novo as comprobacións de ruta e captura; unha ruta que sobrevive ao túnel pero desaparece ao reconectar pertence ao perfil de conexión, non a un comando puntual. Confirma que o transporte do túnel segue saíndo polo underlay e non por si mesmo, o bucle clásico cando se acepta unha ruta predeterminada empurrada sen unha ruta de host cara ao par.

Acepta o deseño só cando un cliente do hotspot poida resolver un nome da casa, abrir un servizo TCP e manter unha sesión viva durante unha reconexión do módem. Se unha aplicación require de verdade descuberta a nivel Ethernet no segmento da casa, escolle un deseño Layer 2 admitido en vez de describir a ponte local como ponteada e esperar a que apareza a difusión.