Masquerade of beleidsroutering: LAN-verkeer via een VPN-gateway

Een heel LAN achter een VPN-tunnel zetten is het makkelijke deel; beslissen hoe de verre kant die clients ziet niet. Masquerade herschrijft elke LAN-bron naar het tunneladres van de gateway, zodat de verre kant op één peer antwoordt. Beleidsroutering behoudt de oorspronkelijke adressen en eist dat de verre kant weet hoe die te bereiken. Geen van beide is standaard; de keuze volgt uit wie de verre kant bezit en of identiteit per apparaat ertoe doet.

De twee ontwerpen beloven verschillende dingen

Masquerade reduceert het LAN tot één zichtbare host: de gateway. Het verre netwerk antwoordt op dat ene adres, en de gateway vertaalt de antwoorden terug naar de client die de stroom begon. Aan de verre kant is geen route naar je privéprefixen nodig, en daarom overleeft dit ontwerp een provider die weigert ze te dragen. De gateway wordt ook de bron van elke verbinding, dus de verre kant kan twee clients niet onderscheiden.

Beleidsroutering houdt elk clientadres intact. Het verre netwerk ziet de werkelijke bron en kan die loggen, een regel per host toepassen of het antwoord rechtstreeks naar dat adres sturen. Die zichtbaarheid is het hele punt, en ze komt met een verplichting: de verre kant moet een route voor het LAN-prefix hebben die terug door de tunnel wijst. Plan die route voordat je de regel inschakelt, want de tunnel komt hoe dan ook omhoog en alleen de antwoorden zullen ontbreken.

De faalmodi verschillen net zoveel als de beloftes. Een ontbrekende masquerade-regel levert pakketten die met privébronnen vertrekken en nooit terugkomen. Een ontbrekende terugroute levert hetzelfde symptoom bij beleidsroutering, maar de oplossing hoort op de verre router en niet op de gateway.

Masquerade: één peer aan de verre kant

Het masquerade-pad heeft een volgorde die ertoe doet. Doorsturen moet aan staan voordat welke NAT-regel dan ook nut heeft, de filtertabel moet de doorgang in beide richtingen toestaan, en pas dan geldt de vertaling op de tunnelinterface.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Clients hebben nog steeds een pad naar de gateway nodig. Ofwel is de gateway hun standaardrouter, ofwel dragen ze een specifieke route voor het verre prefix; blijft een aparte router de standaard, dan heeft die router een statische route naar de tunneldestinaties nodig, anders gaat het pakket naar de verkeerde hop voordat de gateway het ziet.

DNS is een aparte beslissing. Een resolver aan de verre kant antwoordt alleen als zijn antwoord terug naar de client kan reizen. Onder masquerade lijkt de query van de gateway te komen, dus de terugweg van de resolver is al voldaan; onder beleidsroutering heeft de resolver dezelfde terugroute nodig als elke andere verre dienst.

Beleidsroutering: behoud de bron, voeg een terugweg toe

Beleidsroutering begint met een tabel en een regel die die tabel kiest. Verkeer dat via de LAN-interface binnenkomt, gaat naar een aparte tabel, en die tabel draagt een standaardroute door de tunnel. De hoofdtabel blijft onaangeroerd, zodat verkeer dat de gateway zelf opwekt een ander pad kan volgen.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

De verre kant moet dan het LAN-prefix terug door de tunnel routeren. Dat is een configuratie op de verre router, niet op deze gateway. De gateway moet ook antwoorden accepteren die op een andere interface aankomen dan de hoofdtabel zou voorspellen; losse omgekeerde-padfiltering (rp_filter op 2 gezet) is de gebruikelijke aanpassing wanneer de strikte modus die pakketten laat vallen.

Wanneer twee tunnels actief zijn, tag dan elke stroom bij binnenkomst en laat de tag de tabel kiezen. Een regel die alleen naar de ingangsinterface kijkt, stuurt het verkeer van beide tunnels naar dezelfde tabel, zodat de tweede tunnel stromen van de eerste steelt. Test die tag met een verbinding die een herverbinding overleeft, want dan pas blijkt een gemengd beleid.

Beslis op basis van eigendom en van wat de verre kant logt

Als de tunnel bij een provider eindigt, gebruik masquerade. Die operator gaat je privé-LAN-reeksen niet routeren, en hij heeft geen reden om individuele clients achter je gateway te onderscheiden. Eén zichtbare peer is het enige model dat zijn beleid ondersteunt, dus geef hem dat en houd de vertaling aan jouw rand. De provider ziet één peer, precies wat zijn beleid verwacht, en je clients erven die ene identiteit.

Als beide kanten van jou zijn en de verre diensten op bronadressen handelen, verdient beleidsroutering zijn extra route. Firewallregels, toegang per gebruiker en auditlogs kunnen dan clients onderscheiden. Als de verre kant alleen bereikbaarheid nodig heeft, is masquerade eenvoudiger en haalt het een klasse terugroute-fouten weg.

Hybride ontwerpen zijn normaal: beleidsroutering binnen je eigen netwerk, masquerade aan de rand van de provider. Wat telt is opschrijven welke hop vertaalt en welke hop routeert, want een per ongeluk toegevoegde NAT-regel voor één client verbergt de bron voor elke client in dezelfde keten.

Verifieer vanaf één client, dan vanaf een tweede client

Voer de test uit waar het verkeer begint. Controleer de route die de host gebruikt, kijk hoe het pakket op de tunnelinterface verschijnt, en inspecteer conntrack voor de vertaling. Die volgorde bewijst dat het pakket het bedoelde pad nam in plaats van ergens aan te komen.

Herhaal de test na een herverbinding. Een masquerade-regel die de interface noemt, overleeft een nieuw tunneladres; een regel die het oude adres noemt niet. Test daarna een tweede LAN-host, want een ontwerp dat op één machine werkt, hangt vaak af van de eigen route van die machine en niet van het beleid van de gateway.

Schrijf het gekozen model, de vertaalde of behouden bron en de eigenaar van de terugroute in de gateway-notities. Anders raadt de volgende persoon die een client of een tunnel toevoegt, en raden is hoe een werkende LAN-naar-VPN-opstelling een gedeeltelijke wordt.