Masquerade eller policy-ruting: LAN-trafikk gjennom en VPN-gateway

Å sette et helt LAN bak en VPN-tunnel er den enkle delen; å avgjøre hvordan den fjerne siden ser disse klientene er det ikke. Masquerade skriver om hver LAN-kilde til gatewayens tunelladresse, slik at den fjerne enden svarer én peer. Policy-ruting beholder de opprinnelige adressene og krever at den fjerne siden vet hvordan den når dem. Ingen av delene er standard; valget følger av hvem som eier den fjerne siden og om identitet per enhet betyr noe.

De to designene lover forskjellige ting

Masquerade reduserer LAN-et til én synlig vert: gatewayen. Det fjerne nettverket svarer på den ene adressen, og gatewayen oversetter svarene tilbake til klienten som startet flyten. På den fjerne siden trengs ingen rute til dine private prefikser, og derfor overlever dette designet en leverandør som nekter å føre dem. Gatewayen blir også kilden til hver tilkobling, så den fjerne siden kan ikke skille to klienter.

Policy-ruting holder hver klientadresse intakt. Det fjerne nettverket ser den faktiske kilden og kan logge den, bruke en regel per vert eller sende svaret direkte til den adressen. Den synligheten er hele poenget, og den kommer med en forpliktelse: den fjerne siden må ha en rute for LAN-prefikset som peker tilbake gjennom tunnelen. Planlegg den ruten før du aktiverer regelen, for tunnelen kommer opp uansett, og det er bare svarene som vil mangle.

Feilmodusene skiller seg like mye som løftene. En manglende masquerade-regel gir pakker som går ut med private kilder og aldri kommer tilbake. En manglende returrute gir samme symptom under policy-ruting, men rettelsen hører på den fjerne ruteren og ikke på gatewayen.

Masquerade: én peer på den fjerne siden

Masquerade-veien har en rekkefølge som betyr noe. Videresending må være slått på før noen NAT-regel gjør nytte, filtertabellen må tillate gjennomgang i begge retninger, og først da gjelder oversettelsen 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

Klientene trenger fortsatt en vei til gatewayen. Enten er gatewayen standardruteren deres, eller de bærer en spesifikk rute til det fjerne prefikset; hvis en separat ruter blir stående som standard, trenger den ruteren en statisk rute til tunnelens destinasjoner, ellers går pakken til feil hopp før gatewayen ser den.

DNS er en egen beslutning. En resolver på den fjerne siden svarer bare hvis svaret kan reise tilbake til klienten. Under masquerade ser forespørselen ut til å komme fra gatewayen, så resolverens returvei er allerede oppfylt; under policy-ruting trenger resolveren samme returrute som enhver annen fjern tjeneste.

Policy-ruting: behold kilden, legg til en returvei

Policy-ruting begynner med en tabell og en regel som velger den. Trafikk som kommer inn fra LAN-grensesnittet sendes til en egen tabell, og den tabellen bærer en standardrute gjennom tunnelen. Hovedtabellen forblir urørt, så trafikk som gatewayen selv skaper kan følge en annen vei.

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

Den fjerne siden må deretter rute LAN-prefikset tilbake gjennom tunnelen. Det er en konfigurasjon på den fjerne ruteren, ikke på denne gatewayen. Gatewayen må også godta svar som kommer inn på et annet grensesnitt enn hovedtabellen ville forutsi; løs omvendt sti-filtrering (rp_filter satt til 2) er den vanlige justeringen når streng modus slipper de pakkene.

Når to tunneler er aktive, tag hver flyt ved inngangen og la taggen velge tabellen. En regel som bare ser på inngangsgrensesnittet sender trafikken fra begge tunnelene til samme tabell, så den andre tunnelen stjeler flyter fra den første. Test taggen med en tilkobling som overlever en gjenoppkobling, for det er da en blandet policy viser seg.

Avgjør ut fra eierskap og ut fra hva den fjerne siden logger

Hvis tunnelen ender hos en leverandør, bruk masquerade. Den operatøren vil ikke rute dine private LAN-områder, og den har ingen grunn til å skille enkeltklienter bak gatewayen din. Én synlig peer er den eneste modellen dens policy støtter, så gi den det og hold oversettelsen på din kant. Leverandøren ser én peer, som er nøyaktig det policyen forventer, og klientene dine arver den ene identiteten.

Hvis begge ender er dine og de fjerne tjenestene handler på kildeadresser, fortjener policy-ruting sin ekstra rute. Brannmurregler, tilgang per bruker og revisjonslogger kan da skille klienter. Hvis den fjerne siden bare trenger nåbarhet, er masquerade enklere og fjerner en klasse returrute-feil.

Hybride design er normale: policy-ruting i ditt eget nettverk, masquerade ved leverandørens kant. Det viktige er å skrive ned hvilket hopp som oversetter og hvilket hopp som ruter, for en tilfeldig NAT-regel lagt til for én klient skjuler kilden for hver klient i samme kjede.

Verifiser fra en klient, deretter fra en andre klient

Kjør testen der trafikken starter. Kontroller ruten verten bruker, se pakken dukke opp på tunellgrensesnittet, og undersøk conntrack for oversettelsen. Den sekvensen beviser at pakken tok den tiltenkte veien, ikke bare ankom et sted.

Gjenta testen etter en gjenoppkobling. En masquerade-regel som navngir grensesnittet overlever en ny tunelladresse; en regel som navngir den gamle adressen gjør det ikke. Test deretter en annen LAN-vert, for et design som virker på én maskin avhenger ofte av maskinens egen rute snarere enn av gatewayens policy.

Skriv den valgte modellen, kilden som ble oversatt eller bevart, og eieren av returruten i gateway-notatene. Ellers vil den neste personen som legger til en klient eller en tunnel gjette, og gjetting er hvordan et fungerende LAN-til-VPN-oppsett blir delvis.