Del én VPN-tilkobling med alle enheter på LAN-et ditt

Én bærbar PC holder tunnelen, resten av huset vil ha samme tilgang, og det første forsøket er å peke alt mot maskinen som er tilkoblet. Det mislykkes av grunner som ikke har noe med VPN å gjøre: mottakerverten må videresende pakken, skrive om kilden og sørge for at svar finner veien tilbake. Mangler ett av de tre, fortsetter den tilkoblede PC-en å virke mens alle andre enheter får tidsavbrudd. Løsningen er en rutedesign, ikke en klientinnstilling.

Hvorfor det mislykkes å peke enheter mot verten

En vert som mottar en pakke adressert til et eksternt nettverk, blir en ruter for det øyeblikket, enten noen har konfigurert den som det eller ikke. Videresending er av som standard på Linux og på Windows med mindre en funksjon slår den på. Adresseoversettelse er viktig fordi den eksterne siden må vite hvor svarene skal sendes, og en privat LAN-adresse betyr ingenting for den. Returruten er den tredje biten, og det er den folk glemmer når den første ping-en ser ut til å lykkes.

Diagnostiser i den rekkefølgen i stedet for å slå innstillinger av og på tilfeldig. Hver manglende bit gir et litt annet symptom.

Slå på videresending og adresseoversettelse på verten

To endringer på den tilkoblede verten dekker de to første bitene: slå på IPv4-videresending og oversett LAN-trafikken til tunellgrensesnittet.

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

Lagre sysctl-verdien i en fil under /etc/sysctl.d, og sjekk masquerade-regelen på nytt etter omstart, siden brannmur-frontender kan tømme egendefinerte kjeder. På Windows utfører delingsfunksjonen begge trinnene, men den adresserer også LAN-adapteren på nytt til et fast subnett og fjerner gatewayen, noe som ødelegger statisk adressering og port forwarding. Gjenopprett ruterens vei til verten på den nye adressen før du konkluderer med at delingen mislyktes. Se deretter at tellerne for regelen øker mens en annen enhet sender trafikk.

Gi LAN-et en vei som overlever omstart

De andre enhetene trenger en rute til det eksterne prefikset, og de to måtene å skaffe den på skiller seg i omfang.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Å peke standardgatewayen til en klient mot verten sender all trafikken dens gjennom verten, inkludert lokal utskrift og fildeling, slik at urelaterte ting stopper når verten sover. Å legge til en spesifikk rute på ruteren for det eksterne prefikset er smalere: bare destinasjoner bak tunnelen går til den tilkoblede maskinen, og resten av LAN-et fortsetter å virke. Subnettene over er eksempler, så bytt dem ut med dine egne LAN- og tunnelområder. Uansett, test fra en annen enhet med tunnelen på og deretter av.

Følg med på MTU før du gir tunnelen skylden

Tunneler krymper den brukbare pakkestørrelsen, og den andre enheten aner ingenting. Store overføringer og TLS-handshake stopper mens små forespørsler lykkes.

ping -M do -s 1400 10.8.0.5

Et svar beviser at den størrelsen krysser veien ufragmentert; en tidsavbrudd betyr at innkapslingens overhead presset pakken forbi tunnelens MTU. Senk MTU-en på delingsgrensesnittet eller begrens maksimal segmentstørrelse på videresenderen, og gjenta deretter samme test. Test samme størrelse på LAN-siden først, fordi en lokal feil peker på LAN-et og ikke på tunnelen. Noter størrelsen som virker, siden en senere endring hos leverandøren eller i tunnelen kan flytte den.

For én ekstra enhet er deling fra verten nok. For en husstand setter du ruten på ruteren. Når tilgangen må overleve at den bærbare PC-en blir med deg, hører tunnelen selv hjemme på en dedikert gateway.