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

At sætte et helt LAN bag en VPN-tunnel er den nemme del; at afgøre, hvordan den fjerne side ser de klienter, er det ikke. Masquerade omskriver hver LAN-kilde til gatewayens tunleadresse, så den fjerne ende svarer én peer. Policy routing bevarer de oprindelige adresser og kræver, at den fjerne ende ved, hvordan den når dem. Ingen af delene er standard; valget følger af, hvem der ejer den fjerne side, og om identitet pr. enhed betyder noget.

De to designs lover forskellige ting

Masquerade reducerer LAN'et til én synlig vært: gatewayen. Det fjerne netværk svarer på den ene adresse, og gatewayen oversætter svarene tilbage til den klient, der startede flowet. Der er ikke brug for nogen rute til dine private præfikser på den fjerne side, og derfor overlever dette design en udbyder, der nægter at føre dem. Gatewayen bliver også kilden til hver forbindelse, så den fjerne side kan ikke skelne to klienter.

Policy routing holder hver klientadresse intakt. Det fjerne netværk ser den faktiske kilde og kan logge den, anvende en regel pr. vært eller sende svaret direkte til den adresse. Den synlighed er hele pointen, og den kommer med en forpligtelse: den fjerne side skal have en rute til LAN-præfikset, der peger tilbage gennem tunnelen. Planlæg den rute, før du aktiverer reglen, for tunnelen kommer op uanset hvad, og det er kun svarene, der mangler.

Fejltilstandene adskiller sig lige så meget som løfterne. En manglende masquerade-regel giver pakker, der forlader med private kilder og aldrig vender tilbage. En manglende returrute giver det samme symptom under policy routing, men rettelsen hører på den fjerne router og ikke på gatewayen.

Masquerade: én peer på den fjerne side

Masquerade-vejen har en rækkefølge, der betyder noget. Videresendelse skal være slået til, før nogen NAT-regel gør nytte, filtertabellen skal tillade gennemgang i begge retninger, og først derefter gælder oversættelsen på tunnelegrænsefladen.

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

Klienterne skal stadig have en vej til gatewayen. Enten er gatewayen deres standardrouter, eller også bærer de en specifik rute til det fjerne præfiks; hvis en separat router forbliver standard, har den router brug for en statisk rute til tunnelens destinationer, ellers går pakken til det forkerte hop, før gatewayen ser den.

DNS er en separat beslutning. En resolver på den fjerne side svarer kun, hvis svaret kan rejse tilbage til klienten. Under masquerade ser forespørgslen ud til at komme fra gatewayen, så resolverens returvej er allerede opfyldt; under policy routing har resolveren brug for den samme returrute som enhver anden fjern tjeneste.

Policy routing: bevar kilden, tilføj en returvej

Policy routing begynder med en tabel og en regel, der vælger den. Trafik, der kommer ind fra LAN-grænsefladen, sendes til en dedikeret tabel, og den tabel bærer en standardrute gennem tunnelen. Hovedtabellen forbliver urørt, så trafik, der stammer fra gatewayen selv, kan følge en anden vej.

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

Den fjerne side skal derefter rutte LAN-præfikset tilbage gennem tunnelen. Det er en konfiguration på den fjerne router, ikke på denne gateway. Gatewayen skal også acceptere svar, der ankommer på en anden grænseflade, end hovedtabellen ville forudsige; løs omvendt sti-filtrering (rp_filter sat til 2) er den sædvanlige justering, når streng tilstand dropper de pakker.

Når to tunneler er aktive, tag hvert flow ved indgangen, og lad tagget vælge tabellen. En regel, der kun ser på indgangsgrænsefladen, sender begge tunnelers trafik til den samme tabel, så den anden tunnel stjæler flows fra den første. Test det tag med en forbindelse, der overlever en genopkobling, for det er der, en blandet politik viser sig.

Beslut ud fra ejerskab og ud fra, hvad den fjerne side logger

Hvis tunnelen ender hos en udbyder, brug masquerade. Den operatør vil ikke rutte dine private LAN-intervaller, og den har ingen grund til at skelne enkelte klienter bag din gateway. Én synlig peer er den eneste model, dens politik understøtter, så giv den det, og hold oversættelsen ved din kant. Udbyderen ser én peer, hvilket er præcis, hvad dens politik forventer, og dine klienter arver den ene identitet.

Hvis begge ender er dine, og de fjerne tjenester handler på kildeadresser, fortjener policy routing sin ekstra rute. Firewall-regler, adgang pr. bruger og revisionslogge kan så skelne klienter. Hvis den fjerne side kun har brug for nåbarhed, er masquerade enklere og fjerner en klasse af returrute-fejl.

Hybride designs er normale: policy routing i dit eget netværk, masquerade ved udbyderkanten. Det vigtige er at skrive ned, hvilket hop der oversætter, og hvilket hop der router, for en tilfældig NAT-regel tilføjet for én klient skjuler kilden for hver klient i samme kæde.

Verificér fra en klient, derefter fra en anden klient

Kør testen, hvor trafikken starter. Kontrollér den rute, værten bruger, se pakken dukke op på tunnelegrænsefladen, og undersøg conntrack for oversættelsen. Den sekvens beviser, at pakken tog den tilsigtede vej i stedet for blot at ankomme et eller andet sted.

Gentag testen efter en genopkobling. En masquerade-regel, der navngiver grænsefladen, overlever en ny tunleadresse; en regel, der navngiver den gamle adresse, gør ikke. Test derefter en anden LAN-vært, for et design, der virker på én maskine, afhænger ofte af den maskines egen rute snarere end af gatewayens politik.

Skriv den valgte model, den oversatte eller bevarede kilde og returrutens ejer ned i gateway-noterne. Ellers gætter den næste person, der tilføjer en klient eller en tunnel, og et gæt er, hvordan et fungerende LAN-til-VPN-setup bliver delvist.