Comparte unha conexión VPN con cada dispositivo da túa LAN

Un portátil sostén o túnel, o resto da casa quere o mesmo acceso, e o primeiro intento é apuntalo todo á máquina conectada. Falla por motivos que non teñen nada que ver coa VPN: o host receptor debe reenviar o paquete, reescribir a súa orixe e asegurarse de que as respostas atopan o camiño de volta. Se falta unha das tres, o portátil conectado segue funcionando mentres todos os demais dispositivos esgotan o tempo. A solución é un deseño de enrutamento, non un axuste do cliente.

Por que falla apuntar os dispositivos ao host

Un host que recibe un paquete dirixido a unha rede remota convértese en router nese momento, tanto se alguén o configurou como tal como se non. O reenvío está desactivado por defecto en Linux e en Windows salvo que algunha función o active. A tradución importa porque o lado remoto debe saber onde enviar as respostas, e un enderezo privado de LAN non lle di nada. A ruta de volta é a terceira peza, e é a que a xente esquece cando o primeiro ping parece funcionar.

Diagnostica nesa orde en lugar de cambiar axustes ao azar. Cada peza ausente produce un síntoma algo distinto.

Activa o reenvío e a tradución no host

Dous cambios no host conectado cobren as dúas primeiras pezas: activa o reenvío de IPv4 e traduce o tráfico da LAN á interface do túnel.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Garda o valor de sysctl nun ficheiro baixo /etc/sysctl.d e volve comprobar a regra masquerade tras un reinicio, xa que os frontends da devasa poden baleirar cadeas personalizadas. En Windows a función de compartición fai os dous pasos, pero tamén readdresa o adaptador de LAN a unha subrede fixa e borra a súa pasarela, o que rompe o direccionamento estático e a redirección de portos. Restaura o camiño do router ata o host no seu novo enderezo antes de concluír que a compartición fallou. Despois observa como aumentan os contadores de regras mentres un segundo dispositivo envía tráfico.

Dálle á LAN unha ruta que sobreviva aos reinicios

Os demais dispositivos necesitan unha ruta cara ao prefixo remoto, e as dúas formas de proporcionarla difiren en alcance.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Apuntar a pasarela predeterminada dun cliente ao host envía todo o seu tráfico a través do host, incluída a impresión local e a compartición de ficheiros, así que cousas non relacionadas detéñense cando o host dorme. Engadir unha ruta específica no router para o prefixo remoto é máis estreito: só os destinos detrás do túnel van á máquina conectada, e o resto da LAN segue funcionando. As subredes anteriores son exemplos, así que substitúeas polos teus propios rangos de LAN e túnel. En calquera caso, proba desde un segundo dispositivo co túnel activo e despois inactivo.

Vixía a MTU antes de culpar o túnel

Os túneles reducen o tamaño útil do paquete, e o segundo dispositivo non ten nin idea. As transferencias grandes e os handshakes TLS atascan mentres as peticións pequenas funcionan.

ping -M do -s 1400 10.8.0.5

Unha resposta demostra que ese tamaño cruza a ruta sen fragmentar; un tempo de espera significa que a sobrecarga de encapsulación empuxou o paquete máis aló da MTU do túnel. Baixa a MTU na interface de compartición ou limita o tamaño máximo de segmento no reenviador, e despois repite a mesma proba. Proba primeiro o mesmo tamaño no lado da LAN, porque un fallo local apunta á LAN e non ao túnel. Anota o tamaño que funciona, xa que un cambio posterior de provedor ou de túnel pode movelo.

Para un só dispositivo extra abonda coa compartición do host. Para un fogar, pon a ruta no router. Cando o acceso debe sobrevivir a que o portátil marche contigo, o túnel mesmo pertence a unha pasarela dedicada.