Onde está TLS dentro de OpenVPN e que cambia a forma
OpenVPN executa TLS para o seu canal de control dentro do seu propio marco, así que os primeiros bytes non son un handshake web. Tres opcións si cambian o que se ve.
OpenVPN si usa TLS, e a xente adoita estender iso a unha afirmación que non pode soster: que un túnel por tanto parece un navegador que visita un sitio. A primeira parte é certa. A segunda non. Aquí TLS pertence a un canal de control que viaxa dentro do propio contedor de OpenVPN, xunto a un canal de carga cunha criptografía completamente distinta, así que quen inspecciona os bytes iniciais ve OpenVPN.
Dúas conversas nun sobre
Pense nunha sesión como dúas conversas que comparten un sobre. Unha valida certificados e deriva material de chave. A outra cifra o que vostede envía en realidade, usando o que produciu a primeira.
O sobre é o protocolo. Cada paquete comeza cunha cabeceira pequena que nomea o seu tipo, e esa cabeceira chega antes que calquera outra cousa.
Que chega realmente primeiro
Por esa orde, o primeiro no cable non é un rexistro TLS. É a cabeceira de OpenVPN, seguida do contido do canal que anuncie a cabeceira. Un ClientHello existe aí dentro, só que non no byte cero. Non fai falta descifrar nada para notar a diferenza, porque a forma por si soa delátaa.
Os valores por defecto tamén contan. O fluxo é UDP ao 1194 salvo que o perfil elixa TCP. En ambos os casos o aspecto exterior é un túnel e non unha petición web.
Tres maneiras honestas de cambiar a forma
Un terminador TLS como stunnel acepta TLS nun porto en cada extremo e entrega o fluxo descifrado a OpenVPN localmente, así que a rede ve TLS cara a ese porto. Un protocolo que é TLS desde o primeiro byte compórtase doutro xeito: o intercambio compatible con AnyConnect que implementa ocserv parece o acceso remoto corporativo que moitas redes xa esperan. SSTP, que vén con Windows, ten a mesma propiedade noutro produto.
En Linux, a opción -w de SSH transporta unha ligazón punto a punto dentro dunha sesión SSH, o que resulta útil cando SSH é o único protocolo permitido. É a máis barata das catro se SSH xa funciona desde esa rede, e a menos útil se non.
Que non cambia ningunha delas
Ningunha destas cambia a que pode chegar o túnel. Non fan accesible unha dirección bloqueada, non autentican a ninguén e non deciden rutas.
Un envoltorio tamén lle custa un compoñente. Dous escoitadores e dous ficheiros de configuración significan dous lugares para un fallo, e ambos se ven idénticos desde o asento do usuario. Orzamente iso antes de adoptar un. A sesión segue sendo un único fluxo cifrado de longa duración cara a un destino, e o seu volume e o seu tempo seguen visibles.
Primeiro diagnostique, logo escolla
Así que diagnostique primeiro. O UDP descartado respóndese co modo TCP, e unha sinatura recoñecida respóndese con outro protocolo ou un envoltorio. Escoller unha ferramenta antes de coñecer o bloqueo é como a xente acaba mantendo tres capas que fallan todas pola mesma razón.
Unha rede que só permite portos web reduce a elección a un protocolo baseado en TLS no 443. Aplicar as tres á vez dá unha pila que ninguén pode depurar, así que cambie unha cousa e volva probar o mesmo fluxo.
Se non se aplica ningunha, a resposta exacta é que esta rede non transportará un túnel para vostede. Iso é un achado e non un fracaso do esforzo. Percorrer máis opcións non reverte unha decisión de política tomada máis arriba.
Un límite está diante de todo isto. O permiso para executar un túnel na rede doutra persoa é unha cuestión de política, decidida á parte de se o mecanismo funciona. Estes feitos explican o que ve un observador e non conceden permiso.