Masquerade või poliitikapõhine marsruutimine: LAN-liiklus VPN-lüüsi kaudu

Terve LAN-i viimine VPN-tunneli taha on lihtne osa; otsustamine, kuidas kaugpool neid kliente näeb, ei ole. Masquerade kirjutab iga LAN-i allika ümber lüüsi tunneli aadressiks, nii et kaugots vastab ühele peerile. Poliitikapõhine marsruutimine säilitab algseid aadresse ja nõuab, et kaugpool teaks, kuidas neile jõuda. Kumbki ei ole vaikeväärtus; valik tuleneb sellest, kellele kuulub kaugpool ja kas seadmepõhine identiteet on oluline.

Kaks lahendust lubavad erinevaid asju

Masquerade taandab LAN-i üheks nähtavaks hostiks: lüüsiks. Kaugvõrk vastab sellele ühele aadressile ja lüüs tõlgib vastused tagasi kliendile, kes voo algatas. Kaugpoolel pole teie privaatsetele prefiksitele marsruuti vaja, mistõttu see lahendus peab vastu teenusepakkujale, kes keeldub neid kandmast. Lüüsist saab ka iga ühenduse allikas, nii et kaugpool ei suuda kahte klienti eristada.

Poliitikapõhine marsruutimine hoiab iga kliendi aadressi puutumatuna. Kaugvõrk näeb tegelikku allikat ja saab selle logida, rakendada hostipõhist reeglit või saata vastuse otse sellele aadressile. See nähtavus ongi kogu mõte ja toob kaasa kohustuse: kaugpoolel peab olema LAN-i prefiksi marsruut, mis suundub tagasi läbi tunneli. Planeerige see marsruut enne reegli lubamist, sest tunnel tuleb üles igal juhul ja puudu jäävad ainult vastused.

Tõrkerežiimid erinevad sama palju kui lubadused. Puuduv masquerade-reegel annab paketid, mis väljuvad privaatsete allikatega ega pöördu kunagi tagasi. Puuduv tagasitee marsruut annab poliitikapõhise marsruutimise korral sama sümptomi, kuid parandus kuulub kaugruuterisse, mitte lüüsi.

Masquerade: üks peer kaugpoolel

Masquerade-teel on oluline järjekord. Edastamine peab olema lubatud enne, kui ükski NAT-reegel kasu toob, filtrite tabel peab lubama läbipääsu mõlemas suunas, ja alles siis rakendub tõlge tunneli liidesel.

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

Klientidel on endiselt vaja teed lüüsini. Kas lüüs on nende vaikimisi ruuter, või kannavad nad kaugprefiksi jaoks konkreetset marsruuti; kui eraldi ruuter jääb vaikimisi, vajab see ruuter staatilist marsruuti tunneli sihtkohtadele, muidu läheb pakett valesse hüppesse enne, kui lüüs selle näeb.

DNS on eraldi otsus. Kaugpoolel asuv resolver vastab ainult siis, kui selle vastus saab kliendini tagasi jõuda. Masquerade korral näib päring tulevat lüüsist, seega on resolveri tagasitee juba tagatud; poliitikapõhise marsruutimise korral vajab resolver sama tagasiteed nagu iga teine kaugteenus.

Poliitikapõhine marsruutimine: säilita allikas, lisa tagasitee

Poliitikapõhine marsruutimine algab tabelist ja reeglist, mis selle valib. LAN-liidesest sisenev liiklus saadetakse spetsiaalsesse tabelisse ja see tabel kannab vaikimisi marsruuti läbi tunneli. Põhitabel jääb puutumata, nii et lüüsi enda loodud liiklus võib minna teist teed.

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

Seejärel peab kaugpool marsruutima LAN-i prefiksi tagasi läbi tunneli. See on seadistus kaugruuteris, mitte selles lüüsis. Lüüs peab vastu võtma ka vastuseid, mis saabuvad teisele liidesele, kui põhitabel eeldaks; lõdva pöördtee filtreerimine (rp_filter seatud väärtusele 2) on tavaline kohandus, kui range režiim need paketid ära viskab.

Kui kaks tunnelit on aktiivsed, märgista iga voog sisenemisel ja lase märgil tabel valida. Reegel, mis vaatab ainult sisendliidest, saadab mõlema tunneli liikluse samasse tabelisse, nii et teine tunnel varastab voogusid esimeselt. Testi seda märki ühendusega, mis elab üle taasühenduse, sest just siis ilmneb segapoliitika.

Otsusta omandi ja selle järgi, mida kaugpool logib

Kui tunnel lõpeb teenusepakkuja juures, kasuta masquerade'i. See operaator ei hakka teie privaatseid LAN-vahemikke marsruutima ja tal pole põhjust eristada üksikuid kliente teie lüüsi taga. Üks nähtav peer on ainus mudel, mida tema poliitika toetab, seega anna talle see ja hoia tõlge oma servas. Pakkuja näeb ühte peeri, mis on täpselt see, mida tema poliitika ootab, ja teie kliendid pärivad selle ühe identiteedi.

Kui mõlemad otsad on sinu omad ja kaugteenused toimivad lähteaadresside järgi, väärib poliitikapõhine marsruutimine oma lisamarsruuti. Tulemüürireeglid, kasutajapõhine juurdepääs ja auditi logid saavad siis kliente eristada. Kui kaugpoolel on vaja ainult kättesaadavust, on masquerade lihtsam ja kõrvaldab terve klassi tagasitee vigu.

Hübriidlahendused on tavalised: poliitikapõhine marsruutimine teie enda võrgus, masquerade pakkuja servas. Tähtis on kirja panna, milline hüpe tõlgib ja milline hüpe marsruudib, sest ühe kliendi jaoks kogemata lisatud NAT-reegel peidab allika iga kliendi eest samas ahelas.

Kontrolli ühest kliendist, seejärel teisest kliendist

Käivita test seal, kus liiklus algab. Kontrolli marsruuti, mida host kasutab, jälgi paketi ilmumist tunneli liidesele ja vaata conntrackist tõlget. See jada tõestab, et pakett läks kavandatud teed, mitte ei jõudnud lihtsalt kuhugi.

Korda testi pärast taasühendust. Masquerade-reegel, mis nimetab liidest, peab vastu uuele tunneli aadressile; reegel, mis nimetab vana aadressi, ei pea. Seejärel testi teist LAN-hosti, sest ühel masinal töötav lahendus sõltub sageli selle masina enda marsruudist, mitte lüüsi poliitikast.

Kirjuta valitud mudel, tõlgitud või säilitatud allikas ja tagasitee omanik lüüsi märkmetesse. Muidu oletab järgmine inimene, kes lisab kliendi või tunneli, ja oletamine on see, kuidas töötav LAN-ist-VPN-i seadistus muutub osaliseks.