Nginx-Stream-Relay für OpenVPN UDP: Was sich ändert

UDP gehört nicht in ein HTTP-Location. Verschieben Sie es in die Stream-Ebene, bemessen Sie das Sitzungs-Timeout für ein VPN, und rechnen Sie damit, dass der Proxy als Quelle erscheint.

Ihr Client ist auf UDP eingestellt, der Nginx-Server hat einen Location-Block, der auf den VPN-Port zeigt, und es kommt nichts an. Das ist zu erwarten: ein HTTP-Location kann kein UDP-Datagramm transportieren, wie die Frontend-Ebene auch immer heißt. Dafür braucht Nginx einen Stream-Listener, und sobald Sie die Konfiguration dorthin verschieben, entscheidet ein zweiter Satz von Details, ob eine Sitzung überlebt.

Die Proxy-Ebene kommt vor der Adresse

Das Stream-Modul von Nginx proxy't TCP und UDP, ohne HTTP zu parsen. Sein HTTP-Modul erwartet eine Request-Zeile, Header und eine Antwort, und nichts davon enthält ein natives OpenVPN-Datagramm. Die Ebene zu wählen ist daher die erste Entscheidung, und sie ist unabhängig davon, ob der Listener IPv4 oder IPv6 ist.

Eine Konfiguration, die mit TCP-OpenVPN zu funktionieren scheint, sagt nichts über den UDP-Fall. Der Transport ist hier Teil des Protokolls, kein Detail der Bereitstellung.

Der Listener und das Backend

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

Bestätigen Sie, dass der Build das Stream-Modul enthält, bevor Sie etwas bearbeiten; ein Distributionspaket kann es in ein separates Modul auslagern, und ein fehlendes Modul erzeugt einen Konfigurationsfehler statt eines Tunnels. Setzen Sie den Block in den Hauptkontext der Konfiguration, nicht innerhalb von http, und ersetzen Sie die Dokumentationsadresse durch das echte Backend.

Beide Routen und beide Firewalls müssen die Datagramme durchlassen: den Weg zum Listener und den Weg vom Proxy zum Backend. Ein IPv6-Listener erzeugt auch keinen IPv4-Weg, wenn also einige Clients noch IPv4 nutzen, ist dieser Listener ein separater Eintrag mit eigener Prüfung. Prüfen Sie die Firewall des Backends von der Adresse des Proxys aus, nicht von Ihrem Laptop.

Sitzungs-Timeouts sind keine Request-Timeouts

Der Stream-Proxy hält Zustand für eine UDP-Sitzung und verwirft ihn gemäß seinem Timeout und seinen Antwort-Einstellungen. Ein kurzes Timeout, das von einem DNS-Relay kopiert wurde, passt schlecht zu einem VPN, das stundenlang Datagramme austauschen will, und der Fehler zeigt sich als Verbindung, die still stirbt, statt als eine, die den Start verweigert.

Lesen Sie das effektive proxy_timeout der Bereitstellung und jede Einstellung zur Antwortanzahl und vergleichen Sie sie mit dem Keepalive-Verhalten, das das VPN tatsächlich nutzt. Zwei Zahlen, die verschiedene Menschen in verschiedenen Dateien geschrieben haben, sind der Normalzustand eines funktionierenden Systems. Zwei Zahlen, die nie verglichen wurden, sind der Normalzustand eines Systems mit sporadischen Aussetzern. Schreiben Sie beide in den Dienst-Eintrag, damit der Vergleich einmal stattfindet, bei Tageslicht.

Was das Relay ändert und was nicht

Der Stream-Proxy beendet den TLS-Kontrollkanal von OpenVPN nicht und wandelt ihn nicht in HTTPS um. Das Backend bleibt der VPN-Dienst, und die Zertifikatsbeziehung bleibt zwischen dem Client und diesem Dienst. Die beabsichtigte Backend-Identität zu wahren, bleibt Aufgabe von Client und Server.

Gewöhnliches Proxying ändert auch die Quelladresse, die das Backend sieht. Logs zeigen den Proxy, und jede IP-basierte Zugriffsregel auf dem VPN-Server bewertet diese Adresse statt der des Clients. Transparente Quelladress-Erhaltung ist ein eigenes Routing- und Rechte-Design, nichts, was aus dem Hinzufügen von udp zu einem Listener folgt. Planen Sie es, bevor eine Richtlinie geschrieben wird, die von der Client-Adresse abhängt.

Vom Client prüfen, nicht vom Port

Eine lokale Prüfung, dass der UDP-Port offen ist, beweist, dass der Listener existiert. Sie beweist nicht, dass sich ein Client durch ihn authentifizieren oder weiter Daten austauschen kann. Stellen Sie eine echte Verbindung von einem freigegebenen Client her und bestätigen Sie dann, dass die Sitzung lange genug bestehen bleibt, um relevant zu sein.

Wenn jemand berichtet, Nginx könne kein UDP, weil stattdessen ein einfaches Relay-Werkzeug funktioniert hat, hängen die beiden Fakten nicht zusammen. Das Werkzeug bewies, dass das Backend antwortet; über das, was das Frontend unterstützt, sagte es nichts. Beides kann wahr sein, und nur eines davon ist eine Konfiguration für diese Bereitstellung.

Ähnliche Artikel