Como verificar o servidor dun perfil OpenVPN antes de importalo

Alguén lle envía un perfil, vostede impórtao e trinta segundos despois un cliente marca un destino que ninguén comprobou. Lea primeiro o ficheiro nun editor de texto, porque todo o que importa cabe nun puñado de directivas: remote, proto, port, ca, cert, tls-crypt e verify-x509-name. Todo o demais son valores por defecto, e é aí onde viven as sorpresas.

Enumere cada extremo que o ficheiro pode usar

Empece polos extremos, porque un perfil pode conter varios. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn imprime cada candidato na orde do ficheiro, incluídos os aniñados dentro de bloques <connection> en liña.

Cando unha directiva omite o porto, o cliente recorre ao valor por defecto do oínte, así que só remote vpn.example.com significa o porto 1194 con calquera proto que apareza máis adiante no ficheiro. Varias liñas simples remote son alternativas: o cliente proba en orde salvo que remote-random as mesture, e nunca substitúe en silencio o host doutro operador. Dúas liñas remote en dominios non relacionados é o punto onde un se detén e pregunta cal se quería.

Fíxese tamén na escritura de proto. tcp acéptase como sinónimo do tcp-client do lado cliente, pero tcp-server nun perfil de cliente é un erro de configuración que adoita colgarse en vez de fallar limpiamente.

Confirme o nome e despois o porto

dig +short vpn.example.com dille se o nome existe e que enderezos devolve, e un extremo con varios enderezos ou detrás dun proxy pode devolver varios lexitimamente. A resolución é un requisito previo, non unha proba de propiedade; calquera pode apuntar un nome a un enderezo, e un enderezo pode responder por moitos nomes.

Despois comprobe o oínte no porto que atopou, de acordo co transporte. Por TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com imprime a cadea que presenta o servidor. Por UDP fai falta DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 executa a mesma aperta de mans por datagramas. Unha aperta de mans completada demostra que algo escoita e ten un certificado, o cal é máis do que mostra un ping e menos do que esixen os propios axustes de confianza do perfil.

Cando a aperta de mans falla e o host responde ao ping, o porto probablemente é incorrecto ou está filtrado. Tómeo como motivo para pedir o porto correcto, non como invitación a barrer os próximos. nc -vzu tamén informa de éxito nalgunhas pilas sen que nada escoite, así que unha sonda UDP espida non significa nada sen unha aperta de mans detrás.

Lea os pins de confianza á parte do enderezo

O enderezo decide cara a onde vai o cliente; o bloque de confianza decide en quen cre ao chegar. verify-x509-name "vpn.example.com" name fixa o nome común do suxeito, e remote-cert-tls server esixe o uso estendido da chave para a autenticación do servidor. Un perfil que lle entregue un operador debería levar ambos.

Busque ca, un bloque <ca> en liña e tls-crypt ou tls-auth. Un perfil que usa tls-auth precisa key-direction 1 no cliente cando o lado servidor usa a dirección 0, e un desaxuste fai fallar a aperta de mans cun erro TLS que se le como un defecto de certificado. Un CA en liña que non pertence ao operador cuxo nome acaba de resolver significa que o ficheiro se montou con dúas fontes, e ese é o caso que convén rexeitar de plano.

verify-x509-name acepta os modos name, name-prefix ou subject, e o último espera un nome distinguido completo na orde exacta en que o imprime o servidor. Escolla un modo que encaixe coa forma do valor, porque o cliente rexeita cada conexión en lugar de avisar dun case acerto. Para un ficheiro que vostede non escribiu, name cun nome de host simple é a opción menos sorprendente.

Revise as opcións que fallan en silencio

OpenVPN 2.6 negocia os cifrados mediante data-ciphers, e un perfil que só leva unha liña antiga cipher AES-256-CBC pode completar a canle de control e despois atascarse nos datos. Ler ese valor dille se o ficheiro é anterior ao servidor ao que se une; a páxina de manual de 2.6 enumera a orde de negociación se precisa citala ao operador.

auth-user-pass sen nome de ficheiro significa que o cliente preguntará, así que un perfil que parece autosuficiente aínda necesita credenciais. auth-user-pass credentials.txt significa que espera un ficheiro que probablemente non lle enviaron. nobind e resolv-retry infinite son correntes e inofensivos, mentres que explicit-exit-notify é só para UDP e inútil por TCP.

Nada disto cambia cara a onde se conecta o perfil, pero cada un cambia se se conecta ou non, e ningún é visible no diálogo de importación do cliente.

Decida e logo anote o que decidiu

Tras esta lectura hai tres desenlaces e só un é importar. Cando o extremo e os pins coinciden con instrucións recibidas por unha canle aparte, impórteo. Cando o extremo parece correcto pero os pins ou o CA non coinciden, pida un ficheiro corrixido. Cando o ficheiro mestura extremos ou material de CA de fontes distintas, bórreo e pida unha copia nova.

Anote o hash que revisou, para que a seguinte persoa saiba se o ficheiro cambiou: sha256sum profile.ovpn, pegado xunto ao extremo nas súas notas. Un perfil é un arranxo completo, non unha lista de enderezos, así que nunca empalme un remote que funciona no bloque de confianza doutro conservando as súas credenciais.

Manteña as chaves privadas e os contrasinais fóra de capturas de pantalla e fíos de chat mentres compara notas. O extremo e as opcións non secretas abondan para facer unha pregunta precisa, e o resto pertence ao ficheiro.

Se acaba importándoo e o primeiro intento falla, execute o cliente con --verb 3 e lea as dez primeiras liñas: o enderezo remote resolto, o proto negociado e o erro TLS aparecen nesa orde, o que lle di cal das comprobacións anteriores saltou.