proto udp ou tcp-client: cal escolta o teu servidor?

Un perfil que funcionaba o mes pasado agora caduca e alguén propón cambiar proto udp por proto tcp-client. Ás veces é o paso correcto, e ás veces produce un cliente que se conecta a un porto onde nada escoita, porque o servidor nunca se configurou para o outro transporte. A directiva describe como fala o teu extremo; non pode crear un oínte no extremo oposto. Le o perfil e o servidor xuntos antes de cambiar calquera dos dous.

Le o transporte que usa a conexión seleccionada

Un perfil pode levar varias entradas remote, e cada unha pode indicar o seu propio transporte. O cliente percorre-as en orde, así que a liña que ves primeiro non é necesariamente a que se aplica.

Atopa a entrada que realmente se está probando e despois le o seu transporte. A orde importa, porque o cliente non pasa á seguinte en silencio. Algunhas compilacións proban a entrada seguinte só tras un tempo de espera, así que unha alternativa que funciona ao final do ficheiro alcanzase uns segundos máis tarde do que esperas. Vixía no rexistro que extremo se está intentando en lugar de supor que gañou a primeira liña.

Se o ficheiro ten unha liña proto preto de arriba e varias entradas remote debaixo, esa liña é o valor predeterminado para calquera remote que non a anule. Unha edición local do valor predeterminado non fai nada por unha entrada remote que indica o seu propio transporte.

grep -nE '^(remote|proto)\b' client.ovpn

UDP e TCP non son un axuste de velocidade

UDP envía datagramas sen construír un fluxo ordenado, así que o tráfico propio do túnel non se envolve dentro dun segundo transporte fiable. TCP dache un camiño a través de redes que descartan ou bloquean UDP, a cambio dunha retransmisión aniñada que pode facer que unha ligazón con perdas se sinta peor.

É un intercambio de alcanzabilidade, non unha clasificación universal. A elección correcta é a que permite a rede fronte ao cliente. Un camiño que descarta UDP no porto VPN nunca negociará, por ben escrito que estea o perfil. Proba o camiño e despois escolle o transporte.

Escoller entre eles só por unha medición é un erro, porque a resposta depende do que permita a rede que tes diante. Un hotel ou un proxy corporativo pode permitir TCP de saída no 443 e nada máis, e por iso os provedores ofrecen esa variante. Segue sendo unha conexión OpenVPN nese porto, non unha sesión HTTPS, aínda que o número de porto sexa o coñecido.

Que significa realmente tcp-client

A directiva do lado do cliente nomea o extremo que inicia unha conexión TCP. O lado do servidor usa a súa propia forma de escoitar, e copiar a palabra do cliente nunha configuración de servidor produce un oínte que espera que o chamen, non un que acepta.

Coincidir significa que ambos os extremos acordan o transporte, non que compartan a mesma cadea.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Pregunta ao servidor que escoita antes de supor que o perfil está mal. Un oínte UDP non aparece nunha listaxe de sockets TCP, e o contrario tamén é certo, así que mira a vista específica do protocolo en lugar dunha xenérica.

Cando o perfil se importa pero nunca conecta

Un perfil importado que caduca de inmediato adoita fallar antes de calquera autenticación. O paquete vai a un porto sen oínte, ou a rede descártao en silencio.

Proba o camiño da forma máis simple posible: conéctate ao mesmo host e porto co transporte que afirma o perfil, desde a mesma rede que o cliente que falla.

Se unha proba UDP non obtén nada e unha proba TCP conecta, o servidor ofrece o outro transporte e o perfil simplemente está desactualizado. Se ningunha responde, o problema está por riba da elección de transporte e ningunha edición do perfil o arranxará. Distinguir eses dous casos leva un minuto e aforra unha hora de depuración de certificados que nunca foi relevante.

Anota o transporte que funciona

Cando unha combinación funcione, anótaa co servidor, o porto e o protocolo, e indica desde que rede se probou.

Se non, a próxima persoa que se atope cun tempo de espera repetirá o mesmo experimento na outra dirección e quizais cambiará un servidor que estaba ben.

Se o provedor publica ambas as variantes, conserva os dous ficheiros e etiquétaos segundo a rede á que van ben. Dous perfís con nomes claros evitan a mestura accidental dun transporte de cliente cun oínte de servidor que nunca se configurou para el.