Ich habe einen Raspberry Pi am Laufen, den wir im Büro für kleine Testprojekte verwenden, die wir nicht auf unserem Hauptentwicklungsserver haben wollen. Er läuft mit Apache. Der DNS wird über Cloudflare abgewickelt, aber im DNS-Only-Modus. Während ich teste, gilt derzeit keine IP-Einschränkung. Der A-Eintrag mysite.domain.tldverweist auf meine statische IP-Adresse 123.123.123.123und nur ein Standard-Glasfaserrouter/-modem für Unternehmen befindet sich zwischen dem Internet und dem Pi.
Wenn ich mysite.domain.tldbeispielsweise von meinem Telefon ohne WLAN aus zugreife, wird die IP-Adresse des Mobilfunkanbieters angezeigt. Wenn ich wgetvon einem Remote-Server aus zugreife,es ist'IP wird in den Protokollen angezeigt. Alles funktioniert wie erwartet.
mysite.domain.tldWenn ich jedoch aus demselben Netzwerk gehe , in dem sich der Pi befindet, protokolliert Apache die Gateway-IP des Routers 192.168.1.1. Ich würde erwarten, meine öffentliche IP-Adresse zu sehen, da meine Verbindung zum Domänennamen über Cloudflare in die öffentliche IP aufgelöst wird. Stattdessen sehe ich in den Protokollen eine lokale Netzwerk-IP.
Es ist nichts eingestellt /etc/hosts(ich verwende macOS) und auf dem Router ist nur die Portweiterleitung für Verbindungen von Port 443 zum Pi auf demselben Port eingerichtet - der Domänenname wird nirgendwo erwähnt. Wenn ich pinge, mysite.domain.tldbekomme ich dieCloudflareIP-Adresse, das habe ich erwartet.
Es scheint, als ob irgendwo in der Kette meine IP-Adresse und die öffentliche IP-Adresse des Pi abgeglichen werden, sodass die IP durch die interne Gateway-IP überschrieben wird.Was passiert hier eigentlich?Ich tu nichtGeistan sich möchte ich nur sicherstellen, dass ich mich 192.168.*beim Einrichten der IP-Beschränkung auf der Firewall auf die Vertrauenswürdigkeit der IPs verlassen kann.
Hinweis: CF-Connecting-IP und ähnliche Header werden hier nicht von Cloudflare gesendet, ich gehe davon aus, dass dies nur geschieht, wenn nicht im DNS Only-Modus. Und esscheintnur, wenn ich dieselbe Netzwerkverbindung verwende, die auch der Pi verwendet.
Antwort1
Auf Ihrem Router läuft Linux, und dieses Verhalten lässt sich auf jeder Standard-Linux-Distribution leicht implementieren. Ich kann mir vorstellen, welche Regeln in der Firewall Ihres Routers vorhanden sein müssen, damit dies funktioniert. Aber seien Sie sich bewusst, dass dies nur eine Spekulation ist, wir wissen nicht, wie die Regeln in Wirklichkeit genau aussehen.
Als Sie einen Port an Ihren Webserver weitergeleitet haben, wurde eine bestimmte DNAT-Regel hinzugefügt, die wahrscheinlich folgendermaßen aussieht:
iptables -t nat -A PREROUTING -p tcp -d <your-external-address> --dport 443 -j DNAT --to-destination <raspberry-pi-address>
In Worten bedeutet dies: „Bevor Sie entscheiden, ob dieses Paket für das Gerät bestimmt ist oder weitergeleitet werden muss, prüfen Sie, ob die Zieladresse des Pakets Ihre externe Adresse ist und der Zielport 443 ist. Wenn dies übereinstimmt, ändern Sie die Zieladresse in die LAN-Adresse des Raspberry Pi.“ Beachten Sie, dass diese Regel nicht nach der Schnittstelle filtert.
Außerdem verfügt es definitiv über eine SNAT-Regel (zur Bereitstellung des Internetzugangs für das LAN), die wahrscheinlich folgendermaßen aussieht:
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
Mit anderen Worten: Nachdem der Router entschieden hat, wohin das Paket gehen muss, ändert er vor dem Senden des Pakets seine Quelladresse in die Adresse einer ausgehenden Schnittstelle (wenn das Paket vom LAN gesendet wurde). Auch hier wird nichts durch eine Schnittstelle gefiltert.
Betrachten wir nun Ihre HTTPS-Verbindung. Sie geben den Hostnamen im Browser an, richtig? Sie haben ihn so eingerichtet, dass er in die externe Adresse Ihres Routers aufgelöst wird, die dann zur Zieladresse wird. Ihre Quelladresse befindet sich innerhalb des LAN. Es scheint also, dass beide Regeln für die Pakete Ihrer Verbindung gelten.
Bei der Verarbeitung stößt der Router zuerst auf die DNAT-Regel, überprüft die Zieladresse und den Port und beschließt, die Zieladresse auf die des Raspberry Pi zu ändern. Dann findet er heraus, dass die Schnittstelle, über die das Paket gehen muss, LAN 1 ist. Dann prüft er das teilweise übersetzte Paket anhand der zweiten Regel und findet heraus, dass die Quelladresse aus dem LAN stammt. Also ersetzt er die Quelladresse des Pakets durch die Adresse der LAN-Schnittstelle, 192.168.1.1. Das ist, was Ihr Raspberry Pi sieht.
Der NAT-Vorgang ist zustandsbehaftet, d. h. er verwaltet auch einen Tabelleneintrag, der angibt, was durch was ersetzt wurde und wie nachfolgende Weiterleitungs- und Antwortpakete erkannt werden, sodass alle richtig übersetzt werden. Ja, es stellt sich heraus, dass Linux DNAT und SNAT gleichzeitig innerhalb desselben Streams ausführen kann.
Kann man diesem Verhalten vertrauen? Ich weiß es nicht. Wenn die Firmware des Routers Open Source war, hatten wir die Möglichkeit, dies zu überprüfen. Ohne den Quellcode können wir nicht sicher sein. Dies ist immer der Fall, wenn der Quellcode geschlossen ist. Aus diesem Grund müssen Closed-Source-Produkte vermieden werden, wenn Sie sich um die Sicherheit sorgen.