Masquerade eller policy-routing: LAN-trafik genom en VPN-gateway

Att sätta ett helt LAN bakom en VPN-tunnel är den lätta delen; att avgöra hur fjärrsidan ser dessa klienter är det inte. Masquerade skriver om varje LAN-källa till gatewayens tunneladress, så fjärränden svarar en enda peer. Policy-routing behåller de ursprungliga adresserna och kräver att fjärrsidan vet hur den når dem. Ingen av dem är standard; valet följer av vem som äger fjärrsidan och om identitet per enhet spelar roll.

De två designerna lovar olika saker

Masquerade reducerar LAN:et till en enda synlig värd: gatewayen. Fjärrnätverket svarar på den enda adressen, och gatewayen översätter svaren tillbaka till klienten som startade flödet. På fjärrsidan behövs ingen rutt till dina privata prefix, och därför överlever designen hos en leverantör som vägrar bära dem. Gatewayen blir också källan till varje anslutning, så fjärrsidan kan inte skilja två klienter åt.

Policy-routing håller varje klientadress intakt. Fjärrnätverket ser den verkliga källan och kan logga den, tillämpa en regel per värd eller skicka svaret direkt till den adressen. Den synligheten är hela poängen, och den kommer med en skyldighet: fjärrsidan måste ha en rutt för LAN-prefixet som pekar tillbaka genom tunneln. Planera den rutten innan du aktiverar regeln, för tunneln kommer upp ändå och det är bara svaren som kommer att saknas.

Fellägena skiljer sig lika mycket som löftena. En saknad masquerade-regel ger paket som lämnar med privata källor och aldrig kommer tillbaka. En saknad returrutt ger samma symptom vid policy-routing, men rättelsen hör hemma på fjärrroutern och inte på gatewayen.

Masquerade: en enda peer på fjärrsidan

Masquerade-vägen har en ordning som spelar roll. Vidarebefordran måste vara påslagen innan någon NAT-regel gör nytta, filtertabellen måste tillåta genomgång i båda riktningarna, och först då gäller översättningen på tunnelgränssnittet.

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

Klienterna behöver fortfarande en väg till gatewayen. Antingen är gatewayen deras standardrouter, eller så bär de en specifik rutt till fjärrprefixet; om en separat router blir kvar som standard behöver den routern en statisk rutt till tunnelns destinationer, annars går paketet till fel hopp innan gatewayen ser det.

DNS är ett eget beslut. En resolver på fjärrsidan svarar bara om svaret kan resa tillbaka till klienten. Under masquerade ser frågan ut att komma från gatewayen, så resolverns returväg är redan uppfylld; under policy-routing behöver resolvern samma returrutt som varje annan fjärrtjänst.

Policy-routing: behåll källan, lägg till en returväg

Policy-routing börjar med en tabell och en regel som väljer den. Trafik som kommer in från LAN-gränssnittet skickas till en egen tabell, och den tabellen bär en standardrutt genom tunneln. Huvudtabellen förblir orörd, så trafik som gatewayen själv skapar kan följa en annan väg.

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

Fjärrsidan måste sedan rutta LAN-prefixet tillbaka genom tunneln. Det är en konfiguration på fjärrroutern, inte på den här gatewayen. Gatewayen måste också acceptera svar som kommer in på ett annat gränssnitt än huvudtabellen skulle förutse; lös omvänd vägfiltrering (rp_filter satt till 2) är den vanliga justeringen när strängt läge släpper de paketen.

När två tunnlar är aktiva, tagga varje flöde vid ingången och låt taggen välja tabellen. En regel som bara tittar på ingångsgränssnittet skickar trafiken från båda tunnlarna till samma tabell, så den andra tunneln stjäl flöden från den första. Testa taggen med en anslutning som överlever en återanslutning, för det är då en blandad policy visar sig.

Bestäm efter ägarskap och efter vad fjärrsidan loggar

Om tunneln slutar hos en leverantör, använd masquerade. Den operatören kommer inte att rutta dina privata LAN-intervall, och den har ingen anledning att skilja enskilda klienter bakom din gateway. En synlig peer är den enda modell som dess policy stöder, så ge den det och håll översättningen vid din kant. Leverantören ser en peer, vilket är precis vad dess policy förväntar sig, och dina klienter ärver den enda identiteten.

Om båda ändarna är dina och fjärrtjänsterna agerar på källadresser, förtjänar policy-routing sin extra rutt. Brandväggsregler, åtkomst per användare och granskningsloggar kan då skilja klienter åt. Om fjärrsidan bara behöver nåbarhet är masquerade enklare och tar bort en hel klass av returruttfel.

Hybriddesigner är normala: policy-routing i ditt eget nät, masquerade vid leverantörens kant. Det viktiga är att skriva ned vilket hopp som översätter och vilket hopp som ruttar, för en oavsiktlig NAT-regel tillagd för en klient döljer källan för varje klient i samma kedja.

Verifiera från en klient, sedan från en andra klient

Kör testet där trafiken börjar. Kontrollera rutten som värden använder, se paketet dyka upp på tunnelgränssnittet och granska conntrack för översättningen. Den sekvensen bevisar att paketet tog den avsedda vägen, inte att det bara anlände någonstans.

Upprepa testet efter en återanslutning. En masquerade-regel som namnger gränssnittet överlever en ny tunneladress; en regel som namnger den gamla adressen gör det inte. Testa sedan en andra LAN-värd, för en design som fungerar på en maskin beror ofta på maskinens egen rutt snarare än på gatewayens policy.

Skriv ned den valda modellen, källan som översattes eller bevarades och ägaren av returrutten i gateway-anteckningarna. Annars gissar nästa person som lägger till en klient eller en tunnel, och gissande är hur en fungerande LAN-till-VPN-uppsättning blir delvis.