Portweiterleitung, kein Zugriff von intern

jobe · 2024-03-31T19:46:56+00:00

Sunrise Community - Kunden helfen anderen Kunden rund um die Themen Fernsehen, Internet, Telefon und Mobile. Jetzt registrieren!

jobe

Ich habe den Router auf IP4 umstellen lassen um wieder die Möglichkeit für Portweiterleitung zu haben. Dieser Menüpunkt existiert und ich konnte auch die entsprechenden Regeln aktivieren.
Lange habe ich dann gesucht, warum das ganze nicht funktioniert. Weder mein Webserver schien von außen erreichbar noch ein ssh Zugang. Soviel ich auch versucht habe, es kamen keinerlei Anfragen an, weder über ssh, noch über http oder https.
Irgendwann bin ich zufällig auf die Idee gekommen, mal zu sehen wie es vom Natel aus auschaut. Dieses war nicht im WLAN sondern über Mobile Daten im Netz.
Und surprise: Der Webserver ist ereichbar.
D.h für mich, dass dort die ConnectBox etwas falsch macht. Leider gib es
a) keine Möglichkeit in der ConnectBox den DNS Server zu ändern
b) irgendeine Art von Logfiles zu sehen welche zeigen könnte wer wie wo versucht zuzugreifen.

Auch von “intern” wird die URL noch auf die korrekte IP Adresse umgesetzt… aber dann verließen sie ihn.

Über kurz oder lange (hoffe ersteres) fliegt die ConnectBox zwar eh raus aka wird nur noch als Bridge und nutzlose Heizung dienen, aber im ersten Schritt hätte ich gerne nicht alles auf einmal geändert.

Gibt es Hinweise/Vorschläge wie ich die Box dazubringen auch Anfragen von intern korrekt zunächst nach draußen und wieder zurück zu routen?

EZS1234

jobe Irgendwann bin ich zufällig auf die Idee gekommen, mal zu sehen wie es vom Natel aus auschaut. Dieses war nicht im WLAN sondern über Mobile Daten im Netz.
Und surprise: Der Webserver ist ereichbar.
D.h für mich, dass dort die ConnectBox etwas falsch macht.

surprise, surprise, die Limitierungen der Connect Boxen wurden erkannt. Die Box macht es nicht falsch, sie kann es schlicht und einfach nicht. Das sie es nicht kann ist bekannt, beheben lässt sich das nur mit Bordmitteln der Connect Box nicht. https://community.sunrise.ch/d/6291-nat-loopback

Benötigst du eine Portweiterleitung überhaupt, also Zugriff von aussen? Den deine Frage liest sich halt so das du das funktionieren der Portweiterleitung mittels Test von aussen nur eher per Zufall gemacht hast.

jobe

EZS1234
Selstverständlich brauche ich das, sonst hätte ich es nicht eingerichtet. Und wenn man dies einrichtet, configuriert und testet sitzt man normalerweise IM Netz und nicht außerhalb - aber mit der ConnectBox geht dies anscheinend nun schlichtweg nicht; sehr schwache Leistung.

Und selbstverständlich sollte das von innen 1:1 genau so funktionieren wie von außen. Es gibt keinen Grund warum die Connectbox Anfragen von Intern anders behandeln sollte als von extern. Dass sie dies macht ist ein “explizites” (falsches) Feature und zeigt einmal mehr den Grund warum der Routerzwang seitens der Anbieter als ungenügend zu sehen ist.

Aber danke für die Klarstellung, dass die ConnectBox nur ein klein wenig mehr als Elektroschrott ist. 🤨

oli-h

Versteh’ ich das Szenario richtig:

Dein Router hat z.B. LAN-IP 192.168.1.1
Du hast einen Server mit einer LAN-IP, also z.B. 192.168.1.2
Du hast ein zweites Gerät in diesem LAN (sagen wir mal ‘PC’ dazu) von dem aus Du auf diesen Server zugreifen willst. Nehmen wir IP 192.168.1.3 an.
Zudem hast Du ein Port-Forwarding von deiner WAN-IP (öffentliche IP, z.B. 5.5.5.5) auf die LAN-IP deines Server
Vermutlich hast Du noch einen DynDns-Dienst, der deinen Domainname auf diese öffentliche IP auflöst

Und jetzt willst Du von deinem LAN-PC aus mit diesem DNS-Namen (also mit der öffentlichen IP) auf deinen Server zugreifen?

Da passiert folgendes im Netzwerkstack deines PC:

DNS-Name wird zur IP 5.5.5.5 aufgelöst.
IP-Stack stellt fest: diese IP gehört nicht zum LAN, da mittels Netzmaske (typisch 255.255.255.0) diese nicht meiner IP 192.168.1.3 passt
Also gehen die IP-Pakete zum “Default-Gateway”, also dein Router, was eben 192.168.1.1 sein dürfte
Router sieht nun Ziel-IP 5.5.5.5. Auch er stellt fest: Nicht LAN –> muss übers WAN-Interface rausgeschickt werden.
Vermutlich wird dieses IP-Paket dann irgendwo nächsten (Cablecom-)Router verworfen um Endlosschleifen zu vermeiden.

Dein Router müsste also intelligenter sein und erkennen, dass es für 5.5.5.5 (und diesen spezifischen Port) ein Port-Forwarding gibt und dann das LAN-Paket doch wieder zurück ins LAN schicken, diesmal mit der Ziel-IP 192.168.1.2.
Das ist aber nicht unproblematisch:

Entweder bleibt die Quell-IP des IP-Pakets gleich (also die 192.168.1.3 von deinem PC). Nur dann würde der Server sein TCP-ACK direkt an deinen PC zurückschicken, der diese aber nicht ‘von’ der IP 192.168.1.3 erwartet - er hat ja 192.168.1.1 kontaktiert
Oder der Router macht auch hier NAT, trägt also als Quell-IP seine eigene LAN-IP ein. Dann wird der ganze Traffic (obwohl eigentlich LAN-intern) dennoch immer über deinen Router laufen. Zudem sieht man in den Server-Logs nicht, dass die Verbindung von deinem PC kam
Oder der Router schickt ein “ICMP-Redirect-Paket” an deinen PC zurück mit dem Hinweis, dass 5.5.5.5 direkt im LAN unter der IP 192.168.1.2 erreichbar wäre (wobei ich mir hier gerade nicht sicher bin, ob dann noch der Netzwerkstack des Servers angepasst werden müsste)

jobe

oli-h
Deine Beschreibung ist schön und gut. Aber genau auf den Punkt der fehlschlägt gehst du nicht genauer aun. Der Rounter stellt fest: Hey, ist nicht für mich, schick ich mal nach darußen. Und der nächste Hop müßte dann festellen an wen er es zustellen muss: nämlich “Back to sender”. Also schickt er es zurück zum Router der weiß: Hey, das ist meine IP! Und hey, ich habe in meinem NAT Table einen Eintrag: Portweiterleitung von ext. Port 80 auf intern 192.x.x.x:80, das mach ich so.
Wo liegt das Problem? Leitet der Router es also nicht weiter ins Netz? Und wenn er das tut, warum gibt der nächste es dann nicht dorthin weiter wo es hin gehört? Nämlich zurück.
Ich sehe nicht, warum das Problem intern gelöst werden sollte. Dies ist sicher möglich, erfordert aber dann wirklich mehr Intelligenz.
Als ich das früher in Frankreich mit einer Fritzbox als Modem UND Router betrieben habe hat dies ohne Probleme funktioniert. Aber eigene Modems in der Schweiz…

pato

jobe Dies ist eine Router Schutzfunktion welche hier eingreift (also auf Seite Sunrise, nicht Seite Kunde). Ein Paket welches am Interface X hereinkommt, darf nicht wieder am gleichen Interface X herausgehen, sonst gibt es ein Routing Loop. Es gibt noch Ausnahmen bezüglich VRF und so, aber grundsätzlich wäre dies hier nicht der Fall, da er es ja an die gleiche Quelle (dein Router zuhause) wieder zurücksenden müsste, was aber einem Routing Loop entspricht.
Da der Sunrise Endkunden Router jedoch kein Hairpinning kann, wird das Paket somit verworfen und die Verbindung schlägt fehl. Das Problem ist beim Sunrise Router zu suchen (respektive UPC) und ist schon seit vielen Jahren ein Thema. Eine wirkliche Lösung dazu gibt es nicht, ausser von Hand auf die interne IP anstatt den DNS Namen mit externer IP zu verbinden.

jobe

Vielen Dank pato für die Erklärung. Zumindest ist damit klar wo das Problem liegt.
Hast du auch einen Vorschlag wie man das intern auf der UPC Box lösen kann? Ich kann ja noch nicht einmal einen anderen DNS Server einstellen geschweige denn selbst quasi eine “hosts” Datei definieren damit er den Namen schon intern auf die interne Adresse auflösen würde.

pato

jobe Doch das mit der Host Datei könntest du machen 😉
Ich persönlich verbinde halt auf die IP, respektive habe einfach zwei Shortcuts auf dem Handy, einen für extern und einen intern im WLAN (mit der IP anstatt DNS Name).

jobe

pato Nur zur Klarstellung: Ich rede von einer “hosts” Datei auf dem Router, NICHT auf dem PC, denn davon gibt es zu viele im Netz. Soetwas gehört zentral geregelt.

Belegnor

jobe

Auf dem Router wirst du diese DNS Funktion nicht finden. Die beste (nachhaltige) Option wäre einen eigenen DHCP-/DNS-Server einzusetzen. Bei Synology NAS Systeme ist diese Funktion als App dabei. Bei anderen Systemen muss man mit externen Apps bzw. Docker (z. B. Pi-hole als Container) nachhelfen. Alternativ kann man Firewalls einsetzen, welche diese Funktion beinhalten.

Der Einsatz eines eigenen DHCP-/DNS-Servers bringt einige Vorteile mit sich, unter anderem die Möglichkeit, den internen Verkehr durch die Namensauflösung auch intern zu behalten.

Wenn du eine offizielle Domäne hast, kannst du Split DNS verwenden. Dadurch kann die Auflösung eines Hostnamen sowohl eine öffentliche IP (wenn im Internet aufgelöst) als auch eine private IP (wenn intern aufgelöst) ausgeben. Dies ist vor allem bei Applikationen vorteilhaft, in denen nur ein Zielserver eingetragen werden kann.

Wichtig ist, dass der DHCP-Server der Connect Box deaktiviert wird, wenn ein eigener DHCP-/DNS-Server verwendet wird.

Ich hoffe, das hilft weiter

Gruss