VPN-gateway op een Raspberry Pi: één netwerkkaart of een aparte clientpoort

Je hebt één Pi, één werkend uitgaand VPN-profiel en twee apparaten die daardoor internet moeten bereiken. De vraag die de hele opbouw bepaalt, is niet welke handleiding je volgt, maar hoeveel inkapseling je nodig hebt. Eén poort laat de Pi naast die apparaten op het LAN van de router staan en als extra gateway werken; een tweede poort laat je ze op een segment zetten waar de Pi de enige uitweg is. Alles daarna — DHCP, de omvang van de firewall, DNS, het uitvalgeval — volgt daaruit.

Waarin de twee opzetten werkelijk verschillen

Beide ontwerpen routeren. Het verschil is wie er nog meer aan de kabel hangt en wat er gebeurt als je beleid verkeerd is.

Inkapseling is de echte as. Opzet A is adviserend: een apparaat dat de gateway van DHCP negeert en de router kiest, werkt nog steeds, maar onversleuteld. Opzet B wordt door de topologie afgedwongen, omdat er geen andere volgende hop te kiezen is.

Opzet A: de Pi als extra gateway op het bestaande LAN

Stel dat de ISP-router 192.168.50.1 is, de Pi 192.168.50.2, en de gekozen clients naar de Pi wijzen. Het belangrijkste is dat twee verschillende pakketstromen één kabel delen. Het binnenste pakket van de client komt bij de Pi aan en moet door de tunnel naar buiten; het eigen versleutelde pakket van de Pi naar de VPN-partner moet via dezelfde kabel naar de router naar buiten. Ze reizen in tegengestelde richtingen over dezelfde interface en vragen een andere behandeling.

Geef de Pi zijn adres via de geïnstalleerde netwerkbeheerder, niet met een oud interfacebestand-recept dat er met hem om het apparaat vecht. Stel daarna de clients in: een statische gateway op één apparaat, of een DHCP-reservering die 192.168.50.2 als router uitdeelt. Verander niet het hele DHCP-bereik van de router voor twee apparaten, en ga er niet van uit dat een client de optie respecteert — verifieer het.

De zwakte is structureel en niet te repareren. Elke client op dat segment kan naar 192.168.50.1 wijzen en onversleuteld naar buiten, en een apparaat met een tweede interface of een mobiele radio verlaat je handhavingspad volledig. Als die zin onaanvaardbaar is voor het betreffende apparaat, heb je het antwoord al: gebruik opzet B.

Opzet B: een aparte poort sluit de apparaten binnen

Hier houdt de Pi 192.168.50.2 op de uplink met gateway 192.168.50.1, en neemt 10.20.0.1/24 op een tweede interface voor de aangesloten apparaten. De Pi is nu een router met twee netwerken, en het aangesloten segment heeft precies één uitgang.

Controleer het bereik tegen al het andere voordat je je vastlegt: het eigen subnet van de tunnel, andere site-naar-site-prefixen en alles wat via de VPN bereikbaar is. Een 10.20.0.0/24 die botst met een extern LAN levert dat halfwerkende resultaat op waarvan de diagnose een avond kost. Als de tweede poort een USB-adapter is, bevestig dan dat hij wordt ondersteund en zet zijn naam vast in de netwerkbeheerder, zodat een herordening na herstart je LAN-adres niet verplaatst.

Draai de DHCP-luisteraar alleen op die interface. Een server die op de uplink antwoordt, concurreert met de ISP-router en deelt de adressen van jouw segment uit aan de rest van het huis. Bind hem aan de LAN-interface, beperk hem tot het opgegeven bereik, en houd het eigen adres van de Pi buiten de pool.

Doorsturen, vertaling en de regel om bij falen te sluiten

Vier dingen worden vaak als één beschreven en zijn dat niet. Doorsturen aanzetten (net.ipv4.ip_forward=1) vertelt de kernel alleen dat hij pakketten tussen interfaces mag verplaatsen; het staat zelf niets toe en garandeert geen enkele route. De uitgang kiezen is een routeringsbeslissing. Het pakket toestaan is een beleidsbeslissing in de forward-keten. De bron ervan herschrijven is een postrouting-beslissing. Een opbouw die alleen het eerste doet, levert een Pi op die klantverkeer vrolijk via de uplink naar buiten doorstuurt.

Beperk de toestemming tot de bronnen die je bedoelde en tot de interface die het verkeer moet gebruiken, en neem de terugweg en de eigen benodigde bestemmingen van de Pi mee. Vertaal dan op de tunneluitgang als de provider je LAN-prefix niet naar je terugrouteert. nftables-handleiding behandelt doorsturen, lokale uitvoer en bronvertaling als afzonderlijke bewerkingen, wat hier het juiste denkmodel is.

De gebruikelijke fout is een brede masquerade-regel op de fysieke interface. Dan bereikt het verkeer internet via de ISP-route terwijl het er vanaf de clientkant precies uitziet als een werkende VPN. Dat bewijst niets. Houd de vertaling gebonden aan de opgegeven uitgang, en houd je regels in de firewall die de host al gebruikt, in plaats van een concurrerende regelset toe te voegen die een gedeelde postrouting-keten leegmaakt.

Behandel daarna het ontbreken van de tunnel. Een clientprofiel dat een brede standaardroute installeert, betekent ook dat wanneer de tunnel wegvalt, de gewone standaardroute kan terugkomen en klantverkeer stil terugkeert naar de uplink. Waar terugval naar platte tekst niet aanvaardbaar is, moet het forward-beleid verkeer van client naar uplink uitdrukkelijk weigeren, in de toestand waarin de VPN-route weg is. Schrijf dat als een weigeringsregel, niet als een aanname. Het eigen versleutelde transport van de Pi naar de VPN-partner is een aparte local-output-stroom en moet toegestaan blijven, anders kan de tunnel nooit terugkomen.

DNS en IPv6 hebben hun eigen antwoord nodig

Als clients de Pi als resolver gebruiken, komen ze bij een lokale luisteraar uit en start de Pi een nieuwe query. Die upstream-query volgt de eigen route van de Pi, niet de forward-regel die je voor clients schreef, dus een clientpad alleen door de tunnel plus een resolver die direct naar buiten gaat is een lek zonder enige foutmelding. Beslis bewust: een resolver die via de tunnel bereikbaar is, of een lokale die je als direct accepteert, en laat het eigen uitgaande beleid van de Pi bij die beslissing passen.

IPv6 is weer een eigen geval. Een forward-regel voor IPv4 beperkt niets met betrekking tot IPv6, en routeraankondigingen op de uplink kunnen de Pi, en via hem het aangesloten segment, een tweede standaardroute geven die je beleid omzeilt. Geef IPv6 ofwel zijn eigen beschermde pad volgens hetzelfde principe, ofwel beperk het uitdrukkelijk op het clientsegment en zeg dat.

Test de grens voordat je erop vertrouwt

Accepteer het ontwerp pas na vier afzonderlijke controles, want de verleidelijke enkele test — een browser openen op één client — slaagt in meerdere kapotte toestanden.

Bevestig dat één echte client internet bereikt via de tunnel, en bevestig daarna dat dezelfde client geen internet bereikt als de tunnel neerligt. Bevestig dat DNS-resolutie werkt en dat de query naar buiten gaat waar je het bedoelde. Bevestig dat het eigen transport van de Pi na een herstart van de tunnel nog werkt, en dat herstel geen herstart van de machine vereist. Controleer tot slot een apparaat dat je niet hebt gekozen: onder opzet A hoort het normaal te blijven werken, en onder opzet B hoort het daar helemaal niet te bestaan.

• Twee poorten en een weigeringsregel geven handhaving; één poort en een DHCP-optie geven advies.
• Vertaling op de verkeerde interface lijkt een succes en is het niet.
• Het eigen verkeer van de Pi, DNS en IPv6 vragen elk een beslissing, geen gevolgtrekking.