proto udp o tcp-client: quin escolta el teu servidor?

Un perfil que funcionava el mes passat ara caduca i algú proposa canviar proto udp per proto tcp-client. De vegades és el pas correcte, i de vegades produeix un client que es connecta a un port on no escolta ningú, perquè el servidor no es va configurar mai per a l’altre transport. La directiva descriu com parla la teva banda; no pot crear cap oient a l’altra banda. Llegeix el perfil i el servidor junts abans de canviar-ne qualsevol.

Llegeix el transport que utilitza la connexió seleccionada

Un perfil pot portar diverses entrades remote, i cadascuna pot indicar el seu propi transport. El client les recorre en ordre, així que la línia que veus primer no és necessàriament la que s’aplica.

Troba l’entrada que realment s’intenta i després llegeix-ne el transport. L’ordre importa, perquè el client no passa a la següent en silenci. Algunes compilacions proven l’entrada següent només després d’un temps d’espera, així que una alternativa que funciona al final del fitxer s’assoleix uns segons més tard del que esperes. Mira al registre quin punt final s’intenta en lloc de suposar que la primera línia ha guanyat.

Si el fitxer té una línia proto a prop de dalt i diverses entrades remote a sota, aquesta línia és el valor per defecte de qualsevol remote que no la substitueixi. Una edició local del valor per defecte no fa res per una entrada remote que indica el seu propi transport.

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

UDP i TCP no són un paràmetre de velocitat

UDP envia datagrames sense construir un flux ordenat, així que el trànsit propi del túnel no s’embolcalla dins d’un segon transport fiable. TCP et dona un camí a través de xarxes que descarten o bloquegen UDP, a canvi d’una retransmissió imbricada que pot fer que un enllaç amb pèrdues sembli pitjor.

Això és un intercanvi d’abast, no una classificació universal. L’elecció correcta és la que permet la xarxa davant del client. Un camí que descarta UDP al port VPN no negociarà mai, per bé que estigui escrit el perfil. Prova el camí i després tria el transport.

Triar entre ells només per una prova de rendiment és un error, perquè la resposta depèn del que permet la xarxa que tens davant. Un hotel o un proxy corporatiu pot permetre TCP de sortida al 443 i res més, i per això els proveïdors ofereixen aquesta variant. Segueix sent una connexió OpenVPN en aquest port, no una sessió HTTPS, tot i que el número de port sigui el familiar.

Què significa realment tcp-client

La directiva del costat del client anomena l’extrem que inicia una connexió TCP. El costat del servidor fa servir la seva pròpia forma d’escoltar, i copiar la paraula del client a la configuració del servidor produeix un oient que espera que el truquin, no un que accepta.

Coincidir vol dir que les dues bandes acorden el transport, no que comparteixin la mateixa cadena.

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

Pregunta al servidor què escolta abans de suposar que el perfil és incorrecte. Un oient UDP no apareix en un llistat de sòcols TCP, i el revés també és cert, així que mira la vista específica del protocol en lloc d’una de genèrica.

Quan el perfil s’importa però no es connecta mai

Un perfil importat que caduca de seguida normalment falla abans de cap autenticació. El paquet va a un port sense oient, o la xarxa el descarta en silenci.

Prova el camí de la manera més simple possible: connecta’t al mateix amfitrió i port amb el transport que afirma el perfil, des de la mateixa xarxa que el client que falla.

Si una prova UDP no obté res i una prova TCP es connecta, el servidor ofereix l’altre transport i el perfil simplement és antiquat. Si cap de les dues respon, el problema és més amunt de l’elecció del transport i cap edició del perfil ho arreglarà. Distingir aquests dos casos costa un minut i estalvia una hora de depuració de certificats que mai no era rellevant.

Anota el transport que funciona

Quan una combinació funcioni, anota-la amb el servidor, el port i el protocol, i indica des de quina xarxa es va provar.

Si no, la propera persona que topi amb un temps d’espera repetirà el mateix experiment en l’altre sentit i potser canviarà un servidor que estava bé.

Si el proveïdor publica les dues variants, conserva els dos fitxers i etiqueta’ls segons la xarxa a què van bé. Dos perfils amb noms clars eviten la barreja accidental d’un transport de client amb un oient de servidor que mai no es va configurar per a ell.