Zwischen privaten LANs routen, bevor Sie ein weiteres NAT hinzufügen

Zwei interne Firewalls, ein privates Transitsegment und die Anfrage, ein paar Hosts in jedem LAN mit denen im anderen sprechen zu lassen. Der Reflex ist, ein VPN aufzusetzen oder eine zweite NAT-Schicht hinzuzufügen, und beide Reflexe kosten mehr, als das Problem verdient. Gewöhnliches Routing genügt, wenn drei Bedingungen erfüllt sind: Die Adressbereiche überlappen sich nicht, beide Seiten können Verkehr zum anderen LAN zurückschicken, und das Transitsegment ist für die Daten bereits vertrauenswürdig genug. Prüfen Sie diese drei, bevor Sie irgendetwas entwerfen, denn jede von ihnen ändert die Antwort.

Drei Bedingungen, die den Entwurf bestimmen

Die erste Bedingung ist der Adressraum. Wenn beide LANs denselben RFC 1918-Block verwenden, kann Routing sie nicht unterscheiden, und Übersetzung wird unvermeidlich statt optional. Die zweite ist ein Rückweg: Eine Route von A nach B ist nutzlos, wenn B nicht auch weiß, wie es das LAN von A erreicht, und asymmetrisches Wissen ist der häufigste Grund, warum ein geroutetes Design Antworten still verwirft.

Die dritte ist Vertrauen. Routing bewegt Pakete; es schützt sie nicht. Ein privates Transitsegment innerhalb eines Gebäudes ist etwas anderes als eine Übergabe an einen Anbieter oder eine Verbindung, die ein gemeinsames Campus-Backbone quert. Ist das Segment nicht vertrauenswürdig, lautet die Antwort Tunnel zwischen den beiden Firewalls, und der Routingplan unten gilt darin weiterhin.

Nur wenn alle drei in dieselbe Richtung zeigen, gewinnt das einfache Design. Wenn eine davon scheitert, beheben Sie genau diese Bedingung, statt sie mit Übersetzung zu überdecken, denn NAT verbirgt den Fehler, statt ihn zu lösen.

Bauen Sie den Routenplan auf dem Transitnetz

Geben Sie jeder Firewall eine Adresse im gemeinsamen Segment und fügen Sie pro entferntem LAN eine konkrete Route hinzu. Sonst muss sich nichts an der bestehenden Konfiguration bewegen, und insbesondere muss die Internet-Standardroute genau dort bleiben, wo sie ist. Eine Standardroute durch die Peer-Firewall zu ersetzen, würde jedes unabhängige Ziel über den Transit schicken, was eine viel größere Änderung wäre als die angefragte. Die pfSense-Dokumentation zum statischen Routing beschreibt dasselbe Route-plus-Gateway-Modell für diese Plattform, und die entsprechende Einstellung existiert auf jeder Firewall, die Sie tatsächlich betreiben.

Firewall A bedient 10.30.0.0/24 und Firewall B bedient 10.40.0.0/24, wobei die beiden Transitadressen in 192.0.2.0/24 liegen. Jeder LAN-Host behält seine lokale Firewall als Gateway, sodass der einzige neue Zustand eine Route auf jeder Seite ist. Auf einer Linux-basierten Firewall sieht derselbe Plan so aus, und Weiterleitung muss aktiviert sein, sonst wird die Route aufgelöst, während das Paket verworfen wird.

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

Halten Sie Filterung und Übersetzung getrennt

Routing und Policy sind verschiedene Kontrollen, und an der zweiten scheitern die meisten gerouteten Designs tatsächlich. Erlauben Sie die konkreten Quellen, Ziele und Dienste an der eingehenden Grenze, die die Pakete wirklich queren, und bedenken Sie, dass eine Schnittstellenbezeichnung wie WAN ein Name ist und keine Aussage über Vertrauen. Ein Transitport mit privatem Verkehr kann weiterhin die Blockierung privater Adressen standardmäßig aktiviert haben.

Schauen Sie dann auf die ausgehende Übersetzung, bevor Sie schließen, dass kein NAT stattfindet. Automatische ausgehende Regeln können Verkehr umschreiben, der nie übersetzt werden sollte, und das zerstört die Quelladressen, die die Gegenseite für ihre eigene Policy und ihre Protokolle braucht. Bestätigen Sie, dass die ausgewählten Flows ihre ursprünglichen Adressen behalten, und lassen Sie die Internet-Übersetzungsregeln für den Verkehr in Ruhe, der sie noch braucht.

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

Wenn NAT die ehrliche Antwort ist

Übersetzung verdient ihren Platz, wenn sich die Adressbereiche wirklich überlappen und Umnummerierung nicht verfügbar ist, oder wenn eine Policy verlangt, dass eine Seite eine einzelne Adresse statt eines Subnetzes sieht. In diesen Fällen ist ein bewusstes Eins-zu-eins- oder portbeschränktes Mapping eine Designentscheidung mit bekannten Folgen, kein Notbehelf.

Die Folge, die man laut aussprechen muss, ist, dass die Gegenseite einzelne Quellen nicht mehr sehen oder filtern kann. Protokolle fallen auf die übersetzende Adresse zusammen, Policy pro Host funktioniert nicht mehr, und Fehlersuche wird zur Jagd danach, welcher interne Host zu einem bestimmten Zeitpunkt einen Flow besaß. Wenn nichts davon für den betreffenden Verkehr wichtig ist, ist NAT in Ordnung.

Wenn der Transit selbst die falsche Annahme ist

Wenn das gemeinsame Segment einen Anbieter, ein gemeinsames Switch-Fabric oder irgendeinen Pfad quert, auf dem eine andere Partei den Verkehr lesen könnte, ist Routing allein keine vollständige Antwort. Ein Tunnel zwischen den beiden Firewalls gibt Ihnen Vertraulichkeit und Peer-Authentifizierung, und die Routentabelle darin ist dieselbe Tabelle, die Sie auf dem Transit geschrieben hätten.

Entscheiden Sie das aus der Vertrauensfrage im ersten Abschnitt, nicht aus einer Gewohnheit, dass VPNs sicherer seien. Ein Tunnel über ein Segment, das bereits privat ist, fügt Betriebskosten und einen weiteren Fehlermodus ohne Gewinn hinzu, während Routing über ein nicht vertrauenswürdiges Segment Vertraulichkeit gegen eine Einfachheit tauscht, die Sie sich nicht leisten können. Schreiben Sie auf, welche der drei Bedingungen die Wahl getrieben hat, und der nächste Ingenieur muss es nicht erneut ausdiskutieren.