OpenVPN no es connecta al Wi-Fi de l'hotel? Proveu TCP 443

Obriu el client, premeu Connect i llegiu la línia d'estat en lloc del diàleg que la segueix. Un perfil que s'encalla a Connecting o Waiting for server després d'una xarxa d'hotel, campus o mòbil normalment ha perdut el transport en algun punt del camí, no les seves credencials. El següent pas útil és esbrinar què transporta aquesta xarxa abans de tocar el servidor. No canvieu res fins que el mateix perfil hagi funcionat en un altre lloc.

Proveu primer des d'un punt d'accés mòbil. Si el túnel s'aixeca allà, el servidor, el certificat i el compte estan bé, i l'única variable que queda és la xarxa que teniu davant.

Comenceu pel client: llegiu la línia d'estat

La línia d'estat us diu quina etapa ha fallat. Un client encallat a Connecting encara resol l'amfitrió o obre el sòcol exterior; el que arriba a Waiting for server té camí però cap resposta; el que s'autentica i després cau té un problema completament diferent. El registre del client i els propis camps remote i proto del perfil mostren què intenta fer el client, i --verb 4 en un client de línia d'ordres imprimeix el mateix detall. Comparar-ho amb la xarxa que teniu davant és el que converteix «la VPN està bloquejada» en una afirmació concreta.

Després sondegeu la xarxa amb eines que ja teniu. nc -vzu 203.0.113.10 1194 envia un datagrama UDP, curl -v telnet://203.0.113.10:443 informa si es completa un handshake TCP, i un navegador que carrega una pàgina HTTPS només demostra que el 443 de sortida arriba a aquell amfitrió. Les sondes petites responen el que el client VPN no pot: quin port i quin protocol surten d'aquesta xarxa.

Tres comportaments de xarxa semblen iguals des del client i necessiten respostes diferents. El 443 de sortida pot estar obert, potser només es permet un proxy, o potser el 443 es reenvia de manera transparent a una caixa d'inspecció que no pot llegir què transporta. El primer es resol amb el canvi de perfil d'aquí sota, el segon amb la configuració del proxy, i el tercer pot completar un handshake i després encallar-se quan l'inspector decideix que no li agrada el flux. Saber quin teniu al davant és la diferència entre un canvi de deu minuts i una tarda reinstal·lant clients.

Moveu l'oient i el perfil alhora

Al costat del servidor, poseu l'oient en allò que la xarxa permet: port 443 i proto tcp a la configuració del servidor, després reinicieu el servei i confirmeu el sòcol amb ss -lntp. Al costat del client, el perfil ha de coincidir, perquè el transport i el port queden fora del túnel: proto tcp i port 443 al fitxer .ovpn, o els camps corresponents a la pantalla de configuració de l'aplicació. Un perfil que encara apunta a UDP 1194 falla exactament com abans, i la temptació és culpar un tallafoc que ja està arreglat. Si el mateix amfitrió també respon HTTPS al 443, els dos oients no poden compartir aquesta adreça i protocol; doneu a la VPN una segona adreça o poseu un demultiplexor al davant.

Seguiu la primera connexió amb tcpdump -ni any port 443 als dos extrems. Els paquets que surten del client i mai no arriben volen dir que la xarxa filtra després de tot, o que l'adreça del perfil no és la que suposeu. Els paquets que arriben sense resposta us tornen al registre del servidor, on una discrepància de protocol es veu immediatament com un paquet descartat.

Quan només un proxy surt de la xarxa

Algunes xarxes de convidats no permeten res més que un proxy HTTP, la qual cosa és una restricció diferent d'un port tancat i descarta més que OpenVPN. Els clients que només parlen PPTP, L2TP/IPsec o IPsec nu no tenen manera de passar-hi, perquè aquests dissenys esperen que el seu protocol exterior arribi directament al servidor. OpenVPN sí que pot, amb http-proxy proxy.example.net 8080 al perfil del client, sempre que el proxy permeti el mètode CONNECT al vostre port. Un proxy SOCKS encara és més fàcil, perquè reenvia el flux sense preocupar-se de què hi ha a dins.

Quan el client no té suport de proxy, un túnel SSH sobre 443 sol ser el que queda. Afegeix una segona capa, i l'operador de la xarxa pot tenir una opinió al respecte, així que tracteu-lo com un pont per a un sol viatge i no com una arquitectura.

Calculeu el cost del recurs abans de quedar-vos-el

TCP dins de TCP té un cost conegut. Quan la connexió exterior és TCP i la càrrega útil també ho és, un segment perdut provoca retransmissió a les dues capes, i la connexió interior es retira d'una pèrdua que no pot veure. La navegació ho supera; les sessions interactives i les trucades ho noten. Manteniu l'oient TCP 443 com a recurs per a les xarxes que el demanen, i deixeu UDP com a opció per defecte per a tot el que encara el deixa passar.

Anoteu l'elecció al nom del perfil i a les notes de suport: quin port, quin protocol i quina xarxa la va provocar. Després pregunteu a l'administrador de la xarxa si aquest port continuarà obert després de la propera renovació d'equips, perquè un recurs que desapareix en silenci és pitjor que no tenir-ne cap.