Masquerade of beleidsroutering: LAN-verkeer deur ’n VPN-gateway

Om ’n hele LAN agter ’n VPN-tonnel te plaas is die maklike deel; om te besluit hoe die verre kant daardie kliënte sien, is nie. Masquerading herskryf elke LAN-bron na die gateway se tonneladres, sodat die verre kant aan een peer antwoord. Beleidsroutering behou die oorspronklike adresse en vereis dat die verre kant weet hoe om hulle te bereik. Nie een is ’n verstek nie; die keuse volg uit wie die verre kant besit en of identiteit per toestel saak maak.

Die twee ontwerpe belowe verskillende dinge

Masquerade reduseer die LAN tot ’n enkele sigbare gasheer: die gateway. Die verre netwerk antwoord op daardie een adres, en die gateway vertaal die antwoorde terug na die kliënt wat die stroom begin het. Geen roete na jou private prefikse is aan die verre kant nodig nie, en daarom oorleef hierdie ontwerp ’n verskaffer wat weier om hulle te dra. Die gateway word ook die bron van elke verbinding, so die verre kant kan nie twee kliënte onderskei nie.

Beleidsroutering hou elke kliëntadres ongeskonde. Die verre netwerk sien die werklike bron en kan dit log, ’n reël per gasheer toepas of die antwoord direk na daardie adres stuur. Daardie sigbaarheid is die hele punt, en dit bring ’n verpligting mee: die verre kant moet ’n roete vir die LAN-prefiks hê wat terug deur die tonnel wys. Beplan daardie roete voordat jy die reël aktiveer, want die tonnel kom òf so òf so op en net die antwoorde sal ontbreek.

Die foutmodusse verskil net soveel soos die beloftes. ’n Ontbrekende masquerade-reël lewer pakkette wat met private bronne vertrek en nooit terugkom nie. ’n Ontbrekende terugroete lewer dieselfde simptoom onder beleidsroutering, maar die regstelling hoort op die verre router eerder as op die gateway.

Masquerade: een peer aan die verre kant

Die masquerade-pad het ’n volgorde wat saak maak. Voortstuur moet geaktiveer wees voordat enige NAT-reël nut het, die filtertabel moet die deurgang in beide rigtings toelaat, en eers dan geld die vertaling op die tonnelkoppelvlak.

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

Kliënte het steeds ’n pad na die gateway nodig. Óf die gateway is hul verstekrouter, óf hulle dra ’n spesifieke roete vir die verre prefiks; as ’n aparte router die verstek bly, het daardie router ’n statiese roete vir die tonnelbestemmings nodig, anders gaan die pakket na die verkeerde hop voordat die gateway dit sien.

DNS is ’n aparte besluit. ’n Resolver aan die verre kant antwoord net as sy antwoord terug na die kliënt kan reis. Onder masquerade lyk die navraag asof dit van die gateway kom, so die resolver se terugpad is reeds voldoen; onder beleidsroutering het die resolver dieselfde terugroete as enige ander verre diens nodig.

Beleidsroutering: behou die bron, voeg ’n terugpad by

Beleidsroutering begin met ’n tabel en ’n reël wat dit kies. Verkeer wat by die LAN-koppelvlak inkom, word na ’n toegewyde tabel gestuur, en daardie tabel dra ’n verstekroete deur die tonnel. Die hoofdtabel bly onaangeraak, so verkeer wat deur die gateway self ontstaan, kan ’n ander pad volg.

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

Die verre kant moet dan die LAN-prefiks terug deur die tonnel routeer. Dit is ’n instelling op die verre router, nie op hierdie gateway nie. Die gateway moet ook antwoorde aanvaar wat op ’n ander koppelvlak aankom as wat die hoofdtabel sou voorspel; los omgekeerde padfiltering (rp_filter op 2 gestel) is die gewone aanpassing wanneer streng modus daardie pakkette laat val.

Wanneer twee tonnels aktief is, merk elke stroom wanneer dit inkom en laat die merk die tabel kies. ’n Reël wat net na die invoerkoppelvlak kyk, stuur beide tonnels se verkeer na dieselfde tabel, so die tweede tonnel steel strominge van die eerste. Toets daardie merk met ’n verbinding wat ’n herverbinding oorleef, want dit is wanneer ’n gemengde beleid opduik.

Besluit op grond van eienaarskap en van wat die verre kant log

As die tonnel by ’n verskaffer eindig, gebruik masquerade. Daardie operateur gaan nie jou private LAN-reekse routeer nie, en hy het geen rede om individuele kliënte agter jou gateway te onderskei nie. Een sigbare peer is die enigste model wat sy beleid ondersteun, so gee hom dit en hou die vertaling aan jou kant. Die verskaffer sien een peer, wat presies is wat sy beleid verwag, en jou kliënte erf daardie enkele identiteit.

As beide kante joune is en die verre dienste op bronadresse reageer, verdien beleidsroutering sy ekstra roete. Firewall-reëls, toegang per gebruiker en ouditlogboeke kan dan kliënte onderskei. As die verre kant net bereikbaarheid nodig het, is masquerade eenvoudiger en verwyder dit ’n klas terugroete-foute.

Hibriede ontwerpe is normaal: beleidsroutering binne jou eie netwerk, masquerade by die verskaffersrand. Wat saak maak, is om neer te skryf watter hop vertaal en watter hop routeer, want ’n per ongeluk NAT-reël vir een kliënt verberg die bron vir elke kliënt in dieselfde ketting.

Verifieer vanaf ’n kliënt, dan vanaf ’n tweede kliënt

Voer die toets uit waar die verkeer begin. Kyk na die roete wat die gasheer gebruik, sien die pakket op die tonnelkoppelvlak verskyn, en ondersoek conntrack vir die vertaling. Daardie volgorde bewys die pakket het die bedoelde pad gevolg eerder as om bloot ergens aan te kom.

Herhaal die toets na ’n herverbinding. ’n Masquerade-reël wat die koppelvlak noem, oorleef ’n nuwe tonneladres; ’n reël wat die ou adres noem, doen nie. Toets dan ’n tweede LAN-gasheer, want ’n ontwerp wat op een masjien werk, hang dikwels van daardie masjien se eie roete af eerder as van die gateway-beleid.

Skryf die gekose model, die vertaalde of behoude bron, en die eienaar van die terugroete in die gateway-notas neer. Die volgende persoon wat ’n kliënt of ’n tonnel byvoeg, sal anders raai, en ’n raaiskoot is hoe ’n werkende LAN-tot-VPN-opstelling ’n gedeeltelike een word.