PLUCS / XMPP / ejabberd mit unterschiedlicher Domain

Hallo zusammen,

ich habe gerade unseren alten ejabber-Server durch die UCS PLUCS-App ersetzt aber habe noch massive Probleme mit der Konfiguration.
Unser alter Server hörte auf die Jabber-Domain: jabber.firma.de, die auch von außen erreichbar ist, also S2S ist aktiv (wurde per Registry auch auf dem UCS aktiviert).
Der UCS ist als AD konfiguriert und verwendet, da er intern läuft als Domain: firma.local.
Wenn ich in den XMPP-Einstellungen für Computer und Benutzer als Domain firma.local angebe, dann können die Benutzer sich auch korrekt am XMPP-Server mit Benutzername@firma.local anmelden, sind jedoch dann nicht mehr von außen erreichbar.
Wenn ich bei Computer und Benuter die Domäne jabber.firma.de eintrage, dann ist keine Verbindung vom Client vom Server möglich, als Fehler kommt dann so eine tolle Nachricht wie “Rechner unbekannt”.

Wie richtet man PLUCS auf einem internen UCS AD korrekt ein, damit er auch extern und mit der externen Domain funktioniert?
Bin über jeden Tipp mehr als dankbar. :slight_smile:

MfG, Christian Frey.

Hallo,

Ja, das ist nicht trivial. Das was Sie dem EJabberD als “Domain” geben ist lediglich eine Art Namensraum und muß nicht zwingend mit dem DNS Namen des Hosts übereinstimmen. Sinnvoll den gleichen Domain-Namen anzugeben ist es natürlich dann, wenn Ihr XMPP Host von der Außenwelt gefunden werden soll. Die _SRV Records haben Sie ja sicher schon, sonst würde ja niemand von außen eine S2S Verbindung bekommen. Insofern sollte Ihr XMPP Host als XMPP Domain auch “firma.de” haben.

Nun zur Einrichtung innen. Der Fehler “Rechner unbekannt” (von welchem XMPP Client?) kommt nur daher, daß die Standardeinstellung so ist, daß der Client die Jabber ID des Nutzers (uid@firma.de) nimmt, und dann im DNS einen _SRV Record oder einen Alias “firma.de” sucht, mit dem er sich verbinden kann. Und das schlägt innerhalb der Firma fehl, entweder weil ‘jabber.firma.de’ im DNS nicht aufgelöst wird, oder weil ‘jabber.firma.de’ mit seiner Außenadresse von innerhalb nicht zugreifbar ist (bei den meisten Routern ist das so).

Für einen einzelnen Client kann man jederzeit einstellen, daß er einen abweichenden Host ansprechen soll, der nicht der Jabber-Domain entspricht (einzige bisher mir bekannte Ausnahme ist “Swift”, der braucht zwingend einen _SRV Record). Das artet aber in Admin-Arbeit und Support aus, wenn man mal über 50 oder mehr Clients nachdenkt, es sei denn, man hat das Ausrollen und automatische Konfigurieren der Clients auch in der Hand.

Besser wäre aber wahrscheinlich, wenn Sie im internen DNS dafür sorgen, daß entweder ‘jabber.firma.de’ von innerhalb aufgelöst wird auf die innere Adresse Ihres Servers, oder daß die Clients einen _SRV Record im DNS vorfinden, der auf die innere Adresse zeigt.

Ich kenne die Situation in Ihrem Netz nicht. Können Sie die Ergebnisse der folgenden Kommandos (natürlich abgewandelt) posten? (alles von einem Clientrechner im internen Netz aus)

dig -t SRV _xmpp-client._tcp.firma.de
route -n
ping jabber.firma.de

viele Grüße
Frank Greif.

Hallo Frank Greif,

Das denke ich mir auch, denn auf dem alten Jabber-Server hatten wir ja genau dieses Szenario. Intern hieß der Server auch nur jabber.firma.local, aber der Jabber Namensraum war jabber.firma.de. Allerdings waren dort alle Jabber-Benutzer “lokal”, d.h. es gab keine Anbindung an ein LDAP oder ähnliches.

Das stimmt nicht ganz, wir haben für unseren externen Zugang bisher noch keine _SRV Records angelegt, aber andere Jabberserver unserer Kunden konnten sich trotzdem wunderbar mit unserem Jabber verbinden.

Ja, das wäre schön :slight_smile:

Als Clients kommen gerade Adio unter OSX und Pidgin unter Ubuntu zum Einsatz.

Wie auch schon mit unserem alten Server mussten wir natürlich im Client unter Server die interne Adresse, oder den internen Namen eintragen, aber dies hatte dann mit UCS PLUCS leider nicht mehr funktioniert, zumindest nicht, solange der EJabberD Namensraum ein anderer war, als unsere AD Domäne.

ja, so ist das bei uns …

[quote=“greif”] der nicht der Jabber-Domain entspricht (einzige bisher mir bekannte Ausnahme ist “Swift”, der braucht zwingend einen _SRV Record). Das artet aber in Admin-Arbeit und Support aus, wenn man mal über 50 oder mehr Clients nachdenkt, es sei denn, man hat das Ausrollen und automatische Konfigurieren der Clients auch in der Hand.

Besser wäre aber wahrscheinlich, wenn Sie im internen DNS dafür sorgen, daß entweder ‘jabber.firma.de’ von innerhalb aufgelöst wird auf die innere Adresse Ihres Servers, oder daß die Clients einen _SRV Record im DNS vorfinden, der auf die innere Adresse zeigt.[/quote]
Die DNS Umschreibung ist bei uns aktiv. jabber.firma.de wird intern auf die IP von jabber.firma.local geleitet.

wie oben bereits erwähnt gibt es diesen Eintrag nicht.

ist wirklich unspannend, da es nur eine Default-Route zu unserer Firewall gibt :slight_smile:

liefert die Ping-Ergebnisse zu unserem internen Server, da ich in der Firewall DNS überschreiben lasse und damit jabber.firma.de nach jabber.firma.local aufgelößt wird.

Seltsam ist, ich habe nun bei mir noch einmal umgestellt von firma.local auf jabber.firma.de und es funktioniert auch (Pidgin/Ubuntu), auf einem anderen Rechner (Adio/OSX) funktioniert es (noch) nicht … und als Fehler kommt ein Verbindungsfehler. Beide Rechner lösen aber sowohl jabber.firma.local als auch jabber.firma.de korrekt auf die interne Adresse auf.

MfG, Christian Frey.

Hallo,

zunächst noch eine Ergänzung zum Thema SRV-Records:
Das ist erstmal nur eine Komfortfunktion und erspart die manuelle Eingabe des Servers.
Bei uns sieht das so aus:

$ dig +short -t SRV _xmpp-client._tcp.it25.de @8.8.8.8 5 0 5222 sync.it25.de.
Dieser Server steht übrigens auch bei uns im internen Netz und heißt eigentlich auch nicht genau so. Unser internes UCS-DNS ist ebenfalls nicht für it25.de zuständig.

Wenn es bei Ihnen nun mit bestimmten Clients funktioniert und nur mit Adium nicht, könnte es z.B. auch daran liegen, dass sich der Client am SSL-Zertifikat (wir benutzen als default die vorhandene UCS-CA, ansonsten das, was in plucs/certfile steht) stört. Meine eigenen Apfel-Zeiten liegen schon ein paar Jahre zurück, aber soweit ich mich erinnere, kann man da irgendwo auch ein Debuglog aktivieren. Da müsste man was sehen.
Auf dem Server wird auch nach /var/log/ejabberd/ejabberd.log protokolliert , dessen Loglevel müsste mit plucs/loglevel einstellbar sein.

Viele Grüße,
Dirk Ahrnke

Hallo,

[quote=“ahrnke”]zunächst noch eine Ergänzung zum Thema SRV-Records:
Das ist erstmal nur eine Komfortfunktion und erspart die manuelle Eingabe des Servers.
Bei uns sieht das so aus:

$ dig +short -t SRV _xmpp-client._tcp.it25.de @8.8.8.8 5 0 5222 sync.it25.de.[/quote]
vielleicht setzen ich den Eintrag auf unserem externen DNS auch mal, also nicht Ihren, sondern für unseren Jabber :slight_smile:

Ich hatte den LogLevel schon auf 5 gestellt, aber so richtig sinnvolles stand in den LogFiles nicht drin.

Nun gibt es aber Neues vom fauligen Apfel:
Der Adium war das Problem, bzw. dessen IP-Auflösung. Unser DNS gibt für den Jabber zwei IP-Adressen zurück, weil der Server in zwei Netzen erreichbar ist. Mein Pidgin hat sich daran nicht gestört, der Adium hat anscheinend immer versucht auf die falsche IP aus dem falschen Netz zu verbinden. Seit dieser nun direkt auf IP geht funktioniert es dort auch.

Puh, war nun eine schwere Geburt, aber nun scheint alles zu laufen, prima :slight_smile:
Vielen Dank.

MfG, Christian Frey.

Mastodon