OpenVPN-profiilin palvelimen tarkistaminen ennen sen tuontia

Joku lähettää sinulle profiilin, tuot sen ja kolmekymmentä sekuntia myöhemmin asiakasohjelma valitsee kohteen, jota kukaan ei tarkistanut. Lue tiedosto ensin tekstieditorissa, sillä kaikki oleellinen mahtuu kouralliseen direktiivejä: remote, proto, port, ca, cert, tls-crypt ja verify-x509-name. Kaikki muu on oletusarvoja, ja yllätykset asuvat juuri siellä.

Luettele jokainen päätepiste, jota tiedosto voi käyttää

Aloita päätepisteistä, sillä yksi profiili voi sisältää useita. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn tulostaa jokaisen ehdokkaan tiedoston järjestyksessä, mukaan lukien sisäkkäiset rivinsisäisissä <connection>-lohkoissa.

Kun direktiivi jättää portin pois, asiakas palaa kuuntelijan oletukseen, joten pelkkä remote vpn.example.com tarkoittaa porttia 1194 riippumatta siitä, mikä proto myöhemmin tiedostossa esiintyy. Useat tavalliset remote-rivit ovat vaihtoehtoja: asiakas kokeilee niitä järjestyksessä, ellei remote-random sekoita niitä, eikä se koskaan vaihda hiljaa toisen operaattorin isäntää. Kaksi remote-riviä toisiinsa liittymättömillä verkkotunnuksilla on kohta, jossa pysähdyt ja kysyt, kumpaa tarkoitettiin.

Huomaa myös proto-kirjoitusasu. tcp hyväksytään asiakaspuolen tcp-client-synonyymiksi, mutta tcp-server asiakasprofiilissa on määritysvirhe, joka yleensä jumittuu sen sijaan että epäonnistuisi siististi.

Vahvista ensin nimi ja sitten portti

dig +short vpn.example.com kertoo, onko nimi olemassa ja mitä osoitteita se palauttaa, ja moniosoitteinen tai välityspalvelimen takana oleva päätepiste voi laillisesti palauttaa useita. Nimen selvitys on ennakkoehto, ei todiste omistajuudesta; kuka tahansa voi osoittaa nimen osoitteeseen, ja yksi osoite voi vastata monien nimien puolesta.

Tarkista sitten kuuntelija löytämästäsi portista siirtokerroksen mukaisesti. TCP:n yli openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com tulostaa ketjun, jonka palvelin esittää. UDP:n yli tarvitset DTLS:n: openssl s_client -dtls1_2 -connect vpn.example.com:1194 suorittaa saman kättelyn datagrammien yli. Valmis kättely todistaa, että jokin kuuntelee ja pitää varmentetta, mikä on enemmän kuin ping näyttää ja vähemmän kuin profiilin omat luottamusasetukset vaativat.

Kun kättely epäonnistuu ja isäntä vastaa pingiin, portti on todennäköisesti väärä tai suodatettu. Pidä sitä syynä pyytää oikea portti, älä kutsuna harjata läheisiä. nc -vzu ilmoittaa joissakin pinoissa onnistumisen, vaikka mikään ei kuuntelisi, joten pelkkä UDP-koe ei tarkoita mitään ilman kättelyä sen takana.

Lue luottamustapit erillään osoitteesta

Osoite päättää, minne asiakas menee; luottamuslohko päättää, ketä se uskoo saapuessaan. verify-x509-name "vpn.example.com" name kiinnittää kohteen yleisnimen ja remote-cert-tls server vaatii laajennetun avaimen käytön palvelimen todennukselle. Operaattorin antaman profiilin tulisi kantaa molemmat.

Etsi ca, rivinsisäinen <ca>-lohko ja joko tls-crypt tai tls-auth. tls-auth käyttävä profiili tarvitsee asiakkaassa key-direction 1, kun palvelinpuoli käyttää suuntaa 0, ja epäjohdonmukaisuus kaataa kättelyn TLS-virheeseen, joka luetaan varmenteen viaksi. Rivinsisäinen CA, joka ei kuulu operaattorille, jonka nimen juuri selvitit, tarkoittaa, että tiedosto on koottu kahdesta lähteestä, ja se on tapaus, joka kannattaa hylätä suoralta kädeltä.

verify-x509-name hyväksyy tilat name, name-prefix tai subject, ja viimeinen odottaa täydellistä erottavaa nimeä täsmälleen siinä järjestyksessä, jossa palvelin sen tulostaa. Valitse tila, joka vastaa arvon muotoa, sillä asiakas hylkää jokaisen yhteyden sen sijaan että varoittaisi läheltä piti -tilanteesta. Tiedostolle, jota et kirjoittanut, yksinkertaisella isäntänimellä name on vähiten yllättävä valinta.

Tarkista asetukset, jotka epäonnistuvat hiljaa

OpenVPN 2.6 neuvottelee salaukset data-ciphers-asetuksen kautta, ja profiili, jossa on vain vanha cipher AES-256-CBC-rivi, voi saada ohjauskanavan valmiiksi ja sitten juuttua dataan. Tämän arvon lukeminen kertoo, onko tiedosto vanhempi kuin palvelin, johon liityt; 2.6:n käsikirjasivu luettelee neuvottelujärjestyksen, jos tarvitset sitä operaattorille siteerataksesi.

auth-user-pass ilman tiedostonimeä tarkoittaa, että asiakas kysyy, joten itsenäiseltä näyttävä profiili tarvitsee silti tunnistetiedot. auth-user-pass credentials.txt tarkoittaa, että se odottaa tiedostoa, jota sinulle ei todennäköisesti lähetetty. nobind ja resolv-retry infinite ovat tavallisia ja vaarattomia, kun taas explicit-exit-notify on vain UDP:lle ja hyödytön TCP:n yli.

Mikään näistä ei muuta sitä, minne profiili yhdistää, mutta jokainen muuttaa sitä, yhdistääkö se lainkaan, eikä mikään niistä näy asiakkaan tuontivalintaikkunassa.

Päätä ja kirjaa sitten, mitä päätit

Tämän lukemisen jälkeen on kolme lopputulosta, ja vain yksi on tuonti. Kun päätepiste ja tapit vastaavat eri kanavaa pitkin saamiasi ohjeita, tuo se. Kun päätepiste näyttää oikealta mutta tapit tai CA eivät täsmää, pyydä korjattu tiedosto. Kun tiedosto sekoittaa eri lähteistä peräisin olevia päätepisteitä tai CA-materiaalia, poista se ja pyydä tuore kopio.

Kirjaa tarkistamasi hash, jotta seuraava henkilö tietää, muuttuiko tiedosto: sha256sum profile.ovpn, liitettynä päätepisteen viereen muistiinpanoihisi. Profiili on kokonainen järjestely, ei osoiteluettelo, joten älä koskaan liitä toimivaa remotea toisen luottamuslohkoon säilyttäen heidän tunnistetietonsa.

Pidä yksityiset avaimet ja salasanat poissa kuvakaappauksista ja keskusteluketjuista, kun vertailet muistiinpanoja. Päätepiste ja ei-salaiset asetukset riittävät tarkan kysymyksen esittämiseen, ja loput kuuluvat tiedostoon.

Jos kuitenkin tuot sen ja ensimmäinen yritys epäonnistuu, käynnistä asiakas --verb 3-valinnalla ja lue kymmenen ensimmäistä riviä: selvinnyt remote-osoite, neuvoteltu proto ja TLS-virhe ilmestyvät tässä järjestyksessä, mikä kertoo, minkä yllä olevista tarkistuksista jätit väliin.