Sådan kontrollerer du serveren i en OpenVPN-profil, før du importerer den

Nogen sender dig en profil, du importerer den, og tredive sekunder senere ringer en klient til en destination, som ingen har kontrolleret. Læs filen i en teksteditor først, for alt det afgørende står i en håndfuld direktiver: remote, proto, port, ca, cert, tls-crypt og verify-x509-name. Alt andet er standardværdier, og det er i standardværdierne, at overraskelserne bor.

List hvert endpoint, som filen kan bruge

Begynd med endepunkterne, for én profil kan indeholde flere. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn udskriver hver kandidat i filrækkefølge, inklusive dem, der ligger indlejret i inline <connection>-blokke.

Når et direktiv udelader en port, falder klienten tilbage på lytterens standard, så remote vpn.example.com alene betyder port 1194 med den proto, der dukker op senere i filen. Flere almindelige remote-linjer er alternativer: klienten prøver dem i rækkefølge, medmindre remote-random blander dem, og den erstatter aldrig lydløst en anden operatørs vært. To remote-linjer på urelaterede domæner er det punkt, hvor du stopper og spørger, hvilken der var ment.

Læg også mærke til stavemåden af proto. tcp accepteres som synonym for klientsidens tcp-client, men tcp-server i en klientprofil er en konfigurationsfejl, som har tendens til at hænge i stedet for at fejle pænt.

Bekræft navnet, derefter porten

dig +short vpn.example.com fortæller dig, om navnet findes, og hvilke adresser det returnerer, og et multi-homed eller proxyet endepunkt kan med rette returnere flere. Opløsning er en forudsætning, ikke bevis på ejerskab; enhver kan pege et navn mod en adresse, og én adresse kan svare for mange navne.

Kontrollér derefter lytteren på den port, du fandt, i overensstemmelse med transporten. Over TCP udskriver openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com den kæde, serveren præsenterer. Over UDP har du brug for DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 kører det samme håndtryk over datagrammer. Et fuldført håndtryk beviser, at noget lytter og holder et certifikat, hvilket er mere, end en ping viser, og mindre, end profilens egne tillidsindstillinger kræver.

Når håndtrykket fejler, og værten svarer på ping, er porten sandsynligvis forkert eller filtreret. Betragt det som en grund til at anmode om den korrekte port, ikke som en invitation til at feje de nærliggende porte. nc -vzu rapporterer også succes på nogle stakke, mens intet lytter, så en bar UDP-sonde betyder intet uden et håndtryk bag.

Læs tillidsnitterne adskilt fra adressen

Adressen afgør, hvor klienten går hen; tillidsblokken afgør, hvem den tror på, når den ankommer. verify-x509-name "vpn.example.com" name fastgør subjektets fællesnavn, og remote-cert-tls server kræver den udvidede nøgleanvendelse til servergodkendelse. En profil, som en operatør giver dig, bør bære begge.

Kig efter ca, en inline <ca>-blok og enten tls-crypt eller tls-auth. En profil, der bruger tls-auth, har brug for key-direction 1 på klientsiden, når serversiden bruger retning 0, og en uoverensstemmelse får håndtrykket til at fejle med en TLS-fejl, der lyder som en certifikatfejl. En inline CA, der ikke tilhører den operatør, hvis navn du netop har opløst, betyder, at filen er samlet fra to kilder, og det er tilfældet, der er værd at afvise blankt.

verify-x509-name tager name, name-prefix eller subject-tilstande, og den sidste forventer et fuldt distinguished name i præcis den rækkefølge, serveren udskriver det. Vælg en tilstand, der passer til værdiens form, for klienten afviser hver forbindelse i stedet for at advare om et næsten-hit. For en fil, du ikke selv har skrevet, er name med et almindeligt værtsnavn det mindst overraskende valg.

Kontrollér de indstillinger, der fejler stille

OpenVPN 2.6 forhandler cifre via data-ciphers, og en profil, der kun bærer en gammel cipher AES-256-CBC-linje, kan gennemføre kontrolkanalen og derefter gå i stå på data. At læse den værdi fortæller dig, om filen er ældre end den server, du tilslutter dig; 2.6-manualsiden viser forhandlingsrækkefølgen, hvis du skal citere den tilbage til operatøren.

auth-user-pass uden filnavn betyder, at klienten spørger, så en profil, der ser selvforsynende ud, har stadig brug for legitimationsoplysninger. auth-user-pass credentials.txt betyder, at den forventer en fil, du sandsynligvis ikke har fået. nobind og resolv-retry infinite er almindelige og uskadelige, mens explicit-exit-notify kun er til UDP og meningsløs over TCP.

Ingen af disse ændrer, hvor profilen forbinder, men hver især ændrer, om den overhovedet forbinder, og ingen af dem er synlige i en klients importdialog.

Beslut, og notér derefter, hvad du besluttede

Der findes tre udfald efter denne læsning, og kun ét er import. Når endepunktet og nitterne matcher instruktioner, du fik gennem en separat kanal, skal du importere den. Når endepunktet ser rigtigt ud, men nitterne eller CA'en ikke matcher, skal du bede om en rettet fil. Når filen blander endepunkter eller CA-materiale fra forskellige kilder, skal du slette den og anmode om en frisk kopi.

Notér den hash, du gennemgik, så den næste person kan se, om filen er ændret: sha256sum profile.ovpn, indsat ved siden af endepunktet i dine noter. En profil er en hel ordning, ikke en liste af adresser, så man må aldrig indsætte en fungerende remote i en andens tillidsblok, mens man beholder deres legitimationsoplysninger.

Hold private nøgler og adgangskoder ude af skærmbilleder og chattråde, mens du sammenligner noter. Endepunktet og de ikke-hemmelige indstillinger er nok til at stille et præcist spørgsmål, og resten hører til i filen.

Hvis du importerer den, og det første forsøg fejler, så kør klienten med --verb 3 og læs de første ti linjer: den opløste eksterne adresse, den forhandlede proto og TLS-fejlen vises i den rækkefølge, hvilket fortæller dig, hvilken af kontrollerne ovenfor du sprang over.