Wirklich seltsames Debian-Problem: Von einer öffentlichen IP-Adresse aus kann keine Verbindung zu Diensten hergestellt werden, die unter Debian laufen. Mit privaten IP-Adressen funktioniert es einwandfrei.

Wirklich seltsames Debian-Problem: Von einer öffentlichen IP-Adresse aus kann keine Verbindung zu Diensten hergestellt werden, die unter Debian laufen. Mit privaten IP-Adressen funktioniert es einwandfrei.

Erstens handelt es sich nicht um ein Portweiterleitungsproblem. Wenn ich tcpdump ausführe, kann ich sehen, wie die Anfragen an den Debian-Server gelangen und dann aufhören.

Auf meinem Debian-Server läuft sowohl Apache als auch PleX. Wenn ich mich über 192.168.1.210 mit dem Debian-Server verbinde, funktioniert es einwandfrei. Ich kann die Webseiten sehen und von PleX streamen.

Wenn ich mein Netzwerk verlasse, z. B. um zu einem Freund zu gehen, kann ich auch nicht darauf zugreifen. Mit tcpdump kann ich sehen, wie die Pakete den Server erreichen, aber das ist alles. Dasselbe gilt für canyouseeme.org.

ICHTunhabe Routing und iptables eingerichtet. Ich verwende diese Maschine für Torrents + ein VPN, also verwende ich Routing, damit alles funktioniert. Das Routing soll PleX von tun0, der VPN-Schnittstelle, fernhalten, und iptables soll den Benutzer debian-transmission davon abhalten, etwas anderes als tun0 zu verwenden.

 route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.172.1.5      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.172.1.1      10.172.1.5      255.255.255.255 UGH   0      0        0 tun0
10.172.1.5      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
50.18.0.0       192.168.1.1     255.255.0.0     UG    0      0        0 eth0
54.241.0.0      192.168.1.1     255.255.0.0     UG    0      0        0 eth0
128.0.0.0       10.172.1.5      128.0.0.0       UG    0      0        0 tun0
184.72.0.0      192.168.1.1     255.255.192.0   UG    0      0        0 eth0
184.169.128.0   192.168.1.1     255.255.128.0   UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
216.144.236.186 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0

iptables:

target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.1.0/24       owner UID match debian-transmission
REJECT     all  --  anywhere             anywhere             owner UID match debian-transmission reject-with icmp-port-unreachable

Antwort1

Was passiert, lässt sich wahrscheinlich am einfachsten anhand eines Beispiels beschreiben.

Nehmen wir an, die IP-Adresse Ihres NAT-Routers lautet 1.1.1.1 und die IP-Adresse Ihres Freundes ist 2.2.2.2. Nehmen wir der Einfachheit halber außerdem an, dass sich Ihr Freund nicht hinter einem NAT-Router befindet (das macht das Beispiel etwas komplizierter, wenn er sich hinter einem befindet, ändert das aber nichts grundsätzlich am Problem). Ich gehe außerdem davon aus, dass die Portweiterleitung Port 80 Ihrer externen IP an Port 80 der Debian-Box weiterleitet.

Der Computer Ihres Freundes sendet ein Syn-Paket mit der Quelladresse 2.2.2.2, einem zufällig ausgewählten Quellport (sagen wir 12345), der Zieladresse 1.1.1.1 und dem Zielport 80

Das Paket erreicht Ihr NAT, es sucht den Port weiter und ändert die Ziel-IP auf 192.168.1.210. Die Quell-IP bleibt 2.2.2.2, die Ports bleiben gleich. Es wird eine Zuordnung erstellt, sodass die Rückübersetzung für zurückgegebene Pakete durchgeführt werden kann, soweit so gut.

Das Paket erreicht Ihren Server. Es wird an den TCP-Stapel übermittelt, der als Antwort ein Bestätigungspaket erstellt. Wie üblich werden bei der Beantwortung eines Pakets Quelle und Ziel vertauscht. Das Paket hat also eine Quelladresse von 192.168.1.210, eine Zieladresse von 2.2.2.2, einen Quellport von 80 und einen Zielport von 12345.

Die Antwort verlässt den TCP-Stack und erreicht iptables. Ihre Regeln führen einen UID-Abgleich durch, sodass der Besitzerabgleich korrekt funktioniert und das Paket dort durchkommen sollte.

Dann gelangt es in die Routing-Tabelle. Diese sendet es über das VPN. Es gelangt in das VPN zu einem NAT, das seine Quelle auf irgendeine Weise ändert, gelangt zurück zu Ihrem Freund und wird aufgrund der falschen Quelladresse gelöscht.

Mögliche Lösungen: 1: Fügen Sie die IP-Adresse Ihres Freundes zur Routing-Tabelle hinzu. Dies ist offensichtlich nicht sehr skalierbar und kann zu Datenlecks im Torrent-Verkehr führen. 2: Wenn Ihre NAT-Box ein richtiges Linux-System ist, sollte es möglich sein, sie so zu konfigurieren, dass sowohl die Quelle als auch das Ziel eingehender Verbindungen geändert werden. Ihre Torrent-Box sieht dann die NAT-Box als Quelle und nicht das System Ihres Freundes im Internet. 3: Verwenden Sie die „erweiterten Routing“-Funktionen in Linux, um basierend auf dem Quellport zu routen. Leider sind die erweiterten Routing-Funktionen sehr leistungsstark, aber auch schwer zu verstehen. Wenn Sie weitere Informationen zu diesem Weg wünschen, lesen Sie das „Linux Advanced Routing and Traffic Control Howto“.

verwandte Informationen