DH-tiedosto vai tls-auth-avain? Kahden OpenVPN-tiedoston erottaminen

Kaksi tiedostoa, kaksi direktiiviä ja tapa nimetä molemmat sen mukaan, mitä ne määrittävät. Niin dh.pem päätyy tls-auth-riville ja asiakas epäonnistuu viestiin odottamattomasta avainmuodosta. Edessäsi oleva päätös ei ole, kumpi tiedosto on vahvempi. Se on, minkä roolin käyttöönotto todella tarvitsee, ja kolme ehtoa ratkaisee sen: minkä avainvaihdon TLS-pinosi neuvottelee, haluatko ylipäätään ohjauskanavan todennuksen ja täytyykö aineiston pysyä salaisena.

Vastaa niihin järjestyksessä, niin tiedostokysymys vastaa itse itsensä. Jätä ne väliin, niin direktiivien nimet alkavat näyttää vaihdettavilta, ja juuri siitä tilasta virhe syntyy.

Lue tunniste ennen tiedostonimeä

Tiedoston ensimmäinen rivi on tiedottavampi kuin sen nimi, koska nimi on ihmisen käytäntö ja tunnisteen tuottaa työkalu. Diffie-Hellman-parametrit kantavat PEM-tunnistetta BEGIN DH PARAMETERS. OpenVPN:n staattinen avain on täysin erilainen rakenne, jolla on oma otsake ja heksadesimaalinen hyötykuorma.

Uudelleennimeäminen ei muunna mitään. Parametritiedosto nimeltä ta.key on edelleen parametreja, ja staattinen avain nimeltä dh.pem on edelleen staattinen avain; jäsennin lukee sisällön ja hylkää epäsuhdan. Tarkista ennen profiilin muokkausta:

head -n 1 dh.pem
head -n 1 ta.key

Kolme ehtoa, jotka ratkaisevat, minkä tiedoston tarvitset

Ensimmäinen ehto on vaihto. Äärellisen kentän Diffie-Hellman-kättely tarvitsee ryhmän, ja direktiivi dh on paikka, jossa palvelin nimeää sitä varten parametrit. Elliptisen käyrän kättely ei tarvitse tuota tiedostoa lainkaan, koska käyrä on parametrijoukko. Jos palvelimesi neuvottelee vain ECDHE-sarjoja, DH-tiedosto on kuollutta painoa eikä lisää vahvuutta.

Toinen ehto on ohjauskanavan todennus, erillinen ominaisuus omalla aineistollaan. Tiedosto tls-auth on jaettu staattinen avain, jota molemmat osapuolet pitävät ja jolla allekirjoitetaan ohjauskanavan paketit, jotta todentamaton osapuoli ei voi edes suorittaa kättelyä loppuun. Se on olemassa riippumatta siitä, käytätkö äärellisen kentän DH:ta, eikä sillä ole mitään tekemistä ryhmäparametrien kanssa.

Kolmas ehto on salaisuus ja jakelu. DH-parametrit voidaan julkaista heikentämättä istuntoa, koska salaiset arvot luodaan kättelyä kohti eivätkä ne koskaan poistu osapuolilta. Staattista avainta ei saa julkaista: se on samat tavut molemmissa päissä, se ei kierrä itsestään, ja kuka tahansa sen haltija voi tuottaa kelvollisia ohjauskanavan allekirjoituksia. Nämä kaksi vastausta johtavat täysin erilaisiin käsittelysääntöihin, minkä vuoksi toinen tiedosto voi olla tietovarastossa ja toinen ei.

Tuota oikea aineisto kullekin roolille

Käytä työkalua, joka tuottaa direktiivin odottaman muodon, sen sijaan että muuntaisit niiden välillä. OpenVPN 2.6:n jaetulle avaimelle generaattorin tyypitetty muoto ilmoittaa tarkoituksen suoraan.

openvpn --genkey tls-auth ta.key

Tämä komento luo uutta salaista aineistoa; se ei korjaa eikä tarkasta olemassa olevaa avainta, ja uudelleen ajaminen antaa eri avaimen, jota muilla osapuolilla ei ole. Kopioi syntyvä tiedosto sitä tarvitseville osapuolille kanavaa pitkin, jota käyttäisit mille tahansa jaetulle salaisuudelle, ja pidä suuntakäytäntö johdonmukaisena: tls-auth-asetuksella toinen puoli käyttää key-direction 0 ja toinen key-direction 1.

DH-parametrit tulevat tarvittaessa parametrien generoinnista eivätkä avaingeneraattorista, ja niiden alkuperä on merkityksellinen, vaikka tuloste on julkinen. Tuntemattomasta lähteestä otettu ryhmä ei muutu luotettavaksi siksi, että se on julkinen; sen on edelleen oltava ryhmä, josta osapuolesi sopivat, ja sellainen, jota sen koko tai rakenne ei heikennä.

Mitä dh none tekee ja mitä ei

dh none on todellinen direktiivi, jolla on kapea merkitys: äärellisen kentän parametritiedostoa ei ladata, koska kättely käyttää elliptisen käyrän Diffie-Hellmania. Se ei ole lyhenne ”ohita DH-vaihe” merkityksessä heikentää jotain, eikä se varmasti kerro OpenVPN:lle, että jonkin toisen tiedoston hyväksyminen korvaajana olisi sallittua.

Kaksi virhettä seuraa sen väärin lukemisesta. Ensimmäinen on olettaa, että dh none poistaa tls-auth-tarpeen, vaikka kaksi asiaa ohjaavat eri asioita. Toinen on pitää vanhentunut dh-rivi vain käyrä -kokoonpanon vieressä ja ihmetellä sitten, mitä tiedostoa palvelin tosiasiassa käyttää; jos direktiivi on läsnä, tiedosto luetaan, ja rikkinäinen polku siinä epäonnistuttaa käynnistyksen syystä, joka ei liity neuvoteltavaan vaihtoon.

Jos väärä tiedosto on jo otettu käyttöön

Palauta aiottu salaisuus profiilin omistajalta ja jätä varmennekelpoisuuden tarkistus rauhaan sen aikana. Virhe on muotoepäsuhde, ei luottamusvirhe, ja tarkistuksen poistaminen käytöstä virheen ohittamiseksi korvaa käynnistysongelman hiljaisella ongelmalla.

Erottele sitten kaksi tapahtumaa, jotka ihmiset tapaavat yhdistää. DH-parametritiedoston julkaiseminen on lähes vaaratonta, koska parametrit olivat suunnittelultaan julkisia. Avaimen tls-auth paljastaminen on toinen tapahtuma: avain todentaa ohjauskanavan paketteja jokaiselle osapuolelle, joka sen pitää, joten korvaaminen on sovitettava koko käyttöönoton laajuisesti eikä sovellettava yhteen isäntään.

Viiden minuutin tarkistus ratkaisee, missä tapauksessa olet: lue kunkin tiedoston ensimmäinen rivi, vahvista direktiivi, joka viittaa siihen, ja vahvista, että tiedoston jakelu vastaa sitä, mitä aineisto vaatii. Se on pienempi työ kuin toimivan PKI:n luominen uudelleen, ja juuri siihen kolme ehtoa osoittivat koko ajan.