Eén VPN-verbinding delen met elk apparaat op je LAN

Eén laptop houdt de tunnel, de rest van het huis wil dezelfde toegang, en de eerste poging is alles naar de verbonden machine wijzen. Dat mislukt om redenen die niets met de VPN te maken hebben: de ontvangende host moet het pakket doorsturen, de bron herschrijven en ervoor zorgen dat antwoorden de weg terug vinden. Mis je een van de drie, dan blijft de verbonden laptop werken terwijl elk ander apparaat een time-out krijgt. De oplossing is een routeringsontwerp, geen clientinstelling.

Waarom apparaten naar de host wijzen mislukt

Een host die een pakket ontvangt dat aan een extern netwerk is gericht, wordt op dat moment een router, of iemand hem nu als zodanig heeft ingesteld of niet. Doorsturen staat standaard uit op Linux en op Windows, tenzij een functie het aanzet. Adresvertaling is belangrijk omdat de externe kant moet weten waar antwoorden naartoe moeten, en een privaat LAN-adres zegt hem niets. De retourroute is het derde stuk, en dat is het stuk dat mensen vergeten wanneer de eerste ping lijkt te slagen.

Diagnosticeer in die volgorde in plaats van willekeurig instellingen aan en uit te zetten. Elk ontbrekend stuk geeft een iets ander symptoom.

Zet doorsturen en adresvertaling aan op de host

Twee wijzigingen op de verbonden host dekken de eerste twee stukken: IPv4-doorsturen aanzetten en het LAN-verkeer naar de tunnelinterface vertalen.

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

Bewaar de sysctl-waarde in een bestand onder /etc/sysctl.d, en controleer de masquerade-regel opnieuw na een herstart, omdat firewall-frontends aangepaste chains kunnen leegmaken. Op Windows voert de deelfunctie beide stappen uit, maar ze wijzigt ook het LAN-adapter naar een vast subnet en wist de gateway, wat statische adressering en port forwarding breekt. Herstel het pad van de router naar de host op het nieuwe adres voordat je concludeert dat delen is mislukt. Kijk dan hoe de tellers van de regel oplopen terwijl een tweede apparaat verkeer verstuurt.

Geef het LAN een pad dat herstarts overleeft

De andere apparaten hebben een route naar de externe prefix nodig, en de twee manieren om die te bieden verschillen in impact.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

De standaardgateway van een client naar de host wijzen stuurt al zijn verkeer via de host, inclusief lokaal printen en bestandsdeling, waardoor ongerelateerde dingen stoppen wanneer de host slaapt. Een specifieke route op de router voor de externe prefix toevoegen is smaller: alleen bestemmingen achter de tunnel gaan naar de verbonden machine, en de rest van het LAN blijft werken. De subnetten hierboven zijn voorbeelden, dus vervang ze door je eigen LAN- en tunnelbereiken. Test het in beide gevallen vanaf een tweede apparaat met de tunnel aan en daarna uit.

Let op de MTU voordat je de tunnel de schuld geeft

Tunnels verkleinen de bruikbare pakketgrootte, en het tweede apparaat heeft geen idee. Grote overdrachten en TLS-handshakes lopen vast terwijl kleine verzoeken slagen.

ping -M do -s 1400 10.8.0.5

Een antwoord bewijst dat die grootte het pad ongefragmenteerd aflegt; een time-out betekent dat de encapsulatie-overhead het pakket voorbij de MTU van de tunnel duwde. Verlaag de MTU op de deelinterface of begrens de maximale segmentgrootte op de doorstuurder, en herhaal dan dezelfde test. Test dezelfde grootte eerst aan de LAN-kant, want een lokale fout wijst op het LAN en niet op de tunnel. Noteer de werkende grootte, want een latere wijziging van provider of tunnel kan die verschuiven.

Voor één extra apparaat is delen vanaf de host genoeg. Voor een huishouden zet je de route op de router. Als toegang moet blijven bestaan wanneer de laptop met je meegaat, hoort de tunnel zelf op een aparte gateway.