crashbandicot schrieb:
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.
crashbandicot schrieb:
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.
crashbandicot schrieb:
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.
crashbandicot schrieb:
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.
ort)? Von außen (zB Nachbar-Internet, Mobilfunk)?
