Smerujte medzi súkromnými LAN, skôr než pridáte ďalší NAT

Dva interné firewally, jeden súkromný tranzitný segment a požiadavka, aby niekoľko hostov v každej LAN mohlo komunikovať s tými v druhej. Reflex je postaviť VPN alebo pridať druhú vrstvu NAT a oba reflexy stoja viac, než si problém zaslúži. Bežné smerovanie stačí, keď platia tri podmienky: adresné rozsahy sa neprekrývajú, obe strany vedia vracať prevádzku do druhej LAN a tranzitný segment je na dáta už dostatočne dôveryhodný. Skontrolujte tieto tri veci, skôr než čokoľvek navrhnete, pretože každá z nich mení odpoveď.

Tri podmienky, ktoré rozhodujú o návrhu

Prvou podmienkou je adresný priestor. Ak obe LAN používajú ten istý blok RFC 1918, smerovanie ich nedokáže rozlíšiť a preklad sa stane nevyhnutným, nie voliteľným. Druhou je návratová cesta: trasa z A do B je zbytočná, ak B tiež nevie, ako sa dostať do LAN uzla A, a asymetrická znalosť je najčastejším dôvodom, prečo smerovaný návrh ticho zahadzuje odpovede.

Treťou je dôvera. Smerovanie presúva pakety; nechráni ich. Súkromný tranzitný segment v jednej budove je niečo iné ako odovzdanie poskytovateľovi alebo linka, ktorá prechádza zdieľanou kampusovou chrbticou. Ak segment nie je dôveryhodný, odpoveďou je tunel medzi oboma firewallmi a plán smerovania nižšie v ňom stále platí.

Jednoduchý návrh zvíťazí len vtedy, keď všetky tri ukazujú rovnakým smerom. Keď jedna zlyhá, opravte tú podmienku výslovne, namiesto toho, aby ste ju zakryli prekladom, pretože NAT zlyhanie skrýva, nie rieši.

Postavte plán trás na tranzitnej sieti

Dajte každému firewallu adresu v zdieľanom segmente a pridajte jednu konkrétnu trasu pre každú vzdialenú LAN. Nič iné v existujúcej konfigurácii sa nemusí pohnúť, a najmä predvolená trasa do internetu musí zostať presne tam, kde je. Nahradenie predvolenej trasy partnerským firewallom by poslalo každé nesúvisiace cieľové miesto cez tranzit, čo je omnoho väčšia zmena ako požadovaná. Dokumentácia pfSense o statickom smerovaní popisuje ten istý model trasy plus brány pre túto platformu a ekvivalentné nastavenie existuje na každom firewalle, ktorý skutočne prevádzkujete.

Firewall A obsluhuje 10.30.0.0/24 a firewall B obsluhuje 10.40.0.0/24, pričom obe tranzitné adresy sú v 192.0.2.0/24. Každý host v LAN si ponecháva miestny firewall ako bránu, takže jediným novým stavom je jedna trasa na každej strane. Na firewalle založenom na Linuxe vyzerá rovnaký plán takto a preposielanie musí byť zapnuté, inak sa trasa vyrieši, ale paket sa zahodí.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Držte filtrovanie oddelene od prekladu

Smerovanie a politika sú rôzne kontroly a práve na tej druhej väčšina smerovaných návrhov skutočne zlyháva. Povoľte konkrétne zdroje, ciele a služby na vstupnej hranici, ktorú pakety skutočne prechádzajú, a pamätajte, že označenie rozhrania ako WAN je názov, nie tvrdenie o dôvere. Tranzitný port prenášajúci súkromnú prevádzku môže mať predvolene stále zapnuté blokovanie súkromných adries.

Potom sa pozrite na odchádzajúci preklad, skôr než usúdite, že žiadny NAT neprebieha. Automatické odchádzajúce pravidlá môžu prepísať prevádzku, ktorá nikdy nebola určená na preklad, a to ničí zdrojové adresy, ktoré druhá strana potrebuje pre svoju vlastnú politiku a logy. Potvrďte, že vybrané toky si zachovávajú pôvodné adresy, a nechajte internetové pravidlá prekladu na pokoji pre prevádzku, ktorá ich ešte potrebuje.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Keď je NAT úprimná odpoveď

Preklad si zaslúži svoje miesto, keď sa adresné rozsahy skutočne prekrývajú a prečíslovanie nie je dostupné, alebo keď politika vyžaduje, aby jedna strana videla jednu adresu namiesto podsiete. V takých prípadoch je zámerné mapovanie jedna ku jednej alebo obmedzené na porty návrhovým rozhodnutím so známymi dôsledkami, nie obchádzkou.

Dôsledok, ktorý treba povedať nahlas, je, že druhá strana už nemôže vidieť ani filtrovať jednotlivé zdroje. Logy sa zlievajú do prekladajúcej adresy, politika pre jednotlivých hostov prestáva fungovať a riešenie problémov sa mení na pátranie po tom, ktorý interný host vlastnil tok v danom okamihu. Ak na tom pre dotknutú prevádzku nič nezáleží, NAT je v poriadku.

Keď je zlým predpokladom samotný tranzit

Ak zdieľaný segment prechádza poskytovateľom, zdieľanou prepínacou štruktúrou alebo akoukoľvek cestou, kde by prevádzku mohla čítať iná strana, samotné smerovanie nie je úplná odpoveď. Tunel medzi oboma firewallmi vám dá dôvernosť a overenie partnera a smerovacia tabuľka v ňom je tá istá tabuľka, ktorú by ste napísali na tranzite.

Rozhodnite to podľa otázky dôvery v prvej časti, nie podľa zvyku, že VPN sú bezpečnejšie. Tunel cez segment, ktorý už je súkromný, pridáva prevádzkové náklady a ďalší režim zlyhania bez zisku, zatiaľ čo smerovanie cez nedôveryhodný segment mení dôvernosť za jednoduchosť, ktorú si nemôžete dovoliť. Zapíšte, ktorá z troch podmienok viedla voľbu, a ďalší inžinier to nebude musieť znova rozoberať.