Relé stream de Nginx para o UDP de OpenVPN: que cambia

O UDP non pertence a un location de HTTP. Léveo á capa stream, dimensione o tempo de espera de sesión para unha VPN e conte co proxy como orixe.

O teu cliente está configurado para UDP, o servidor Nginx ten un bloque location que apunta ao porto da VPN e non chega nada. É de esperar: un location de HTTP non pode transportar un datagrama UDP, por moito que reciba outro nome a interface. Nginx necesita un listener de stream para isto, e unha vez que movas alí a configuración, un segundo conxunto de detalles decide se unha sesión sobrevive.

A capa de proxy vai antes ca o enderezo

O módulo stream de Nginx fai proxy de TCP e UDP sen analizar HTTP. O seu módulo HTTP espera unha liña de petición, cabeceiras e unha resposta, e nada diso existe nun datagrama OpenVPN nativo. Escoller a capa é, polo tanto, a primeira decisión, e é independente de que o listener sexa IPv4 ou IPv6.

Unha configuración que parece funcionar con OpenVPN en TCP non di nada do caso UDP. Aquí o transporte forma parte do protocolo, non é un detalle do despregamento.

O listener e o backend

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

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

Confirma que a compilación inclúe o módulo stream antes de editar nada; un paquete de distribución pode separalo nun módulo á parte, e un módulo ausente produce un erro de configuración en lugar dun túnel. Pon o bloque no contexto principal de configuración, non dentro de http, e substitúe o enderezo de documentación polo backend real.

Tanto as dúas rutas como os dous cortafogos teñen que permitir os datagramas: o camiño ata o listener e o camiño do proxy ata o backend. Un listener IPv6 tampouco crea un camiño IPv4, así que se algúns clientes aínda usan IPv4, ese listener é unha entrada aparte coas súas propias probas. Comproba o cortafogo do propio backend desde o enderezo do proxy, non desde o teu portátil.

Os tempos de espera de sesión non son os de petición

O proxy stream garda estado para unha sesión UDP e descártao segundo o seu tempo de espera e a súa configuración de respostas. Un tempo de espera curto copiado dun relé DNS encaixa mal nunha VPN que espera intercambiar datagramas durante horas, e o fallo aparece como unha conexión que morre en silencio en vez de unha que se nega a arrancar.

Le o proxy_timeout efectivo do despregamento e calquera axuste de reconto de respostas, e despois compáraos co comportamento keepalive que a VPN usa realmente. Dous números escritos en ficheiros distintos por persoas distintas é o estado normal dun sistema que funciona. Dous números que nunca se compararon é o estado normal dun sistema intermitente. Escribe ambos no rexistro do servizo para que a comparación ocorra unha vez, á luz do día.

Que cambia o relé e que non

O proxy stream non remata a canle de control TLS de OpenVPN nin a converte en HTTPS. O backend segue sendo o servizo VPN, e a relación do certificado segue entre o cliente e ese servizo. Preservar a identidade de backend prevista segue sendo traballo do cliente e do servidor.

O proxy ordinario tamén cambia o enderezo de orixe que ve o backend. Os rexistros amosarán o proxy, e calquera regra de acceso baseada en IP no servidor VPN avaliará ese enderezo en vez do do cliente. Preservar a orixe de forma transparente é un deseño á parte de enrutamento e privilexios, non algo que derive de engadir udp a un listener. Planifícao antes de escribir unha política que dependa do enderezo do cliente.

Verifica desde o cliente, non desde o porto

Unha comprobación local de que o porto UDP está aberto demostra que o listener existe. Non demostra que un cliente poida autenticarse a través del ou seguir intercambiando tráfico. Completa unha conexión real desde un cliente aprobado e despois confirma que a sesión se mantén o tempo suficiente para importar.

Cando alguén informa de que Nginx non pode facer UDP porque unha ferramenta de relé sinxela funcionou no seu lugar, os dous feitos non teñen relación. A ferramenta demostrou que o backend responde; non dixo nada sobre o que admite a interface. Ambas as dúas cousas poden ser certas, e só unha delas é unha configuración para este despregamento.

Artigos relacionados