Slik kontrollerer du serveren i en OpenVPN-profil før du importerer den

Noen sender deg en profil, du importerer den, og tretti sekunder senere ringer en klient til en destinasjon som ingen har kontrollert. Les filen i en tekstredigerer først, for alt som betyr noe sitter i en håndfull direktiver: remote, proto, port, ca, cert, tls-crypt og verify-x509-name. Alt annet er standardverdier, og det er i standardverdiene 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, inkludert dem som ligger nestet i innebygde <connection>-blokker.

Når et direktiv utelater en port, faller klienten tilbake på lytterens standard, så remote vpn.example.com alene betyr port 1194 med hvilken proto som helst som dukker opp senere i filen. Flere vanlige remote-linjer er alternativer: klienten prøver dem i rekkefølge med mindre remote-random stokker dem, og den erstatter aldri stille en annen operatørs vert. 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 klientsidens tcp-client, men tcp-server i en klientprofil er en konfigurasjonsfeil som har en tendens til å henge i stedet for å feile pent.

Bekreft navnet, deretter porten

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

Kontroller deretter lytteren på porten du fant, i samsvar med transporten. 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 kjører 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 profilens egne tillitsinnstillinger krever.

Når håndtrykket feiler og verten svarer på ping, er porten sannsynligvis feil eller filtrert. Behandle det som en grunn til å be om riktig port, ikke som en invitasjon til å feie de nærliggende portene. nc -vzu rapporterer også suksess på enkelte stabler mens ingenting lytter, så en bar UDP-sond 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 først er fremme. verify-x509-name "vpn.example.com" name pinner subjektets common name, og remote-cert-tls server krever den utvidede nøkkelbruken for serverautentisering. En profil en operatør gir deg 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å klientsiden når serversiden bruker retning 0, og et avvik får håndtrykket til å feile med en TLS-feil som høres ut som en sertifikatfeil. En innebygd CA som ikke tilhører operatøren hvis navn du nettopp slo opp, betyr at filen er satt sammen fra to kilder, og det er tilfellet som er verdt å avvise blankt.

verify-x509-name tar modusene name, name-prefix eller subject, og den siste forventer et fullstendig distinguished name i nøyaktig den rekkefølgen serveren skriver det ut. Velg en modus som passer til verdens form, for klienten avviser hver tilkobling i stedet for å varsle om en nesten-treff. For en fil du ikke har skrevet selv, er name med et vanlig vertsnavn det minst overraskende valget.

Kontroller alternativene som feiler stille

OpenVPN 2.6 forhandler chiffre via data-ciphers, og en profil som bare bærer en gammel cipher AES-256-CBC-linje kan fullføre kontrollkanalen og deretter stoppe på data. Å lese den verdien forteller deg om filen er eldre enn serveren du kobler til; 2.6-manualsiden lister forhandlingsrekkefølgen hvis du må sitere den tilbake til operatøren.

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

Ingen av disse endrer hvor profilen kobler til, men hver endrer om den kobler til i det hele tatt, og ingen av dem er synlig i en klients importdialog.

Bestem, og skriv deretter ned hva du bestemte

Det finnes tre utfall etter denne lesingen, og bare ett er import. Når endepunktet og pinnene samsvarer med instruksjoner du fikk gjennom en separat kanal, importer den. Når endepunktet ser riktig ut men pinnene eller CA-en ikke samsvarer, be om en korrigert fil. Når filen blander endepunkter eller CA-materiale fra ulike kilder, slett den og be om en fersk kopi.

Skriv ned hashen du gikk gjennom, slik at 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 arrangement, ikke en liste av adresser, så skjøt aldri inn en fungerende remote i noen andres tillitsblokk mens du beholder påloggingsupplysningene deres.

Hold private nøkler og passord unna skjermbilder og chattekster mens du sammenligner notater. Endepunktet og de ikke-hemmelige alternativene er nok til å stille et presist spørsmål, og resten hører hjemme i filen.

Hvis du importerer den og det første forsøket feiler, kjør klienten med --verb 3 og les de ti første linjene: den oppslåtte eksterne adressen, det forhandlede protoet og TLS-feilen vises i den rekkefølgen, noe som forteller deg hvilken av kontrollene ovenfor du hoppet over.