Comparteix una connexió VPN amb cada dispositiu de la teva LAN

Un portàtil sosté el túnel, la resta de la casa vol el mateix accés, i el primer intent és apuntar-ho tot a la màquina connectada. Falla per motius que no tenen res a veure amb la VPN: l’amfitrió receptor ha de reenviar el paquet, reescriure’n l’origen i assegurar-se que les respostes trobin el camí de tornada. Si en falta un dels tres, el portàtil connectat continua funcionant mentre tots els altres dispositius expiren. La solució és un disseny d’encaminament, no un paràmetre del client.

Per què falla apuntar els dispositius a l’amfitrió

Un amfitrió que rep un paquet adreçat a una xarxa remota es converteix en router en aquell moment, tant si algú l’ha configurat com a tal com si no. El reenviament està desactivat per defecte a Linux i a Windows tret que una funció l’activi. La traducció importa perquè el costat remot ha de saber on enviar les respostes, i una adreça privada de LAN no li diu res. La ruta de tornada és la tercera peça, i és la que la gent oblida quan el primer ping sembla funcionar.

Diagnostica en aquest ordre en lloc de canviar paràmetres a l’atzar. Cada peça que falta produeix un símptoma una mica diferent.

Activa el reenviament i la traducció a l’amfitrió

Dos canvis a l’amfitrió connectat cobreixen les dues primeres peces: activa el reenviament d’IPv4 i tradueix el trànsit de la LAN a la interfície del túnel.

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

Desa el valor de sysctl en un fitxer sota /etc/sysctl.d i torna a comprovar la regla masquerade després d’un reinici, ja que els fronts de tallafocs poden buidar cadenes personalitzades. A Windows la funció de compartició fa els dos passos, però també readreça l’adaptador de LAN a una subxarxa fixa i esborra la seva passarel·la, cosa que trenca l’adreçament estàtic i el reenviament de ports. Restaura el camí del router fins a l’amfitrió a la seva nova adreça abans de concloure que la compartició ha fallat. Després observa com augmenten els comptadors de regles mentre un segon dispositiu envia trànsit.

Dona a la LAN un camí que sobrevisqui als reinicis

Els altres dispositius necessiten una ruta cap al prefix remot, i les dues maneres de proporcionar-la difereixen en abast.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Apuntar la passarel·la per defecte d’un client a l’amfitrió envia tot el seu trànsit a través de l’amfitrió, inclosa la impressió local i la compartició de fitxers, així que les coses no relacionades s’aturen quan l’amfitrió dorm. Afegir una ruta específica al router per al prefix remot és més estret: només les destinacions darrere del túnel van a la màquina connectada, i la resta de la LAN continua funcionant. Les subxarxes anteriors són exemples, així que substitueix-les per les teves de LAN i túnel. De totes maneres, prova des d’un segon dispositiu amb el túnel actiu i després aturat.

Vigila la MTU abans de culpar el túnel

Els túnels redueixen la mida útil del paquet, i el segon dispositiu no en té ni idea. Les transferències grans i les negociacions TLS s’encallen mentre les peticions petites funcionen.

ping -M do -s 1400 10.8.0.5

Una resposta demostra que aquesta mida travessa el camí sense fragmentar; un temps d’espera significa que la sobrecàrrega d’encapsulament ha empès el paquet més enllà de la MTU del túnel. Baixa la MTU a la interfície de compartició o limita la mida màxima de segment al reenviador, i després repeteix la mateixa prova. Prova primer la mateixa mida al costat de la LAN, perquè una fallada local apunta a la LAN i no al túnel. Anota la mida que funciona, ja que un canvi posterior de proveïdor o de túnel la pot moure.

Per a un sol dispositiu extra, n’hi ha prou amb la compartició de l’amfitrió. Per a una llar, posa la ruta al router. Quan l’accés ha de sobreviure que el portàtil marxi amb tu, el túnel mateix pertany a una passarel·la dedicada.