Masquerade eller politikkbasert rutting: LAN-trafikk gjennom ei VPN-gateway

Å setje eit heilt LAN bak ein VPN-tunell er den enkle delen; å avgjere korleis den fjerne sida ser desse klientane er det ikkje. Masquerade skriv om kvar LAN-kjelde til tunelladressa til gatewayen, slik at den fjerne enden svarar éin peer. Politikkbasert rutting held på dei opphavlege adressene og krev at den fjerne sida veit korleis ho når dei. Ingen av delane er standard; valet følgjer av kven som eig den fjerne sida og om identitet per eining tyder noko.

Dei to designa lovar ulike ting

Masquerade reduserer LAN-et til éin synleg vert: gatewayen. Det fjerne nettverket svarar på den eine adressa, og gatewayen omset svara tilbake til klienten som starta flyten. På den fjerne sida trengst ingen rute til dine private prefiks, og difor overlever dette designet ein leverandør som nektar å føre dei. Gatewayen blir også kjelda til kvar tilkopling, så den fjerne sida kan ikkje skilje to klientar.

Politikkbasert rutting held kvar klientadresse intakt. Det fjerne nettverket ser den faktiske kjelda og kan logge henne, bruke ei regel per vert eller sende svaret rett til den adressa. Den synlegheita er heile poenget, og ho kjem med ei plikt: den fjerne sida må ha ei rute for LAN-prefikset som peikar tilbake gjennom tunellen. Planlegg den ruta før du aktiverer regelen, for tunellen kjem opp uansett, og det er berre svara som vil mangla.

Feilmodusane skil seg like mykje som lovnaden. Ein manglande masquerade-regel gjev pakkar som går ut med private kjelder og aldri kjem tilbake. Ei manglande returrute gjev same symptom under politikkbasert rutting, men rettinga høyrer på den fjerne rutaren og ikkje på gatewayen.

Masquerade: éin peer på den fjerne sida

Masquerade-vegen har ein rekkjefølgje som tyder noko. Vidaresending må vere slått på før noka NAT-regel gjer nytte, filtertabellen må tillate gjennomgang i begge retningar, og først då gjeld omsetjinga på tunellgrensesnittet.

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

Klientane treng framleis ein veg til gatewayen. Anten er gatewayen standardrutaren deira, eller dei ber ei særskild rute til det fjerne prefikset; blir ein separat rutar ståande som standard, treng den rutaren ei statisk rute til tunellmåla, elles går pakken til feil hopp før gatewayen ser han.

DNS er eit eige val. Ein resolvar på den fjerne sida svarar berre om svaret kan reise tilbake til klienten. Under masquerade ser førespurnaden ut til å kome frå gatewayen, så returvegen til resolvaren er alt oppfylt; under politikkbasert rutting treng resolvaren same returrute som kvar annan fjern teneste.

Politikkbasert rutting: hald på kjelda, legg til ein returveg

Politikkbasert rutting byrjar med ein tabell og ei regel som vel han. Trafikk som kjem inn frå LAN-grensesnittet, blir send til ein eigen tabell, og den tabellen ber ei standardrute gjennom tunellen. Hovudtabellen blir ståande urørd, så trafikk som gatewayen sjølv skaper kan følgje ein annan veg.

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

Den fjerne sida må deretter rute LAN-prefikset tilbake gjennom tunellen. Det er ein konfigurasjon på den fjerne rutaren, ikkje på denne gatewayen. Gatewayen må også godta svar som kjem inn på eit anna grensesnitt enn hovudtabellen ville spå, laus omvend sti-filtrering (rp_filter sett til 2) er den vanlege justeringa når streng modus slepp dei pakkane.

Når to tunellar er aktive, tag kvar flyt ved inngangen og la taggen velje tabellen. Ei regel som berre ser på inngangsgrensesnittet, sender trafikken frå begge tunellane til same tabell, så den andre tunellen stel flytar frå den første. Test taggen med ei tilkopling som overlever ei attoppkopling, for det er då ein blanda politikk viser seg.

Avgjer ut frå eigarskap og ut frå kva den fjerne sida loggar

Om tunellen endar hos ein leverandør, bruk masquerade. Den operatøren vil ikkje rute dei private LAN-områda dine, og han har ingen grunn til å skilje enkeltklientar bak gatewayen din. Éin synleg peer er den einaste modellen som politikken hans støttar, så gje han det og hald omsetjinga på din kant. Leverandøren ser éin peer, som er nett det politikken hans ventar, og klientane dine arvar den eine identiteten.

Om begge endane er dine og dei fjerne tenestene handlar på kjeldeadresser, fortener politikkbasert rutting den ekstra ruta si. Brannmurreglar, tilgang per brukar og revisjonsloggar kan då skilje klientar. Om den fjerne sida berre treng nåbarheit, er masquerade enklare og fjernar ein klasse returrute-feil.

Hybride design er normale: politikkbasert rutting i ditt eige nettverk, masquerade ved kanten av leverandøren. Det viktige er å skrive ned kva hopp som omset og kva hopp som rutar, for ein tilfeldig NAT-regel lagd til for éin klient gøymer kjelda for kvar klient i same kjeda.

Stadfest frå ein klient, deretter frå ein annan klient

Køyr testen der trafikken byrjar. Kontroller ruta verten brukar, sjå pakken dukke opp på tunellgrensesnittet, og gransk conntrack for omsetjinga. Den sekvensen beviser at pakken tok den tiltenkte vegen, ikkje berre kom ein stad.

Gjenta testen etter ei attoppkopling. Ein masquerade-regel som namngjev grensesnittet overlever ei ny tunelladresse; ein regel som namngjev den gamle adressa gjer det ikkje. Test deretter ein annan LAN-vert, for eit design som verkar på éi maskin heng ofte på ruta til maskinen sjølv snarare enn på politikken til gatewayen.

Skriv den valde modellen, kjelda som vart omsett eller bevart, og eigaren av returruta i gateway-notata. Elles vil den neste personen som legg til ein klient eller ein tunell gjetta, og gjetting er korleis eit fungerande LAN-til-VPN-oppsett blir delvis.