Dela en VPN-anslutning med alla enheter på ditt LAN

En laptop håller tunneln, resten av huset vill ha samma åtkomst, och det första försöket är att peka allt mot den anslutna maskinen. Det misslyckas av skäl som inte har något med VPN att göra: mottagande värd måste vidarebefordra paketet, skriva om dess källa och se till att svar hittar vägen tillbaka. Saknas någon av de tre fortsätter den anslutna laptopen att fungera medan alla andra enheter får tidsgräns. Lösningen är en routingdesign, inte en klientinställning.

Varför det misslyckas att peka enheter mot värden

En värd som tar emot ett paket adresserat till ett avlägset nätverk blir en router för det ögonblicket, oavsett om någon har konfigurerat den som en sådan eller inte. Vidarebefordran är av som standard på Linux och på Windows om inte en funktion slår på den. Adressöversättning spelar roll eftersom fjärrsidan måste veta vart svaren ska skickas, och en privat LAN-adress betyder ingenting för den. Returvägen är den tredje biten, och det är den folk glömmer när den första pingningen verkar lyckas.

Diagnostisera i den ordningen i stället för att slå inställningar av och på på måfå. Varje saknad bit ger ett något annat symptom.

Slå på vidarebefordran och adressöversättning på värden

Två ändringar på den anslutna värden täcker de två första bitarna: slå på IPv4-vidarebefordran och översätt LAN-trafiken till tunnelgränssnittet.

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

Spara sysctl-värdet i en fil under /etc/sysctl.d, och kontrollera masquerade-regeln igen efter en omstart, eftersom brandväggens frontends kan tömma anpassade kedjor. På Windows utför delningsfunktionen båda stegen, men den adresserar också om LAN-adaptern till ett fast subnät och rensar dess gateway, vilket bryter statisk adressering och port forwarding. Återställ routerns väg till värden på den nya adressen innan du drar slutsatsen att delningen misslyckades. Titta sedan på hur regelns räknare ökar medan en andra enhet skickar trafik.

Ge LAN:et en väg som överlever omstarter

De andra enheterna behöver en väg till fjärrprefixet, och de två sätten att tillhandahålla den skiljer sig i omfattning.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Att peka en klients standardgateway mot värden skickar all dess trafik genom värden, inklusive lokal utskrift och fildelning, så orelaterade saker stannar när värden sover. Att lägga till en specifik väg på routern för fjärrprefixet är smalare: bara destinationer bakom tunneln går till den anslutna maskinen, och resten av LAN:et fortsätter att fungera. Subnäten ovan är exempel, så ersätt dem med dina egna LAN- och tunnelintervall. Testa i vilket fall som helst från en andra enhet med tunneln på och sedan av.

Håll koll på MTU innan du skyller på tunneln

Tunnlar krymper den användbara paketstorleken, och den andra enheten har ingen aning. Stora överföringar och TLS-handskakningar fastnar medan små förfrågningar lyckas.

ping -M do -s 1400 10.8.0.5

Ett svar bevisar att den storleken korsar vägen ofragmenterad; en tidsgräns betyder att inkapslingens overhead sköt paketet förbi tunnelns MTU. Sänk MTU:n på delningsgränssnittet eller begränsa den maximala segmentstorleken på vidarebefordraren och upprepa sedan samma test. Testa samma storlek på LAN-sidan först, eftersom ett lokalt fel pekar på LAN:et och inte på tunneln. Anteckna storleken som fungerar, eftersom en senare ändring av leverantören eller tunneln kan flytta den.

För en enda extra enhet räcker delning från värden. För ett hushåll sätter du vägen på routern. När åtkomsten måste överleva att laptopen följer med dig hör själva tunneln hemma på en dedikerad gateway.