OpenVPN funciona a casa però no en una xarxa: UDP o TCP?

El mateix perfil es connecta des de casa i s’encalla en una xarxa d’hotel, de campus o de sucursal. Les credencials no han canviat, així que la variable interessant és el camí: què passa amb els paquets abans que OpenVPN els llegeixi. Comparar quatre causes candidates en l’ordre en què es poden provar és millor que endevinar certificats. Cadascuna deixa un rastre diferent, i és el rastre el que les separa.

Quina etapa ha fallat diu quina comparació importa

El registre del client ja anota fins on has arribat. Una línia que diu que la negociació de clau TLS no s’ha produït dins del termini significa que un primer paquet ha sortit i no ha tornat res utilitzable, cosa que apunta al camí. Un rebuig de certificat no s’hi assembla gens: arriba una resposta i després un error de verificació concret n’anomena la causa. Fixa’t en l’última línia abans del bucle de reintents, perquè aquest és el valor que compares entre xarxes.

Captura mentre reintentes, no després. Al client, tcpdump -ni any udp port 1194 mostra si torna alguna resposta. Repeteix-ho a la interfície WAN d’un servidor que controles, cosa que revela si aquests paquets arriben del tot a l’extrem oposat.

El trànsit unilateral és el resultat més útil disponible aquí, perquè converteix una queixa intermitent en una direcció on investigar. Guarda els fitxers de captura, perquè el proper informe del mateix problema es tanca més fàcilment amb proves que amb una descripció.

Filtratge UDP enfront d’un port tancat

Moltes xarxes d’accés tracten l’UDP sostingut com a sospitós, i alguns proveïdors hi estan d’acord. Un port tancat produeix el mateix silenci des del costat del client. La diferència és la selectivitat: un filtre sol triar quins destins o ports descarta, mentre que un port tancat refusa tot el que va adreçat a aquell port.

Un perfil TCP al port 443 és la solució habitual, perquè s’assembla a un flux HTTPS normal i passa la majoria de portals captius i filtres de sortida. S’han de complir dues condicions. El servidor ha d’escoltar amb proto tcp-server i el client ha de coincidir amb proto tcp-client, i l’operador ha de publicar aquest punt final alternatiu. Reesciure un perfil UDP que funciona per declarar TCP 443 no porta enlloc quan a l’altre extrem no hi ha ningú escoltant.

Un port tancat és un problema de configuració i no de censura. Un servidor darrere d’un encaminador domèstic necessita el port UDP reenviat, i el tallafoc de l’encaminador ho ha de permetre. Quan el port no s’ha permès mai, tots els clients fallen a la negociació independentment de les credencials, i la fallada segueix el servidor i no la xarxa.

Els protocols més antics no surten ben parats en aquest eix. PPTP necessita TCP 1723 més GRE, i GRE és el protocol IP 47 i no un port, així que cap reenviament de port corrent ho expressa.

Quan és el commutador qui descarta paquets

Un commutador gestionat pot descartar el túnel expressament. Alguns models HPE i Aruba ofereixen un control de protecció contra inundacions UDP, de vegades etiquetat Prevent UDP Blat Attack, a la seva secció de seguretat avançada. Un cop aquest control és actiu, un servidor darrere del commutador no respon res i tots els clients esgoten el temps de la mateixa manera. Desactivar-lo i desar la configuració en curs és tota la reparació, però només després d’establir que el commutador és realment al camí.

Les proves contràries són el que separa un descart del commutador d’un bloqueig del proveïdor. Llegeix els comptadors d’interfície i el registre de protecció contra inundacions abans d’obrir un tiquet amb el proveïdor. Els encaminadors de consum amb protecció DoS o contra inundacions fallen de la mateixa manera, i també qualsevol dispositiu intermedi amb un temps d’inactivitat UDP curt. Un handshake que no s’acaba mai suggereix un descart, mentre que un túnel que mor després de minuts de silenci suggereix el temps d’espera.

Anota cada dispositiu entre el client i el servidor abans de canviar un perfil. Una correcció aplicada a la capa equivocada sembla correcta fins a la xarxa següent. Aquesta llista també diu al proper enginyer on mirar sense repetir tota la investigació.

Un solapament d’adreces que sembla una fallada de DNS

Una xarxa d’accés numerada dins de 10.0.0.0/8 pot solapar-se amb el pool del túnel, i el resolutor sol viure dins d’aquest pool. Quan un portàtil rep una adreça com 10.184.178.50 amb una màscara /8 a la Wi-Fi, tota destinació 10.x és local per definició. Els paquets per a 10.4.0.1 van llavors a la LAN, el túnel segueix aixecat i la resolució de noms falla.

ip addr exposa el solapament d’un cop d’ull, i ip route get 10.4.0.1 mostra on es lliuraria realment el paquet. Com que el símptoma visible és una fallada del resolutor, aquest cas sovint sobreviu a diverses rondes de canvis de DNS.

Renombra el pool o mantén aquella xarxa d’accés fora de l’abast. Cap ajust del costat del client no recupera un solapament.

Decidir entre un TCP alternatiu i una correcció del camí

Tria el TCP alternatiu quan no controles el camí i els usuaris han de treballar avui, i accepta’n el cost: TCP dins de TCP es comporta malament en enllaços amb pèrdues, i l’alternativa necessita un oient que tu operes. Tria la correcció del camí quan el bloqueig és en infraestructura que posseeixes, perquè una regla de tallafoc és més barata que un segon oient. De qualsevol manera, recorre les capes en ordre: enllaç, transport extern, negociació, encaminament intern. L’etapa que va fallar en aquella xarxa és l’únic fet que importa.

Registra el resultat per xarxa i no per usuari. El proper informe de la mateixa fallada comença llavors en una etapa coneguda en lloc d’una teoria sobre certificats. Aquest registre també és el que justifica un segon oient permanent, si mai cal.