Com verificar el servidor d'un perfil OpenVPN abans d'importar-lo

Algú us envia un perfil, l'importeu i trenta segons després un client marca una destinació que ningú no ha comprovat. Llegiu primer el fitxer en un editor de text, perquè tot el que importa cap en un grapat de directives: remote, proto, port, ca, cert, tls-crypt i verify-x509-name. La resta són valors per defecte, i els valors per defecte són on viuen les sorpreses.

Llista cada punt final que el fitxer pot utilitzar

Comenceu pels punts finals, perquè un sol perfil pot contenir-ne diversos. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn imprimeix cada candidat en l'ordre del fitxer, inclosos els imbricats dins de blocs <connection> en línia.

Quan una directiva omet el port, el client recorre al valor per defecte de l'oient, així que remote vpn.example.com sol significa port 1194 amb qualsevol proto que aparegui més endavant al fitxer. Diverses línies simples remote són alternatives: el client les prova en ordre tret que remote-random les barregi, i mai no substitueix silenciosament l'amfitrió d'un altre operador. Dues línies remote en dominis no relacionats és el punt on us atureu i pregunteu quina es volia.

Fixeu-vos també en l'escriptura de proto. tcp s'accepta com a sinònim del tcp-client del costat client, però tcp-server en un perfil de client és un error de configuració que sol penjar-se en lloc de fallar net.

Confirmeu el nom, després el port

dig +short vpn.example.com us diu si el nom existeix i quines adreces retorna, i un punt final amb diverses adreces o darrere d'un proxy pot retornar-ne diverses legítimament. La resolució del nom és un requisit previ, no una prova de propietat; qualsevol pot apuntar un nom a una adreça, i una adreça pot respondre per molts noms.

Després comproveu l'oient al port que heu trobat, d'acord amb el transport. Per TCP, openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com imprimeix la cadena que presenta el servidor. Per UDP cal DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 executa la mateixa negociació per datagrames. Una negociació completada demostra que alguna cosa escolta i té un certificat, cosa que és més del que mostra un ping i menys del que exigeixen els propis ajustos de confiança del perfil.

Quan la negociació falla i l'amfitrió respon al ping, el port probablement és incorrecte o filtrat. Preneu-ho com un motiu per demanar el port correcte, no com una invitació a escombrar els propers. nc -vzu també informa d'èxit en algunes piles sense que res escolti, així que una sonda UDP nua no vol dir res sense una negociació al darrere.

Llegiu els pins de confiança separats de l'adreça

L'adreça decideix on va el client; el bloc de confiança decideix en qui creu quan arriba. verify-x509-name "vpn.example.com" name fixa el nom comú del subjecte, i remote-cert-tls server exigeix l'ús estès de la clau per a l'autenticació del servidor. Un perfil lliurat per un operador hauria de portar tots dos.

Busqueu ca, un bloc <ca> en línia, i tls-crypt o tls-auth. Un perfil que utilitza tls-auth necessita key-direction 1 al client quan el costat servidor fa servir la direcció 0, i un desajust fa fallar la negociació amb un error TLS que es llegeix com un defecte de certificat. Un CA en línia que no pertany a l'operador el nom del qual acabeu de resoldre vol dir que el fitxer es va muntar a partir de dues fonts, i aquest és el cas que val la pena rebutjar de ple.

verify-x509-name accepta els modes name, name-prefix o subject, i l'últim espera un nom distingit complet en l'ordre exacte en què el servidor l'imprimeix. Trieu un mode que encaixi amb la forma del valor, perquè el client rebutja cada connexió en lloc d'avisar d'un gairebé encert. Per a un fitxer que no heu escrit, name amb un nom d'amfitrió simple és l'opció menys sorprenent.

Reviseu les opcions que fallen en silenci

OpenVPN 2.6 negocia els xifratges mitjançant data-ciphers, i un perfil que només porta una línia antiga cipher AES-256-CBC pot completar el canal de control i després encallar-se a les dades. Llegir aquest valor us diu si el fitxer és anterior al servidor al qual us uniu; la pàgina de manual del 2.6 llista l'ordre de negociació si cal citar-la a l'operador.

auth-user-pass sense nom de fitxer vol dir que el client preguntarà, així que un perfil que sembla autosuficient encara necessita credencials. auth-user-pass credentials.txt vol dir que espera un fitxer que probablement no us han enviat. nobind i resolv-retry infinite són ordinaris i innocus, mentre que explicit-exit-notify és només per a UDP i inútil per TCP.

Cap d'aquestes coses no canvia on es connecta el perfil, però cadascuna canvia si es connecta o no, i cap no és visible al diàleg d'importació del client.

Decidiu, i després anoteu què heu decidit

Hi ha tres desenllaços després d'aquesta lectura, i només un és la importació. Quan el punt final i els pins coincideixen amb les instruccions que heu rebut per un canal separat, importeu-lo. Quan el punt final sembla correcte però els pins o el CA no coincideixen, demaneu un fitxer corregit. Quan el fitxer barreja punts finals o material de CA de fonts diferents, esborreu-lo i demaneu una còpia nova.

Anoteu el hash que heu revisat, perquè la propera persona pugui saber si el fitxer ha canviat: sha256sum profile.ovpn, enganxat al costat del punt final a les vostres notes. Un perfil és un arranjament sencer, no una llista d'adreces, així que mai no empalmeu un remote que funciona dins del bloc de confiança d'algú altre conservant les seves credencials.

Mentre compareu notes, manteniu les claus privades i les contrasenyes fora de captures de pantalla i fils de xat. El punt final i les opcions no secretes ja basten per fer una pregunta precisa, i la resta pertany al fitxer.

Si finalment l'importeu i el primer intent falla, executeu el client amb --verb 3 i llegiu les deu primeres línies: l'adreça remote resolta, el proto negociat i l'error TLS apareixen en aquest ordre, cosa que us diu quina de les comprovacions de dalt us heu saltat.