Axuda de verdade o TCP 443? Só se o servidor escoita alí
Un perfil TCP é unha alternativa, non un disfrace. Comprobe que o servidor escoita nese porto e despois valore o custo do TCP dobre fronte á imposibilidade de conectar.
O TCP 443 é unha alternativa cunha condición previa, non un disfrace que cola un túnel por calquera filtro. Axuda cando o operador xa publica un oínte TCP nese porto e a ruta tolera unha conexión que queda aberta durante horas. Falla, normalmente como tempo de espera, cando falta unha das dúas cousas, e o tempo de espera raramente di cal. Decidir se cambiar esixe tres preguntas, e só unha delas trata do número de porto.
Un número de porto non é unha promesa de transporte
Un porto nomea un extremo; o TCP convérteo nun fluxo ordenado de bytes; OpenVPN decide que viaxa dentro dese fluxo. Un servidor web no mesmo número usa unha disposición de aplicación completamente distinta, así que compartir o porto 443 fai que os dous se parezan para un filtro e nada máis. O número é unha pista que le un filtro, non unha propiedade que cambie o que conteñen os paquetes. Tratalos como o mesmo porque comparten un porto é o erro que está detrás da maior parte da confusión.
Os equipos intermedios raramente toman unha decisión simple de permitir ou denegar sobre un porto. Moitos inspeccionan os primeiros bytes, algúns fixan un destino e algúns reinician conexións que quedan abertas demasiado tempo. Por iso o mesmo perfil pode funcionar desde unha rede e esgotarse desde outra, e por iso paga a pena probar a alternativa como unha opción soportada en lugar de confiar nela como unha promesa. Cando un filtro examina o tráfico, o número de porto é só o primeiro que mira.
Confirme o oínte antes de tocar o perfil
O servidor ten que estar configurado para TCP no porto, e o perfil do cliente ten que pedir o mesmo transporte. Reescribir un perfil UDP para que pida TCP non crea o oínte, e o tempo de espera resultante non se distingue dun cortalumes que descarta o porto. Descargue o perfil TCP propio do operador cando exista, porque algúns servizos publican un extremo e uns axustes de identidade separados para cada transporte. Editar a man vai ben para unha proba controlada e é unha mala forma de adiviñar a configuración que pretendía o provedor.
Os dous lados desa correspondencia aparecen na configuración, e as opcións de enlace do proxecto OpenVPN documentan as dúas formas. O par mínimo ten este aspecto:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Tres condicións deciden se a alternativa compensa
A primeira condición é que o operador ofreza o transporte sequera; sen iso, nada máis importa. A segunda é que a ruta manteña viva unha sesión de longa duración, xa que algunhas redes reinician conexións que quedan abertas en vez de bloquear o porto de plano. A terceira é se a alternativa é unha excepción deliberada ou un apaño que oculta unha avaría que non corrixiu.
Cada condición ten unha comprobación barata. Un fallo en calquera delas vese igual desde o cliente:
| 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 |
Antes de comparar transportes, complete calquera inicio de sesión nun portal cativo. Unha rede que non admitiu o seu dispositivo bloquea ambos os transportes, e entón a comparación mide o portal e non o túnel. Inicie sesión, confirme que a navegación normal funciona e só despois comece a proba.
O custo que acepta: TCP dentro de TCP
O TCP retransmite os segmentos perdidos e conserva a súa orde. Cando unha aplicación que tamén usa TCP corre dentro dun túnel TCP, dúas capas de recuperación reaccionan á mesma perda, e esa interacción é o que fai que o túnel se senta lento nunha ruta con perdas. O síntoma é atraso e jitter máis que un fallo limpo, o que facilita culpar o extremo afastado. Mida desde o cliente con ambos os transportes antes de sacar conclusións.
O UDP evita esa imbricación, e é a razón principal pola que os operadores o prefiren e ofrecen TCP só como alternativa. Unha conexión TCP estable segue sendo máis útil ca unha UDP inalcanzable, así que a comparación é entre dous custos reais e non entre unha opción boa e unha mala. Manteña o dispositivo e a rede de acceso sen cambios mentres compara, ou o resultado describirá a variable equivocada.
Algunhas funcións do cliente están documentadas só para un transporte, así que un perfil alternativo pode deixar caer en silencio un comportamento do que dependía. Lea o requisito de transporte da opción antes de tratar o perfil TCP como un simple cambio.
Averías que outro transporte non toca
Un certificado caducado segue necesitando unha comprobación do reloxo ou unha renovación, e unha conta rexeitada segue necesitando as credenciais correctas. Manteña as comprobacións de identidade do servidor que forneceu o operador, porque un número de porto familiar non autentica a ninguén. Un porto que responde só di que algo está escoitando.
Se o túnel sobe e os destinos seguen fallando, o problema restante é o encamiñamento ou a resolución de nomes despois da conexión, non o transporte. Siga ese camiño en vez de dar voltas polos portos, que é como se perde unha tarde. O perfil dille que transporte probar; nunca lle di por que fallou a ruta UDP.