Telekom All IP Privat endlich erfolgreiche Registierung SSL/TLS möglich

[gehtdoch]

Die SSL-Chain sieht ja ok aus. Ich weiß nicht, wie das bei CompanyFlex ist, aber bei den "Endkunden"-Servern musst Du bei Asterisk TLS 1.2 einstellen (zumindest war das in der Vergangenheit so) - sonst geht nichts.

Die Fehlermeldung von Asterisk (No response received ...) deutet aber auf ein anderes Problem hin: der kommt IP-technisch nicht raus (oder die Antwort nicht rein). Gehen die IP-Pakete tatsächlich mit der richtigen SRC-IP raus? Ist der Port 5061 auch tatsächlich für den Asterisk-Server freigeschaltet? NAT im Spiel? Da hilft nur ein tcpdump-Trace, um zu sehen, was auf IP-Ebene geht. Reden die beiden miteinander? Kannst Du den TCP three-way-handshake sehen? Dabei ist der Connectversuch von Asterisk zu tracen und nicht Dein openssl-Versuch oder telnet-Versuche!

 

[Cenion]

Danke für die Antwort.

Für mich als Laie sieht die Kommunikation erfolgreich aus.
NAT ist aktiv, ja. Wobei dies bei unseren SIP-Trunks der Telekom immer funktioniert hat, und mit TCP ja genauso funktioniert in dieser Konfiguration.

Ich habe die Server (Blau = Prio 10, Schwarz = Prio 20, Grün = Prio 30) entsprechend markiert.


Vollbild(er) gemäß Boardregeln als Vorschau eingebunden by stoney

Kann dir auch gerne per PN den Trace als pcap zur Verfügung stellen.

 

[gehtdoch]

Danke für den Trace. Damit ist klar, dass TCP funktioniert - der TLS - Handshake geht aber den Bach runter - wird von Asterisk beendet (einer der Verbindungsversuche wird von der Telekom beendet) - evtl. kann er den Server nicht verifizieren. So wie ich das interpretiere, versucht es asterisk dann beim nächsten aus der Liste. Fällt dadurch auf, dass beim zweiten Server die Antwortpakete viel größer sind (1390 vs. 1506 - die 1390 sind schon sehr klein - ist da ein Tunnel dazwischen? 1506 ist eigentlich die erwartete Größe).

Was sagt denn:

rasterisk
pjsip show transport [dein Transport - Auswahl bekommst Du mit der Tab-Taste]
Transport:  <TransportId........>  <Type>  <cos>  <tos>  <BindAddress....................>
==========================================================================================

Transport:  t-915                     tls      3    184  192.168.6.170:0

 ParameterName              : ParameterValue
 =============================================================
 allow_reload               : false
 async_operations           : 1
 bind                       : 192.168.6.170:0
 ca_list_file               : /etc/pki/tls/certs/ca-bundle.crt
 ca_list_path               :  
 cert_file                  :  
 cipher                     :  
 cos                        : 3
 domain                     :  
 external_media_address     : external.my.dom
 external_signaling_address : external.my.dom
 external_signaling_port    : 0
 local_net                  : 192.168.0.0/255.255.0.0
 method                     : tlsv1_2
 nobind                     : true
 password                   :  
 priv_key_file              :  
 protocol                   : tls
 require_client_cert        : No
 symmetric_transport        : false
 tos                        : 184
 verify_client              : No
 verify_server              : Yes
 websocket_write_timeout    : 100

Spannend sind die Werte für ca_list_file und verify_server. Funktioniert es, wenn verify_server aus ist? Ist der Pfad bei ca_list_file oder ca_list_path ok? D.h., er führt zu validen Zielen? Hast Du evtl. eigene Zertifikate? Sind das offizielle Zertifikate oder self signed?

Diese Seite sagt auch, dass Du ein entsprechendes Zertifikat in Deiner CA-Liste haben sollst (unter "Verschlüsselung an Nicht-Telekom Endgeräten") - hast Du das?

 

[Cenion]

Du hast Recht, danke fürs Augen-öffnen!
Den Transport hatte ich unter #120 gepostet.
Sobald ich verify_server deaktiviere, funktioniert alles wie gewollt!
Die Zertifikate hatte ich selbst erstellt.
Ich habe es jetzt jedoch selbst mit "ca_list_file : /etc/ssl/certs/ca-certificates.crt" nicht fertig gebracht, verify_server aktivieren zu können, ohne dass Asterisk die TLS-Verbindung wieder abbricht.
Hast du dazu noch einen Tipp?

 

[gehtdoch]

Sehr schön, dann funktioniert es ja mal grundsätzlich. Bis zu #120 hatte ich nicht mehr geschaut. Sorry. Ist auf der anderen Seite hier .

Für einen reinen Client-Betrieb (= Anmeldung zum Provider) benötigt Dein Transport keine eigenen Zertifikate. Die kannst Du in diesem Fall komplett weglassen. Self Signed Zertifikate (=selbst erstellte / signierte Zertifikate) gehen nach außen sowieso nicht - denen vertraut niemand. Daher hat dann wohl auch die Telekom dankend abgelehnt - in einem Fall wurde ja auch von der Telekom beendet.

Hast Du das von der Telekom geforderte Zertifikat, auf das ich in #123 verwiesen habe, in Deiner Zertifikatsliste drin? Dann klappt es wahrscheinlich auch mit dem verify.

Eigene Zertifikate brauchst Du nur dann, wenn sich Clients bei Dir via TLS registrieren können sollen - sprich, Asterisk in der Rolle als Server tätig wird. Falls Du dann trotzdem mit self signed Zertifikaten operieren möchtest, musst Du dafür einen eigenen Transport erstellen und den für die Endpoints verwenden, die sich an Asterisk via TLS registrieren sollen. Ich würde unabhängig davon so oder so getrennte Transports für Server (Netzwerkschnittstelle für Deine Endpoints) und Client (Netzwerkschnittstelle für den Registrierungsclient zum Trunk) machen. Da kannst Du z.B. via alias IPs sogar unterschiedliche IPs auf eine Netzwerkschnittstelle binden - so kannst Du die beiden Schnittstellen übersichtlicher voneinander trennen (v.a. auch hinsichtlich eines FW-Regelwerks).

 

[qupfer2]

Bis voraussichtlich Jahresende werden die Mediasec-Parameter aufgrund des Einsatzes neuer Proxys bei der Telekom überflüssig
[Edit Novize: Überflüssiges Fullquote gemäß der Forumsregeln reduziert]

habs heute mal probiert und tatsächlich. Auf tls und SRTP in der FreePBX-Gui gestellt und es lief. (Asterisk 19.8 und 20.1)

 

[gehtdoch]

Siehe hier.

Aber: die Backup-Server im SRV-Eintrag sind (zumindest hier) alle noch die alten - daher kann man mediasec nach wie vor noch nicht ausschalten (sonst wird es nämlich nichts mit dem Backup). Ist aber nicht weiter dramatisch, weil die neuen Server hinsichtlich mediasec abwärtskompatibel sind (d.h., die kann man auch mit mediasec "belästigen").

 

[Yannik_]

habs heute mal probiert und tatsächlich. Auf tls und SRTP in der FreePBX-Gui gestellt und es lief. (Asterisk 19.8 und 20.1)

Bei mir hat das Aktivieren von SRTP so auf freepbx nicht funktioniert. Anrufe funktionieren danach nicht mehr (Inbound: "Serverfehler", Outbound: "All lines are busy") - warum, habe ich nicht weiter debugged. TLS hatte ich schon lange aktiviert.

Die Server sind bei mir scheinbar noch - allesamt - die alten:

$ dig +short naptr tel.t-online.de
10 0 "s" "SIPS+D2T" "" _sips._tcp.tel.t-online.de.
30 0 "s" "SIP+D2T" "" _sip._tcp.tel.t-online.de.
20 0 "s" "SIP+D2U" "" _sip._udp.tel.t-online.de.
$ dig +short srv _sips._tcp.tel.t-online.de
20 0 5061 d-eps-100.edns.t-ipnet.de.
10 0 5061 hh-eps-100.edns.t-ipnet.de.
30 0 5061 h2-eps-100.edns.t-ipnet.de.
$ dig +short srv _sip._tcp.tel.t-online.de
30 0 5060 h2-epp-100.edns.t-ipnet.de.
20 0 5060 d-epp-100.edns.t-ipnet.de.
10 0 5060 hh-epp-100.edns.t-ipnet.de.
$ dig +short srv _sip._udp.tel.t-online.de
30 0 5060 h2-epp-100.edns.t-ipnet.de.
20 0 5060 d-epp-100.edns.t-ipnet.de.
10 0 5060 hh-epp-100.edns.t-ipnet.de.

 

[gehtdoch]

Ja - die neuen Server werden (zu Recht!) sehr vorsichtig eingeführt. Das ganze ist auch regional zu betrachten. (Nicht nur) daher habe ich ja auch geschrieben, dass es bis auf Weiteres noch viel zu früh ist, auf Mediasec zu verzichten. Man könnte auch so formulieren: im Einzelfall tauchen schon neue Server (temporär) auf, bei denen kein Mediasec benötigt wird - was aber kein Sinn macht am Ende des Tages, weil die Backup-Liste immer noch Mediasec benötigt! Solange keine Komplettumstellung aktiv ist, muss man Mediasec nutzen. Daher habe ich ja auch hier geschrieben, woran man einen neuen Server erkennt.

 

[qupfer2]

Eventuell hats bei mir auch deshalb funktioniert?

[ASTERISK-30032] Support of mediasec SIP headers and SDP attributes - Digium/Asterisk JIRA

issues.asterisk.org

(nutze ja 20.1)

 

[gehtdoch]

1. Nur, wenn Du es expl. konfiguriert hast,
2. Würde ich von diesem Change bis auf Weiteres dringend die Finger lassen, weil der nicht immer sauber funktioniert. Du riskierst, dass Deine ganze Nummern offline gehen.
3. Außerdem fehlen basale Dinge.

Der Entwickler weiß das (schon lange), und hat auch teilweise schon Patche dafür zur Verfügung gestellt - die aber (warum auch immer) nicht den Weg ins Release gefunden haben. Warum das dann trotzdem so angenommen wird und dann auch noch als stable rausgeht - ich kann es nicht nachvollziehen. Spricht nicht gerade für die Qualität und Zuverlässigkeit der Asteriskmaintainer. Denen scheint wohl so ziemlich egal zu sein, was da in Asterisk reinkommt.

 

[qupfer2]

Vollzitat gemäß Boardregeln entfernt by stoney

Alles klar.
Konfiguriert hatte ich nichts, aber tatsächlich taucht ein Server mit neuem Namensschema in der DNS Liste auf. Vermutlich lief es deshalb.
Mein Hauptanschluss lass ich dann aber lieber weiter über die FritzBox laufen und meine Testnummer direkt. Mal schauen ob sie gelegentlich (r)ausfällt .

 

[gehtdoch]

Bei den neuen SIP-Servern brauchst Du kein Mediasec mehr - daher funktioniert es da. Hat also mit dem Patch überhaupt nichts zu tun.

Edit 30.01.2023:
Aktueller Patch: siehe hier.

 

[Yannik_]

Update:
Inzwischen ist auch bei mir einer der neuen Server aufgetaucht:

20 0 5061 h2-eps-100.edns.t-ipnet.de.
30 0 5061 d-eps-100.edns.t-ipnet.de.
10 0 5061 hmb026-l01-mav-pc-rt-001.edns.t-ipnet.de.

RTP/SAVP (SRTP) funktioniert.

Apropros: Nur TLS, ohne gleichzeitige Verwendung von SRPT, scheinen die neuen Server nicht zu akzeptieren.

 

[Meester Proper]

Apropros: Nur TLS, ohne gleichzeitige Verwendung von SRPT, scheinen die neuen Server nicht zu akzeptieren.

Das hätte auf den alten Proxys auch eigentlich nicht funktionieren sollen, wurde aber offenbar nicht auf allen Proxys identisch konfiguriert.

 

[Yannik_]

Interessant, nach einiger Zeit erhalte ich nun folgenden Fehler:

<--- Transmitting SIP request (498 bytes) to TLS:217.0.130.69:5061 --->
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/TLS 1.2.3.4:5061;rport;branch=z9hG4bKPj76b53522-36c9-4f5b-9b49-f683116ac96b;alias
From: <sip:[email protected]>;tag=aeac9d9a-45a6-4540-9dc9-236020df61f6
To: <sip:[email protected]>
Call-ID: 6c808695-6ce7-4a5e-aeda-717f8ba9f7bf
CSeq: 60602 REGISTER
Contact: <sip:[email protected]:5061;transport=TLS;line=lxsfkhq>
Expires: 0
Max-Forwards: 70
User-Agent: FPBX-16.0.40.3(16.28.0)
Content-Length:  0


<--- Received SIP response (631 bytes) from TLS:217.0.130.69:5061 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/TLS 1.2.3.4:5061;received=79.222.137.149;rport=51175;branch=z9hG4bKPj76b53522-36c9-4f5b-9b49-f683116ac96b;alias
From: <sip:[email protected]>;tag=aeac9d9a-45a6-4540-9dc9-236020df61f6
To: <sip:[email protected]>;tag=mavodi-0-4b-0-2-ffffffc7-1747-ffffffffffffffff-b0830000-64598e97-_02E580FEE57A-15c4-2a8c700-1679b2f-648612d0-2d89c
Call-ID: 6c808695-6ce7-4a5e-aeda-717f8ba9f7bf
CSeq: 60602 REGISTER
Reason: SIP;cause=403;text="CC_IMS_OBSOLETE_DEREG"
Session-ID: 00000000000000000000000000000000; remote=10e8b01e42266ee442ad9952255ba100
Content-Length: 0

Jemand eine Idee, was "CC_IMS_OBSOLETE_DEREG" bedeuten könnte?
Edit: Schalte ich TLS/SRTP wieder ab, funktioniert das REGISTER auch nicht. 403 mit Fehler "CC_IMS_MAA_FAILURE".

 

[Meester Proper]

Was ist denn der Sinn und Zweck dieser Deregistrierung (expires=0)?

 

[gehtdoch]

Asterisk macht beim Register an einen Server, bei dem es aus seiner aktuellen Sicht direkt(!) vorher nicht registriert war, erstmal ein Deregister.

Der T-Server teilt ihm dabei mit, dass das quatsch ist (CC_IMS_OBSOLETE_DEREG -> unnötige Deregistrierung, vermutlich weil nicht registriert - es macht keinen Sinn, sich irgendwo zu deregistrieren, wo man gar nicht registriert war).

Irgendwas hat Asterisk wohl aus der Bahn geschmissen (falls es nicht ein Problem des Telekom-Servers war - so richtig stabil sind die "neuen" nach meiner bisherigen Erfahrung noch nicht - ich hatte den einige Monate auf die Blacklist gesetzt, weil es immer wieder zu Wacklern kam. Erst aktuell beobachte ich mal eine Phase richtig stabiles Fahrwasser, wie ich es von der Telekom über Jahre bei den alten Servern bisher gewohnt war - die, oder besser der, war rockstable).
Dein Problem kann man aber nur beurteilen, wenn man sich einige Registers vor dieser Aktion anschaut. Alles andere ist Kaffeesatzleserei.

 

[Yannik_]

Nach dem ursprünglichen Schluckauf ist die Registrierung nun seit 5 Tagen stabil.. Keine Ahnung, woran das lag.

 

[Yannik_]

Schwups, heute ist der neue Server wieder weg, und plötzlich gehen keine Anrufe mehr (fehlgeschlagene RTP/SAVP negotiation):

20 0 5061 h2-eps-100.edns.t-ipnet.de.
30 0 5061 d-eps-100.edns.t-ipnet.de.
10 0 5061 hh-eps-100.edns.t-ipnet.de.

Tatsächlich scheinen *sämtliche* neue Server nicht mehr erreichbar zu sein.

hmb026-l01-mav-pc-rt-001.edns.t-ipnet.de
ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de
hno002-l01-mav-pc-rt-001.edns.t-ipnet.de
dtm010-l01-mav-pc-rt-001.edns.t-ipnet.de

akzeptieren allesamt keine Verbindungen auf Port 5060/5061 (und beantworten keine PINGs).

Das deaktivieren von SRTP löst das Problem, ist jedoch insofern problematisch, dass, sobald wieder einer der neuen Server auftauchen sollte, das ganze wieder nicht funktioniert, da die neuen Server kein TLS ohne gleichzeitiges RTP/SAVP akzeptieren. Super!