Routa mellan privata LAN innan du lägger till ännu ett NAT

Två interna brandväggar, ett privat transitsegment och en begäran om att låta några få värdar i varje LAN tala med dem i det andra. Reflexen är att resa en VPN eller lägga till ett andra NAT-lager, och båda reflexerna kostar mer än problemet förtjänar. Vanlig routning räcker när tre villkor gäller: adressområdena överlappar inte, båda sidor kan skicka tillbaka trafik till det andra LANet och transitsegmentet är redan betrott nog för data. Kontrollera de tre innan du designar något, eftersom vart och ett av dem ändrar svaret.

Tre villkor som avgör designen

Det första villkoret är adressrymd. Om båda LANen använder samma RFC 1918-block kan routning inte skilja dem, och översättning blir oundviklig i stället för valfri. Det andra är en returväg: en rutt från A till B är värdelös om inte B också vet hur man når As LAN, och asymmetrisk kunskap är det vanligaste skälet till att en routad design tyst tappar svar.

Det tredje är förtroende. Routning flyttar paket; det skyddar dem inte. Ett privat transitsegment inne i en byggnad är något annat än en överlämning till en leverantör eller en länk som korsar en delad campusstomme. Om segmentet inte är betrott är svaret en tunnel mellan de två brandväggarna, och ruttplanen nedan gäller fortfarande inuti den.

Bara när alla tre pekar åt samma håll vinner den enkla designen. När ett av dem brister, åtgärda just det villkoret uttryckligen i stället för att dölja det med översättning, eftersom NAT döljer felet i stället för att lösa det.

Bygg ruttplanen på transitnätet

Ge varje brandvägg en adress på det delade segmentet och lägg till en specifik rutt per avlägset LAN. Inget annat i den befintliga konfigurationen behöver flytta sig, och särskilt internetstandardrutten måste stanna exakt där den är. Att ersätta en standardrutt med motpartens brandvägg skulle skicka varje orelaterad destination över transiten, vilket är en mycket större ändring än den som efterfrågas. pfSense-dokumentationen om statisk routning beskriver samma rutt-plus-gateway-modell för den plattformen, och motsvarande inställning finns på vilken brandvägg du än faktiskt kör.

Brandvägg A betjänar 10.30.0.0/24 och brandvägg B betjänar 10.40.0.0/24, med de två transitadresserna på 192.0.2.0/24. Varje LAN-värd behåller sin lokala brandvägg som gateway, så det enda nya tillståndet är en rutt på varje sida. På en Linux-baserad brandvägg ser samma plan ut så här, och vidarebefordran måste vara aktiverad, annars löses rutten upp medan paketet släpps.

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

Håll filtrering åtskild från översättning

Routning och policy är olika kontroller, och det är i den andra som de flesta routade designer faktiskt misslyckas. Tillåt de specifika källorna, destinationerna och tjänsterna vid den ingående gränsen som paketen verkligen korsar, och kom ihåg att en gränssnittsetikett som WAN är ett namn, inte ett påstående om förtroende. En transitport som bär privat trafik kan fortfarande ha blockering av privata adresser aktiverad som standard.

Titta sedan på utgående översättning innan du drar slutsatsen att ingen NAT sker. Automatiska utgående regler kan skriva om trafik som aldrig var avsedd att översättas, och det förstör källadresserna som den andra sidan behöver för sin egen policy och sina loggar. Bekräfta att de valda flödena behåller sina ursprungliga adresser, och lämna internetöversättningsreglerna i fred för trafiken som fortfarande behöver dem.

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

När NAT är det ärliga svaret

Översättning förtjänar sin plats när adressområdena verkligen överlappar och omnumrering inte är tillgänglig, eller när en policy kräver att en sida ser en enda adress i stället för ett subnät. I de fallen är en medveten ett-till-ett- eller portbegränsad mappning ett designbeslut med kända konsekvenser, inte en nödlösning.

Konsekvensen som måste sägas högt är att den andra sidan inte längre kan se eller filtrera enskilda källor. Loggarna faller samman till den översättande adressen, policy per värd slutar fungera, och felsökning blir en jakt på vilken intern värd som ägde ett flöde vid ett givet tillfälle. Om inget av detta spelar roll för trafiken i fråga är NAT okej.

När transiten själv är det felaktiga antagandet

Om det delade segmentet korsar en leverantör, ett delat switchfabric eller vilken väg som helst där en annan part skulle kunna läsa trafiken, är routning ensamt inte ett fullständigt svar. En tunnel mellan de två brandväggarna ger konfidentialitet och motpartsauth, och rutttabellen inuti den är samma tabell som du skulle ha skrivit på transiten.

Avgör det utifrån förtroendefrågan i första avsnittet, inte utifrån en vana att VPN är säkrare. En tunnel över ett segment som redan är privat lägger till driftskostnader och ännu ett feläge utan vinst, medan routning över ett otrott segment byter konfidentialitet mot en enkelhet du inte har råd med. Skriv ner vilket av de tre villkoren som styrde valet, och nästa ingenjör slipper ta upp det igen.