Ich habe gerade einen Ubuntu-Server als Router mit NAT/PAT konfiguriert und versuche Folgendes:
Ich arbeite für eine Schule, die ihr Netzwerk in kleinere Netzwerke aufgeteilt hat, die durch Router verbunden sind. Ich muss eine IP-Adresse erstellen, die im internen Netzwerk eines Raums sichtbar ist und den gesamten Datenverkehr an eine externe IP-Adresse weiterleitet.
Zur Erklärung, das ist die Konfiguration:
NAT außen: eth1 - 192.168.1.254/24
NAT innen: br0 - 192.168.2.10, Masquerading aktiviert
Ich muss eine Adresse wie 192.168.2.1 erstellen, auch für br0, die ihren gesamten Datenverkehr an die IP 192.168.1.1 weiterleitet und so aussieht, als sei diese IP direkt mit dem Netzwerk verbunden, für die aber KEINE Masquerading-Funktion aktiviert ist.
Die Grundidee ist, dass die Routeradresse von br0 auf 192.168.2.10 eingestellt wird und dass br0 außerdem eine andere Adresse hat, die nicht maskiert ist und den gesamten Verkehr an 192.168.1.1 weiterleitet, die Adresse des Hauptrouters. Der Grund dafür ist, dass br0 eine Brücke zwischen dem physischen Netzwerk und einem VPN ist, auf das von hinter einem Router mit derselben Adresse wie die Ziel-NAT-IP-Adresse – 192.168.1.1 – zugegriffen werden kann. Da ich nicht sicherstellen kann, dass Clients immer einen „Route Add“-Befehl ausgeben können, muss ich dies irgendwie umgehen.
Ich habe herausgefunden, wie man sekundäre IP-Adressen für br0 konfiguriert, und ich habe br0:1 als 192.168.2.1 konfiguriert, aber ich schaffe es anscheinend nicht, den gesamten Datenverkehr an 192.168.1.1 weiterzuleiten.
Ich danke Ihnen im Voraus für Ihre Hilfe.
Antwort1
Wenn ich Sie richtig verstehe, versuchen Sie im Grunde eine Art Policy-Routing mit NAT. Es klingt, als wollten Sie nur einen Alias für einen Host außerhalb eines bestimmten gerouteten Subnetzes erstellen, der sich in diesem Subnetz befindet.
Sie können DNAT-Regeln ohne entsprechendes SNAT (oder Masquerading) erstellen. Der Grund dafür, dass dies nicht gemacht wird, ist lediglich, dass die meisten NATs darauf ausgelegt sind, ein Verbindungsproblem zu umgehen, bei dem die Adressen auf der „Innenseite“ des NATs sonst nicht von „außen“ geroutet werden könnten. Wenn der Host 192.168.1.1 tatsächlich eine Route zurück zu 192.168.2.0/24 oder was auch immer hat, können Sie, wenn ich mich recht erinnere, tatsächlich einfach eine DNAT-Regel einrichten:
iptables -t nat -A PREROUTING -s 192.168.2.0/24 -d 192.168.2.1 -j DNAT --to 192.168.1.1
Halten Sie jetzt einen Moment inne und tun Sie das noch nicht.
Das funktioniert, wenn 192.168.2.1 eine Zieladresse ist (und erzeugt eine seltsame Eigenart, bei der die Adresse, die auf den Datenverkehr antwortet, sich vom ursprünglichen Ziel unterscheidet). Ihrer Beschreibung nach glaube ich nicht, dass Sie das tun möchten, obwohl ich mir ehrlich gesagt nicht sicher bin. DNAT hilft überhaupt nicht, wenn der Host 192.168.2.1 als Router und nicht als Ziel fungieren soll. Wenn er als Router fungieren soll, hilft NAT (oder PAT) überhaupt nicht.
Es klingt, als ob VPN-Verkehr hereinkommt, der auf dieses Subnetz 192.168.2.0/24 überbrückt wird, wenn ich Sie richtig verstehe und die Lücken so fülle, wie sie sind, und der über dieses Gateway 192.168.1.1 in die weite Welt oder einen Teil davon hinausgehen muss. In diesem Fall ist das, was zu tun ist,Weisen Sie Ihrem Router einfach die Adresse 192.168.2.1/24 zu (die Sie vermutlich als Standard-Gateway auf den VPN-Clients festgelegt haben)., stellen Sie sicher, dass die Weiterleitung aktiviert ist, und schon kann es losgehen – die VPN-Clients müssen sich keine Gedanken darüber machen, ob der nächste Hop 192.168.1.1 ist, genau wie ihr ursprüngliches Standard-Nicht-VPN-Gateway (Heim-Gateway?); sie sind sich dessen während der Paketübertragung überhaupt nicht bewusst. ISPs verwenden diese Art von Schema mit RFC1918-Adressen ständig, um zu vermeiden, dass versehentlich knappe routingfähige Adressen verschwendet werden; es ist nicht erforderlich, dass alle Router entlang des Pfads überhaupt eindeutige Adressen haben (obwohl dies die Fehlersuche erheblich erleichtert, wenn sie welche haben). Der Trick dabei ist, dass die Endpunkte einer TCP-Verbindung nichts weiter als die IP-Adresse des nächsten Hops wissen müssen.
Wenn Sie dies bereits tun und Probleme haben, überprüfen Sie den Rückweg. Es besteht die Möglichkeit, dass Ihr Gateway bei 192.168.1.1 kein NAT für diese Adressen durchführt, wenn deren Datenverkehr außerhalb Ihres NAT gesendet wird (das es immer noch als 192.168.2.0/24 erkennt), sie durch eine Firewall abschirmt oder keine geeignete Route zurück zu 192.168.2.0/24 hat.
Wenn ich Ihre Absicht in beiden Punkten missverstanden habe, gibt es eine dritte Sache, die Ihnen helfen könnte. Die einzige Möglichkeit, ein Gateway in iptables anzugeben, ist das TEE-Ziel, das das Paket klont und den Klon unverändert an einen beliebigen Host weiterleitet. Sie müssten jedoch irgendwie mit dem nicht geklonten Paket umgehen. Dieses Ziel kann in der mangle PREROUTING-Kette hinzugefügt werden:
iptables -t mangle -A PREROUTING -s 192.168.2.0/24 -j TEE --gateway 192.168.1.1
Das ist eine seltsame Vorgehensweise; es ist für die Protokollierung des Datenverkehrs gedacht, nicht für dessen Weiterleitung. Ich nehme an, Sie könnten das Originalpaket zu einem späteren Zeitpunkt in iptables entsorgen, aber das ist einfach nur ein Chaos und ich empfehle es wirklich nicht.
Als zufälliger Punkt können Sie mit dem ip addr addBefehl zusätzliche IP-Adressen zu Schnittstellen hinzufügen. Verwenden Sie nicht net-tools (ifconfig); es ist veraltet und es fehlen viele Funktionen und wird Ihnen auf lange Sicht nur Kopfschmerzen bereiten.