Ajuda realment el TCP 443? Només si el servidor hi escolta
Un perfil TCP és una alternativa, no un camuflatge. Comproveu que el servidor escolti en aquest port i després valoreu el cost del TCP doble davant de la impossibilitat de connectar.
El TCP 443 és una alternativa amb una condició prèvia, no un camuflatge que cola un túnel per qualsevol filtre. Ajuda quan l’operador ja publica un oient TCP en aquest port i el camí tolera una connexió que queda oberta durant hores. Falla, normalment com a temps d’espera, quan falta una de les dues condicions, i el temps d’espera poques vegades diu quina. Decidir si cal canviar planteja tres preguntes, i només una és sobre el número de port.
Un número de port no és una promesa de transport
Un port anomena un extrem; el TCP el converteix en un flux ordenat de bytes; OpenVPN decideix què viatja dins d’aquest flux. Un servidor web en el mateix número fa servir una disposició d’aplicació completament diferent, així que compartir el port 443 fa que tots dos semblin iguals per a un filtre i res més. El número és una pista que llegeix un filtre, no una propietat que canviï el que contenen els paquets. Tractar-los com si fossin el mateix perquè comparteixen un port és l’error que hi ha darrere de la major part de la confusió.
Els equips intermediaris poques vegades prenen una decisió simple de permetre o denegar sobre un port. Molts inspeccionen els primers bytes, alguns fixen una destinació i alguns reinicien connexions que queden obertes massa estona. Per això el mateix perfil pot funcionar des d’una xarxa i caducar des d’una altra, i per això val la pena provar l’alternativa com una opció suportada en lloc de confiar-hi com una promesa. Quan un filtre examina el trànsit, el número de port és només el primer que mira.
Confirmeu l’oient abans de tocar el perfil
El servidor ha d’estar configurat per a TCP en aquest port, i el perfil del client ha de demanar el mateix transport. Reescriure un perfil UDP perquè demani TCP no crea l’oient, i el temps d’espera resultant no es distingeix d’un tallafoc que descarta el port. Baixeu el perfil TCP propi de l’operador quan n’hi hagi, perquè alguns serveis publiquen un extrem i uns paràmetres d’identitat separats per a cada transport. Editar a mà va bé per a una prova controlada i és una mala manera d’endevinar la configuració que volia el proveïdor.
Els dos costats d’aquesta correspondència apareixen a la configuració, i les opcions d’enllaç del projecte OpenVPN documenten les dues formes. La parella mínima és així:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Tres condicions decideixen si l’alternativa val la pena
La primera condició és que l’operador ofereixi el transport; sense això, res més no importa. La segona és que el camí mantingui una sessió de llarga durada, ja que algunes xarxes reinicien connexions que queden obertes en lloc de bloquejar el port directament. La tercera és si l’alternativa és una excepció deliberada o una solució improvisada que amaga una avaria que no heu arreglat.
Cada condició té una comprovació barata. Un fracàs en qualsevol d’elles es veu igual des del client:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
Abans de comparar transports, acabeu qualsevol inici de sessió en un portal captiu. Una xarxa que no ha admès el vostre dispositiu bloqueja tots dos transports, i llavors la comparació mesura el portal i no el túnel. Inicieu la sessió, confirmeu que la navegació normal funciona i només després comenceu la prova.
El cost que accepteu: TCP dins de TCP
El TCP retransmet els segments perduts i en preserva l’ordre. Quan una aplicació que també fa servir TCP funciona dins d’un túnel TCP, dues capes de recuperació reaccionen a la mateixa pèrdua, i aquesta interacció és el que fa que el túnel sembli lent en un camí amb pèrdues. El símptoma és retard i jitter més que un fracàs net, cosa que facilita culpar l’extrem llunyà. Mesureu des del client amb tots dos transports abans de treure conclusions.
L’UDP evita aquesta imbricació, i és la raó principal per la qual els operadors el prefereixen i ofereixen TCP només com a alternativa. Una connexió TCP estable continua sent més útil que una d’UDP inaccessible, així que la comparació és entre dos costos reals i no entre una opció bona i una de dolenta. Manteniu el dispositiu i la xarxa d’accés estables mentre compareu, o el resultat descriurà la variable equivocada.
Algunes funcions del client estan documentades només per a un transport, així que un perfil alternatiu pot deixar caure en silenci un comportament del qual depeníeu. Llegiu el requisit de transport de l’opció abans de tractar el perfil TCP com un simple canvi.
Avaries que un altre transport no toca
Un certificat caducat encara necessita una comprovació del rellotge o una renovació, i un compte rebutjat encara necessita les credencials correctes. Manteniu les comprovacions d’identitat del servidor que va proporcionar l’operador, perquè un número de port familiar no autentica ningú. Un port que respon només diu que alguna cosa hi escolta.
Si el túnel s’aixeca i les destinacions continuen fallant, el problema restant és l’encaminament o la resolució de noms després de la connexió, no el transport. Seguiu aquest camí en lloc de fer voltes pels ports, que és com desapareix una tarda. El perfil us diu quin transport provar; mai no us diu per què va fallar el camí UDP.