Wer kann mir Exposed-Host erklären?

Ihr macht mir Sachen. Selbst nie probiert. Warum nicht mal selbst ausprobieren? Abkürzungen ohne Definition. Was ist EP … Egress-Port? Egal …
er hat den Browser aufgemacht und eine Verbindung auf den Ursprünglichen QuellPort als neuen Zielport initiert. (Das kann er ja auch z.B. auf dem ursprünglichem Zielhost). Das bedeut aber, dass das neue Paket einen neuen Quellport hat und damit eine neue Verbindung ist.
Genau so bin ich (unter anderem) vorgegangen.

Was mich eigentlich stört: Viele VoIP/SIP-Clients nehmen bei UDP (manche auch bei TCP) als Quell-Port 5060. Teilweise kann man das denen gar nicht austreiben. Ich habe also auf einem meiner Geräte im Heimnetz ein VoIP/SIP-Client gestartet. Parallel habe ich einen VoIP/SIP-Server für SIP-URI-Dialling; an dem bin ich gar nicht unbedingt angemeldet. Das ist gleichzeitig ein Honey-Pot und daher Exposed-Host.

Dadurch, durch das Öffnen eines dieser VoIP/SIP-Clients, habe ich mir den Port 5060 auf dem Exposed-Host gesperrt. Und zwar für den ganzen NAT-Timeout. Genau deswegen, weil die FRITZ!Box ausgehend – nicht immer – (k)ein Port-Remapping macht.

Das allein empfinde ich schon als einen kleinen Hammer. Workaround: Parallel zum Exposed-Host auch Port-Freigaben anlegen. Dadurch macht die FRITZ!Box jetzt immer schön Port-Remapping (ab Port 61000 aufwärts) für diese Ports. Das war sozusagen Frage 1, ob Ihr diesen Workaround schon kanntet.

Was ich überhaupt nicht verstehe, warum dieses erkannte Muster nicht immer klappt; Beispiele siehe vorher. Da das Verhalten keiner kennt, hilft nur wundern oder selbst mal probieren. t_bone, ich bin Dir sehr dankbar, dass Du meine Beobachtungen versuchst zu bestätigen, was in der Hauptfrage ja bereits gelungen ist – soweit ich das jetzt verstanden habe.
 
Zuletzt bearbeitet:
Hi PeterPawn,

Das lese ich in #1 überhaupt nicht. Er schreibt gar nichts von einem Browser, sondern führt zweimal sogar explizit den Port 5060 an, der i.d.R. ja für SIP genutzt wird (da dann auch sowohl mit UDP als auch TCP, was die Unterscheidung bei weiteren Überlegungen erforderlich macht) und für den er beschreibt, daß eingehende Verbindungen mit diesem Zielport mal bei seinem "exposed host" ankommen und mal nicht (weil eine ausgehende Verbindung diesen Port i.V.m. der öffentlichen IPv4-Adresse verwendet) und daß er darin kein wirkliches System erkennen kann - was zur Suche/Frage nach ähnlichen Erfahrungen bei anderen führt.

wie von sonykatze schon geschrieben hat er es genauso probiert. Das UDP/TCP da einen Unterschied machen sollte ist nicht nicht richtig. Warum erläutere ich noch.

Bei Deinen eigenen Experimenten hast Du dann halt auch nur - wenn ich das alles richtig verstanden habe - mit TCP-Verbindungen hantiert (SSH und HTTP wären jedenfalls üblicherweise solche) und das Verhalten mit UDP-Paketen gar nicht weiter betrachtet. Auch vermisse ich die Aussagen, was mit den Paketen jeweils passiert, wenn Du nur schreibst, die Verbindung taucht nicht im Log des "exposed host" auf. Gibt es denn nun die von Dir vermuteten/erwarteten ICMP-Pakete bei "nicht zustellbar" oder geht das Paket tatsächlich sogar an den Client, der die Connection in der FRITZ!Box-Firewall freigeschaltet hatte? Macht es einen Unterschied, ob ein einkommendes Paket jetzt das SYN-Flag gesetzt hat oder nicht?

Stimmt, ich habe den Versuchsaufbau vereinfacht. UDP ist an dieser Stelle erstmal nicht relevant, ich erläutere warum. Was mit den Paketen passiert ist, ist Mir letzendlich egal. Wichtig ist, dass das Paket nicht am exposed Host gelandet ist. Wenn das Paket an den Client gehen würde, wäre das ein grober Bug und ein Verstoß gegen sämtliche Routingregeln.
Auch das SYN-FLAG sollte an dieser Stelle egal sein, ich erläutere warum. :)
Solange die beiden EP einer Verbindung in einem Paket "passen" und es "passieren" darf, wird es halt irgendwie weiter verarbeitet.

Diese EP sind dann die von Dir und auch von mir in #14 schon erwähnten Angaben aus Quell-Adresse/-Port und Ziel-Adresse/-Port - und auch nur die stehen in einem Paket und auch nur die können daher zur "Einordnung" eines Pakets herangezogen werden und da interessiert es mich dann wiederum nicht, was das NAT lt. #15 sich da noch "merkt" für eine ausgehende Verbindung und ob das jetzt ein Quadrupel oder ein Quintupel sein sollte. Bei der PPE sind das dann eben nicht nur 4, 5 oder 6 "Merkmale", die in so einem Eintrag verwaltet werden, weil auch das Umschreiben der L2-Adressen ja gleich mitgemacht wird (ebenso das "Zählen" von Paketen) und nicht - wie bei "normalem NAT" im Linux-Kernel - erst nachträglich per ARP erledigt wird, wenn das umgeschriebene Paket wieder ins Routing gesteckt wird.

Bei einem UDP-Paket kann die Firewall in der FRITZ!Box (und auch die PPE) bei identischen EPs nicht erkennen, ob ein einkommendes Paket zu der vorhandenen "Verbindung" gehört

Und an dieser Stelle, mein Lieber (ich hoffe Du nimmst Mir das nicht krum) bist Du auf dem Holzweg.
Kurz als Begriffsklärung: EP meint Endpunkte, also die Kombination aus Port und IP-Adresse. Davon gibt es in einer Verbindung 2. Auch für UDP gilt im Rahmen dieses Posts, dass die Kombination aus den beiden EP (SourceIP+SourcePort und ZielIP+SourcePort) als Synonym Verbindung verwendet wird, obwohl Du richtig schriebst, dass das an dieser Stelle eigentlich nicht passt (es heißt ja deswegen auch Datagramm). Für unser Problem ist das aber erstmal egal. Der Netzwerk-Stack unterscheidet Verbindungen nämlich nur anhand dieser 2 EP, unabhängig davon ob Du nun ein UDP-Datagramm hast oder einen TCP-Stream. Die Verbindung wird über SourceIP+SourcePort und ZielIP+SourcePort definiert. ich glaube da sind wir uns einig.

Bleiben wir jetzt bei meinem Experiment. Ich habe eine SSH-Verbindung vom Client zum Server aufgebaut. Diese definiert sich über
interneIP:35106 zu ServerIP:22. Das wird auf der Fritzbox zu FritzboxIP:35106 zu ServerIP:22
Nehmnen wir an das diese Verbindung gehalten wird.
Wenn ich jetzt auf dem Server mit telnet eine Verbindung zur Fritzbox mit Zielport 35106 aufbaue ist das eine NEUE Verbindung, da der Quell-EP neu ist. telnet macht eine neue Verbindung mit einem eigenen QuellPort auf.
ServerIP:44321 zu Fritzbox:35106
Diese Verbindung hat nichts mit der ursprünglichen Verbindung zu tun. Nur weil ein EP der selbe ist, ist nicht die Verbindung die selbe.
Das gleiche würde passieren wenn ich jetzt netcat für UDP verwende. Auch eine UDP-"Verbindung" (ein Datagramm) definiert sich über BEIDE EP. Es ist also egal ob TCP oder UDP, allerdings habe ich das Verhalten nur für TCP nachgestellt.

Wenn jetzt ein exposed Host definiert ist, würde ich erwarten das diese neue Verbindung an diesen weitergeleitet wird. Dabei könnte die Fritzbox natürlich kontrollieren welchen Status die Verbindung hat (SYN, aufgebaut u.s.w.) das ist für die Weiterleitung aber eigentlich unerheblich. Wie die Fritzbox dabei mit den SYN Paketen umgeht ist grundsätzlich egal. Sie kann natürlich den Verbindungsstatus prüfen und dem Netzwerkstack des anderen Gerätes die Arbeit abnehmen, aber nur wenn sich innerhalb einer bestehenden Verbindung da etwas ändert ist das von Belang. Und das über telnet eine NEUE Verbindung aufbebaut wird, hatten wir ja schon. Aus diesem Grund sind die FLAGS auch erstmal Wurst.

Wenn jetzt die telnet-Verbindung welche ich vom Server aufgebaut habe (die ja neu ist), zum ursprünglichen Client weitergeleitet werden würde, hätten "wir" ein größeres Problem mit der Sessiontable.

Aber selbst wenn das FRITZ!OS dieses Paket tatsächlich "verschwinden" läßt ... welche Alternativen hätte es denn? Wenn es dieses Paket passieren läßt zum "exposed host", kann es in folgenden Paketen gar nicht mehr erkennen, ob die nun für den "exposed host" oder für den bereits bestehenden Tunnel gedacht sind - denn den nachfolgenden Paketen fehlt dann das SYN-Flag und alle anderen Schutzmaßnahmen in irgendwelchen Protokollen gegen "spoofing" (wie die Sequenznummern auf L4), sind Sache des jeweiligen Protokoll-Stacks auf dem Server und dem Client und haben mit der Firewall im FRITZ!OS (und mit der PPE am Ende) nichts zu tun. Diese führt Buch über die (IPv4-)Verbindungen und nicht über die Inhalte der übermittelten Pakete.
Da diese Verbindung aber nicht für die Fritzbox sondern nur über die Fritzbox läuft, ist das im einfachsten Fall egal. Die FLAGS dienen nicht der Erkennung der Zugehörigkeit zu einer Verbindung sondern die Prüfung dient, wie Du richtig schreibst dem Schutz der Verbindung. Die Fritzbox erkennt (sollte Sie zumindest nicht) die Verbindung nicht anhand der FLAGS, sondern anhand der Kombination der beiden EP. Die FLAGS dienen der Erkennung des Status der Verbindung.

Nochmal: Eine TCP Verbindung definiert sich ausschließlich über die beiden EP. Nicht über die FLAGS, diese dienen nur der Erkennung und der Festlegung des Status der TCP-Verbindung.

Die Frage, was "sinnvoll begründbar" ist im Kontext einer Portfreigabe, eines "exposed host" oder sogar einer richtigen demilitarisierten Zone (so ein "exposed host" wird ja oft auch als Pseudo-DMZ gewertet), kann man auch nicht wirklich - unparteiisch - beantworten, denn es gibt (afaik) dafür gar keine exakten Definitionen und so versteht jeder (Kunde und auch jeder Hersteller) darunter ggf. etwas Abweichendes und die Implementierung eines Herstellers wird halt immer auf seinen Vorstellungen und Möglichkeiten basieren und denen muß man sich dann eben (als Kunde) anpassen.
Da sind wir glaub ich, beisammen. Unabhängig von der Sinnhaftigkeit einer DMZ hinter EINER öffentlichen IP.

Mit der Lösung, daß eine eingerichtete Portfreigabe einen solchen Port dann "reserviert" und damit dafür sorgt, daß er für ausgehende Verbindungen nicht länger verwendet wird, hat man da in meinen Augen schon das Maximum am Flexibilität erreicht, was mit dem - doch sehr auf einfache Bedienbarkeit getrimmten - Interface des FRITZ!OS beim "normalen Benutzer" benötigt würde.

Letztlich läuft das hier im Thread ja gar nicht auf ein "geht nicht" hinaus ... es fehl(t)en nur die Ansätze zum Verständnis des Ganzen und daraus resultierte dann wohl die Suche nach irgendwelchen Einstellungen dafür (#1, letzter Satz), die es m.W. so gar nicht gibt, weil sich das Verhalten an dieser Stelle aus dem dynamischen Verlauf der "Verbindungen" in der FRITZ!OS-Firewall ergibt.
Gerade in Bezug auf SIP und andere Protokolle, welche den selben Quell und Zielport verwenden oder eigene zur usrprünglichen Verbindung zugehörige TCP-Streams aufmachen, stimme ich Dir zu.


Letztlich läuft das hier im Thread ja gar nicht auf ein "geht nicht" hinaus ... es fehl(t)en nur die Ansätze zum Verständnis des Ganzen und daraus resultierte dann wohl die Suche nach irgendwelchen Einstellungen dafür (#1, letzter Satz), die es m.W. so gar nicht gibt, weil sich das Verhalten an dieser Stelle aus dem dynamischen Verlauf der "Verbindungen" in der FRITZ!OS-Firewall ergibt.
Jup, aber interessant ist es trotzdem. :)


Dadurch, durch das Öffnen eines dieser VoIP/SIP-Clients, habe ich mir den Port 5060 auf dem Exposed-Host gesperrt. Und zwar für den ganzen NAT-Timeout. Genau deswegen, weil die FRITZ!Box ausgehend – nicht immer – (k)ein Port-Remapping macht.
Mit SIP ist es eh spannend, da auch die Fritz in der Regel VoIP macht und damit den SIP-Port geöffnet hat. Diesen kannst Du ohne weiteres sowieso nicht an den exposed Host weiterleiten außer Du deaktivierst SIP an der Fritz komplett.


Braucht der SIP-Server nicht eigentlich auch eine direkt ereichbare IP? Hinter NAT sollte das eh nicht 100% funktionieren.

Was mich eigentlich stört: Viele VoIP/SIP-Clients nehmen bei UDP (manche auch bei TCP) als Quell-Port 5060.
Das machen fast alle (gehört zum Verbindungsaufbau) und dürfte einer der Gründe sein warum die Fritzbox so NAT macht wie sie es macht.


Gruß
 
Zuletzt bearbeitet:
Abkürzungen ohne Definition. Was ist EP
Hast Du es tatsächlich nicht gefunden? Das ist nämlich (und zwar vor der Benutzung von "EP" als Abkürzung) in #14 im zweiten Absatz schon "erklärt" von mir. Oder es ist doch eine Franchise-Kette für den Vertrieb von Elektro- und Elektronik-Produkten ... wer weiß das schon so genau. Eine weitere Alternative wäre vielleicht "Exo-Planeten" - wobei das dann vermutlich schon wieder deutlich OT wäre.

=========================================================================

wie von sonykatze schon geschrieben hat er es genauso probiert.
Wo steht das in #1? Davon ist frühestens in #7 nach vielem Hin und Her bei der Beschreibung eines weiteren Tests die Rede und auch das ist ja nur die Beschreibung eines etwas komplizierteren Verfahrens, auf einem anderen Gerät eine TCP-Verbindung zu starten und dabei zu schauen, wo das SYN-Paket nun bleibt, weil das eben nach seinen Beobachtungen nicht da ankommt, wo er es gerne hätte.

Wenn das von einem anderen Host kommt, als von dem im ausgehenden Tunnel adressierten und dann nicht beim "exposed host" ankommt, ist das sicherlich ein Fehler - da braucht man gar nicht weiter zu diskutieren, das deckt sich auch mit meiner eigenen "Erwartungshaltung". Das war aber gar nicht die Frage (in #1) ... sondern die lautete, wie dieses - aus mancher Sicht wohl nicht nachvollziehbare - Verhalten zustande kommen könnte und wo man da irgendetwas einstellen könnte. Und auch wenn ich hier dann selbst von einem "Fehler" spreche/schreibe, ist das absolut meine subjektive Einschätzung ... denn mangels passender Definition ist das dabei zu "erwartende Verhalten" eines Edge-Routers ja gar nicht wirklich festgelegt und auch ein (unterstellter) Standpunkt von AVM, daß dieser Port dann eben für die gesamte Dauer der Existenz der "ausgehenden Verbindung" für jedes eingehende Paket an einen anderen Host (wozu dann auch der "exposed host" zählen würde) "gesperrt" würde, wäre ja nicht per se "falsch" - sondern eben immer noch Ansichtssache bzw. abhängig von der eigenen Erwartungshaltung, die aber sicherlich auch auf irgendwelchen Erfahrungen (ggf. mit Geräten eines anderen Herstellers) basiert und ja wohl kaum schon bei der Geburt als "Prägung" vorhanden war.

Nur weil ein EP der selbe ist, ist nicht die Verbindung die selbe.
Ich verstehe überhaupt nicht, warum Du mir jetzt - in anderen Worten - genau das noch einmal erklären willst, was ich zuvor bereits selbst geschrieben habe. Wenn es sich bei der eingehenden Verbindung eben um unterschiedliche EP handelt (dazu reicht es, wenn eine der vier Angaben abweicht), dann SOLLTE das beim "exposed host" aufschlagen, weil es ja gerade nicht auf die ausgehende Verbindung paßt und damit auch keine Antwort innerhalb dieser Verbindung sein kann. Genau das ist aber bei den 1&1-Telefonie-Servern auch der Fall, wenn ich den letzten Absatz in #1 nicht vollkommen mißverstanden habe - die erreichen die öffentliche IP-Adresse der Box auch dann noch auf irgendeinem Port (vermutlich ja auch 5060), wenn von dort bereits eine Verbindung zu irgendeinem anderen Server aufgebaut wurde.

All das, was Du da sonst noch zum "Interesse" des Routers an den vorbeiziehenden Paketen schreibst, ist sicherlich schön und richtig ... gilt aber eben eher für Geräte, bei denen keine Hardware-Beschleunigung vorhanden ist und das alles "im Kernel" bzw. im Connection-Tracking (CT) des Kernels ablaufen kann bzw. muß (und bei CT "interessiert" sich auch der Linux-Kernel dann plötzlich doch wieder für die Flags, weil er dann auch seine "trackings" abräumen muß/kann, wenn die TCP-Verbindung erledigt ist). BTW: Falls sich jemand hier fragt, warum ich immer von "Kernel" schreibe, obwohl doch ein guter Teil dieser Funktionalitäten bei vielen Distributionen in nachladbaren Modulen steckt (z.B. im "nf_conntrack") ... das sind alles Bestandteile des Kernels in diesem Falle, nur daß sie halt nicht statisch mit diesem gelinkt sind und daher erst dynamisch zur Laufzeit nachgeladen werden können/müssen.

Das ist aber bei einer (modernen) FRITZ!Box mit entsprechendem SoC einigermaßen anders (und bei anderen Routern, die auf diesen SoC basieren, ebenfalls, wenn sie die Patches von Lantiq (oder wie auch immer die gerade heißen mögen) verwenden) - hier besteht nämlich bei einer ausgehenden TCP-Verbindung zusätzlich noch die Aufgabe, die Protocol Processor Engine (PPE) so zu programmieren, daß sie die Pakete durch direkte Manipulationen an ihren Header-Strukturen so umformt, daß diese - und zwar ohne weitere Zuhilfenahme der CPU, bis sich der Status einer Verbindung wieder ändert - direkt weiter an den Client im LAN gesendet werden können.

Und genau deshalb "interessiert" sich das FRITZ!OS auch dafür, wie der genaue Status so einer Verbindung aussieht - dabei erkennt es dann "neue TCP-Verbindungen" eben genau an den gesetzten SYN-Flags in den Paketen und programmiert die PPE auch so, daß alle weiteren Pakete innerhalb dieser Verbindung (wenn sie denn erst mal durch den 3-Way-Handshake erfolgreich aufgebaut wurde) ohne Inanspruchnahme der CPU weitergeleitet werden.

Und aus genau diesem Grund, daß eine TCP-Verbindung auch vom Router als "beendet" erkannt und dann zeitnah abgeräumt werden kann, macht es auch Sinn, dabei UDP- und TCP-Verbindungen getrennt zu betrachten. Während bei einer ausgehenden TCP-Verbindung der Port nach deren Beendigung auch umgehend wieder "frei" sein sollte (sofern die ganze Geschichte korrekt funktioniert und das tat sie zumindest in früheren FRITZ!OS-Versionen, als ich solche Dinge selbst untersucht habe, tatsächlich), braucht es bei UDP-Verbindungen eben immer das Timeout für diesen Tunnel, also eine gewisse Zeitspanne ohne weiteren Traffic innerhalb dieses Tunnels (das kann man sich auch wieder über das procfs für den AVM-PA ansehen), bevor der "abgeräumt" werden kann.

Erst dann, wenn da wieder (TCP-)Pakete mit gesetzten Flags auftauchen (üblicherweise wären das dann RST und FIN, weil PSH sicherlich auch den Router nicht interessiert, da es keinen Einfluß auch den weiteren Status der Verbindung hat), werden diese zum Client weitergereicht und (i.d.R. zusätzlich, soweit ich weiß bzw. das bisher gesehen hatte) an die CPU übergeben, die dann ihrerseits nach dem kompletten Abbau einer TCP-Verbindung (die ist nun mal nach 2x FIN + ACK am Ende) auch den Eintrag in den PPE-Tabellen entfernen sollte, da ansonsten eben wieder "unsolicited traffic" durch die Firewall käme, wenn der Eintrag weiterhin bestünde und die Daten direkt von der PPE weitergeleitet werden (davon kriegt die CPU dann nicht mal etwas mit, außer ggf. über steigende Zählerstände) - deshalb MUSS die CPU diese Verbindungen auch "überwachen" und die Einträge in der PPE wieder abräumen.

Sollte die PPE dieses "Bereinigen" tatsächlich alleine können (ich weiß es nicht), bliebe ja immer noch die Aufgabe, die innerhalb dieser Verbindung aufgelaufenen "Statistikdaten" (wieviel wurde gesendet, wieviel wurde empfangen) irgendwohin zu sichern - daher würde ich wieder wetten, daß ein "Abräumen" von PPE-Einträgen explizit durch die CPU erfolgt (nur über den "Trigger" dafür könnte man sicherlich diskutieren, weil das ja auch ein von der PPE selbst erkanntes Ende einer TCP-Verbindung sein könnte).

Letztlich landet dann alles das, was von keinem anderen Eintrag in der PPE verarbeitet werden konnte, entweder beim Abdecker und wird von der PPE direkt abgelehnt oder es geht eben an den "exposed host" - wobei es tatsächlich ziemlich schwierig ist, genau auszumachen, was davon dann über die CPU geroutet wird und was nicht (über die CPU ist halt langsamer, auch für die Daten zum "exposed host", der ansonsten ja - quasi als "catch all"-Target - auch direkt angeschrieben werden könnte).

Der einfachste Weg, sich da einen Überblick über den "CPU-Traffic" zu verschaffen (denn ein guter Teil ist eben "closed source" im "kdsldmod.ko" bzw. im Userspace-Daemon "dsld" dazu), ist es tatsächlich, auf der Box selbst einen Paketmitschnitt zu machen ... aber eben nicht mit den Mitteln des FRITZ!OS, weil das dazu ja wieder die Konfiguration der PPE verändert. Dazu braucht man nur ein einzelnes Capture-Programm, z.B. "tcpdump" und mit dem kann man dann das mitschneiden, was "im Normalfall" auch über die CPU läuft. Daß das deutlich weniger ist als der gesamte Traffic, kann man auch hier in diversen Threads (von früher, als das noch nicht so richtig bekannt war) nachlesen - da wunderten sich dann nämlich die Leute, warum in ihren Mitschnitten nur ein Bruchteil der Pakete enthalten war.

Die Tatsache, daß das alles tatsächlich nicht so einfach nachzustellen ist mit einer FRITZ!Box (angefangen bei einem Image mit Shell-Zugang und den notwendigen Tools auf der Box selbst, um das sauber "beobachten" zu können), ist es auch, die mich davon abhält, das jedesmal aufs Neue selbst zu testen - mir reicht es auch, wenn ich die "größeren Zusammenhänge" halbwegs durchschauen kann und wenn meine Erklärungsversuche(!) jemandem nicht passen, muß er sie ja nicht lesen. Wenn sie jemandem nicht einleuchtend erscheinen, diskutiere ich das gerne aus ... wobei ich bei Dir einfach auch keinen Ansatzpunkt für irgendeinen Unterschied in der "Interpretation" sehe - mal abgesehen von Deiner Ansicht, daß es für die Verwaltung von Verbindungen im FRITZ!OS (und in der Folge dann auch in der PPE) total egal wäre, ob es sich um eine TCP- oder eine UDP-Verbindung handelt.

Wenn man sich einen (ungefähren) Eindruck von den Fähigkeiten der PPE verschaffen will, muß man sich - mangels frei zugänglicher Dokumentationen - halt in den Netzwerk-Code des Kernel vertiefen und zwar in den mit den Lantiq-Patches (weil erst da dann die PPE genutzt wird). Ein Teil davon findet sich auch in den AVM-Quellen (unterhalb von drivers/net/avm_cpmac), wobei bei AVM eben große Teile in deren eigenem WAN-Stack stecken und der besteht (nicht ganz scharf "abgegrenzt") in erster Linie aus dem bereits erwähnten "Loadable Kernel Module" (LKM) "kdsldmod.ko" und aus dem - ebenfalls bereits erwähnten - Userspace-Daemon "dsld" für die Konfiguration und die Kommunikation mit dem Rest des Systems.

Daß dabei auch der "Zustand" von Verbindungen überwacht wird, sieht man dann spätestens an entsprechenden Funktionsnamen/-beschreibungen, wie z.B. "ppa_is_tcp_established":
Code:
1318  /*! \brief   Returns true if tcp connection state is established for a PPA session.
1319    \param[in] p_session  Pointer to ppa connection tracking session data structure.
1320    \return   This function returns the one of the following values: \n
1321                       - IFX_TRUE if TCP connection state is established after SYN from server. \n
1322                       - IFX_FALSE if TCP connection is not established completely. \n
1323    \note
1324 */
1325  int32_t ppa_is_tcp_established(PPA_SESSION *p_session);
, wobei diese Funktion nun gerade wieder ein Beispiel ist, wo AVM den Lantiq-Code tatsächlich durch eigenen ersetzt (denn bei AVM wird diese Lantiq-Funktion dann "ausgeblendet").

Wobei man auch hier wieder sauber zwischen den verschiedenen SoC unterscheiden muß (das oben ist vom VR9) - selbst wenn die Prinzipien bei Lantiq-SoCs halt immer dieselben sind (bzw. neue "Spezialeinheiten" dazukommen), so ist das doch immer vom SoC abhängig und auf anderen Plattformen (z.B. Broadcom-SoCs oder auch die Qualcomm-Linien) werden zwar auch dieselben Prinzipien verwendet, wenn irgendetwas "beschleunigt" werden soll oder muß, aber die Einzelheiten unterscheiden sich dann schon deutlich und das dürfte auch einer der Hauptgründe sein, warum bei AVM vieles erst mal ohne die jeweiligen spezialisierten Hardware-Einheiten umgesetzt wird (quasi basierend auf dem kleinsten gemeinsamen Nenner) und die dann erst nach und nach wirklich "ausgenutzt" werden in späteren OS-Versionen.
 
Hast Du es tatsächlich nicht gefunden? Das ist nämlich (und zwar vor der Benutzung von "EP" als Abkürzung) in #14 im zweiten Absatz schon "erklärt" von mir. Oder es ist doch eine Franchise-Kette für den Vertrieb von Elektro- und Elektronik-Produkten ... wer weiß das schon so genau. Eine weitere Alternative wäre vielleicht "Exo-Planeten" - wobei das dann vermutlich schon wieder deutlich OT wäre.

Ach komm...

Wenn das von einem anderen Host kommt, als von dem im ausgehenden Tunnel adressierten und dann nicht beim "exposed host" ankommt, ist das sicherlich ein Fehler - da braucht man gar nicht weiter zu diskutieren, das deckt sich auch mit meiner eigenen "Erwartungshaltung". Das war aber gar nicht die Frage (in #1) ... sondern die lautete, wie dieses - aus mancher Sicht wohl nicht nachvollziehbare - Verhalten zustande kommen könnte und wo man da irgendetwas einstellen könnte. Und auch wenn ich hier dann selbst von einem "Fehler" spreche/schreibe, ist das absolut meine subjektive Einschätzung ... denn mangels passender Definition ist das dabei zu "erwartende Verhalten" eines Edge-Routers ja gar nicht wirklich festgelegt und auch ein (unterstellter) Standpunkt von AVM, daß dieser Port dann eben für die gesamte Dauer der Existenz der "ausgehenden Verbindung" für jedes eingehende Paket an einen anderen Host (wozu dann auch der "exposed host" zählen würde) "gesperrt" würde, wäre ja nicht per se "falsch"

Ok, für mich war eher die Frage, ist das ein Fehler und lässt er sich nachstellen. Tatsächlich kann ich nur mutmaßen, ob dieses Verhalten so programmiert oder nicht so beabsichtigt ist. Und das der QuellPort der einen Verbindung auch als Zielport für eine neue Verbindung "blockiert" ist, ist aus meiner Sicht ein Fehler.

Ich verstehe überhaupt nicht, warum Du mir jetzt - in anderen Worten - genau das noch einmal erklären willst, was ich zuvor bereits selbst geschrieben habe. Wenn es sich bei der eingehenden Verbindung eben um unterschiedliche EP handelt (dazu reicht es, wenn eine der vier Angaben abweicht), dann SOLLTE das beim "exposed host" aufschlagen, weil es ja gerade nicht auf die ausgehende Verbindung paßt und damit auch keine Antwort innerhalb dieser Verbindung sein kann. Genau das ist aber bei den 1&1-Telefonie-Servern auch der Fall, wenn ich den letzten Absatz in #1 nicht vollkommen mißverstanden habe - die erreichen die öffentliche IP-Adresse der Box auch dann noch auf irgendeinem Port (vermutlich ja auch 5060), wenn von dort bereits eine Verbindung zu irgendeinem anderen Server aufgebaut wurde.

Für mich las es sich so als wenn Du davon ausgehst dass es die selben EP sind. Die neuen EP schlagen, wie Du schön an meinem Experiment sehen kannst, nicht auf dem exposed Host auf. Der letzte Abschnitt im ursprünglichen Startpost ist für mich missverständlich, da Angaben zu den konkreten ZielIP+Ports und der Konfigurtation der Fritzbox fehlen. (Wenn die jetzt auch für 1&1 Telefonie konfiguriert ist, müssen die Ports angepasst werden) Aber das ist ein anderes Thema.


All das, was Du da sonst noch zum "Interesse" des Routers an den vorbeiziehenden Paketen schreibst, ist sicherlich schön und richtig ... gilt aber eben eher für Geräte, bei denen keine Hardware-Beschleunigung vorhanden ist und das alles "im Kernel" bzw. im Connection-Tracking (CT) des Kernels ablaufen kann bzw. muß (und bei CT "interessiert" sich auch der Linux-Kernel dann plötzlich doch wieder für die Flags, weil er dann auch seine "trackings" abräumen muß/kann, wenn die TCP-Verbindung erledigt ist). BTW: Falls sich jemand hier fragt, warum ich immer von "Kernel" schreibe, obwohl doch ein guter Teil dieser Funktionalitäten bei vielen Distributionen in nachladbaren Modulen steckt (z.B. im "nf_conntrack") ... das sind alles Bestandteile des Kernels in diesem Falle, nur daß sie halt nicht statisch mit diesem gelinkt sind und daher erst dynamisch zur Laufzeit nachgeladen werden können/müssen. ..... Du schriebst noch weiteres zur Beschelunigung der Pakete

Du hast absolut Recht, aber :) vollkommen egal, ob die Fritzbox das jetzt in einem Schritt oder in 5 macht oder ob das für die Stafeful-Liste oder das NAT notwendig ist oder sie die Pakete über die Flags in Hardware oder Software macht.
Ich weiß, dass Du ein unheimlich tiefes Wissen über die Fritzbox hast und habe dankenswerterweise davon auch schon in einigen Situationen profitieren können, Aber letztendlich ist es für diese Betrachtung egal, wie die das hardwaretechnisch umgesetzt ist. ;-)

Und genau deshalb "interessiert" sich das FRITZ!OS auch dafür, wie der genaue Status so einer Verbindung aussieht - dabei erkennt es dann "neue TCP-Verbindungen" eben genau an den gesetzten SYN-Flags in den Paketen und programmiert die PPE auch so, daß alle weiteren Pakete innerhalb dieser Verbindung (wenn sie denn erst mal durch den 3-Way-Handshake erfolgreich aufgebaut wurde) ohne Inanspruchnahme der CPU weitergeleitet werden.

Und aus genau diesem Grund, daß eine TCP-Verbindung auch vom Router als "beendet" erkannt und dann zeitnah abgeräumt werden kann, macht es auch Sinn, dabei UDP- und TCP-Verbindungen getrennt zu betrachten. Während bei einer ausgehenden TCP-Verbindung der Port nach deren Beendigung auch umgehend wieder "frei" sein sollte (sofern die ganze Geschichte korrekt funktioniert und das tat sie zumindest in früheren FRITZ!OS-Versionen, als ich solche Dinge selbst untersucht habe, tatsächlich), braucht es bei UDP-Verbindungen eben immer das Timeout für diesen Tunnel, also eine gewisse Zeitspanne ohne weiteren Traffic innerhalb dieses Tunnels (das kann man sich auch wieder über das procfs für den AVM-PA ansehen), bevor der "abgeräumt" werden kann.

Absolut richtig.

Bei SIP kommt an dieser Stelle noch hinzu das die Telefone gleichzeitig Server und Client sind, die Fritzbox auch ein Telefon und ein Registrar (für das LAN) sein kann und über die UDP-Verbindung schon mal der eingehende Weg "freigemacht" wird.


@sonyKatze
ich konnte dein Problem aus dem Post 7 nachvollziehen und bei meiner 7490 mit der 7.12 tritt es auch auf.

Zu SIP ist das ganz aber komplizierter. Ist auf der Fritzbox auch VoIP eingerichtet? Dann bietet Sie den Port 5060 nach draußen auch an und Du kannst diesen Port nicht an den exposed Host weiterleiten. Sind an der Fritzbox die selben VoIP Server eingerichet wie auf den Clients?

Eine SIP-Verbindung funkltioniert wie folgt: Ein SIP-Endgerät (Endgerät1) (Telefon, Fritzbox) meldet sich mit bei einem SIP-Server an. Dieser beinhaltet heutzutage einen SIP-Registrar und einen SIP-Proxy. Dazu schicket es unter anderem seine SIP-URI mit. Diese besteht aus der öffentlichen IP-Adresse (diese muss das Endgerät wenn es nicht die Fritzbox ist, erst in Erfahrung bringen) mit einem SIP-Port und seiner Telefonnummer. Dieser SIP-Port ist außerdem der QuellPort der aufgebauten Verbindung. Das ist wichtig.

Wenn jetzt ein anderes (irgendwo angemeldetes) SIP-Endgerät (Endgerät2) das erste Endgerät erreichen möchte, fragt es sich durch seinen Registrar und deinen um deine SIP-URI zu erhalten. Es hat damit deine öffentliche IP-Adresse und deinen SIP-Port. Endgerät2 wird diese Verbidnung jetzt, da nicht sichergestellt ist dass Endgerät1 direkt erreichbar ist. über die SIP-Server versuchen. Dabei kommt, da das ganze UDP ist, die erste Verbindung von Endgerät1 zu seinem SIp-Server ins Spiel. Ein Gateway kann bei UDP (verbindungslos), wie auch @PeterPawn dargestellt hat nicht erkennen wie der Status der Verbindung ist. Es hat aber die ursprüngliche Verbindung Endgerät1 zu seinem SIp-Server noch als erlaubt in seiner Verbindungstabelle. Wenn der SIP-Server jetzt eine Verbindung in die andere Richting zu Endgerät1 aufbaut kann das Gateway das nicht unterscheiden und lässt die Verbindung zu und leitet diese zum Telefon weiter. (Die EP passen ja zur ursprünglichen Verbindung). Du bohrst sozusagen mit der ausgehenden ersten Verbindung einen Tunnel durch das Gateway.

Und wenn mehrere Clients jetzt auf 5060 lauschen wird es dann schon schwieriger. Wenn dann noch ein SIP-Server dazu kommt der auch auf dem Port hört.....
Ich weiß nicht, welchen SIP-Client Du im internen Netz verwendest. Bei den Gigaset kannst Du den "Listen Port für VoIP Verbindungen" verändern. Das Problem:
VoIP/SIP-Clients nutzen (viel zu oft) sowohl als Dst-Port als auc Src-Port 5060/udp
hättest Du damit gelöst

Gruß


Gruß
 
Zuletzt bearbeitet:
Leute, ich bin noch hier. Ihr müsst gar nicht darüber philosophieren, wie ihr mich zu interpretieren habt oder wer besser in Deutsch aufgepasst hat. Ihr könnt mich frisch von der Leber weg fragen. Wegen SIP: Diesem Thread hier ging jener voraus. Ich wollte es dort nicht anhängen. Telefonie auf der FRITZ!Box wird nicht genutzt. Port 5060 ist in beide Richtungen frei. Aber ich weiß auch, wie ich den verlegen könnte. Dank rport sehe ich auch den wirklich ausgehenden Port. Und ja, ich habe ein paar VoIP/SIP-Clients, die es mit 5060 als abgehenden Port nicht lassen können. Dank der expliziten Port-Freigabe zusätzlich zum Exposed-Host habe ich die jetzt im Griff. SIP war der Auslöser für den Thread hier.
Hast Du [die Ausschreibung der Abkürzung „EP“] tatsächlich nicht gefunden?
Nö.

Was ich stattdessen vermute habe, schrieb ich. Nochmal, es ist ein Quintuple aus Quell-Port, Quell-IP, Egress-Port, Ziel-Port und Ziel-IP. Gab es kein Re-Mapping ist der Egress-Port gleich dem Quell-Port. Bei TCP könnte sich die FRITZ!Box auch noch den Zustand merken. Schön. Damit könnte sie Sessions früher abräumen. Das ist etwas, was Plattformen wie DrayTek Vigor und Lancom LCOS auch machen, da gesondert einstellbar. Aber darum geht es hier (eigentlich) wirklich nicht, sondern um die aktuelle Blockade (und eben nicht deren Dauer).

Irgendwas muss die FRITZ!Box noch zusätzlich zu diesem Quintuple tun. Ansonsten würden nicht auf einmal einzelne Datenpakete dann doch auf dem Exposed-Host aufschlagen. Obwohl sich das Quintuple nicht geändert hat. Obwohl die Session noch nicht abgelaufen ist. Für mich sieht das nach einer verkappten Status-Maschine aus, die tatsächlich einen halben TCP-Stack implementiert – und dann doch komplett falsch programmiert ist. Anders kann ich mir das nicht erklären. Hätte sein können, dass ich was übersehen hatte. Dann hätte ich vielleicht auch das Grund-Konzept eines Exposed-Host in den falschen Hals bekommen. Scheint aber alles so zu sein, wie ich mir das denke. Also werde ich wohl am Montag ein Ticket eröffnen lassen. Der erste Teil meiner Beobachtung ist schon wild genug. Der Rest sind hoffentlich nur Folgefehler.
 
  • Like
Reaktionen: t_bone
Davon abgesehen, dass "exposed Host" für mich nicht so richtig zu einem Szenario passt, wo sich noch andere "NAT-Kunden" munter Ports öffnen, ist das Verhalten von AVMs Firmware nicht ganz unschlüssig. Wenn wir exposed Host als Portfreigabe mit dem Bereich Port 1 bis 65535 definieren, ist ja kein Platz mehr für die Umleitung auf einen anderen, mehr
BTW: Interessant, wie lange so AVM TCP/UDP-Ports offen hält.
Laut AVM:
TLDR:
löscht die FRITZ!Box automatisch alle TCP-Verbindungen nach 15 Minuten und alle UDP-Verbindungen nach 5 Minuten ohne Datenaustausch aus ihrer NAT-Tabelle ("NAT-Timeout"). Dadurch werden alle Ports, die von diesen Verbindungen verwendet wurden, geschlossen und die Internetverbindung der zugehörigen Anwendung getrennt.
https://avm.de/service/fritzbox/fri...h-die-Verbindung-zu-Gegenstellen-im-Internet/
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.