Slik verifiserer du serveren til en OpenVPN-profil før du importerer den

Noen sender deg en profil, du importerer den, og tretti sekunder senere ringer en klient et mål som ingen har kontrollert. Les filen i et tekstredigeringsprogram først, for alt som betyr noe står i en håndfull direktiver: remote, proto, port, ca, cert, tls-crypt og verify-x509-name. Alt annet er standardverdier, og det er der overraskelsene bor.

List opp hvert endepunkt filen kan bruke

Begynn med endepunktene, for én profil kan inneholde flere. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn skriver ut hver kandidat i filrekkefølge, også de som ligger inne i innebygde <connection>-blokker.

Når et direktiv utelater porten, faller klienten tilbake til standardverdien til lytteren, så bare remote vpn.example.com betyr port 1194 med hvilken som helst proto som dukker opp senere i filen. Flere enkle remote-linjer er alternativer: klienten prøver dem i rekkefølge med mindre remote-random stokker dem, og den bytter aldri stille ut verten til en annen operatør. To remote-linjer på urelaterte domener er punktet der du stopper og spør hvilken som var ment.

Legg også merke til stavemåten til proto. tcp godtas som synonym for tcp-client på klientsiden, men tcp-server i en klientprofil er en konfigurasjonsfeil som lett henger i stedet for å feile rent.

Bekreft navnet, så porten

dig +short vpn.example.com forteller deg om navnet finnes og hvilke adresser det returnerer, og et endepunkt med flere adresser eller bak en proxy kan med rette returnere flere. Navneoppslag er en forutsetning, ikke et bevis på eierskap; hvem som helst kan peke et navn mot en adresse, og én adresse kan svare for mange navn.

Så kontroller lytteren på porten du fant, i samsvar med transportlaget. Over TCP skriver openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com ut kjeden serveren presenterer. Over UDP trenger du DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 gjør samme håndtrykk over datagrammer. Et fullført håndtrykk beviser at noe lytter og holder et sertifikat, som er mer enn en ping viser og mindre enn det profilens egne tillitsinnstillinger krever.

Når håndtrykket feiler og verten svarer på ping, er porten trolig feil eller filtrert. Se på det som en grunn til å be om riktig port, ikke som en invitasjon til å feie de nærmeste. nc -vzu rapporterer også suksess på noen stabler uten at noe lytter, så en bar UDP-prøve betyr ingenting uten et håndtrykk bak.

Les tillitspinnene atskilt fra adressen

Adressen avgjør hvor klienten går; tillitsblokken avgjør hvem den tror på når den kommer frem. verify-x509-name "vpn.example.com" name pinnar det vanlige navnet til subjektet, og remote-cert-tls server krever utvidet nøkkelbruk for serverautentisering. En profil du får av en operatør bør bære begge.

Se etter ca, en innebygd <ca>-blokk og enten tls-crypt eller tls-auth. En profil som bruker tls-auth trenger key-direction 1 på klienten når serversiden bruker retning 0, og et avvik får håndtrykket til å feile med en TLS-feil som leses som en sertifikatfeil. Et innebygd CA som ikke tilhører operatøren du nettopp slo opp navnet til, betyr at filen er satt sammen fra to kilder, og det er tilfellet som er verdt å avvise blankt.

verify-x509-name tar imot modusene name, name-prefix eller subject, og den siste venter et fullt utskilt navn i nøyaktig den rekkefølgen serveren skriver det ut i. Velg en modus som passer til formen på verdien, for klienten avviser hver tilkobling i stedet for å varsle om et nesten-treff. For en fil du ikke har skrevet, er name med et enkelt vertsnavn det minst overraskende valget.

Kontroller valgene som feiler stille

OpenVPN 2.6 forhandler om chiffere via data-ciphers, og en profil som bare har en gammel cipher AES-256-CBC-linje kan fullføre kontrollkanalen og så stoppe på data. Å lese den verdien forteller deg om filen er eldre enn serveren du kobler deg til; manualsiden for 2.6 lister forhandlingsrekkefølgen om du trenger å sitere den til operatøren.

auth-user-pass uten filnavn betyr at klienten vil spørre, så en profil som ser selvstendig ut trenger fortsatt påloggingsdetaljer. auth-user-pass credentials.txt betyr at den venter en fil du trolig ikke fikk tilsendt. nobind og resolv-retry infinite er vanlige og harmløse, mens explicit-exit-notify bare er for UDP og meningsløs over TCP.

Ingen av disse endrer hvor profilen kobler seg til, men hver av dem endrer om den kobler seg til i det hele tatt, og ingen av dem er synlige i importdialogen til klienten.

Avgjør, og skriv så ned hva du avgjorde

Etter denne lesingen finnes det tre utfall, og bare ett er import. Når endepunktet og pinnene stemmer med instruksjonene du fikk via en separat kanal, importerer du den. Når endepunktet ser riktig ut men pinnene eller CA-en ikke stemmer, ber du om en rettet fil. Når filen blander endepunkter eller CA-materiale fra ulike kilder, sletter du den og ber om en fersk kopi.

Skriv ned hashen du gikk gjennom, så neste person kan se om filen er endret: sha256sum profile.ovpn, limt inn ved siden av endepunktet i notatene dine. En profil er et helt oppsett, ikke en liste med adresser, så sett aldri en fungerende remote inn i tillitsblokken til noen andre mens du beholder påloggingsdetaljene deres.

Hold private nøkler og passord borte fra skjermbilder og chat-tråder mens du sammenligner notater. Endepunktet og de ikke-hemmelige valgene er nok til å stille et presist spørsmål, og resten hører hjemme i filen.

Hvis du likevel importerer den og første forsøk feiler, kjør klienten med --verb 3 og les de ti første linjene: den løste remote-adressen, den forhandlede proto-en og TLS-feilen kommer i den rekkefølgen, noe som forteller deg hvilken av kontrollene ovenfor du hoppet over.