Så kontrollerar du servern i en OpenVPN-profil innan du importerar den

Någon skickar dig en profil, du importerar den, och trettio sekunder senare ringer en klient upp ett mål som ingen har kontrollerat. Läs filen i en textredigerare först, för allt som spelar roll sitter i en handfull direktiv: remote, proto, port, ca, cert, tls-crypt och verify-x509-name. Allt annat är standardvärden, och det är i standardvärdena överraskningarna bor.

Lista varje slutpunkt som filen kan använda

Börja med slutpunkterna, för en profil kan rymma flera. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn skriver ut varje kandidat i filordning, inklusive dem som ligger inbäddade i inline <connection>-block.

När ett direktiv utelämnar en port faller klienten tillbaka på lyssnarens standard, så remote vpn.example.com ensamt betyder port 1194 med vilken proto som helst som dyker upp senare i filen. Flera vanliga remote-rader är alternativ: klienten provar dem i ordning om inte remote-random blandar dem, och den ersätter aldrig tyst en annan operatörs värd. Två remote-rader på orelaterade domäner är punkten där du stannar och frågar vilken som var avsedd.

Notera också stavningen av proto. tcp accepteras som synonym till klientsidans tcp-client, men tcp-server i en klientprofil är ett konfigurationsfel som tenderar att hänga sig snarare än att misslyckas snyggt.

Bekräfta namnet, sedan porten

dig +short vpn.example.com berättar om namnet finns och vilka adresser det returnerar, och en multi-homed eller proxad slutpunkt kan legitimt returnera flera. Uppslagning är en förutsättning, inte bevis på ägarskap; vem som helst kan peka ett namn mot en adress, och en adress kan svara för många namn.

Kontrollera sedan lyssnaren på den port du hittade, i enlighet med transporten. Över TCP skriver openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com ut den kedja som servern presenterar. Över UDP behöver du DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 kör samma handskakning över datagram. En slutförd handskakning bevisar att något lyssnar och håller ett certifikat, vilket är mer än en ping visar och mindre än profilens egna trust-inställningar kräver.

När handskakningen misslyckas och värden svarar på ping är porten förmodligen fel eller filtrerad. Betrakta det som en anledning att begära rätt port, inte som en inbjudan att svepa de närliggande portarna. nc -vzu rapporterar också framgång på vissa stackar när inget lyssnar, så en bar UDP-sond betyder inget utan en handskakning bakom.

Läs trust-pinnarna skilt från adressen

Adressen avgör vart klienten tar vägen; trust-blocket avgör vem den tror på när den väl är framme. verify-x509-name "vpn.example.com" name pinnar subjektets common name, och remote-cert-tls server kräver den utökade nyckelanvändningen för serverautentisering. En profil som en operatör ger dig bör bära båda.

Leta efter ca, ett inline <ca>-block och antingen tls-crypt eller tls-auth. En profil som använder tls-auth behöver key-direction 1 på klientsidan när serversidan använder riktning 0, och en avvikelse får handskakningen att misslyckas med ett TLS-fel som låter som ett certifikatfel. En inline-CA som inte tillhör operatören vars namn du just slog upp betyder att filen satts ihop från två källor, och det är fallet som är värt att avvisa direkt.

verify-x509-name tar lägena name, name-prefix eller subject, och det sista förväntar sig ett fullständigt distinguished name i exakt den ordning servern skriver ut det. Välj ett läge som matchar värdets form, för klienten avvisar varje anslutning i stället för att varna för en nära miss. För en fil du inte själv har skrivit är name med ett vanligt värdnamn det minst överraskande valet.

Kontrollera alternativen som misslyckas tyst

OpenVPN 2.6 förhandlar chiffer via data-ciphers, och en profil som bara bär en gammal cipher AES-256-CBC-rad kan slutföra kontrollkanalen och sedan fastna på data. Att läsa det värdet säger dig om filen är äldre än servern du ansluter till; 2.6-manualsidan listar förhandlingsordningen om du behöver citera den tillbaka till operatören.

auth-user-pass utan filnamn betyder att klienten frågar, så en profil som ser självförsörjande ut behöver ändå inloggningsuppgifter. auth-user-pass credentials.txt betyder att den förväntar sig en fil som du förmodligen inte fick. nobind och resolv-retry infinite är vanliga och ofarliga, medan explicit-exit-notify bara gäller UDP och är meningslös över TCP.

Inget av detta ändrar var profilen ansluter, men var och ett ändrar om den ansluter alls, och inget av dem syns i en klients importdialog.

Bestäm, och skriv sedan ned vad du bestämde

Det finns tre utfall efter den här läsningen, och bara ett är import. När slutpunkten och pinnarna matchar instruktioner du fick via en separat kanal, importera den. När slutpunkten ser rätt ut men pinnarna eller CA:n inte matchar, be om en korrigerad fil. När filen blandar slutpunkter eller CA-material från olika källor, radera den och begär en fräsch kopia.

Skriv ned hashen du granskade, så att nästa person kan se om filen har ändrats: sha256sum profile.ovpn, inklistrad bredvid slutpunkten i dina anteckningar. En profil är ett helt arrangemang, inte en lista av adresser, så skarva aldrig in en fungerande remote i någon annans trust-block medan du behåller deras inloggningsuppgifter.

Håll privata nycklar och lösenord borta från skärmbilder och chattrådar medan du jämför anteckningar. Slutpunkten och de icke-hemliga alternativen räcker för att ställa en exakt fråga, och resten hör hemma i filen.

Om du importerar den och det första försöket misslyckas, kör klienten med --verb 3 och läs de första tio raderna: den uppslagna fjärradressen, det förhandlade protot och TLS-felet visas i den ordningen, vilket säger dig vilken av kontrollerna ovan du hoppade över.