Směrujte provoz mezi privátními LAN, než přidáte další NAT

Dvě interní firewally, jeden privátní tranzitní segment a požadavek, aby několik hostů v každé LAN mohlo mluvit s těmi v druhé. Reflexem je postavit VPN nebo přidat druhou vrstvu NAT a oba reflexy stojí víc, než problém zaslouží. Běžné routování stačí, když platí tři podmínky: adresní rozsahy se nepřekrývají, obě strany umějí vracet provoz do druhé LAN a tranzitní segment je pro data už dost důvěryhodný. Zkontrolujte ty tři věci, než cokoli navrhnete, protože každá z nich mění odpověď.

Tři podmínky, které rozhodují o návrhu

První podmínkou je adresní prostor. Pokud obě LAN používají stejný blok RFC 1918, routování je nedokáže rozlišit a překlad se stává nevyhnutelným, nikoli volitelným. Druhou je zpětná cesta: trasa z A do B je k ničemu, pokud B také neví, jak se dostat do LAN u A, a asymetrická znalost je nejčastějším důvodem, proč routovaný návrh tiše zahazuje odpovědi.

Třetí je důvěra. Routování přenáší pakety; nechrání je. Privátní tranzitní segment uvnitř jedné budovy je něco jiného než předání poskytovateli nebo linka, která prochází sdílenou kampusovou páteří. Pokud segment není důvěryhodný, odpovědí je tunel mezi oběma firewally a plán routování níže v něm stále platí.

Jednoduchý návrh vyhraje jen tehdy, když všechny tři míří stejným směrem. Když jedna selže, opravte tu podmínku výslovně, místo abyste ji zakrývali překladem, protože NAT selhání skrývá, nikoli řeší.

Postavte plán tras na tranzitní síti

Dejte každému firewallu adresu na sdíleném segmentu a přidejte jednu konkrétní trasu pro každou vzdálenou LAN. Nic jiného v existující konfiguraci se hýbat nemusí, a zejména výchozí trasa do internetu musí zůstat přesně tam, kde je. Nahrazení výchozí trasy partnerským firewallem by poslalo každé nesouvisející cílové místo přes tranzit, což je mnohem větší změna, než o jakou se žádá. Dokumentace pfSense ke statickému routování popisuje stejný model trasy plus brány pro tuto platformu a ekvivalentní ovládací prvek existuje na každém firewallu, který skutečně provozujete.

Firewall A obsluhuje 10.30.0.0/24 a firewall B obsluhuje 10.40.0.0/24, přičemž obě tranzitní adresy jsou v 192.0.2.0/24. Každý host v LAN si ponechává místní firewall jako bránu, takže jediným novým stavem je jedna trasa na každé straně. Na firewallu založeném na Linuxu vypadá stejný plán takto a přeposílání musí být zapnuté, jinak se trasa vyřeší, ale paket se 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 filtrování oddělené od překladu

Routování a politika jsou různé kontroly a právě na druhé z nich většina routovaných návrhů skutečně selhává. Povolte konkrétní zdroje, cíle a služby na vstupní hranici, kterou pakety skutečně procházejí, a pamatujte, že označení rozhraní jako WAN je jméno, nikoli tvrzení o důvěře. Tranzitní port přenášející privátní provoz může mít ve výchozím nastavení stále zapnuté blokování privátních adres.

Pak se podívejte na odchozí překlad, než usoudíte, že se žádný NAT neděje. Automatická odchozí pravidla mohou přepsat provoz, který nikdy neměl být překládán, a tím ničí zdrojové adresy, které druhá strana potřebuje pro svou vlastní politiku a logy. Potvrďte, že vybrané toky si zachovávají původní adresy, a nechte internetová pravidla překladu na pokoji pro provoz, který je stále potřebuje.

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

Když je NAT poctivá odpověď

Překlad si své místo zaslouží, když se adresní rozsahy skutečně překrývají a přečíslování není k dispozici, nebo když politika vyžaduje, aby jedna strana viděla jednu adresu místo podsítě. V takových případech je záměrné mapování jedna ku jedné nebo s omezením portů návrhovým rozhodnutím se známými důsledky, nikoli obchvatem.

Důsledek, který je třeba říct nahlas, je, že druhá strana už nemůže vidět ani filtrovat jednotlivé zdroje. Logy se slijí do překládající adresy, politika pro jednotlivé hosty přestane fungovat a řešení potíží se změní v pátrání po tom, který interní host vlastnil tok v daném okamžiku. Pokud na tom u dotyčného provozu nic nezáleží, NAT je v pořádku.

Když je špatným předpokladem sám tranzit

Pokud sdílený segment prochází poskytovatelem, sdílenou přepínací strukturou nebo jakoukoli cestou, kde by provoz mohla číst jiná strana, samotné routování není úplná odpověď. Tunel mezi oběma firewally vám dá důvěrnost a autentizaci protějšku a směrovací tabulka v něm je stejná tabulka, kterou byste napsali na tranzitu.

Rozhodněte to podle otázky důvěry v první části, ne podle zvyku, že VPN jsou bezpečnější. Tunel přes segment, který už je privátní, přidává provozní náklady a další režim selhání bez zisku, zatímco routování přes nedůvěryhodný segment mění důvěrnost za jednoduchost, kterou si nemůžete dovolit. Zapište, která ze tří podmínek volbu vedla, a další inženýr to nebude muset znovu rozebírat.