Routeer tussen privé-LAN's voordat je nog een NAT toevoegt

Twee interne firewalls, één privé-transitsegment en een verzoek om een paar hosts in elk LAN met die in het andere te laten praten. De reflex is een VPN opzetten of een tweede NAT-laag toevoegen, en beide reflexen kosten meer dan het probleem verdient. Gewone routing volstaat wanneer drie voorwaarden gelden: de adresreeksen overlappen niet, beide kanten kunnen verkeer terugsturen naar het andere LAN en het transitsegment is voor de gegevens al betrouwbaar genoeg. Controleer die drie voordat je iets ontwerpt, want elk ervan verandert het antwoord.

Drie voorwaarden die het ontwerp bepalen

De eerste voorwaarde is adresruimte. Als beide LAN's hetzelfde RFC 1918-blok gebruiken, kan routing ze niet onderscheiden en wordt vertaling onvermijdelijk in plaats van optioneel. De tweede is een retourpad: een route van A naar B is nutteloos tenzij B ook weet hoe het LAN van A te bereiken, en asymmetrische kennis is de meest voorkomende reden dat een gerouteerd ontwerp antwoorden stil laat vallen.

De derde is vertrouwen. Routing verplaatst pakketten; het beschermt ze niet. Een privé-transitsegment binnen één gebouw is iets anders dan een overdracht aan een provider of een link die een gedeelde campusbackbone kruist. Is het segment niet betrouwbaar, dan is het antwoord een tunnel tussen de twee firewalls, en het routingplan hieronder geldt daarbinnen nog steeds.

Alleen wanneer alle drie dezelfde kant op wijzen, wint het eenvoudige ontwerp. Mislukt een van hen, herstel die voorwaarde dan expliciet in plaats van hem met vertaling te bedekken, want NAT verbergt de fout in plaats van hem op te lossen.

Bouw het routeplan op het transitnetwerk

Geef elke firewall een adres op het gedeelde segment en voeg één specifieke route per extern LAN toe. Niets anders in de bestaande configuratie hoeft te verschuiven, en vooral de internet-standaardroute moet precies blijven waar hij is. Een standaardroute vervangen door de peer-firewall zou elke ongerelateerde bestemming over de transit sturen, wat een veel grotere wijziging is dan de gevraagde. De pfSense-documentatie over statische routing beschrijft hetzelfde route-plus-gateway-model voor dat platform, en de gelijkwaardige instelling bestaat op elke firewall die je werkelijk draait.

Firewall A bedient 10.30.0.0/24 en firewall B bedient 10.40.0.0/24, met de twee transitadressen op 192.0.2.0/24. Elke LAN-host houdt zijn lokale firewall als gateway, dus de enige nieuwe toestand is één route aan elke kant. Op een Linux-gebaseerde firewall ziet hetzelfde plan er zo uit, en doorsturen moet zijn ingeschakeld, anders wordt de route opgelost terwijl het pakket wordt weggegooid.

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

Houd filtering gescheiden van vertaling

Routing en beleid zijn verschillende beheersmaatregelen, en in de tweede falen de meeste gerouteerde ontwerpen in de praktijk. Sta de specifieke bronnen, bestemmingen en diensten toe op de inkomende grens die de pakketten werkelijk passeren, en bedenk dat een interfacelabel als WAN een naam is, geen uitspraak over vertrouwen. Een transitpoort die privéverkeer draagt, kan nog steeds blokkering van privéadressen standaard aan hebben staan.

Kijk dan naar uitgaande vertaling voordat je concludeert dat er geen NAT gebeurt. Automatische uitgaande regels kunnen verkeer herschrijven dat nooit voor vertaling bedoeld was, en dat vernietigt de bronadressen die de andere kant voor zijn eigen beleid en logs nodig heeft. Bevestig dat de gekozen stromen hun oorspronkelijke adressen behouden, en laat de internet-vertaalregels met rust voor het verkeer dat ze nog nodig heeft.

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

Wanneer NAT het eerlijke antwoord is

Vertaling verdient haar plaats wanneer de adresreeksen echt overlappen en hernummering niet beschikbaar is, of wanneer beleid eist dat één kant één adres ziet in plaats van een subnet. In die gevallen is een bewuste één-op-één- of poortbeperkte mapping een ontwerpbeslissing met bekende gevolgen, geen noodoplossing.

Het gevolg dat hardop gezegd moet worden, is dat de andere kant geen individuele bronnen meer kan zien of filteren. Logs vallen samen tot het vertalende adres, beleid per host werkt niet meer en probleemoplossing wordt een jacht op welke interne host op een bepaald moment een stroom had. Als niets daarvan voor het betreffende verkeer uitmaakt, is NAT prima.

Wanneer de transit zelf de verkeerde aanname is

Als het gedeelde segment een provider, een gedeeld switchfabric of een pad kruist waar een andere partij het verkeer zou kunnen lezen, is routing alleen geen volledig antwoord. Een tunnel tussen de twee firewalls geeft vertrouwelijkheid en peer-authenticatie, en de routetabel daarbinnen is dezelfde tabel die je op de transit zou hebben geschreven.

Beslis dat op basis van de vertrouwensvraag in de eerste sectie, niet uit een gewoonte dat VPN's veiliger zijn. Een tunnel over een segment dat al privé is, voegt operationele kosten en nog een faalmodus toe zonder winst, terwijl routing over een onbetrouwbaar segment vertrouwelijkheid ruilt voor eenvoud die je je niet kunt permitteren. Schrijf op welke van de drie voorwaarden de keuze heeft gestuurd, en de volgende ingenieur hoeft het niet opnieuw te bediscussiëren.