Ein entferntes /24 über einen Tunnel erreichen: NETMAP, DNAT oder Route?
Bilden Sie ein ganzes Präfix mit NETMAP ab, fügen Sie DNAT-Regeln pro Host hinzu oder routen Sie den echten Bereich – und entscheiden Sie danach, was die Gegenseite sehen muss und wer Verkehr beginnen darf.
Ein Subnetz hinter einem Tunnelendpunkt erreichen Sie auf drei Wegen, und eine Minute Fakten sammeln schließt meist zwei aus. Die Fakten sind, ob die Server dort Nutzer unterscheiden müssen, ob von dort jemals jemand zu Ihrem Bereich wählt, und wer den Router am fernen Ende bearbeiten darf. Beantworten Sie diese drei, und das Design wählt sich selbst. Der Rest setzt voraus, dass Sie den Endpunkt betreiben und seine Firewall bearbeiten dürfen.
Drei Optionen, und was jede tatsächlich ändert
Präfixabbildung, DNAT pro Host und ein geroutetes Präfix bewegen alle Pakete zwischen denselben zwei Bereichen, ändern aber verschiedene Dinge. Abbildung erfindet einen Alias-Bereich und schreibt Adressen im Flug arithmetisch um. Regeln pro Host schreiben ebenfalls um, nur wird jedes Ziel von Hand benannt. Ein geroutetes Präfix schreibt nichts um: Pakete behalten die echten Adressen, und beide Enden sind sich einig, wo diese Adressen leben.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
Beginnen Sie die Ausscheidung auf der Gegenseite, wo die Einschränkungen am schwersten zu ändern sind. Wenn ein Server dort Client-Adressen in Logs schreibt, gegen eine Positivliste prüft oder an ein anderes System weitergibt, zerstört die Übersetzung der Quelle ihre einzige Kennung. Wenn die Gegenseite auch selbst wählen muss, fällt die Übersetzung völlig weg, weil dort niemand weiß, dass der Alias existiert. Erst wenn die Gegenseite nur Anfragen beantwortet, werden die billigeren Optionen sicher.
Präfixpaare, und warum die Größen übereinstimmen müssen
NETMAP ist ein nat-Tabellenziel, das auf einem Paar gleich langer Präfixe arbeitet. Es hat keine Tabelle pro Adresse: Es entfernt das Präfix, behält die Host-Bits und hängt sie an das neue Präfix, weshalb ein /24 auf ein /24 und nie auf ein /25 abgebildet wird. Die Position entscheidet die Richtung: Ein Ziel-Match in PREROUTING schreibt um, wohin ein Paket geht, und ein Quell-Match in POSTROUTING schreibt um, woher es kam.
Ein Host unter 192.168.2.17 erscheint Ihren Clients als 10.50.1.17, und das letzte Oktett ist nicht dekorativ — es ist auf beiden Seiten dieselbe Zahl. Fügen Sie morgen einen Host unter 192.168.2.40 hinzu, ist sein Alias 10.50.1.40, ohne Regel zum Bearbeiten.
Clients brauchen weiterhin eine Route für den Alias-Bereich, die auf Ihre Box zeigt, es sei denn, der Alias liegt in einem Subnetz, das sie bereits erreichen. Das Gateway braucht keine Route für den Alias, weil die Zielübersetzung in PREROUTING läuft, vor der Routensuche. Weiterleitung muss ebenfalls an sein, sonst verwirft der Kernel das Paket nach dem Umschreiben. Die drei Befehle unten sind das ganze Setup auf einem Gateway im Debian-Stil mit Clients auf br0, dem Alias auf 10.50.1.0/24 und dem Tunnel auf tun0.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEDie Antwort muss ihren eigenen Weg zurückfinden
Das Umschreiben des Ziels entscheidet nur, wohin ein Paket geliefert wird. Der Server auf der Gegenseite muss weiterhin eine Adresse beantworten, die er erreichen kann, und dafür gibt es zwei Wege. Übersetzen Sie die Quelle, damit Antworten zu Ihrer Box zurückkehren, oder lassen Sie die Quelle in Ruhe und geben Sie der Gegenseite eine Route für den Client-Bereich.
Maskieren auf dem Weg hinaus ist der kürzere Weg: eine Regel in POSTROUTING, und die Gegenseite sieht Ihre Tunneladresse, braucht also keine eigene Route. Der Preis ist, dass alle Nutzer in einer Adresse zusammenfallen und Logs pro Nutzer aufhören, etwas zu bedeuten. Die Quelle unangetastet zu lassen bewahrt diese Information, aber dann muss die ferne Seite Antworten für den Client-Bereich durch den Tunnel zurückschicken. Auf einem OpenVPN Server ist das ein gepushtes push "route 10.50.9.0 255.255.255.0", plus eine Zeile route 192.168.2.0 255.255.255.0.
Der teure Fehler ist, von jedem die Hälfte zu tun. Wenn Sie einen Teil des Verkehrs maskieren, während die Gegenseite auch eine Rückroute für anderen Verkehr trägt, kommen Antworten auf einer Schnittstelle an, auf der der Verbindungsverfolgungseintrag nie gesehen wurde. Der Client meldet eine Zeitüberschreitung für eine Anfrage, die der Server als bedient protokolliert hat. Beide Richtungen eines Flusses müssen dieselbe netfilter-Instanz passieren: ein Gateway, das übersetzt, nicht zwei Firewalls in Reihe.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nLesen Sie den Eintrag in beide Richtungen: Das ursprüngliche Tupel behält Ihren Alias als Ziel, während das Antwort-Tupel die echte Adresse trägt. Fehlt das Antwort-Tupel, ist der Rückweg das Problem und nicht die Regel. Haben sich die PREROUTING-Zähler nie bewegt, erreichte das Paket diesen Hook nie.
Kollisionen und die Suche, die zuerst läuft
Zwei verschiedene Bereiche können kollidieren, und beide Fehler sehen wie ein kaputter Tunnel aus, nicht wie eine schlechte Regel. Der Alias, den Sie erfinden, muss auf dem ganzen Weg unbenutzt sein, und der echte Bereich der Gegenseite darf in Ihrem Netz nicht bereits existieren. Ein Duplikat erzeugt sporadischen Verkehr zum falschen Host, was schwerer zu diagnostizieren ist als eine abgelehnte Verbindung. Fragen Sie die Routentabelle, bevor Sie eine Regel hinzufügen.
Auf dem Gateway sollte ip route get 192.168.2.17 das Tunnelgerät nennen; eine lokale Bridge bedeutet, dass der ferne Bereich verdeckt ist und keine nat-Regel das repariert. Wenn Ihr eigenes Netz bereits 192.168.2.0/24 verwendet, nummerieren Sie die ferne Seite neu, statt eine Abbildung auf die Kollision zu stapeln.
Von einem echten Client testen und dann behalten
Testen Sie von einer Maschine, die den Alias tatsächlich nutzt, nicht vom Gateway, weil lokal erzeugter Verkehr PREROUTING nie auf dieselbe Weise durchläuft. Öffnen Sie eine Verbindung zu einem Host mit Alias und beobachten Sie, wie Zähler und conntrack-Eintrag gemeinsam erscheinen, schließen Sie sie dann und bestätigen Sie, dass der Eintrag verschwindet. Ein veralteter Eintrag deutet auf eine halboffene Verbindung hin, was meist heißt, dass die Antwort nie zurückkam.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17Zwei oder drei erfolgreiche Verbindungen beweisen die Arithmetik, sagen aber nichts über Persistenz oder den nächsten Ingenieur. Speichern Sie die Regeln dort, wo der Bootvorgang sie liest, was unter Debian und Ubuntu iptables-save > /etc/iptables/rules.v4 mit aktiviertem netfilter-persistent bedeutet. Eine Abbildung, die beim Neustart verschwindet, ist schlimmer als keine, weil der Ausfall ohne eine aktuelle Änderung kommt, der man die Schuld geben kann.
Legen Sie eine Notiz neben die Regeln: den Alias-Bereich, den echten Bereich, den Grund für das Paar und welche Seite initiieren darf. Diese Notiz trennt ein Design von einem Haufen Regeln, die niemand zu löschen wagt. Sie klärt auch die spätere Frage, wenn die ferne Seite einen Host hinzufügt und eine Adresse, die niemand konfiguriert hat, bereits antwortet. Sagt die Notiz, dass die Gegenseite eine Rückroute braucht, weiß die nächste Person, dass das Entfernen der Maskerade-Regel die Konnektivität bricht. Dokumentation ist hier billig; eine NAT-Abhängigkeit um drei Uhr morgens neu zu entdecken, ist es nicht.