Ne. Wenn Digium Asterisk der Server ist, also der Telefonie-Anbieter, dann nutzt es on-default nicht die bestehende TCP-Verbindung sondern den Header Contact. Will man es anders, muss das der Telefonie-Anbieter explizit umschalten: rewrite_contact=yes. Lies Dir das Ticket durch. Bau es nach. Und Du wirst es sehen. Aber jenes Ticket betrifft ATO nur dann, wenn Telekom Deutschland auf 5061/tcp umschwenken würde. Oder anders formuliert, würde mich wundern, wenn ATO davon betroffen ist. Aber dazu bräuchten wir wieder ihn.
Hilfe für Grundeinstellung Asterisk/Telekom benötigt
- Ersteller Fredericderzweite
- Erstellt am
Mag sein. Dazu kann ich nichts sagen. Aber:
Hier geht es aus meiner Sicht nicht darum, dass Asterisk der VoIP-Provider ist. Asterisk ist der initiierende Client, der sich via Register beim VoIP All-IP-Server der Telekom anmeldet und damit die TCP-Verbindung aufbaut und hält. Davon reden wir hier. Wenn man im aktuell produktiven Asterisk/pjsip einen Register losschickt (oder Invite oder whatever), steht im Contact der falsche lokale Port drin (nämlich der listener-Port vom verwendeten transport) - egal ob mit oder ohne rewrite_contact=yes. Die Telekomserver hat das aber nie interessiert hier - die sind grundsätzlich immer innerhalb der bestehenden Verbindung geblieben, weil das via alias-Parameter auch so definiert wird. Die gehen scheinbar schlicht und ergreifend auf den "physischen" Port der Verbindung und interessieren sich nicht für die Infos im SIP-Packet (glücklicherweise). Sonst hätte das hier gar nie funktioniert. Erst seit diesem Patch (der noch nicht übernommen wurde bis dato) steht in Contact und Co der korrekte lokale Port drin. Das Interessante wäre jetzt, ob z.B. im Register im Via-Header der alias-Parameter mit drin ist oder nicht. Ebenso wie es interessant wäre, wie der Verkehr hinter dem letzten NAT zur Telekom aussieht (also nicht nur der Inhalt, sondern auch die relaen Ports und IP-Adressen). Es wäre auch interessant, ob mit dem genannten Patch die Probleme bereinigt wären. Fragen über Fragen ... .
Ja. Ist es auch nicht. Die Frage war/ist, ob die Telekom wirklich immer den TCP-Verbindung nimmt bzw. auf welchem TCP-Port bei ATO die INVITEs aufschlagen. Ich hatte lediglich „eingworfen“, dass eben nicht alle das so machen. Und die Telekom das vielleicht in diesem speziellen Fall auch nicht macht. Das kam auch nur daher, weil sich ATO in die Richtung verlaufen hat. Daher wäre wichtig zu wissen, auf welchem Port die INVITEs reinkommen. Kommen die auf dem dynamischen Port, von der registrierten IP, dann stimmt was mit der Firewall nicht. Kommen die auf dem dynamischen Port, von einer anderen IP, dass stimmt was mit dem Load-Balancing nicht. Kommen die auf dem statischen Port, dann wäre das ein Hammer. Dann müssten wir die Ursache suchen … dürfte dann aber auch die Firewall sein.
Dann steht immer noch nur der statische Port drin, aber nicht der dynamische. Aber ATO kann das gerne mal probieren.
Der Router, ein Draytek Vigor 2860 ermöglicht leider nur recht aufwendig Paket-Mitschnitte, weshalb ich die INVITES dort nicht direkt aufzeichnen kann, aber sobald ich einen OpenPort 5061 konfiguriere, kommen die INVITES an, ohne das sonst etwas am System verändert wird, und da keine PortRedirection oder ähnliches konfiguriert hast, heisst das, dass die Telekom auf 5061 antwortet, was ja auch sinn macht, da Asterisk ja diesen Port im VIA/Contact Header angibt, und auch der Quellport ist eben 5061.
Der Draytek-Support hat jetzt noch zwei Optionen angemerkt, die ich prüfen soll, dazu kam ich noch nicht - aber ich fürchte, dass das auch nicht zum Erfolg führen wird. Warum der Router die Verbindung offenbar situationsbedingt nicht öffnet weiss ich nicht. So wie ich es verstanden habe ist die Verbindung durch REGISTER bzw. OPTIONS geknüpft an Quell-IP+Quell-Port und Ziel-IP, und es gibt darüber hinaus keine Session-ID oder ähnliches, sodass es ein Problem sein könnte, dass die INVITES mit einer anderen Session-ID ankommen und deswegen die komplette Öffnung des Ports notwendig ist. Ich habe auch überlegt, ob der Router vielleicht nur Ports im dynamischen Bereich (also >10.000) dynamisch öffnet, womit 5061 natürlich nicht funktionieren würde, aber das hat mir der Support vom Hersteller, die meinen Paketmitschnitt auch zur Durchsicht bekommen haben, nicht mitgeteilt. Es bleibt daher ab zu warten, was beim Test mit den beiden Optionen heraus kommt.
Bezüglich des Timeouts und OPTIONS etc. sei angemerkt, dass ja dann die INVITES wenigstens unmittelbar nach dem ersten REGISTER durchgehen müssten, aber selbst das ist ja schon nicht möglich! Der Router behandelt offenbar die Antworten auf das REGISTER (es kommt ja eine Bestätigung der Telekom mit "OK" zurück, die auch am Aterisk ankommt) anders, als die INVITE-Pakete bei eingehenden Anrufen, warum ist mir wie gesagt, ein Rätsel.
Wieso denn 900s (15min)? bzw. 240 Sekunden wie Du weiter unten schreibst - wo hast Du diese Werte her? Ich meine, die Telekom erlaubt im Minimum 480 Sekunden (8min.) für die Expiry.
Dass das Problem mitunter an der Firewall liegen kann, habe ich ja schon eingehend gesagt - nur ist "macht dicht" nicht ganz richtig, weil es funktioniert ja sofort nach der Registrierung nicht, wie gesagt - also zutreffender würde "ist dicht" den Zustand besser beschreiben ;-)
Wie gesagt, Quellport ist 5061, der auch in den VIA/CONTACT Headern steht.
Die Weiterleitung der dyn. RTP-Ports sehe ich als relativ unproblematisch an, da hier ja auf Empfängerseite nichts permanent offen ist, aber da Asterisk ja IMMER auf dem PJSIP/SIP Port lauscht, finde ich genau das eben ein großes Sicherheitsrisiko, dass ich gern vermeiden möchte, wenn ich schon einen Asterisk habe, der eigentlich garnicht von der Aussenwelt erreichbar sein muss, weil er nur mit seinem Provider kommunizieren muss und alle Clients, so wie bei 95% unserer Kunden, im internen Netz/via VPN angebunden sind.
Zuletzt bearbeitet:
Problem ist, dass sich die Telekom nicht an die RFCs hält. So verwendet sie SIP-UPDATE obwohl der UAC gesagt hat „ich nix SIP-UPDATE können“. Und selbst wenn, irgendeine Kleinigkeit – wie wir an dem aktuellen Beispiel sehen – kann dazu führen, dass man zeitweise nicht erreichbar ist oder sonst was kaputt ist. ATO hat noch das „Glück“, dass er dauerhaft nicht erreichbar ist und es daher gleich gemerkt hat.
Du haben nicht verstanden. Und Du zeigt aus nicht, dass Du es verstehen willst.
Nicht chan_sip ist das tote Pferd sondern ganz Digium Asterisk. Sangoma kapiert nicht, dass das mit SDP so nicht weiter geht. Das war so vor 22 Jahren falsch. Und ist heute noch Falscher. FreeSWITCH hat sich wenigstens dem Thema SDP ein wenig angenommen. Daher ja auch die Abspaltung damals. Jetzt mit chan_pjsip hat sich Digium auch noch von uns Heimanwender wahnsinnig entfernt – und meiner Erfahrung nach komplett aus den Augen verloren.
Was deutsche Verhältnisse angeht, ist weder FreeSWITCH, FreePBX noch Asterisk besser. Daher ja auch der dringende Rat einen getesteten B2BUA dazwischenzuschalten. Dir kann jeden Tag irgendeine Kleinigkeit den Stecker ziehen – und Du merkst es nicht einmal. Das kann Dir auch bei einer FRITZ!Box passieren. Aber dann hat die Telekom Deutschland so viele Kunden-Anrufe, dass sich ganz schnell irgendwer bewegt (Telekom Deutschland, AVM, …). Wenn die Telekom Deutschland irgendwas ändert, bedeutet das für Dich, dass Du laufend testen müsstest, alle Anruf-Szenarien, alle Wege. Und wenn es dann passiert, dass Du dann hinterherrennen darfst. Wenn Du darauf Bock hast, gerne. Aber es ändert nichts daran, dass man das dazu schreiben sollte.
Du weißt was eine FRITZ!Box kostet? 5€ Wenn Du überhaupt diese Stabilität haben musst. Eine Box, wenn Problem, Recovery. Wenn Du selbst analyiseren willst, eine zweite Box. Die eh da stehen sollte, als Hardware-Ersatz.
Für Dich. Abgesehen davon, dass ich jene Stelle jetzt nicht kenne.
Ich kann jedem nur davon abraten, ein Asterisk mit einem unserer großen Netzbetreibern verheiraten zu wollen. FRITZ!Box dazwischen und schauen, ob das nicht reicht. Wenn nicht, helfen wir gerne in einer Kaufberatung, ob es nicht noch andere B2BUAs gibt, die für die jeweiligen Situation dann doch passen: bintec-elmeg, Lancom oder Zyxel Sphairon.
Was meinst Du mit Quellport? Den Port von Telekom Deutschland oder den Port Deines Digium Asterisk?
1. Wenn Du Port 5061 im DrayTek Vigor forwardest, siehst Du dann mittels Wireshark einen kompletten TLS-Handshake, also ein TLS-Client-Hello – den nicht Dein Asterisk sondern die Telekom Deutschland startet?
2. Wenn sich Dein Asterisk registrierst, stehen in der Antwort, im Header Contact, dann einer oder mehrere? Nicht das wir hier noch eine alte Registrierung parallel laufen haben.
Wäre echt Hammer, wenn die Telekom Deutschland auf Port 5061 eine TLS-Client-Connection aufmacht. Dann müsstest Du eine Bug-Bounty für ASTERISK-29190 starten. Wenn Dir das Preis-Limit zu hoch ist, häng Dich wenigstens an das Ticket und poste, dass Du betroffen bist.DrayTek kann man so verstellen, dass er die Ports im WAN ummapped. Das bedeutet, dass Du neben Quell- und Ziel-Port auch noch einen einen dritten Port – einen Egress-Port – hast. Aber das müsste alles egal sein. Selbst dessen SIP-ALG müsste egal sein, weil Du SIP-over-TLS verwendest. Selbst dessen NAT-TCP-Timeout müsste egal sein, weil DrayTek von Haus aus einen ganzen Tag erlaubt. Daher müssten wir herausbekommen, warum sich Dein Aufbau so anders verhält und somit inkompatibel zu Digium Asterisk ist. Andere Idee:
3. Kannst Du testweise von TLS auf auf SIP-over-TCP wechseln? Asterisk schickt auf einem dynamischen Port das Register raus. Bekommst Du dann auf jenem dynamischen Port Deine INVITEs oder auf dem statischen Port 5060/tcp? Schau bitte mal bei DrayTek Vigor → NAT → ALG, dass dort alles aus ist.
4. Wie lautet die Vertragsbezeichnung, der Name Deines Tarifs genau? Hast Du die Telekom Deutschland auch als DSL-Reseller? Ich meine nicht das Backbone, sondern denjenigen, der Dir DSL schaltet.
5. Hast Du noch ein anderes DSL-Modem oder Router. Dann könntest Du mal schauen, ob es überhaupt am DrayTek liegt. Kann mir zwar nicht (mehr) vorstellen, was das sein könnte, aber nur um das Problem einzukreisen.
Seltsam. Kenne nicht genau Dein Modell. Bei meinem (einfacheren) DrayTek Vigor ist diese Option unter „LAN → LAN Port Mirror → Mirrored port: WAN 1“ versteckt. So kann ich dann direkt mit einem Notebook auf den „Mirror port“ gehen und live mit Wireshark zuschauen. Geht das bei Dir nicht? Das bedeutet, wir sehen nicht genau, was WAN-seitig passiert. In dem Fall bitte unbedingt ein anderes DSL-Modem+Router gegentesten (siehe Rückfrage 5).
Asterisk sendet die Pakete von Port 5061 an die Telekom Port 5060 - so wie es im binding hinterlegt ist. Die Telekom sendet von Port 5060 an den Asterisk (bzw. Vigor) zurück an Port 5061
nein, aber TLS habe ich auch nicht konfiguriert.
Ich weiss nicht was du mit "einer oder mehrere" meinst, aber hier ist ein "OK" von der Telekom als antwort auf in REGISTER request:
Der ALG ist aus. Der Draytek-Support meinte ich solle das mal einschalten testweise - das war eine der beiden Optionen, die der Support vorgeschlagen hat. Ich habe jetzt auch nochmal per Mail gefragt, ob der Router vielleicht das dynamische aufmachen der Ports auch nur im dyn. Port-Bereich macht - dann wäre der Bug, den gehtdoch beschrieben hat, vermutlich die Ursache, weil einfach kein dyn. Port verwendet wird - hier in dem Asterisk ist ja SIP (intern) und PJSIP (extern) aktiv...
Es handelt sich um einen ALL-IP-Anschluss vond er Telekom, es gibt keinen Reseller des DSL-Anschlusses.
Klar, wir sind ein IT-Systemhaus, wir haben Router auf Lager liegen, allerdings eben fast nur Draytek, weil wir mit denen grundsätzlich sehr zufrieden sind - aber erstmal werde ich die vom Support vorgeschlagenen Optionen noch probieren und die Antwort mit dem Port abwarten - es muss ja eine Erklärung für das Problem geben.
Genau das meine ich mit "nicht ohne weiteres" - ich müsste mit einem Notebook Vorort sein dafür, bin ich aber nicht.... wenn der Schritt unumgänglich wird, wird das natürlich gemacht. Habe auch letzte Woche Draytek nochmal gebeten, an Taiwan bei der Entwicklung an zu regen, dass doch ein Paketmitschnitt über die GUI einfach zeitgemäß ist und bei anderen Routern wie LANCOM/Fritzbox auch ohne Umstände möglich ist - vermutlich wird leider nix passieren - aber drauf hinweisen kann man ja mal...
Wie gesagt, geht, ist nur mit unverhältnismäßigem Aufwand verbunden. Wenn ich Zeit in den Abendstunden finde (der Anschluss ist ja sonst nicht mehr erreichbar, und ich muss nach dem Deaktivieren des Port-Forwards immer eine mir bisher unbekannte Zeit warten, bis der Anschluss nicht mehr erreichbar ist), werde ich erstmal noch die Optionen durch probieren und dann ggf. nochmal Draytek dazu befragen... und auch hier noch abschließend berichten, sobald eine Lösung vorliegt.
Uhh. Du machst UDP. Der Thread hier handelt eigentlich von TLS+MediaSec (bzw. ist dorthin gewandert, weil in Post #5 eine entsprechende Anleitung stand). Jedenfalls kam ich auf diesen Trichter, als ich 5061 las. Und unser User gehtdoch wird das vermutlich auch gedacht haben.
Nachtrag, nach erneutem Durcharbeiten:
In Deinem Bildschirm-Foto siehst Du den Egress-Port Deines DrayTek Vigor im Via;rport. Dieser ist 38597. Digium Asterisk bietet zwar rPort, schreibt aber den Header Contact nicht wie in RFC 3581 Abschnitt 9 um. Jetzt kenne ich die Telekom Deutschland zu wenig, was Priorität hat, der physische Port oder der Port im Header Contact. Offensichtlich in Deinem Fall Letzteres. Folglich landet die Antwort der Telekom Deutschland auf dem Port 5061, der aber von niemanden geöffnet wurde. Lediglich 38597 ist offen. Meine Tipps:
Nicht überall schaltet die Telekom das DSL selbst. Ich hatte schon Logs in der Hand, mit Telekom All-IP und es war kein DSL von Telekom Deutschland. Daher die Rückfrage, zur Sicherheit. Wenn Du weißt, dass es Telekom DSL ist, fliegt das als mögliche Ursache raus. Aber weil Du UDP machst, muss ich eh nochmals alle Deine Posts durcharbeiten und aus einem anderen Blick betrachten.
Das kannst Du schnell testen, indem Du das Patch einspielst. Siehst Du das Patch, weißt Du wie das geht, geht das bei Euch aus der Ferne?
Die Telekom erlaubt Mehrfach-Registrierungen unter einer Rufnummer. Das führt dann zu mehrere Contact-Header.
Nachtrag, nach erneutem Durcharbeiten:
In Deinem Bildschirm-Foto siehst Du den Egress-Port Deines DrayTek Vigor im Via;rport. Dieser ist 38597. Digium Asterisk bietet zwar rPort, schreibt aber den Header Contact nicht wie in RFC 3581 Abschnitt 9 um. Jetzt kenne ich die Telekom Deutschland zu wenig, was Priorität hat, der physische Port oder der Port im Header Contact. Offensichtlich in Deinem Fall Letzteres. Folglich landet die Antwort der Telekom Deutschland auf dem Port 5061, der aber von niemanden geöffnet wurde. Lediglich 38597 ist offen. Meine Tipps:
a) Was passiert, wenn Du einen ganz hohen Port in PJSIP nimmst, gleich ganz hinten also 65535.
Mein Ziel: Einen Port finden, bei dem der DrayTek Vigot kein re-Mapping macht, also am Ende Via;rport = Contact.
b) Was passiert, wenn Du das SIP-ALG einschaltest und dort Deinen Quell-Port einträgst, also aktuell 5060-5061?
Meine Vermutung: Normal lauscht das SIP-ALG nur auf Port 5060. Ich weiß aber nicht, ob das Ziel-Port oder Quell-Port ist.
c) Ist das ein Vigor2860Vac oder ein „normaler“ Vigor ohne V, also ohne VoIP?
d) Was spricht dagegen, statt UDP auf TLS vielleicht sogar mit MediaSec zu wechseln?
Nachtrag, Nachtrag:Was mich noch wundert, ist das expires=0. In einer Antwort dürfte das gar nicht vorkommen. Mhm.
Zuletzt bearbeitet:
einige Punkte auf die Schnelle:
- Ich bin von TCP 5060 ausgegangen - nicht TLS.
- Da hier UDP eingesetzt wird, verhält sich die Sache ein wenig anders. Zunächst: bei UDP tritt das Problem mit dem falschen Port im SIP-Protokoll nicht auf (war zumindest in meinen ca. 1 Jahr alten letztem UDP-Trace mit Asterisk 16 / pjsip völlig ok - Verbindung ging de facto von Port 5061 -> 5060 Telekom). Somit passt das also hier: Die Antwortpakete der Telekom sind exakt so, wie ich beschrieben habe (aus physischer Sicht). Woher der abweichende rport kommt? NAT-Geraffel? Was macht der Router? Greift der "intelligent" ein? Ganz abgesehen davon: ohne den kompletten Verkehr an sämtlichen Stellen zu kennen, macht das hier alles keinen Sinn. Reine Kaffesatzleserei.
- Das expires = 0 deutet auf einen deRegister hin aus meiner Sicht. Dann kommt natürlich auch kein Call mehr rein.
- Telekom würde UPDATE-Methode verwenden, obwohl nicht als supported gelistet: wäre mir neu. Bei chan_sip kam die bei mir nie zum Einsatz (kann chan_sip nicht). Mit pjsip immer - das war ja mit einer der Hauptgründe, warum ich sehr früh gewechselt habe, weil dann das Sessionhandling nicht mehr über reInvites gefahren wird, die gerne zum Abbruch geführt haben - je nach dem, bei welchem Provider der TN B war.
- Finger weg von NAT und SIP - das garantiert (dauerhaft) Ärger mit Ansage und maximale Zeitverschwendung.
Mein DrayTek Vigor erzeugt immer (?) einen anderen Egress-Port, außer die Quelle liegt in seiner DMZ bzw. hat ein Port-Forwarding. Aber das ist erstmal egal, weil die Firewall auf diesem Port dann automatisch lauscht. Die Frage ist, ob Telekom Deutschland auf den physischen Port oder den Port aus dem SIP-Header Contact antwortet. Wenn das keiner beantworten kann, ATO, empfehle ich Dir ein VoIP/SIP-Telefon vor Ort anzuschließen, welches wahlweise den SIP-Header Contact umschreibt (nach RFC 3581 Abschnitt 9). Zum Beispiel Yealink bietet das in seiner T4/5xS-Serie.
Wie soll er es denn sonst machen … DrayTek bietet noch die Möglichkeit der Active-True-IP. Aber dann liegt nicht nur der eine Port sondern der ganze der Asterisk-Server als Exposed-Host im Netz. Das wäre eine Steigerung von DMZ. ATO will nicht einmal Port-Forwarding.
Das kann nur der UAC, also Asterisk. Wäre mir neu, dass die Telekom Deutschland von sich aus mich de-registrieren darf.
Eben. Bei TCP antwortet sie auf den physischen Port - das weiß ich sicher - zumindest solange kein NAT im Spiel ist. Bei UDP kann ich es nicht sicher sagen, weil da seitens Asterisk auch der physische lokale Port tatsächlich der gleiche war, wie im SIP referenziert.
Er darf es machen, wie er möchte und kann. Ist mir am Ende des Tages egal, welchen Ärger er sich damit einhandelt - ist ja nicht mein Ärger. Wie Active-True-IP technisch umgesetzt wird, würde mich auch mal interessieren. Mit den mir bekannten Tools ppp(oe) scheint es auf die Schnelle zumindest nicht machbar zu sein.
Das kann jeder - auch die Telekom. Gibt genügend Gründe dafür.
Jetzt weiß ich es … immer noch nicht.
Die Frage war, wie er seinen Asterisk ohne NAT betreiben soll. Ich kenne keine Alternative außer eine Übergangsbox als SIP-B2BUA dazwischen zu schalten … Active-True-IP, Exposed-Host und Port-Forwarding … was Du vorschlägst, ist den Asterisk auf einen öffentlichen Server im Internet zu platzieren.
Kann das nicht mal wer mit Telekom Deutschland für UDP testen?
Dann weiß ATO, dass das normal ist (und er muss das umgehen) oder das irgendwas in seinem Aufbau noch krumm ist.
Im Posting von ATO war ja die Antwort zu sehen. Ein Expire von 0 heißt meines Wissens: Ende Gelände - nicht registriert. Warum der Telekomserver ihn nicht habe will, musst Du schon die Telekom fragen - ich kenne ja den Ursprungsrequest nicht. Vielleicht war einfach der angebotene Expire im gesendeten Request zu gering - wenn ich mich noch recht erinnere mag das zumindest die Telekom nicht. Mindestens 660s sollten da schon im Angebot sein.
Nein - kein öffentlicher Server. Es gibt wohl das von Dir erwähnte Active-True-IP (scheint ein spezielles Feature von manchen Draytek-Devices zu sein - mir sagt das nichts). Ich verwende pppoe-passthrough. IPv6 ist ja leider keine Option, weil die VoIP-Server der Telekom nur via IPv4 erreichbar sind (zumindest weiß ich nichts anderes).
Nur als Nachtrag zu dem Einwurf: Selbst mit IPv6 hättest Du immer noch eine Firewall. Und damit diese ganzen Port-Binding-Probleme immer noch. Lediglich das Port-Mapping – dieser Egress-Port – entfiele. Aber Port+Ziel muss man immer noch auf halten. Und im SIP muss der richtige Port stehen. Daher ist/wird IPv6 leider auch nicht das Allheilmittel für VoIP/SIP.
Das heißt, bei Dir macht der Server mit Asterisk zusätzlich auch noch Router, NAT und Firewall.
Nein - nicht zwangsweise. Aufgrund von "prefix delegation" (Du kriegst von der Telekom zur einzelnen globalen IPv6-Adresse des Routers ein globales /56 - Netz zugewiesen. Das kannst Du aufteilen in 256 /64-Netze). D.h., der Router kann (falls er es unterstützt) einzelne IPv6-Adressen dieser 256 Netze auf dahinterliegende Devices verteilen. Jedes dahinterliegende Device ist damit ohne NAT und ähnliche Handstände direkt aus dem Internet erreichbar. Der Router routet hier nur noch (solange Du das nicht firewalltechnisch einschränkst logischerweise). Da gibt es dann auch keine Ports mehr unterwegs aufzuhalten.
V.a. kennt der VoIP-Server seine globale IP, die er ja auch für den SDP zwingend benötigt (also auch kein STUN/TURN-Geraffel mehr). Diese Lösung ist extrem schick und schlank und entspricht im Prinzip der pppoe-passthrough-Lösung auf IPv4-Ebene (wo Du eben auf einen einzigen Host eingeschränkt bist - bei IPv6 hast Du für private Zwecke fast unendlich viele globale IPs
, die Du auf dahinterliegende Devices verteilen kannst). Aber ist ja hier nicht möglich, weil die VoIP-Infrastruktur der Telekom nicht via IPv6 zu erreichen ist.Ein Asterisk als B2BUA mit Anbindung an einen Trunk (wie z.B. Telekom) für die Welt nach außen, kann ja grundsätzlich auch völlig ohne global offene Listenerports (transports aus Asterisk pjsip-Sicht) ins Internet betrieben werden (dafür brauchst Du u.U. noch nicht mal einen Portfilter). Ok, nicht out of the box - aber ich habe es ja an anderer Stelle beschrieben, wie es grundsätzlich geht. In der Beschreibung fehlt allerdings noch der Hinweis, dass man den Standardtransport, den z.B. FreePBX anlegt, wenn man in den pjsip-Einstellungen die entsprechenden Einstellungen vornimmt, auch weglassen kann - dann gibt es bei netstat -tulpn auch keinen offenen Port mehr (falls man ihn nicht gleichzeitig zu Registrierungszwecken für die internen Devices benötigt - aber dann kann man den transport ja auch fest auf eine interne IP binden oder man macht dann eben doch noch einen Portfilter davor, der jeden Zugriff von Außen unterbindet, falls eine dedizierte Konfiguration nicht ordentlich funktionieren sollte).
Firewall nicht (Firewall ist ein Gesamtkonzept, welches sich am Ende des Tages aus vielen unterschiedlichen Tools / weiteren Konzepten zusammensetzt), aber VoIP-Server (als B2BUA), Router, NAT, Portfilter, pppoe-Terminierung und IPv6-handling. Kannst Du schön aufbauen z.B. mit einer APU2 und einer SSD-Karte als Speichermedium - braucht wenig Strom (ca. 6 Watt inkl. zusätzlichem USB-Stick, den ich für Logging-Zwecke verwende) ist aber trotzdem ziemlich leistungsfähig und hat Coreboot als BIOS (eine opensource-Lösung). Da könntest Du auch noch eine WLAN-Karte einbauen (habe ich aber nicht, weil ich das anderweitig bereitstelle).
...und vielleicht auch garnicht gewünscht! Damit stehen ja alle Scheunentore sperangelweit offen! Jedes System ist damit potentielles Angriffsziel und offene Sicherheitslücken sind noch ein viel größeres Problem, als sie es ohnehin schon sind! Aus diesem Grund möchte ICH zumindest keine Geräte ins öffentliche Netz hängen oder die Öffnung wieder per Firewall explizit schließen müssen, von daher bin ich ganz froh drum, dass das alles noch so ist wie es ist und gewisse Dienste einfach nur über IPv4 laufen.Nein - nicht zwangsweise. Aufgrund von "prefix delegation" (Du kriegst von der Telekom zur einzelnen globalen IPv6-Adresse des Routers ein globales /56 - Netz zugewiesen. Das kannst Du aufteilen in 256 /64-Netze). D.h., der Router kann (falls er es unterstützt) einzelne IPv6-Adressen dieser 256 Netze auf dahinterliegende Devices verteilen. Jedes dahinterliegende Device ist damit ohne NAT und ähnliche Handstände direkt aus dem Internet erreichbar. Der Router routet hier nur noch (solange Du das nicht firewalltechnisch einschränkst logischerweise). Da gibt es dann auch keine Ports mehr unterwegs aufzuhalten.
V.a. kennt der VoIP-Server seine globale IP, die er ja auch für den SDP zwingend benötigt (also auch kein STUN/TURN-Geraffel mehr). Diese Lösung ist extrem schick und schlank und entspricht im Prinzip der pppoe-passthrough-Lösung auf IPv4-Ebene (wo Du eben auf einen einzigen Host eingeschränkt bist - bei IPv6 hast Du für private Zwecke fast unendlich viele globale IPs
Eben halt nur grundsätzlich, und in meinem Fall aus welchem Grund auch immer nicht.
Aufgrund der Tatsache, dass das Problem super unschön zu analysieren ist, weil ich nach Entfernung des öffentlichen Ports eine mir unbekannte Zeit warten muss, bis die Nummer NICHt mehr erreichbar ist, der Router keine Paketmitschnitte ohne Vorort-Installation ermöglicht, und schon unsummen an Zeit in diese Thematik geflossen ist, ich die vom Router-Hersteller vorgeschlagenen Optionen als wenig zielführend einschätze, und es mir eigentlich nur darum geht, keine offenen Ports in dem System zu haben, probiere ich jetzt den Lösungsansatz mit TLS über TCP, in der Hoffnung dass das Problem in der Konfiguration einfach nicht auftritt. Habe daher TLS aktiviert und UDP deaktiviert. Im Moment geht noch alles (was es mit UDP ja auch ging, also ERGO, ich noch nicht sagen kann ob das jetzt endgültig funktioniert oder nicht), ich werde dann nochmal berichten ob das so bleibt. Wundere mich auch, dass ich der einzige mit dieser Problematik bin. Ich habe das gleiche Problem an drei verschiedenen Systemen, immer mit einem Vigor dazwischen! Der Draytek-Support hat sich bisweilen auf meine letzte Mail vom 23.03.21 garnicht mehr zurück gemeldet, ob wegen mangeldner Kompetenz oder Hilfsbereitschaft oder Überlastung weiss ich nicht, jedenfalls leider ein ziemliches Armutszeugnis.
sorry, dass ich da nicht klarer drauf hingewiesen habe und somit für verwirrung gesorgt habe!
oha! das ist mir auch gänzlich neu, gut zu wissen!
hierzu habe ich noch eine Frage:
Du meinst also, der Draytek öffnet bei dem gezeigten Paket nicht den SourcePort 5060 (das, nehme ich an, meinst du mit physikalischem Port?), sonder inspiziert die SIP-Pakete und öffnet den rport 38597? Ich meine mich zu erinnern, dass das Problem auch ohne die RPORT-Option auftrat, wenn der RPORT von Asterisk garnicht gesetzt war, da hätte der Vigor dann doch aber den physikalischen Port aufmachen, und die Telekom daraauf antworten, und der Call zustande kommen müssen - tat es aber nicht.
Also eigentich müsste der ganze Quatsch doch komplett ohne SIP ALG laufen - das hat auch der Supportler von Draytek geschrieben. Der SIP ALG wäre doch nur sinnvoll, wenn der Draytek selbst eine VOIP-Funktion hätte!?
ist ein Modell ohne VoIP.
es sprach dagegen, dass es bei meinem letzten Test nicht auf anhieb ging! ;-) ...ich habe jetzt alle UDP-Trunks temporär deaktiviert, erst dann ging der Trunk, den ich auf TLS umgeschaltet habe, vorher kam kein Gespräch zustande, und iwie kam immer eine Fehlermeldung im Log, dass die Pakete dem UDP-Transport nicht zugeordnet werden konnten, wenn ich auf der Nummer des Trunks angerufen habe, die ich auf TLS umgestellt hatte.
Mhm, habe eben mal kurz gegooglet. Expires=0 soll eigentlich eine deregistrierung auslösen? Wieso sendet asterisk die bei einer Registrierung mit? Finde dazu diesen Link:
Asterisk sends “Expires: 0” when registering SIP trunk
My System: CentOS 6.2 (2.6.32-220.13.1.el6.x86_64) Asterisk 1.8.11.1 FreePBX 2.10.0.4 FOP2 2.26 I recently upgraded Asterisk from 1.8.7.0 to 1.8.11.1 on my system. Mostly things seem fine after the upgrade, although I have noticed one “niggle”; on the homepage of my SIP trunk provider...
community.freepbx.org
Zuletzt bearbeitet:
Du hast es leider nicht verstanden und was Du als Deine Erkenntnisse hier schreibst ist die Folge von Fehlern, die allein Du machst, weil Du Zusammenhänge einfach erst noch lernen musst - aber damit kann ich leben
- mach ruhig weiter so! Ist ja Dein System und nicht meines!Erkläre mir bitte den Unterschied, ob ein Angreifer via NAT auf Deinen sinnlosen Listener zugreift oder direkt.
Ich glaube, mit Verlaub, wir kennen uns zu schlecht, als dass Du mein Verständnis für Sachverhälte beurteilen kannst und ich würde Dich bitten doch sachlich zu bleiben, anstatt mir zu unterstellen, ich würde Fehler machen und Folgen von Fehlern beschreiben. Und wenn Du das schon tust, wäre es schön, wenn Du wenigstens konkret erklärst, was Du meinst. Von großartigen Erkenntnissen habe ich hier indes, wenn ich mich jetzt recht entsinne, auch noch nirgends gesprochen. Bisher sind mir diverse Dinge einfach nur unklar - nach wie vor. Wenn Du so genau Bescheid weisst, warum das System sich so verhält, wie es sich verhält, und dass das an von mir gemachten Fehlern liegt, dann hast Du sicher auch die 100% garantiert funktionierende Lösung für mein Problem in der Hosentasche und möchtest diese einfach so aus Spaß an der Freude nicht heraus geben, richtig?
Es gibt keinen Listener über den ich hier spreche, der per NAT erreichbar wäre! Wenn es in einem IPv4-Netz keinen Port gibt, der am Router an einen internen Netzteilnehmer weiter geleitet wird, ist es völlig egal ob intern Ports lauschen oder nicht, Du darfst mich gern eines besseren belehren, solltest Du dazu andere Informationen haben, als ich, ich bin zum Glück nicht allwissend und lerne gern etwas neues. Wenn ein an einen Router angeschlossener Netzteilnehmer über eine IPv6-Adresse direkt aus dem öffentlichen Netz erreichbar ist, wird aber ein Listener-Port, der davor nur intern zugänglich war, für alle zugänglich. Das ist schon ein beachtlicher Unterschied, findest Du nicht?
Zuletzt bearbeitet:
gehtdoch, Du hast mit Deinen beiden Vorschlägen (IPv4 PPPoE Passthrough; IPv6 ohne Firewall) nichts anderes als einen öffentlichen Server geschaffen. Kann man machen. Kann man wie ATO aber auch nicht machen wollen. Und ja, man muss bei IPv6 nicht zwingend eine Firewall haben. Aber das ist dann eher ein Glücksfall als Können: Es kann passieren, dass einem die IPv6-Firewall aufgezwungen wird (keine Kontrolle über Firewall in Router bzw. Mobilfunk in Deutschland quasi immer Firewall). Daher ist IPv6 nicht das Allheilmittel – als Anwendungsentwickler muss man weiterhin auf die Ports achten. Daher ist so wichtig, dass dort das Richtige steht. Lediglich bei den Adressen wird es in IPv6 einfacher, weil der Anwendungsentwickler „nur“ darauf achten muss, dass konstant die richtigen verwendet werden.
SIP/SDP ist und bleibt wegen der Durchbrechung des OSI-Modells einfach ein wahnsinnig komplexes Gebilde, besonders dann wenn ein Netz-Übergang geschieht (z.B. Heimnetz ↔︎ globales Internet). Daher mein Rat für all jene, die
Nein, Du brauchst SIP-ALG – Dadurch, dass ein DrayTek um-mappt, also aus Spaß heraus nach seinem NAT einen anderen Port nutzt, müsste man bei jenen Protokollen, die sich nicht an das OSI-Modell halten, den Daten-Inhalt umschreiben. Das bedeutet bei SIP, dass der DrayTek sich die SIP-abgehenden Nachrichten anschaut und alle Erwähnungen des Quell-Ports (bei Dir 5061) auf den Egress-Port (bei Dir damals temporär 38597) umschreibt. Das selbe Spiel in umgekehrter Richtung bei eingehenden Nachrichten.
Ja, es geht auch ohne SIP-ALG – Wenn Dein Telefonie-Anbieter die Ports in den SIP-Nachrichten ignoriert und seinen Quell-Port nimmt = Egress Port im DrayTek = physikalischen Port, dann bräuchtest Du kein SIP-ALG. Manche, viele Anbieter wie DUStel und Sipgate machen das so. Bei Telekom Deutschland weiß ich es nicht und kann es auch nicht testen. Bei TCP bzw. TLS hat es sich bei den Telefonie-Anbietern eingebürgert, immer den Quell-Port zu nehmen und die Ports in den SIP-Nachrichten zu ignorieren. Aber auch das ist lediglich eine Heuristik, weil es Anbieter gibt, die das nicht machen (und pathologisch könnte die Telekom Deutschland das jederzeit ändern).
Ja, es geht auch ohne SIP-ALG – Wenn Du herausbekommst, in welchen Fällen der DrayTek nicht um-mappt. Das kannst Du Dank rport vergleichsweise einfach kontrollieren. Also zum Test den (UDP) Quell-Port in Asterisk statt auf 5061 noch weiter hochschrauben.
Ja, es geht auch ohne SIP-ALG – Wenn Du die Firewall anders überwindest, also über Port-Forwarding, DMZ, Active-True-IP, IPv6 …
SIP/SDP ist und bleibt wegen der Durchbrechung des OSI-Modells einfach ein wahnsinnig komplexes Gebilde, besonders dann wenn ein Netz-Übergang geschieht (z.B. Heimnetz ↔︎ globales Internet). Daher mein Rat für all jene, die
- selbst keine Firewall pflegen wollen und
- einen Telefonie-Anbieter haben, der sich nicht darum schert, ob man erreichbar ist,
Anders herum. Durch rport siehst Du, von welchem Port die SIP-Nachricht kam, die bei der Telekom Deutschland aufgeschlagen ist. Anders formuliert: rport ist eine Status-Nachricht, die der Telefonie-Betreiber befüllt, um Dir zu sagen, von welchem Port er die Nachricht empfangen hat. Daher machte das kein Unterschied, ob Du in Asterisk rport ein oder ausschaltest war/ist. Dank rport siehst Du, dass ein anderer Egress-Port zum Einsatz kommt – auch ohne das WAN mitprotokollieren zu müssen. Ein DrayTek mappt einfach um. Dabei schaut er nicht in das Paket. Wann genau DrayTek um-mappt, habe ich auch noch nicht herausgefunden. Vielleicht, wenn der Quell-Port im Heimnetz sehr niedrig ist. Ich meine aber, dass mal angetestet zu haben und bei mir hatte er stupide immer um-gemappt.
Ja und nein.
Nein, Du brauchst SIP-ALG – Dadurch, dass ein DrayTek um-mappt, also aus Spaß heraus nach seinem NAT einen anderen Port nutzt, müsste man bei jenen Protokollen, die sich nicht an das OSI-Modell halten, den Daten-Inhalt umschreiben. Das bedeutet bei SIP, dass der DrayTek sich die SIP-abgehenden Nachrichten anschaut und alle Erwähnungen des Quell-Ports (bei Dir 5061) auf den Egress-Port (bei Dir damals temporär 38597) umschreibt. Das selbe Spiel in umgekehrter Richtung bei eingehenden Nachrichten.
Ja, es geht auch ohne SIP-ALG – Wenn Dein Telefonie-Anbieter die Ports in den SIP-Nachrichten ignoriert und seinen Quell-Port nimmt = Egress Port im DrayTek = physikalischen Port, dann bräuchtest Du kein SIP-ALG. Manche, viele Anbieter wie DUStel und Sipgate machen das so. Bei Telekom Deutschland weiß ich es nicht und kann es auch nicht testen. Bei TCP bzw. TLS hat es sich bei den Telefonie-Anbietern eingebürgert, immer den Quell-Port zu nehmen und die Ports in den SIP-Nachrichten zu ignorieren. Aber auch das ist lediglich eine Heuristik, weil es Anbieter gibt, die das nicht machen (und pathologisch könnte die Telekom Deutschland das jederzeit ändern).
Ja, es geht auch ohne SIP-ALG – Wenn Du herausbekommst, in welchen Fällen der DrayTek nicht um-mappt. Das kannst Du Dank rport vergleichsweise einfach kontrollieren. Also zum Test den (UDP) Quell-Port in Asterisk statt auf 5061 noch weiter hochschrauben.
Ja, es geht auch ohne SIP-ALG – Wenn Du die Firewall anders überwindest, also über Port-Forwarding, DMZ, Active-True-IP, IPv6 …
Müssten, könnten, sollten für UDP mit den Standard-Einstellungen drei Minuten sein. Aber lediglich eine Spekulation. Selbst nie getestet.
Meine Vermutungen: Viel zu viele dürften aufgeben und den Workaround „Port-Forwarding“ nehmen. Das betrifft auch nur jene, die mit der Telekom Deutschland direkt verbinden und ein NAT/Firewall nehmen, welches um-mappt. Das machen wenige Router von Haus aus. Ich kenne nur DrayTek. Lancom macht das, wenn man viel herum konfiguriert hat. Aber alle (?) machen das, wenn man parallel auf diesem Port bereits ein Port-Forwarding zu einem anderen Gerät liegen hat.
Zuletzt bearbeitet:
Verstehe, vielen Dank für die Erklärung!
mhm, also ich habe ALG bisher noch nirgends benötigt. Wir haben als Provider easybell, Telekom, Entega Medianet (das ist hier ein lokaler Anbieter), da war das bisher immer ohne ALG möglich - und wir verwenden fast ausschließlich Draytek's.
Nein, selbst nach 15 Minuten war der Anschluss nach Schließung des Ports trotzdem noch erreichbar - das macht eine zügige Analyse natürlich unmöglich. Nach jeder Konfigurationsänderung musste ich ewig warten, und weiss nicht mal wie lang..
Ich hatte mich hier auch geirrt, in einem Fall haben wir das gleiche Problem mit einem Zyxel-Router. Ich denke auch, die meisten leiten einfach den Port weiter ohne sich Gedanken darüber zu machen (wie es z. B. auch Herr Griebsch in seinem Blog-Beitrag beschreibt), was das bedeutet, und dass das eigentlich nicht notwendig sein dürfte.
Jedenfalls, mit TLS funktionierte heute Morgen alles wie gewünscht, ohne PortForward - daher habe ich jetzt die anderen Systeme auch entsprechend umgestellt - ist ja ohnehin die schönere Variante. Für mich hat sich das Thema damit erstmal erledigt. Vielen Dank für's Mitdenken! Auch an Dich @gehtdoch.
Hättest Du es gleich so gemacht, wie ich es im 5. Beitrag hier dokumentiert habe, hättest Du Dir und uns sehr viel Ärger und Zeit erspart.
An alle anderen, die über diesen Thread stolpern: UDP verwendet man schon lange nicht mehr für SIP. Bereits seit einiger Zeit ist TLS Standard. Bei UDP kann man davon ausgehen, dass das früher oder später abgeschaltet wird - genauso wie die DNS A-Records derzeit auf NAPTR / SRV umgestellt werden. Ich lerne daraus: auf Fragen, die sich auf UDP beziehen, werde ich zukünftig grundsätzlich nicht mehr antworten. Es ist seit längerem sowieso schon der grundsätzlich falsche Weg. Es ist einfach nur Zeitverschwendung.
Genau so beginnt man schon seit geraumer Zeit nicht mehr mit chan_sip (-> Legacy und kann Vieles einfach noch nicht und wird es auch nicht mehr können, weil es schon seit Jahren nicht mehr weiterentwickelt wird) sondern ausschließlich mit pjsip - auch wenn das noch härter ist, weil es noch nicht so viel Doku gibt, über die man einfach so stolpert und weil es vom Konzept her anders, etwas komplexer ist. Mit der Abschaltung der A-Records der Telekom wird man dann sowieso zu pjsip gezwungen.
[Update]
Ebenso ist es falsch, heute noch RTP zu verwenden, weil es den heutigen Minimalanforderungen nicht mehr entspricht (DSGVO z.B.). SRTP ist nicht primär die schönere Lösung (wie ATO hinsichtlich SIP/TLS formuliert hat), sondern schlicht und ergreifend heutiger Standard und damit die korrekte Lösung. Leider benötigt man für die Telekom hierzu Mediasec.
Zuletzt bearbeitet:
Neueste Beiträge
-
5690 Pro Datenraten Problem 5ghz und 6ghz- Letzte: Jstessi
-
Ersatz für Festnetz-Telefon (IP Provider mit Portierung) mit Zugang via WiFi
- Letzte: KunterBunter
-
[Sammlung] Fritz!Box 7690 - Release 8.xx - Zyklus 'Smart24P1FCS'
- Letzte: spike01
-
-
Wechselassistent wie lange von 7590 auf 5690pro
- Letzte: MSprecher
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: Netzonline