Relais stream de Nginx pour l'UDP d'OpenVPN : ce que cela change

L'UDP n'a pas sa place dans un location HTTP. Déplacez-le vers la couche stream, dimensionnez le délai de session pour un VPN, et attendez-vous à voir le proxy comme source.

Votre client est réglé sur UDP, le serveur Nginx possède un bloc location qui pointe vers le port du VPN, et rien n'arrive. C'est attendu : un location HTTP ne peut pas transporter un datagramme UDP, quel que soit le nom donné à l'interface. Nginx a besoin d'un listener stream pour cela, et une fois la configuration déplacée là, un second ensemble de détails décide si une session survit.

La couche proxy vient avant l'adresse

Le module stream de Nginx fait proxy de TCP et UDP sans analyser HTTP. Son module HTTP attend une ligne de requête, des en-têtes et une réponse, dont rien n'existe dans un datagramme OpenVPN natif. Choisir la couche est donc la première décision, et elle est indépendante du fait que le listener soit IPv4 ou IPv6.

Une configuration qui semble fonctionner avec OpenVPN en TCP ne dit rien du cas UDP. Le transport fait ici partie du protocole, ce n'est pas un détail du déploiement.

Le listener et le backend

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

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

Vérifiez que la compilation inclut le module stream avant toute modification ; un paquet de distribution peut l'isoler dans un module séparé, et un module manquant produit une erreur de configuration plutôt qu'un tunnel. Placez le bloc dans le contexte principal de configuration, pas à l'intérieur de http, et remplacez l'adresse de documentation par le vrai backend.

Les deux routes et les deux pare-feu doivent laisser passer les datagrammes : le chemin vers le listener et le chemin du proxy vers le backend. Un listener IPv6 ne crée pas non plus de chemin IPv4, donc si certains clients utilisent encore IPv4, ce listener est une entrée distincte avec ses propres tests. Vérifiez le pare-feu du backend depuis l'adresse du proxy, pas depuis votre portable.

Les délais de session ne sont pas des délais de requête

Le proxy stream conserve un état pour une session UDP et le jette selon son délai et ses réglages de réponse. Un délai court copié d'un relais DNS convient mal à un VPN qui compte échanger des datagrammes pendant des heures, et la panne apparaît comme une connexion qui meurt silencieusement plutôt qu'une qui refuse de démarrer.

Lisez le proxy_timeout effectif du déploiement et tout réglage de comptage de réponses, puis comparez-les au comportement keepalive que le VPN utilise réellement. Deux nombres écrits dans des fichiers différents par des personnes différentes, c'est l'état normal d'un système qui fonctionne. Deux nombres jamais comparés, c'est l'état normal d'un système intermittent. Écrivez les deux dans la fiche de service pour que la comparaison ait lieu une fois, à la lumière du jour.

Ce que le relais change, et ce qu'il ne change pas

Le proxy stream ne termine pas le canal de contrôle TLS d'OpenVPN et ne le convertit pas en HTTPS. Le backend reste le service VPN, et la relation de certificat reste entre le client et ce service. Préserver l'identité de backend prévue reste le travail du client et du serveur.

Le proxy ordinaire modifie aussi l'adresse source que voit le backend. Les journaux montreront le proxy, et toute règle d'accès basée sur l'IP sur le serveur VPN évaluera cette adresse plutôt que celle du client. La préservation transparente de la source est une conception distincte de routage et de privilèges, pas quelque chose qui découle de l'ajout de udp à un listener. Prévoyez-la avant qu'une politique dépendant de l'adresse du client ne soit écrite.

Vérifiez depuis le client, pas depuis le port

Une vérification locale que le port UDP est ouvert prouve que le listener existe. Elle ne prouve pas qu'un client peut s'authentifier à travers lui ou continuer d'échanger du trafic. Effectuez une vraie connexion depuis un client approuvé, puis confirmez que la session tient assez longtemps pour compter.

Quand quelqu'un rapporte que Nginx ne peut pas faire d'UDP parce qu'un simple outil de relais a fonctionné à sa place, les deux faits n'ont aucun rapport. L'outil a prouvé que le backend répond ; il n'a rien dit de ce que l'interface prend en charge. Les deux peuvent être vrais, et un seul des deux est une configuration pour ce déploiement.

Articles similaires