Portweiterleitung FB7490 funktioniert nicht mehr

crashbandicot

Commander
Dabei seit
Dez. 2013
Beiträge
2.591
Hallo,

ich habe eine neue Portweiterleitung eingerichtet (RPi, Webserver) - diese Weiterleitung hat allerdings nur einige Tage funktioniert. Andere Weiterleitungen (z.B. Weboberfläche von meinem NAS) funktionieren weiterhin. Der RPi Webserver ist intern erreichbar, von außen allerdings nicht.

Laut FB ist diese Weiterleitung aktiv und "grün". Den RPi habe ich schon durchgestartet, keine Besserung.

Bei den nach außen geöffneten Ports ist kein well-known Port dabei.

Was/wo kann ich noch prüfen, warum es nicht mehr funktioniert?
 

Madman1209

Fleet Admiral
Dabei seit
Nov. 2010
Beiträge
25.116
Hi,

hat sich die IP Adresse vom Pi geändert oder ist diese fest vergeben? Wie genau greifst du intern drauf zu? Per Name oder per IP? FritzBox auch schon mal neu gestartet? Irgendwelche anderen Configs verändert?

VG,
Mad
 

crashbandicot

Commander
Ersteller dieses Themas
Dabei seit
Dez. 2013
Beiträge
2.591
Die IP vom RPi ist fest vergeben. Intern funktioniert der Zugriff via Name (z.B. rpi.fritz.box) sowie auch über die IP-Adresse.
Die FB habe ich noch nicht durchgestartet. Geändert habe ich ansonsten nichts.
 

Raijin

Fleet Admiral
Dabei seit
Nov. 2007
Beiträge
10.415
Erstmal stellt sich die Frage ob es überhaupt an der Portweiterleitung liegt.

Wie testest du die Weiterleitung? Von innen (zB WLAN/LAN --> DDNS:port)? Von außen (zB Nachbar-Internet, Mobilfunk)?
Läuft der Dienst, auf den weitergeleitet wird (zB der Webserver, o.ä.)?
Akzeptiert die Firewall des Zielgeräts Verbindungen von öffentlichen IPs?

Am besten versuchst du mal am PI mittels "tcpdump" den Port zu cappen. Dort siehst du dann ob Daten ankommen oder nicht. Wenn ja, funktioniert die Portweiterleitung so wie sie soll und es liegt am PI selbst bzw. am Dienst.


Grundsätzlich empfehle ich stets, nur ein VPN von außen erreichbar zu machen. Wenn du Webguis und dergleichen erreichbar machst, steigt das Risiko einer Sicherheitslücke exponentiell. Via VPN kann man zB auch unverschlüsselte Dienste und sogar solche, die gar nicht für das Internet gedacht sind (und demnach geradezu gefährlich, zB SMB) vollkommen gefahrlos nutzen, weil alles über die verschlüsselte VPN-Verbindung läuft und von Dritten nicht einsehbar ist. Wenn man mehrere Geräte über Portweiterleitungen erreichbar macht, kommt es auf die Sicherheit eines jeden Geräts einzeln an - zB eine potentiell schlecht gesicherte Web-GUI eines NAS.
 

DeusoftheWired

Fleet Admiral
Dabei seit
Juni 2009
Beiträge
10.140

h00bi

Fleet Admiral
Dabei seit
Aug. 2006
Beiträge
13.597

FranzvonAssisi

Vice Admiral
Dabei seit
Dez. 2013
Beiträge
6.663
Jup, den gibt's bei den Speedports auch und hat mich fast zum verzweifeln gebracht... :D
 

crashbandicot

Commander
Ersteller dieses Themas
Dabei seit
Dez. 2013
Beiträge
2.591
@Raijin
Es liegt ganz sicher an der Portweiterleitung. Ich habe mit portqry oder auch externen Diensten geprüft, ob der Zielport erreichbar ist. Der vom NAS ist es, der vom RPi nicht (mehr).
Der Dienst selbst läuft, sonst könnte ich von intern nicht darauf zugreifen. Eine Firewall o.ä. gibt es nicht.

Mit tcpdump müsste ich mich dann beschäften, nutze unter Windows Wireshark, wird aber wohl das gleiche in grün sein. Wollte nicht direkt mit Kanonen auf Spatzen schießen. ;)

Bzgl. des VPNs: ja, wäre mir auch lieber, aber ich kann nicht von jedem Rechner oder Smartphone eine VPN Verbindung aufbauen, um mich ins NAS oder auf den RPi einzuwählen...

@DeusoftheWired
Das NAS wird mit Success angezeigt, der RPi mit Error. Eine Extrarunde durchs Internet drehe ich nicht, das bekommt die FB gut geregelt. Ich löse nur den externen DNS Namen auf, connecte mich auf die externe IP und ab dann läuft der Traffic intern. So jedenfalls das Ergebnis eines einfachen Tests von mir: auf die ext. IP des NAS verbinden, Download starten, >100MBit und keine Auslastung des Internet-Up-/Downstreams im FB Onlinemonitor zu erkennen.
 

Raijin

Fleet Admiral
Dabei seit
Nov. 2007
Beiträge
10.415
Es liegt ganz sicher an der Portweiterleitung. Ich habe mit portqry oder auch externen Diensten geprüft, ob der Zielport erreichbar ist.
Aha, ganz sicher also.
Ein "Fehler" bei einem Portscanner und/oder ein fehlerhafter Verbindungsversuch einer Client-Software sagt an dieser Stelle rein gar nichts über die Portweiterleitung an sich aus. Wenn die Verbindung von außen am Router geblockt wird (zB durch eine nicht vorhandene/fehlerhafte Portweiterleitung) oder letztendlich am PI selbst, das Ergebnis ist weitestgehend dasselbe "Connection refused", o.ä. Portscanner zeigen dann meistens pauschal "closed" an, ungeachtet der eigentlichen Rückmeldung.

Wenn andere Portweiterleitungen funktionieren, ist das erst recht ein Indiz dafür, dass die fragliche Portweiterleitung auch funktioniert, sofern denn der externe bzw. interne Port sowie die Ziel-IP stimmen. Allerdings kann es vorkommen, dass du Ports verwendest, die der Router explizit selbst nutzt (zB der Klassiker: VPN @ Router vs VPN hinter Portweiterleitung). Im Zweifel nach Möglichkeit den externen Port mal zum Test abändern und erneut probieren.


Der Dienst selbst läuft, sonst könnte ich von intern nicht darauf zugreifen. Eine Firewall o.ä. gibt es nicht.
Sei dir da mal nicht so sicher. Der Dienst selbst kann Verbindungsanfragen aus dem www blockieren. Dann läuft er wunderbar lokal, aber trotz (funktionierender) Portweiterleitung und offener Firewall reagiert er nicht auf externe Zugriffe.

Mit tcpdump müsste ich mich dann beschäften [..] Wollte nicht direkt mit Kanonen auf Spatzen schießen.
tcpdump ist im Prinzip dasselbe wie WireShark, nur eben für die Linux Konsole. Mit folgendem Befehl würdest du alle Pakete an eth0 auf tcp 443 sehen:

tcpdump -i eth0 tcp port 443

Das ist auch keine Kanone, sondern ein simpler Schraubenzieher für Netzwerkprobleme. ;)
Wie willst du das Problem sonst analysieren? Durch scharf hinsehen?


Deswegen prüfe das bitte und gehe nicht davon aus, dass es per Definition an der Portweiterleitung liegt. Es kann natürlich trotzdem an der Weiterleitung liegen, aber auch ein negatives Ergebnis bei tcpdump (=keine eingehenden Daten) trägt zur Lösungsfindung bei. Es gilt schließlich, alle potentiellen Fehlerquellen auszuschließen.


Das NAS wird mit Success angezeigt, der RPi mit Error. Eine Extrarunde durchs Internet drehe ich nicht, das bekommt die FB gut geregelt. Ich löse nur den externen DNS Namen auf, connecte mich auf die externe IP und ab dann läuft der Traffic intern.
Da widersprichst du dir nun aber selbst bzw. das funktioniert anders als du denkst.

Wenn man von innerhalb des Netzwerks eine DDNS-Domain ansteuert, kommt es auf die Details an. Du sagst der DNS-Eintrag wird mit einer externen IP aufgelöst. Dann drehst du eine Extrarunde durchs Internet, besser gesagt durch den WAN-Port des Routers. Das nennt sich NAT-Loopback oder auch NAT-hairpin. Dabei verbindet sich der PC mit einer öffentlichen IP und schickt die Anfrage wie gehabt Richtung Standard-Gateway (Router). Dieser merkt dann aber, dass seine eigene WAN-IP gemeint ist und dreht den Traffic quasi im letzten Moment um und schickt ihn als externen Traffic getarnt wieder in den WAN-Port hinein und durchläuft die gaaaaaaaaaanze NAT-Pipeline, inkl. Portweiterleitung. Je nach Router kann das extrem ineffizient und langsam sein - zB wenn der Router max 100 Mbit/s WAN schafft, man aber ein komplettes Gigabit-LAN hat.
Egal ob PC und PI am selben Switch hängen, der Traffic wird in diesem Szenario immer PC <-Router-> PI gehen. Beim PI, der ja nu keine Netzwerkrakete ist, wirst du das vermutlich gar nicht merken, aber wenn du zB ein NAS auf diese Art verbindest, stehen die Chancen gut, dass auch diese Verbindung dann zT deutlich unter 1 Gbit/s laufen wird, NAT-Loopback sei Dank....
Außerdem: Wenn man die Portweiterleitung sogar durch weitere Parameter eingeschränkt hat (zB Quell-IP = Büro), dann wird sie beim NAT-Loopback nicht ausgelöst.

Der angesprochene DNS-Rebind-Schutz dreht sich hingegen darum, dass die ursprüngliche DNS-Abfrage eben nicht mit der externen IP aufgelöst wird, sondern direkt mit der lokalen IP des eigentlichen Ziels, des PI. Hängen PC und PI nun am selben Switch, geht der Traffic auch direkt PC <--> PI, ohne Umweg über den Router, ohne potentielle Spaßbremse der langsamen NAT-Engine des Routers, da der Router selbst nur zu Beginn beim DNS-Request beteiligt ist. Die Fritzbox verhindert mit dem Rebind-Schutz allerdings aktiv, dass DNS-Einträge mit lokalen IPs beantwortet werden, dafür muss man Ausnahmen erstellen.


Du siehst, das Thema ist recht komplex. Eben gerade deswegen darf man nicht per Definition davon ausgehen, dass es an X oder Y liegt. Teste daher im Idealfall bitte von einem echten externen Zugang (zB via mobilem Hotspot am Handy), um etwaige Probleme mit NAT-Loopback auszuklammern. Anschließend mittels tcpdump prüfen ob überhaupt Daten am PI ankommen.
 

crashbandicot

Commander
Ersteller dieses Themas
Dabei seit
Dez. 2013
Beiträge
2.591
So, habe mit tcpdump getestet und anscheinend lag es an dem verwendeten ext. Port. Kaum hatte ich diesen geändert, lief die Verbindung wieder wie gewohnt. Mal gucken wie lange dieses Mal...

Danke übrigens für deinen gesamten Text. Ich bin kein großer Netzwerker, und da ich im alltäglichen Geschäft eher schlechte Erfahrungen mit Netzwerkern mache, bin ich da wohl ein gebranntes Kind.

Wie auch immer... Ich werde mir mal nen Reverse Proxy für den RPi angucken, um das NAS und den Webserver des RPi nicht direkt zu veröffentlichen, sondern wenigstens eine HTTP Basic Authentication vorschalten. Einverstanden? ;)
 

Raijin

Fleet Admiral
Dabei seit
Nov. 2007
Beiträge
10.415
Danke übrigens für deinen gesamten Text. Ich bin kein großer Netzwerker
Das erwartet auch keiner. Wie man meinem Beitrag entnehmen kann ist Netzwerk deutlich komplexer als Otto Normal glaubt. Deswegen sind eben gerade solche Schnellschüsse "das liegt nicht daran, sondern daran, punkt!" ein zweischneidiges Schwert, weil man unter Umständen die anderen potentiellen Ursachen gar nicht kennt ;)

Welchen externen Port hattest du denn ursprünglich benutzt? Du sprachst ja explizit davon, dass kein well-known Port dabei war. Klassische Beispiel für einen Konflikt mit vom Router selbst genutzten Ports wären sonst zB tcp 80/443 oder auch udp 500/4500 sowie udp/tcp 1194. Das wären nämlich die Ports für die GUI oder etwaige VPN-Server. Es mag bei der Fritzbox noch weitere geben, für Management-Funktionen, o.ä. Daher wäre es mal ganz interessant mit welchem Port es denn nicht lief.

Bezüglich Reverse Proxy: Wie gesagt, ich mache das aus Prinzip nur mit VPN und mir kommt nix anderes ins Netzwerk. Allerdings habe ich auch nicht den Anspruch, mich von jedem x-beliebigen Smartphone oder PC aus bei mir einloggen zu können. Auf meinen Geräten ist VPN eingerichtet, auf fremdem Smartphones backe ich mir ein Ei drauf, auf mein Netzwerk zuzugreifen und auf fremden PCs nutze ich im worst case ein Live-Linux auf einem USB-Stick mit VPN. Der Vorteil des VPNs liegt auf der Hand: Ich kann jeden Dienst von außen nutzen als säße ich auf der Couch daheim.
 

crashbandicot

Commander
Ersteller dieses Themas
Dabei seit
Dez. 2013
Beiträge
2.591
Top