Der (vielleicht korrekte) Aufbau einer Kommunikationsverbindung im IP-Netz

Wie baut man eine Kommunikationsverbindung im IP-Netz auf?

In vielen Softwareprojekten, egal ob offen oder kommerziell, wird der Verbindungsaufbau bzw. die Parametrisierung dieser immer wieder falsch begangen.

Ich möchte hier nun eine kurze Anleitung geben, wie diese sinnvoller erfolgen kann. Hierzu müssen wir für uns definieren, in wie weit die Verbindung automatisiert oder durch administrative Eingaben erfolgen soll. Es sollte der Ansatz verfolgt werden, dass so viele Parameter wie möglich (besonders beim Endanwender) automatisch aus dem Netzwerk ermittelt werden soll.

Hierbei kann wie folgt vorgegangen werden:

1. DNS Namensauflösung zur technischen Adressierung verwenden
2. Ermitteln weiterer Verbindungsparameter für den  Dienst
3. Konnektierung bzw. Kontextwechsel zur etablierten Verbindung hin

1. DNS Namensauflösung

Zur korrekten Adressierung von Diensten ist es sinnvoll, nicht nur eine einfache Namensauflösung zum DNS Typ A oder AAAA durchzuführen, sondern auch auf Diensteeinträge zu prüfen. Hierbei wird zur angegeben Domäne einfach ein Prefix aus "_<Dienstename>._<Protokoll>." vorangestellt und der Datentyp "SRV" abgefragt. Wird keine Information gefunden, kann eine Typ "A" oder "AAAA" Abfrage erfolgen. Eventuell muss auch das Protokoll beachtet werden.

Wird ein A oder AAAA Eintrag aufgelöst, sollte als erstes eine Verbindung zu dem Standardport des Dienstes aufgebaut werden.

Wurde ein Diensteeintrag ermittelt, bekommt man nun alle Grundparameter zur Adressierung des Dienstes geliefert. Parameter die in einem Diensteeintrag hinterlegt sind: Priorität, Gewichtung, Port und das Ziel des Dienstes. Über den Port und das Ziel kann nun eine erste (initiale) Verbindung zum Dienst aufgebaut werden.

Anmerkungen:

Die Priorität und Gewichtung dient der Sortierung der Liste der Einträge, da es mehrere Diensteeinträge bzw. Server für einen Dienst geben kann. Eventuell kann auf die Sortierung nach Priorität und Gewichtung verzichtet werden, wenn sich die Netzwerkumgebung innerhalb einer Strukturdomäne befindet (Firma, Behörde, etc.) und über den DNS die Einträge vorsortiert werden, um eine geographische Abbildung zum nächsten Server zu ermöglichen.

2. Ermitteln weiterer Verbindungsparameter

Die initiale Verbindung ist aufgebaut. Nun kann je nach Dienst die Ermittlung von weiteren spezifischen Verbindungsparameter erfolgen. Als Beispiel soll uns hier der Dienst LDAP dienen. Durch die Abfrage des RootDSE und den Attributen:

NamingContexts
supportedSASLMechanisms
supportedLDAPVersion
supportedExtension
supportedFeatures
supportedControl

bekommen wir weitere wichtige Parameter wie z.B. den Basis DN, die Unterstützung von TLS (STARTTLS),  die LDAP Protokollversion und die Protokolle im SASL Stack  heraus.

Beispiel:

NamingContext: dc=myserver,dc=local
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedSASLMechanisms: GSSAPI

Wir können also über Inband Signalisierung einen TLS Tunnel über die bereits bestehende Verbindung aufbauen. Des Weiteren verbinden wir uns mit der Basis dc=myserver,dc=local und melden uns per GSSAPI (Kerberos) an.

Hierdurch konnte unser Client alle für die Verbindung relevanten Parameter automatisch ermitteln, ohne dass auch nur eine weitere Angabe des Anwenders von nöten gewesen wäre.

LDAP Extension ID for STARTTLS: 1.3.6.1.4.1.1466.20037

IANA LDAP Parameters: http://www.iana.org/assignments/ldap-parameters/ldap-parameters.xml