7590AX: Portfreigaben: mehrere externe Ports auf einen internen Port?

[Rolf Grisu]

Hallo zusammen!

ich versuche gerade die externen Ports 80 und 443 auf eine interneRessource:8080 freizugeben. Das wird von der FB mit "Für diese Freigabe wurden andere Ports extern vergeben als von Ihnen gewünscht." quittiert. Weshalb ist das nicht möglich?

 

[stoney]

möglicherweise wegen:

FRITZ!Box meldet "Für diese Freigabe wurden andere Ports extern vergeben als von Ihnen gewünscht" | FRITZ!Box 7590 AX

Nach der Einrichtung einer Portfreigabe zeigt die FRITZ!Box in der Liste der Portfreigaben unter "Port extern vergeben" andere Ports an, als die, die freigegeben werden sollten. Die abweichenden Ports sind mit einem Ausrufezeichen gekennzeichnet. Bei einem Klick auf dieses wird die folgende...

avm.de

Also welches Gerät verwendet denn bereits die Ports? (Siehe "Diagnose > Sicherheit")

 

[Rolf Grisu]

Diagnose -> Sicherheit zeigt z.B. für Port 80 "Zugriff auf die FRITZ!Box Oberfläche (HTTP)" obwohl dieser eigentlich nach "interneRessource:8080" zeigen sollte. Da aber bereits 443 erfolgreich auf "interneRessource:8080" eingerichtet ist, erscheint die Fehlermeldung. Auf einer Hilfeseite bei AVM heißt es nur "...geht nicht ..." ohne zu erklären warum das nicht geht.

 

[stoney]

Naja wenn doch 443 bereits an 8080 geht, wie soll da 80 ebenfalls an 8080 gehen können.

80 an 8080
443 an 8081

wäe zB möglich.


Schaust Du auch richtig? (Zuerst geht's ums interene Netz > 80 an FBObx GUI - im nächsten Abschnitt sollten die externen Ports aufgelistet sein)

 

[Rolf Grisu]

Naja wenn doch 443 bereits an 8080 geht, wie soll da 80 ebenfalls an 8080 gehen können.

Die Frage ist: wieso geht das NICHT? Ob's Sinn ergibt, sei mal dahingestellt. Technisch sehe ich aber keinen Hinderungsgrund.

80 an 8080
443 an 8081

wäe zB möglich.

klar. Das ist aber nicht die Frage.

Schaust Du auch richtig? (Zuerst geht's ums interene Netz > 80 an FBObx GUI - im nächsten Abschnitt sollten die externen Ports aufgelistet sein)

Ich denke, ja. Zu finden unter "Übersicht der geöffneten Ports für den Zugriff aus dem Heimnetz" Weil die Weiterleitung nicht eingerichtet wird (Ausrufezeichen), greift ein Automatismus der FBs: ist die interne Ressource nicht verfügbar, wird automatisch auf die Anmeldeseite der FB umgeleitet (nur bei internen Zugriff)

 

[stoney]

Technisch sehe ich aber keinen Hinderungsgrund.

vielleicht liest Du dich mal in diese Richtung etwas ein.
zB:

NAT - Network Address Translation

oder

Netzwerkadressübersetzung – Wikipedia

de.wikipedia.org

 

[Exodus88]

@kaffeetante

kurz und knapp.... Das, was du vorhast, ist nicht möglich.

Evtl. hilft es dir/und, wenn du uns sagst, was du eigentlich vorhast. Geht es evtl. um eine Freigabe für eine IP Kamera, damit du von außen mit einem PC bzw. Browser zugreifen und steuern kannst?

Gruß

Roland

 

[Grisu_]

Wenn 2 externe Ports auf den selben internen übersetzt würden, wohin meinst sollte dann der Verkehr zurück vom Client ins Netz hingeroutet werden?
Da darf sich die Box dann aussuchen wenns von intern 8080 kommt, ob sie es auf 443 oder 80 schickt.
Das Gerät auf der anderen Seite wird sich freuen, wenns am falschen Port daherkommt und somit keinen Abnehmer findet.

 

[chrsto]

Selbstverständlich ist das möglich:



Möglicherweise lässt das aber eine Fritz!Box mit Bordmitteln nicht zu.

 

[Rolf Grisu]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Sorry, aber das beantwortet die Frage nicht.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Okay, sofern die FB ein Entscheidung treffen muss, leuchtet das ein. Ich dachte immer dass die Port-Information über das http-Protokoll gesteuert wird (z.B. über http-referer). D.h. die FB schickt die Antwort einfach an die IP zurück und die Port-Entscheidung wird beim Empfänger getroffen.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Interessant. Dann bin ich mit meinen Überlegungen wohl doch nicht auf dem Holzweg und die FB ist der Schwachpunkt.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Nunja, eigentlich hatte ich Blödsinn im Hinterkopf, d.h. ich verfolge kein konkretes Ziel. Dennoch habe ich mich gewundert und deshalb die Frage gestellt. Wie sich jetzt herauskristallisiert, ist das wohl ein FB-Feature.

 

[chrsto]

Und wenn du deine 4 Beiträge mit sinnvollen Zitatgrößen in einen einzigen Beitrag gepackt hättest, dann wäre es nun auch übersichtlich.

 

[Exodus88]

Möglicherweise lässt das aber eine Fritz!Box mit Bordmitteln nicht zu.

Die FB übernimmt die Einträge, aber routet selbstständig - wie in deinem Beispiel - den Port 8081 auf 8080





Was geht oder nicht bzw. sinnvoll ist, muss jeder für sich selbst entscheiden und kann von Fall zu Fall unterschiedlich sein.

Ich kann auch mit dem Auto in falscher Fahrtrichtung auf die Autobahn fahren. Ob das richtig ist, nur weil ich es kann?

Solange man anschließend nicht der Meinung ist, das es sich nicht um einen Geisterfahrer handelt, sondern um hunderte

Die Routine der Box verhindert das "falsche Auffahren"...

 

[PeterPawn]

Möglicherweise lässt das aber eine Fritz!Box mit Bordmitteln nicht zu.

Aus RFC 6887:

It is possible that a mapping might already exist for a requested internal address, protocol, and port. If so, the PCP server takes the following actions:
[...]
2. If the existing mapping is static (created outside of PCP), the PCP server MUST return the external address and port of the existing mapping in its response and SHOULD indicate a lifetime of 2^32-1 seconds, regardless of the suggested external address and port in the request.

3. If the existing mapping is explicit dynamic inbound (created by a previous MAP request), the PCP server MUST return the existing external address and port in its response, regardless of the suggested external address and port in the request. Additionally, the PCP server MUST update the lifetime of the existing mapping, in accordance with Section 15, "Mapping Lifetime and Deletion".
[...]

Da seit der Implementierung von PCP im FRITZ!OS dieses Protokoll auch genutzt wird, um im FRITZ!OS eingerichtete permanente Weiterleitungen zu aktivieren (das kann jeder in den Support-Daten (s)einer Box nachlesen), werden seitdem auch die Beschränkungen des Protokolls "vererbt" und wie man anhand der o.g. Zitate erkennen kann, ERZWINGT das PCP dabei ein 1:1-Mapping für jede Kombination aus interner IP-Adresse, Protokollnummer und (sofern verwendet vom Protokoll) Portnummer, solange man kein "all protocols"- oder "all ports"-Mapping will (jeweils mit einer 0 für den Wert angezeigt).

Wer also mehr als einen externen Port auf denselben internen Port mappen möchte, der muß eben zur Option des "Exposed host" greifen (das dürfte AVM auch als Kombination aus "all protocols" und "all ports" implementiert haben) ... damit ist das beschriebene Szenario problemlos zu realisieren. Dann ist man halt selbst dafür verantwortlich, daß alle Protokolle und Portnummern, die NICHT für Serverdienste genutzt werden sollen, passend abgesichert sind, sofern dort entsprechende Dienste aktiviert sind.

---

Ansonsten gibt es bei der Verwendung von PCP KEINERLEI Garantie, daß auch ein bestimmter externer Port zugewiesen wird (selbst wenn der PCP-Client einen "Wunsch" äußern darf) - es wird sogar explizit verlangt, daß ein Client auch mit dieser Situation zurechtkommen muß:

A PCP client MUST be written assuming that it may *never* be assigned the external port it suggests.

Daher MUSS es bei der Nutzung von PCP auch irgendeine Form von "rendezvous server" geben, wo der "Anbieter" von Serverdiensten dann auch noch die Information, auf welcher Portnummer der Dienst zu erreichen ist, hinterlegen kann.

Ich hatte irgendwie die Hoffnung, daß AVM das zumindest für Freigaben über den MyFRITZ!-Service auch im DNS implementieren würde (m.W. ist das bisher nicht passiert), z.B. in Form von SRV-, NAPTR- oder auch allgemeineren TXT-Records, die dann beim DynDNS-Update auch passend aktualisiert werden könnten. Allerdings müßte die verwendete Client-Software für den Zugriff auf solche Dienste dann auch noch den zusätzlichen Schritt der "Portauflösung" beherrschen bzw. durchführen, was auch heute noch nicht so häufig der Fall ist. Bei SIP-Clients hat sich das aber z.B. mittlerweile durchgesetzt, weil die Carrier entsprechende Standards gesetzt haben und diese auch verwenden.

 

[frank_m24]

Diagnose -> Sicherheit zeigt z.B. für Port 80 "Zugriff auf die FRITZ!Box Oberfläche (HTTP)" obwohl dieser eigentlich nach "interneRessource:8080" zeigen sollte.

Da steht doch das Problem. Der Port ist in Benutzung, dann kann man ihn nicht noch mal freigeben.

Ansonsten kann man natürlich 2 externe Ports auf den gleichen Zielport leiten, kein Problem. Aber bei Port 443 und Port 80 macht das keinen Sinn, denn Anwendungen erwarten hinter Port 443 eine verschlüsselte Verbindung. Wenn man von außen auf Port 80 oder 443 zugreift, dann wird der Zugriff auf einen dieser Ports in 9 von 10 Fällen scheitern - je nachdem, ob da hinter ein HTTP oder ein HTTPS Service wartet, vor allem von Geräten, wo man das Protokoll in der URL nicht angeben kann.

 

[PeterPawn]

dann wird der Zugriff auf einen dieser Ports in 9 von 10 Fällen scheitern

Dann ist das hier ein Beispiel für den zehnten: https://datatracker.ietf.org/doc/html/rfc2817 - eben ein Beispiel dafür, daß auch bei "spezifikationsgemäßem Gebrauch" von (Standard-)Ports nicht immer auf Anhieb (von außen) zu erkennen ist, ob die Daten in der Verbindung verschlüsselt übertragen werden oder nicht.

Und die auf einem Port "lauschende" Software kann natürlich (auch ohne späteres "Umschalten" wie im o.g. Beispiel) schon am Beginn anhand der gesendeten Daten entscheiden, ob der Client eine TLS-Verbindung erwartet oder nicht: https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2

When a client first connects to a server, it is REQUIRED to send the ClientHello as its first TLS message.

Es gibt auch Beispiele für Software, die das auf diesem Weg erkennt und entsprechend behandelt, z.B. dieser Multiplexer: https://www.rutschle.net/tech/sslh/README.html

---

wo man das Protokoll in der URL nicht angeben kann

Ich würde (deutlicher) von "wo man das Protokoll im Gerät in der URL nicht eintragen bzw. konfigurieren kann" schreiben ... denn ansonsten leitet sich aus der Angabe des Schemas in einer URI ja genau die (Standard-)Portnummer ab: https://de.wikipedia.org/wiki/Uniform_Resource_Identifier#Schema_(Scheme) - und wie man oben sehen kann, sagt dieser "Standard-Port" auch nicht immer etwas über die tatsächlich übertragenen Daten aus.

Aber es gab (oder gibt eventuell immer noch) auch im FRITZ!OS mind. ein Beispiel, wo durch die Angabe einer Portnummer implizit auch das Protokoll umgeschaltet wurde ... das war bei den diversen Definitionen von DynDNS-Anbietern der Fall, die bis zu einer der jüngeren FRITZ!OS-Versionen noch unterstützt (bzw. automatisch eingebaut) wurden. Dort gab es auch keine Möglichkeit, für einen DynDNS-Anbieter Updates per HTTPS explizit zu konfigurieren (außer eben beim Anbieter "Benutzerdefiniert") und ich habe erst relativ spät realisiert, daß bei der Angabe der Portnummer 443 in der (nicht per GUI änderbaren) Update-URL auch tatsächlich HTTPS benutzt wurde.

 

[Rolf Grisu]

Aus RFC 6887:

...

Es freut mich, dass das Thema offensichtlich doch nicht so trivial ist wie eingangs vermutet. Vielen Dank für die aufschlussreiche und hochwertige Erklärung.