Warum eine OpenVPN-UDP-Antwort von der falschen Adresse kommt

Ein OpenVPN-Client wählt eine Adresse, der Server antwortet von einer anderen, und der Tunnel kommt nie zustande. Das Serverprotokoll zeigt das ankommende Paket, und ein Mitschnitt zeigt die abgehende Antwort, also wird der Fehler dem Client angelastet. Auf einem Host mit mehreren Schnittstellen oder mehreren Adressen auf einer Schnittstelle sind sich beide Seiten schlicht uneinig darüber, welche Adresse verwendet wird. Die Antwort ist auf IP-Ebene gültig, dennoch verwerfen viele Clients ein Datagramm, dessen Quelle nicht die Adresse ist, die sie angesprochen haben.

Was der Client sieht, wenn sich die Quelle ändert

Ein UDP-Socket, der nicht an eine bestimmte lokale Adresse gebunden ist, hat keine feste Quelle, daher wählt der Kernel beim Senden eine aus. Diese Wahl stammt aus einer Routensuche zur Adresse des Clients, und die Quelle wird die Adresse der Schnittstelle, die die Suche auswählt. Auf einem Rechner mit nur einer Schnittstelle ist die Wahl unsichtbar; auf einem Host mit Verwaltungsadresse, öffentlicher Adresse und einer Zweitadresse auf derselben Netzwerkkarte hängt sie von Routing-Metriken und -Richtlinien ab. Richtlinienbasiertes Routing macht die Abweichung wahrscheinlicher statt unwahrscheinlicher, weil eine Regel einen Uplink auswählen kann, den der Client nie erreicht hat. Eine von einem Anbieter gelernte Standardroute plus eine Quellregel, die auf einen anderen zeigt, genügt, um das herbeizuführen.

Clients, die Antworten filtern, und Verbindungsverfolgung, die das exakte Vier-Tupel und die Quelle erwartet, verwerfen die Antwort ohne brauchbare Meldung. Der Tunnel läuft dann ab, als wäre nichts angekommen, weshalb das fälschlich für ein Firewall-Problem auf Clientseite gehalten wird. Ein nur auf dem Server erstellter Mitschnitt bestätigt den Fehler, statt ihn zu erklären, denn die Antwort geht wirklich hinaus. Vergleichen Sie die Quelle der Antwort mit der Adresse, die der Client gewählt hat, bevor Sie etwas anderes ändern.

Was die Option multihome tatsächlich bewirkt

Die Direktive wird als multihome in einer Konfigurationsdatei und als --multihome auf der Befehlszeile geschrieben, und sie bringt einen UDP-Server dazu, von der Adresse zu antworten, die das Paket des Clients erreicht hat. Der Kernel übergibt die ursprüngliche Zieladresse beim Empfang als Zusatzdaten, und OpenVPN verwendet diesen Wert als Quelle der Antwort. Ein Server, der auf einer Platzhalteradresse lauscht, local 0.0.0.0 für IPv4 oder das IPv6-Äquivalent, verhält sich dann, als hätte jeder Client einen eigenen Listener erreicht. Clients, die über die öffentliche Adresse hereinkommen, erhalten Antworten von der öffentlichen Adresse, und Clients auf einer internen Adresse erhalten sie von dieser. Sonst bewegt sich nichts im Paketpfad: die Route, die Filterregeln und die Tunnelkonfiguration bleiben genau, wie sie waren.

Gerade diese letzte Eigenschaft macht die Option für einen ansonsten funktionierenden Server unbedenklich, und sie ist auch der Grund, warum sie einen Filter nicht reparieren kann, der nur eine Adresse zulässt. Das Paket muss weiterhin auf dem Weg angenommen werden, den es nimmt, daher ändert die Quellkorrektur den Ursprung der Antwort und nichts weiter. Sie gilt außerdem nur für UDP: ein TCP-Listener hat dieses Problem nicht in derselben Form, weil die Verbindung über das Vier-Tupel statt über die Quelladresse der Antwort identifiziert wird.

Wann eine feste lokale Adresse die falsche Voreinstellung ist

Bevor Sie zur Option greifen, prüfen Sie, ob der Server eine bestimmte lokale Adresse bindet, denn ein gebundener Listener antwortet immer von dieser Adresse. Das ist für eine Bereitstellung mit einer Schnittstelle richtig und falsch, sobald Clients berechtigt mehr als eine Adresse nutzen. War die Bindung beabsichtigt, entscheiden Sie, ob der Server überhaupt Verkehr auf weiteren Adressen annehmen soll. Das Entfernen der Bindung erhöht die Angriffsfläche, daher müssen die zulässigen Schnittstellen und Quellnetze vom Dienst und vom Filter durchgesetzt werden, nicht allein von der Bindungsadresse.

Die OpenVPN-Referenz beschränkt die Option auf UDP-Server, vermerkt die zusätzliche Verarbeitung im Paketpfad und hält fest, welche Plattformen sie unterstützen. Bestätigen Sie das an der installierten Version, bevor Sie damit planen. Wo sie nicht unterstützt wird, ist das Binden der bestimmten Adresse oder das Korrigieren des Rückwegs die Alternative, und beides sind engere Änderungen, als es zunächst scheint. Lauschen auf einer Platzhalteradresse hat auch Folgen über Antworten hinaus: ein Server auf allen Adressen ist aus jedem Netz erreichbar, an das der Host angeschlossen ist, und das ist möglicherweise nicht die Angriffsfläche, die jemand beabsichtigt hat.

Beweisen Sie die Quelle der Antwort von außen

Testen Sie von außerhalb des Servers und notieren Sie die genaue Adresse und das Transportprotokoll, die der Client verwendet hat, bevor Sie irgendetwas aufzeichnen. Die drei Prüfungen unten beantworten drei verschiedene Fragen, und die Reihenfolge ist wichtig.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Der Mitschnitt zeigt die Quelladresse in der Antwort, und darauf beruht der ganze Artikel. Die Socket-Auflistung zeigt, woran der Server tatsächlich gebunden ist, denn ein Platzhalter- und ein bestimmter Listener sehen in einer Konfigurationsdatei gleich aus und verhalten sich im Netz unterschiedlich. Die Routensuche zeigt die Quelle, die der Kernel für diesen Fluss wählen würde, und das erklärt den Mitschnitt, bevor Sie etwas ändern. Wiederholen Sie alle drei für IPv4 und IPv6 getrennt, denn es sind getrennte Listener und getrennte Suchen, und ein Platzhaltereintrag für eine Familie sagt nichts über die andere.

Routing, Erkennung und Filterung bleiben getrennt

Die Quelle der Antwort zu erhalten, installiert keine ausgehende Route, aktualisiert kein dynamisches DNS und bringt keine Adressfamilie dazu, die andere anzunehmen. Auf einem Server mit mehreren Uplinks muss der Rückweg für jede Quelle bewusst vereinbart werden, sonst verlassen Antworten eine Schnittstelle, die der Filter des Clients nie zugelassen hat. Ebenso muss eine neue Adresse nach einem Präfixwechsel die Clients über Erkennung und den unterstützten Wiederverbindungsablauf erreichen und nicht über den alten Eintrag.

Lassen Sie Serveridentitätsprüfungen und Zertifikatsprüfung genau so, wie sie sind, denn eine geänderte Adresse rechtfertigt nicht, einen ungeprüften Partner zu akzeptieren. Wenn die Antwort nun von der vorgesehenen Quelle ausgeht und der Tunnel weiterhin scheitert, betrachten Sie das Quellproblem als gelöst und gehen Sie weiter. Der nächste beobachtete Fehler gehört zu Routing, Filterung oder Authentifizierung, und ein erneuter Wechsel des Listeners erreicht ihn nicht. Schreiben Sie die Quelle der Antwort ins Ticket neben die Adresse, die der Client gewählt hat, damit die nächste Person dieselbe Tatsache mit einem Befehl prüfen kann.