TCP funktioniert und UDP erreicht auf demselben Port einen anderen Server

Ein Profil funktioniert über TCP und scheitert über UDP mit einer Zertifikatswarnung. Die naheliegende Lesart ist, dass der UDP-Pfad das Vertrauen gebrochen hat, und die naheliegende Korrektur ist, das Zertifikat zu akzeptieren. Beide Annahmen überspringen eine Möglichkeit, die das Symptom vollständig erklärt: Die beiden Transporte haben unterschiedliche Maschinen erreicht. Eine Weiterleitungsregel wird pro Protokoll zugeordnet, und nichts erzwingt, dass die TCP- und die UDP-Hälfte einer Portnummer auf denselben Host zeigen.

Eine Portnummer, zwei unabhängige Regeln

Weiterleitung ist eine Tabellensuche, die nach Protokoll, Zieladresse und Port erfolgt. Ein Gateway mit einer Regel für TCP 1194 und einer Regel für UDP 1194 drückt zwei unabhängige Entscheidungen aus, und diese können verschiedene interne Hosts benennen. Die gemeinsame Nummer ist eine Bequemlichkeit für Menschen, keine Eigenschaft, die das Netzwerk erzwingt. Behandeln Sie die Portnummer als Beschriftung und nicht als Dienstdefinition.

Betrachten Sie die wirksamen Regeln und nicht die beabsichtigten. Zieladresse, übersetzter Port und Eingangsschnittstelle wirken alle mit, und eine übrig gebliebene Regel aus einer früheren Migration ist der übliche Grund, warum die beiden Hälften nicht übereinstimmen.

Schreiben Sie beide Zuordnungen auf, bevor Sie etwas anderes ändern. Das Zeilenpaar ist die gesamte Hypothese.

Was der Client tatsächlich geprüft hat

Während des Handshakes prüft der Client das Zertifikat gegen sein konfiguriertes Vertrauen und gegen den Namen, den er erwartet. Ein unerwartetes Zertifikat ist eine erfolgreiche Verifikation, die die Identitätsprüfung nicht bestanden hat, und das ist das richtige Ergebnis, wenn der Gegenüber nicht der ist, den Sie erreichen wollten. Es abzulehnen ist ein Beleg dafür, dass der Client funktioniert, und nicht dafür, dass der Transport defekt ist. Lesen Sie den gemeldeten Namen vor der gemeldeten Kette, denn der Name ist das, was der Client verglichen hat.

Die Unterscheidung ist wichtig, weil die beiden Fehler zu unterschiedlichen Korrekturen führen. Ein Vertrauensproblem braucht eine Vertrauenskorrektur, während ein unerwarteter Gegenüber eine Korrektur an Routing oder Weiterleitung braucht.

Notieren Sie, welche Identität der Client gemeldet hat. Dieser Name ist der stärkste Hinweis darauf, welche Maschine geantwortet hat.

Den Versuch einem Server zuordnen

Notieren Sie das Profil, die öffentliche Adresse, den Transport und den Port, den der Client verwendet hat. Ordnen Sie dann die Zeit des Versuchs dem Protokoll des Servers zu, den Sie erreichen wollten. Dessen Fehlen ist ein Hinweis und kein Beweis für einen Firewall-Verwurf, weil sich die Protokollierungsstufen zwischen Installationen unterscheiden. Ein Zeitstempel zusammen mit einer Quelladresse grenzt es stärker ein als beides allein.

Vergleichen Sie die Zertifikatsidentität, auf die Sie gestoßen sind, über einen administrativen Kanal mit der erwarteten Identität. Dieser Vergleich außerhalb des Kanals ist es, was die Prüfung vertrauenswürdig hält.

Prüfen Sie alte Weiterleitungsregeln, alternative Listener und jeden Lastverteilungspfad, bevor Sie schließen, dass beide Transporte ein Backend teilen. Jeder davon kann einen Fluss umleiten, ohne den anderen Transport zu berühren.

Vertrauen nicht an einen falschen Gegenüber anpassen

Das Importieren der unerwarteten CA lässt das Symptom verschwinden und ändert, wem der Client vertraut. Das ist ein schlechterer Zustand als eine fehlgeschlagene Verbindung, weil es die Nichtübereinstimmung verbirgt, statt sie aufzulösen. Dasselbe gilt für das Abschalten der Prüfung, nur um zu sehen, ob der Tunnel hochkommt.

Wenn sich der Gegenüber als legitim, aber unbeabsichtigt herausstellt, besteht die richtige Handlung darin, ihn außer Betrieb zu nehmen oder die Regel auf den richtigen Host zu richten. Der Vertrauensspeicher ist nicht der Ort, um einen Inventurfehler zu bereinigen.

Bewahren Sie den Ablehnungstext auf. Er ist der einzige Beleg dafür, was der Client gesehen hat.

Nach der Korrektur einen neuen Fluss testen

Korrigieren Sie die Zuordnung und verbinden Sie sich dann mit einer neuen Client-Sitzung. Zustandsbehaftete Übersetzung kann einen bestehenden Fluss auf das alte Ziel zeigen lassen, sodass eine etablierte Verbindung die Änderung überlebt und Sie in die Irre führt. Starten Sie eine neue und bestätigen Sie im Protokoll des beabsichtigten Servers, dass er den Versuch behandelt hat.

Wenn beide Transporte nachweislich denselben Server erreichen und sich dennoch unterschiedlich verhalten, ist der verbleibende Unterschied die eigene Listener- und Konfigurationslage dieses Servers. Der Transportvergleich bedeutet erst etwas, wenn die Endpunktidentität feststeht.