Lösung 1:
Ich habe meine ursprüngliche Antwort gelöscht, weil ich nicht ganz sicher war, dass sie richtig ist. Seitdem hatte ich einige Zeit, um ein kleines virtuelles Netzwerk von VMs einzurichten, um das betreffende Netzwerk zu simulieren. Hier ist der Satz von Firewall-Regeln, der bei mir funktioniert hat (in iptables-save Format, für nat nur Tabelle):
-A PREROUTING -d 89.179.245.232/32 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
-A POSTROUTING -s 192.168.2.0/24 -o ppp0 -j MASQUERADE
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.10/32 -p tcp -m multiport --dports 22,25,80,443 -j MASQUERADE
Die erste POSTROUTING Regel ist eine einfache Möglichkeit, die Internetverbindung mit dem LAN zu teilen. Ich habe es der Vollständigkeit halber dort gelassen.
Die PREROUTING Regel und die zweite POSTROUTING Regel zusammen die entsprechenden NATs aufbauen, damit Verbindungen zum Server über die externe IP-Adresse erfolgen können, unabhängig davon, ob die Verbindungen von außerhalb oder innerhalb des LANs stammen. Wenn sich Clients im LAN über die externe IP-Adresse mit dem Server verbinden, sieht der Server die Verbindungen als von der internen IP-Adresse des Routers kommend (192.168.2.1).
Interessanterweise stellt sich heraus, dass es einige Variationen der zweiten POSTROUTING-Regel gibt, die ebenfalls funktionieren. Wenn das Ziel auf -j SNAT --to-source 192.168.2.1 geändert wird , ist der Effekt (wenig überraschend) derselbe wie bei MASQUERADE :Der Server sieht Verbindungen von lokalen LAN-Clients als vom internen des Routers stammend IP Adresse. Andererseits, wenn das Ziel auf -j SNAT --to-source 89.179.245.232 geändert wird , dann funktionieren die NATs immer noch, aber diesmal sieht der Server Verbindungen von lokalen LAN-Clients als von extern des Routers stammend IP-Adresse (89.179.245.232).
Beachten Sie abschließend, dass Ihr ursprünglicher PREROUTING /DNAT Regel mit -i ppp0 funktioniert nicht, da die Regel niemals auf Pakete passt, die von den LAN-Clients kommen (da diese nicht über den ppp0 in den Router gelangen Schnittstelle). Es wäre möglich, es zum Laufen zu bringen, indem man einen zweiten PREROUTING hinzufügt Regel nur für die internen LAN-Clients, aber es wäre unelegant (IMO) und müsste sich immer noch explizit auf die externe IP-Adresse beziehen.
Nun, selbst nachdem ich eine „Hairpin-NAT“- (oder „NAT-Loopback“- oder „NAT-Reflektion“- oder wie auch immer man es nennen mag)-Lösung ausführlich dargelegt habe, glaube ich immer noch, dass eine Split-Horizon-DNS-Lösung – - mit externen Clients, die auf die externe IP auflösen, und internen Clients, die auf die interne IP auflösen, wäre der empfehlenswertere Weg. Wieso den? Weil mehr Leute verstehen, wie DNS funktioniert, als wie NAT funktioniert, und ein großer Teil des Aufbaus guter Systeme besteht darin, Teile zu verwenden, die wartbar sind. Es ist wahrscheinlicher, dass ein DNS-Setup verstanden und somit korrekt gewartet wird als ein obskures NAT-Setup (meiner Meinung nach natürlich).
Lösung 2:
Ich bin überrascht, dass nach fast 8 Jahren niemand erklärt hat, wie man dies richtig macht, indem man das UCI-Konfigurationssystem verwendet, das standardmäßig in OpenWRT verwendet wird.
Die Antwort von Steven Monday ist richtig, verwendet jedoch iptables Befehle direkt, was eine niedrigere Schicht als das UCI-Konfigurationssystem ist und am besten von den meisten OpenWRT-Benutzern möglichst unberührt gelassen wird.
Der korrekte Weg, auf interne Server über ihre öffentlichen IP/Port-Kombinationen von einem anderen internen Host in UCI zuzugreifen, ist die Aktivierung der Konfigurationsoption reflection unter jedem spezifischen DNAT-Target in der Datei /etc/config/firewall . Dieses Verhalten ist hier dokumentiert.
Zum Beispiel:
config redirect
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '44322'
option dest_ip '192.168.5.22'
option dest_port '443'
option name 'apache HTTPS server'
option reflection '1'
Hinweis:Gemäß der angegebenen OpenWRT-Dokumentation reflection ist standardmäßig aktiviert. In meinen Tests war dies nicht der Fall.
Lösung 3:
Eine gängige Lösung besteht darin, Ihre internen Hosts auf einen lokalen DNS-Server zu verweisen, der die richtige "interne" Adresse für diese Hostnamen zurückgibt.
Eine andere Lösung – und wir verwenden diese dort, wo ich an unseren Cisco-Firewalls arbeite – besteht darin, DNS-Antworten auf der Firewall neu zu schreiben, die diesen Adressen entsprechen. Ich glaube nicht, dass es derzeit Tools für Linux gibt, die dies tun.
Sie sollten in der Lage sein, das Routing auf Ihrem Gateway so zu konfigurieren, dass es das Richtige tut. Möglicherweise müssen Sie die Server so konfigurieren, dass sie ihre extern zugeordnete IP-Adresse kennen (z. B. indem Sie sie einer Dummy-Schnittstelle zuweisen). Bei dieser Konfiguration würde die Kommunikation von einem internen System zu einem anderen internen System – unter Verwendung seiner „externen“ Adresse – über den Router laufen.
Lösung 4:
Was Sie tun möchten, heißt NAT Loopback und es erfordert, dass Sie eine SNAT-Regel hinzufügen, damit Pakete, die von Ihrem LAN zu Ihrem Server kommen, durch den Router zurückgehen:
-A POSTROUTING -p tcp -s 192.168.2.0/24 -d 192.168.2.10 -m multiport --dports 22,25,80,443 -j SNAT --to-source 89.179.245.232