Korleis stadfeste serveren til ein OpenVPN-profil før du importerer han

Nokon sender deg ein profil, du importerer han, og tretti sekund seinare ringjer ein klient eit mål som ingen har kontrollert. Les fila i ein tekstredigerar først, for alt som tel står i ei handfull direktiv: remote, proto, port, ca, cert, tls-crypt og verify-x509-name. Alt anna er standardverdiar, og det er der overraskingane bur.

List opp kvar endepunkt fila kan bruke

Byrja med endepunkta, for ein profil kan halde fleire. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn skriv ut kvar kandidat i filrekkjefølgje, òg dei som ligg inne i innebygde <connection>-blokker.

Når eit direktiv utelèt porten, fell klienten tilbake til standardverdien til lyttaren, så berre remote vpn.example.com tyder port 1194 med kva proto som helst som dukkar opp seinare i fila. Fleire enkle remote-linjer er alternativ: klienten prøver dei i rekkjefølgje med mindre remote-random stokkar dei, og han byter aldri stille ut verten til ein annan operatør. To remote-linjer på urelaterte domene er punktet der du stoppar og spør kva som var meint.

Legg òg merke til stavinga av proto. tcp blir godteke som synonym for tcp-client på klientssida, men tcp-server i ein klientprofil er ein konfigurasjonsfeil som har lett for å henge i staden for å feile reint.

Stadfest namnet, så porten

dig +short vpn.example.com fortel deg om namnet finst og kva adresser det returnerer, og eit endepunkt med fleire adresser eller bak ein proxy kan rettmessig returnere fleire. Namneoppløysing er ein føresetnad, ikkje eit prov på eigarskap; kven som helst kan peike eit namn mot ei adresse, og éi adresse kan svare for mange namn.

Så kontroller lyttaren på porten du fann, i samsvar med transportlaget. Over TCP skriv openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com ut kjeda serveren presenterer. Over UDP treng du DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 gjer same handtrykket over datagram. Eit fullført handtrykk provar at noko lyttar og held eit sertifikat, som er meir enn ein ping viser og mindre enn det profilens eigne tillitsinnstillingar krev.

Når handtrykket feilar og verten svarar på ping, er porten truleg feil eller filtrert. Sjå på det som ein grunn til å be om rett port, ikkje som ei oppmoding om å feie dei næraste. nc -vzu melder òg om suksess på nokre stablar utan at noko lyttar, så ei berr UDP-prøve tyder ingenting utan eit handtrykk bak.

Les tillitsnaglane skilde frå adressa

Adressa avgjer kvar klienten går; tillitsblokka avgjer kven han trur på når han kjem fram. verify-x509-name "vpn.example.com" name naglar det vanlege namnet til subjektet, og remote-cert-tls server krev utvida nøkkelbruk for serverautentisering. Ein profil du får av ein operatør bør bere båe.

Sjå etter ca, ei innebygd <ca>-blokk og anten tls-crypt eller tls-auth. Ein profil som brukar tls-auth treng key-direction 1 på klienten når serversida brukar retning 0, og eit avvik får handtrykket til å feile med ein TLS-feil som blir lesen som ein sertifikatfeil. Eit innebygd CA som ikkje høyrer til operatøren du nettopp løyste namnet til, tyder at fila er sett saman frå to kjelder, og det er tilfellet som er verdt å avvise blankt.

verify-x509-name tek imot modusane name, name-prefix eller subject, og den siste ventar eit fullt utskilt namn i nøyaktig den rekkjefølgja serveren skriv det ut i. Vel ein modus som passar til forma på verdien, for klienten avviser kvar tilkopling i staden for å varsle om eit nesten-treff. For ei fil du ikkje har skrive, er name med eit enkelt vertsnamn det minst overraskande valet.

Kontroller vala som feilar stille

OpenVPN 2.6 forhandlar om chiffers via data-ciphers, og ein profil som berre har ei gammal cipher AES-256-CBC-linje kan fullføre kontrollkanalen og så stoppe på data. Å lese den verdien fortel deg om fila er eldre enn serveren du sluttar deg til; manualsida for 2.6 listar forhandlingsrekkjefølgja om du treng å sitere henne til operatøren.

auth-user-pass utan filnamn tyder at klienten vil spørje, så ein profil som ser sjølvstendig ut treng framleis innloggingsopplysningar. auth-user-pass credentials.txt tyder at han ventar ei fil du truleg ikkje fekk tilsend. nobind og resolv-retry infinite er vanlege og harmlause, medan explicit-exit-notify berre er for UDP og meiningslaus over TCP.

Ingen av desse endrar kvar profilen koplar seg til, men kvar av dei endrar om han koplar seg til i det heile, og ingen av dei er synlege i importdialogen til klienten.

Avgjer, og skriv så ned kva du avgjorde

Etter denne lesinga finst det tre utfall, og berre eitt er import. Når endepunktet og naglane stemmer med instruksjonane du fekk via ein separat kanal, importerer du han. Når endepunktet ser rett ut men naglane eller CA-en ikkje stemmer, ber du om ei retta fil. Når fila blandar endepunkt eller CA-materiale frå ulike kjelder, slettar du henne og ber om ein fersk kopi.

Skriv ned hashen du gjekk gjennom, så neste person kan sjå om fila er endra: sha256sum profile.ovpn, limt inn ved sida av endepunktet i notata dine. Ein profil er eit heilt oppsett, ikkje ei liste med adresser, så set aldri ein fungerande remote inn i tillitsblokka til nokon andre medan du held på innloggingsopplysningane deira.

Hald private nøklar og passord borte frå skjermbilete og chat-trådar medan du samanliknar notat. Endepunktet og dei ikkje-hemmelege vala er nok til å stille eit presist spørsmål, og resten høyrer til i fila.

Viss du likevel importerer han og første forsøk feilar, køyr klienten med --verb 3 og les dei ti første linjene: den løyste remote-adressa, den forhandla proto-en og TLS-feilen kjem i den rekkjefølgja, noko som fortel deg kva av kontrollane ovanfor du hoppa over.