Solved
Telefongespräch bricht nach SIP REGISTER auf anderen Server ab
4 years ago
Ich betreibe eine Fritz!Box und PhonerLite (nur zum testen) hinter einen Linux Router mit Statefull Firewall (nftables mit conntrack sip helper) für die VoIP Telefonie. Bisher hatte ich pfSense als Firewall genutzt und seit Jahren brechen Telefongespräche einfach nach einiger Zeit ab. Deswegen wechselte ich von pfSense zu Linux, doch die Gesprächabbrüche bleiben.
Ich konnte nun nachvollziehen, dass nach einem REGISTER auf einen neuen Server (andere IP), das Gespräch von der Telekom mit BYE beendet wird. Die Telekom verlangt wohl alle 15 Minuten diese regelmäßigen REGISTERs, diese meistens zur bisherigen IP erfolgen. Doch wenn die IP des SIP Server wechselt, dann kommt direkt das BYE von genau diesem Server!
Ich habe mir mit dem sngrep-Befehl die Verbindungen anzeigen lassen. Die 192.168.0.22 ist der PhonerLite und die 217.0.21.128 und 217.0.20.192 sind die SIP-Server der Telekom. Man sieht wie 14:19 Uhr dieser Server wechsel vorgenommen wird.
In der Ausgabe der Statefull Firewall, mit der Zuordnungen für das NAT, ist nach dem Server wechsel auch die neue Verbindung korrekt eingetragen. Die Ausgabe erfolgt mit dem Befehl: conntrack -L | grep -E 'sip|helper'
udp 17 3529 src=192.168.0.22 dst=217.0.21.128 sport=5060 dport=5060 src=217.0.21.128 dst=87.111.12.34 sport=5060 dport=35021 [ASSURED] mark=0 helper=sip use=1
udp 17 3589 src=192.168.0.22 dst=217.0.20.192 sport=5060 dport=5060 src=217.0.20.192 dst=87.111.12.34 sport=5060 dport=35021 [ASSURED] mark=0 helper=sip use=1
Das scheint meiner Meinung nach auch zu funktionieren. Aber warum wird auf dem SIP Server der Telekom das REGISTER angenommen und danach mit BYE das Gespräch beendet?
Gibt es hier jemand der ebenfalls mit Linux und conntrack sip helper ohne diese Fehler am laufen hat?
1271
13
4 years ago
Hallo @H. Rüdiger ,
was sagt denn die Debugausgabe von PhonerLite?
11
Answer
from
4 years ago
@wari1957
Das ist ein sehr guter Hinweis, dass die DNS-Einträge nicht wechseln sollten! Auf meinen Linux Router läuft ein DNS-Server (DNS Resolver) und ich werde mir nun genau anschauen, was dieser tut. Danke auf jeden Fall für den Hinweis! Vielleicht ist das der entscheidende Ansatz zur Lösung. Sobald ich das getestet habe, melde ich mich zurück.
Answer
from
4 years ago
@wari1957
Ich muss mich wirklich bei dir bedanken! Dein genaues hinschauen in die Log-Datei vom PhonerLite hat die Unstimmigkeit mit der DNS-Auflösung zu Tage gebracht. Mein oberflächliches Wissen zu SIP/RTP reicht da offensichtlich nicht aus. Ich bin mir auch nicht sicher, ob mir dieser Fehler irgendwann selbst auch aufgefallen wäre!
Den Wechsel der DNS-Auflösung konnte ich im lokalen DNS-Server (Unbound DNS Resolver) meines Linux Router nachvollziehen. Der lokale DNS-Server auf dem Router verwendet nicht die Telekom DNS-Server, sondern eine Liste öffentlicher DNS-Server (Google, Quad9, usw.). Diese öffentlichen Server werden der Reihe nach mit dem Round-Robin-Verfahren abgefragt. Dieser ständige Wechsel ist ein Grund für den Fehler mit der wechselnden DNS-Auflösung. Der zweite Grund könnte von einen Verfahren kommen, dass die eigene geographische Lage bei der DNS-Abfrage beachtet. Also das man zu einen Streaming-Dienst in seiner geographischen Nähe eine Namensauflösung bekommt. Ich vermute, das so etwas bei SIP/RTP angewendet wird.
Einen praktischen Test konnte ich durchführen, indem ich auf dem Rechner mit PhonerLite (192.168.0.22), den DNS-Server der Telekom angegeben habe. Es werden zwei DNS-Server der Telekom bei der DSL-Einwahl an einen übermittelt. Dann habe ich ein Telefongespräch aufgebaut und mit nslookup -q=SRV _sip._udp.tel.t-online.de die DNS-Abrage zwischen Telekom und den meines Router verglichen. Die Unterschiede waren von Anfang an zu erkennen. Aber nach einer guten halben Stunde änderten sich die SRV-Server von meinen Linux Router. Die SRV-Server von der Telekom blieben unverändert.
Im übrigen musste ich das SIP ALG (Linux Conntrack SIP Helper) aktiviert lassen. Manchmal konnte dann ankommende Gespräche nicht weitergeleitet werden. Aber der Conntrack SIP Helper ist auch nie das Problem gewesen. Im Gegenteil er hat die Fehler der DNS-Auflösung sogar schnell und korrekt vermittelt. Sonst wären im PhonerLite gar keine SIP-Pakete mehr angekommen.
Ich werde nun den Testaufbau in eine praktische Lösung überführen. Das dann noch einmal gründlich Testen, deine Antwort als Lösung kennzeichnen und dann vermutlich mit dem Thema abschließen.
Answer
from
4 years ago
Die praktische Lösung scheint nun auch zuverlässig zu laufen. Ich betreibe nun zwei lokale DNS-Server, einmal mit Telekom DNS-Servern von der DSL-Einwahl und den zweiten wie dieser schon bisher lief.
@wari1957 und @Stefan vielleicht ist die folgende Information für euch Interessant:
Mein zuverlässige arbeitende SIP ALG (Linux Conntrack SIP Helper) werde ich wohl deaktivieren müssen. Der Grund dafür ist der NAT-Slipstreaming-Angriff mittels ALG. Die Sicherheitsforscher Samy Kamkar, Ben Seri und Gregory Vishnipolsky haben diese Lücke erst kürzlich mit der Variante 2.0 erweitert. Denn Webbrowser-Hersteller hatten mit Portsperren darauf reagiert. Doch mit der neuen Variante 2.0, ist der Betrieb einer SIP ALG nicht mehr verantwortbar! Wer weitere Informationen benötigt findet beim Heise Verlag den Artikel "NAT-Slipstreaming-Angriffe: Es kommt noch schlimmer".
Unlogged in user
Answer
from
Accepted Solution
accepted by
4 years ago
@H. Rüdiger
Normalerweise müßte PhonerLite jetzt den Eintrag:
_sip._udp.tel.t-online.de service = 10 0 5060 n-epp-110.edns.t-ipnet.de.
verwenden.
Der Eintrag wechselt normalerweise auch nicht.
0
Unlogged in user
Ask
from