Relé stream d'Nginx per a l'UDP d'OpenVPN: què canvia

L'UDP no té lloc en un location HTTP. Moveu-lo a la capa stream, dimensioneu el temps d'espera de sessió per a una VPN i espereu el proxy com a origen.

El vostre client està configurat per a UDP, el servidor Nginx té un bloc location apuntant al port de la VPN, i no hi arriba res. És d'esperar: un location HTTP no pot transportar cap datagrama UDP, per molts noms que rebi la interfície frontal. Nginx necessita un listener stream per a això, i un cop moveu la configuració allà, un segon conjunt de detalls decideix si la sessió sobreviu.

La capa de proxy va abans que l'adreça

El mòdul stream d'Nginx fa de proxy de TCP i UDP sense analitzar HTTP. El seu mòdul HTTP espera una línia de petició, capçaleres i una resposta, i res d'això hi ha en un datagrama OpenVPN natiu. Triar la capa és, per tant, la primera decisió, i és independent que el listener sigui IPv4 o IPv6.

Una configuració que sembla funcionar amb OpenVPN TCP no diu res del cas UDP. Aquí el transport forma part del protocol, no un detall del desplegament.

El listener i el backend

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

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

Confirmeu que la compilació inclou el mòdul stream abans d'editar res; un paquet de distribució pot separar-lo en un mòdul a part, i un mòdul que falta produeix un error de configuració en lloc d'un túnel. Poseu el bloc al context principal de configuració, no dins de http, i substituïu l'adreça de documentació pel backend real.

Tant les dues rutes com els dos tallafocs han de permetre els datagrames: el camí fins al listener i el camí del proxy fins al backend. Un listener IPv6 tampoc no crea un camí IPv4, així que si alguns clients encara fan servir IPv4, aquell listener és una entrada separada amb les seves pròpies proves. Comproveu el tallafoc del propi backend des de l'adreça del proxy, no des del vostre portàtil.

Els temps d'espera de sessió no són els de petició

El proxy stream guarda estat per a una sessió UDP i el descarta segons el seu temps d'espera i la configuració de respostes. Un temps d'espera curt copiat d'un relé DNS encaixa malament en una VPN que espera intercanviar datagrames durant hores, i la fallada apareix com una connexió que mor silenciosament més que no una que es nega a arrencar.

Llegiu el proxy_timeout efectiu del desplegament i qualsevol paràmetre de recompte de respostes, i compareu-los amb el comportament keepalive que la VPN fa servir realment. Dos números escrits en fitxers diferents per persones diferents és l'estat normal d'un sistema que funciona. Dos números que mai no s'han comparat és l'estat normal d'un sistema intermitent. Escriviu-los tots dos al registre del servei perquè la comparació passi una vegada, a la llum del dia.

Què canvia el relé i què no

El proxy stream no acaba el canal de control TLS d'OpenVPN ni el converteix en HTTPS. El backend continua sent el servei VPN, i la relació de certificats es manté entre el client i aquell servei. Preservar la identitat de backend prevista continua sent feina del client i del servidor.

El proxy ordinari també canvia l'adreça d'origen que veu el backend. Els registres mostraran el proxy, i qualsevol regla d'accés per IP al servidor VPN avaluarà aquella adreça en lloc de la del client. Preservar l'origen de manera transparent és un disseny de routing i privilegis a part, no una cosa que surti d'afegir udp a un listener. Planifiqueu-ho abans que s'escrigui cap política que depengui de l'adreça del client.

Verifiqueu des del client, no des del port

Una comprovació local que el port UDP és obert demostra que el listener existeix. No demostra que un client pugui autenticar-s'hi o continuar intercanviant trànsit. Completeu una connexió real des d'un client aprovat i després confirmeu que la sessió es manté prou estona perquè sigui rellevant.

Quan algú diu que Nginx no pot fer UDP perquè una eina de relé senzilla va funcionar al seu lloc, els dos fets no hi tenen res a veure. L'eina va demostrar que el backend respon; no va dir res sobre què admet la interfície frontal. Totes dues coses poden ser certes, i només una és una configuració per a aquest desplegament.

Articles relacionats