Wenn man sich das genau ansieht, wobei „MAILSERVER“ unsere Mailserver IP war, wird man bei HOST das irritierende „:26“ entdecken. Die Portnummer gehört im HTTP Protokoll gar nicht in den „Host:“- Header rein, trotzdem hat dieses miserable Script es angehängt. Unser Glück, so kann man das aufklären 🙂
Es handelt sich offenbar um einen Portscanner, der bei „nicht-so-standart“-Ports wie „26“ , einfach mal austestet, ob da nicht ein Webserver zu finden ist. Vielleicht in der Hoffnung da was zu finden, was auf Port 80 nicht zu finden wäre, wer weiß. Auf Port 26 hat unser Mailserver einen Ausweichport, falls der DSL-Router des Kunden mal wieder Port 25 für alles außer T-Offline-Mailservern sperrt. Das hat sich in der Vergangenheit extrem gut bewährt, weil man im Mailprogramm nur statt Port 25 26 angeben brauchte und schon war diese leidige Routersperre umgangen.
Eingeführt haben die Routerhersteller das, damit die ganzen gehackten Windows-Pcs nicht ständig das Netz mit Spams beglücken. Das war aber nur bedingt erfolgreich 😉
Wie kam ich jetzt auf dämlich, achso ja, weil sich der Mailserver natürlich, wie auf Port 25 auch, sofort als Mailserver outet 🙂 Man muß also nicht erst HTML hinschicken um zu sehen was es ist 😀
sagt dem entfernen Server normalerweise, daß der Remote-Server einen Port 24007 für alle zugänglich auf 0.0.0.0 binden soll und alles was reinkommt, soll an die lokale IP 192.168.178.1 Port 24007 weitergeleitet werden.
Wenn das aber immer im Netstat auf 127.0.0.1 angezeigt wird:
dann ist Eure SSHD-Config zu alt 🙂 Vor einigen Jahren wurde eine neue Option eingeführt, so daß der SSHD zwingend konfiguriert sein muß, globale Ports binden zu können.
Die Lösung
Fügt in die /etc/ssh/sshd_config die folgende Zeile ein und startet den Dienst neu:
GatewayPorts yes
Damit darf der SSHD das wieder für Euch erledigen und die Tunnelwelt funktioniert für Euch wieder.
Einen ganzen Vormittag kann man damit verbrennen, wenn Jitsi und Linphone zusammen laufen und beide SIP VOIP Anschlüsse bedienen können sollen. „Sollen“, weil „können“ tun sie es nicht, bis man die wahre Ursache erkennt 🙂
Falls der geneigte Leser etwas Frust aus dem Text herausliest, „etwas“ ist stark untertrieben.
Was war passiert ?
Nun, ich hatte LinPhone4 installiert, um es auszuprobieren und es behalten, weil es, an dem Tag, besser mit Sipgate funktionierte, als Jitsi, welches mit Sipgate gar nicht mehr kann 🙁 Jetzt mußte ich feststellen, daß ich mit LinPhone ohne irgendwelche Fehlermeldungen auf UI Seite, weder angerufen werden, noch selbst anrufen konnte, egal auf welchem Konto!
Nachdem ich in den Einstellungen von LinPhone die Position des Logs gefunden hatte, fielen mir dort wiederholt diese Zeilen auf:
2017-10-05 11:25:17:394 ERROR No listening point matching for [udp://sipgate.de:5060] 2017-10-05 11:25:17:394 ERROR belle_sip_client_transaction_send_request(): no channel available
Natürlich neben jeder Menge „Technobabble“ des Clienten, versteht sich 🙂
Was sagt uns das ?
Antwort: Nichts 🙂
Lediglich 1 .. in Worten EINE .. Webseite konnte Google finden, die schon mal was davon gehört hatte. Zum Glück, war es die richtige.
Übersetzt meint die Fehlermeldung, daß das Programm keinen Kommunikationskanal öffnen konnte. Nur wieso nicht, darüber schweigt es sich aus. Hellseher haben halt immer Konjunktur, weil der Rest blöd genug ist, Raum für deren „Notwendigkeit“ zu schaffen. Dank der einen Webseite, war es dann aber zum Glück recht einfach, der Ursache auf die Spur zu kommen.
Auflösung
Einen „Channel“ etabliert man, in dem man einen TCP Port bindet und dem Gegenüber sagt, das man darauf angerufen werden kann. Wieso man beim „Anrufen“ nicht direkt mit dem SIP Provider eine TCP-Connection aufmachen kann, will ich gar nicht wissen, wenn man SIP lernen will, wird man eh durch Unlogik erschlagen. IMHO, eins der schlechtesten Protokolle aller Zeiten. Stückwerk ^10.
Ok, was braucht man um einen Port zu binden ? Eine Portnummer und niemanden, der schneller als man selbst war! Mit anderen Worten, Jitsi hatte sich schon permanent auf Port 5060 gebunden, weswegen Linphone das nicht konnte. Soweit, so in den RFCs für TCP Ports vorgesehen. Warum Linphone das nicht schreiben kann, ist ein weiteres Rätsel, weil die Fehlermeldung des TCP/IP Stacks zu dem „Fehler“ ist eindeutig!
Jetzt bietet LinPhone in den Kontoeinstellungen an, daß man statt Port 5060 zufällige Ports benutzen kann. Wieso das nicht der Standard ist, wird man nie erfahren. Jedenfalls funktioniert das SIP Konto sofort, wenn man die feste Portzuweisung abgeschaltet hat:
Fazit: In Jitsi habe ich jetzt SIP deaktiviert, damit entfällt auch das Binden des Ports.
Da Jitsi eh derzeit nicht mit Sipgate kann, spielt das es keine Rolle mehr. Warum das alles am Tag, an dem ich Linphone ausprobiert habe, funktioniert hat, ist ein weiteres Mysterium.
Das VOIP stinkt, dürfte vielen leidgeplagten Telefonanschlußinhabern bekannt sein, wie sehr das grade stinkt, hier im Überblick:
Skype:
Old: Raustelefonieren geht, angerufen werden geht nicht. New: Raustelefonieren geht, Gui ist Mist, angerufen werden, geht nicht, weil sobald man „abnimmt“ legt Skype auf! Fix in Sicht ? Nein. Problem bekannt ? Seit Monaten.
Jitsi:
Fritz!box: Raus geht, Rein geht. Sipgate: Raus geht, Rein geht nicht.
Jitsi Android:
Fritz!box: geht gar nicht. Sipgate: Raus geht, Rein geht.
LinPhone:
Fritz!box: geht beides Sipgate: geht beides
Einzig gültiger Kommentar zu Sipgate+Jitsi: AAAAAAAAAAAAAAAAAAAARRGGS!
