tls-auth key-direction: arvojen 0 ja 1 on erottava, ei täsmättävä
Tls-authissa molemmat päät tarvitsevat vastakkaiset suunnat, 0 ja 1, tai molempien on jätettävä asetus pois. Sama numero epäonnistuu, eikä tls-crypt koskaan käytä sitä.
Tunnelin toinen pää allekirjoittaa ohjauskanavan avainpaikalla, jota toinen pää ei koskaan tarkista, ja yhteys kuolee todennusvirheeseen ennen kuin yhtäkään varmennetta on vaihdettu. Tältä tls-auth-asetuksen suuntaristiriita näyttää, ja se on deterministinen: samat kaksi tiedostoa epäonnistuvat joka yrityksellä, mistä tahansa verkosta. Mikään lokissa ei nimeä asetusta, jota etsit, siksi ihmiset rakentavat avaimia uudelleen ja myöntävät varmenteita, jotka eivät koskaan olleet rikki. Ratkaisu on tehdä kahdesta päästä toisiaan täydentävät tai jättää molemmat kaksisuuntaisiksi, ei heikentää tarkistusta.
Virhe tapahtuu ennen varmenteita
tls-auth-asetuksessa molemmilla osapuolilla on sama jaettu avain, ja kumpikin käyttää yhtä kahdesta siitä johdetusta paikasta: toinen paikka allekirjoittaa lähtevät ohjauspaketit, toinen tarkistaa saapuvat. Suunta 0 ja suunta 1 jakavat nämä roolit päinvastaisessa järjestyksessä, joten parin on oltava täydentävä, jotta HMAC-tarkistukset osuvat kohdakkain. Kun jako käännetään toisella puolella, vastaanottaja etsii allekirjoitusta väärästä paikasta ja hylkää paketin. Istunto päättyy siihen, siksi virhe koskee pakettien todennusta eikä mitään, mitä varmennevarasto tuottaisi.
Determinismi on tärkeää diagnostiikalle, koska aika- tai reittiongelma jättää erilaisen jäljen: ajoittaisia katkoksia, yhden suunnan epäonnistuminen tai istunto, joka kuolee vain tietyssä verkossa. Suuntaristiriita epäonnistuu ensimmäisessä kättelyssä joka kerta, ja se epäonnistuu samalla tavalla toisella koneella, jossa on samat kaksi tiedostoa. Lue lokia --verb 4 -asetuksella ja etsi ensimmäinen hylätty paketti viimeisen rivin sijaan. Jos hylkäys tapahtuu ennen mitään varmennevaihtoa, jaettu avain ja sen suunta ovat ne kaksi asiaa, jotka kannattaa tarkistaa.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Missä numero asuu
Opas OpenVPN 2.6 dokumentoi kaksi paikkaa suunnalle: tls-auth-asetuksen toinen argumentti, kun avain on omassa tiedostossaan, ja erillinen key-direction-rivi, kun avain on upotettu profiiliin. Molemmat asettavat saman arvon, joten profiilin pitäisi käyttää toista muotoa, ei koskaan molempia. Myös pois jättäminen on valinta, ja se asettaa molemmat osapuolet kaksisuuntaiseen järjestelyyn, joka toimii, kun kumpikaan puoli ei nimeä suuntaa. Kaksi saman numeron osapuolta ei ole siinä järjestelyssä: kumpikin odottaa allekirjoittavansa toisessa paikassa ja tarkistavansa toisessa, ja molemmat tekevät sen samoin päin.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
Upotettu muoto on direktiivi omalla rivillään, ei attribuutti avainlohkon avaustagissa, ja argumentin lisääminen siihen tagiin on virhe, ei suunnan muutos. Myös sijoitus merkitsee: direktiivi on sen lohkon ulkopuolella, johon se kuuluu, joten lohkon sisään kirjoitettu arvo luetaan avainmateriaaliksi. Kopioi järjestely, jonka profiilin jakelija on tarkoittanut, älä keksi paria, sillä yhtä palvelinta vastaan toimiva profiili voi olla jo peilattu toiselle puolelle.
Mitä asetus jättää rauhaan
Se ei salaa sovellusliikennettä. tls-auth asettaa HMAC:n ohjauskanavan pakettien ympärille, kun taas datakanavaa suojaavat kättelyssä neuvotellut istuntoavaimet, joten läpäisykykyä tai salausta koskeva kysymys ei liity suuntanumeroon mitenkään. Asetus ei myöskään lisää toista salauskerrosta, ja juuri se oletus lähettää ihmiset etsimään pidempää avainta.
Se ei koske tls-crypt-asetusta, toinen ohjauskanavan mekanismi, jolla on omat asetuksensa ja avainkäsittelynsä, eikä se kerro mitään minkään osapuolen varmenneidentiteetistä. Toimiva suuntien täsmääminen todistaa siis vain, että molemmat päät ovat yhtä mieltä ohjauskanavan todennuksesta, ei sitä, että luottamusketju on validoitu.
Kohdista pari ja yhdistä uudelleen
Vertaa molempia kokoonpanoja ennen kuin muutat kumpaakaan, sillä jo oikean puolen muokkaaminen kaksinkertaistaa työn. Alla oleva grep näyttää, minkä mekanismin kukin tiedosto valitsee; yksityiskohtainen ajo näyttää, todennettiinko ohjauskanava lainkaan. Säilytä molemmat tulosteet, jotta seuraavaa muutosta voidaan verrata tunnettuun tilaan.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Käynnistä molemmat osapuolet uudelleen jokaisen muutoksen jälkeen, sillä nämä asetukset luetaan kerran käynnistyksessä ja toisen puolen uudelleenlataus jättää parin epäjohdonmukaiseksi vanhan istunnon koko eliniäksi. Jos käyttöönotto toimii nyt ilman määritettyä suuntaa, asetuksen lisääminen toiselle osapuolelle toistaa sen virheen, jolla aloitit; joko jätä molemmat rauhaan tai määritä molemmat. Muuta yhtä päätä kerrallaan ja säilytä edellinen tiedosto, jotta regressio on kahden minuutin palautus eikä uudelleenrakennus.
Kirjaa mekanismi, avaintiedosto ja suunta kummallekin päälle käyttöönoton muistiinpanoihin, sillä muuten seuraava henkilö lukee kaksi samankaltaista tiedostoa ja olettaa, että numeroiden pitäisi täsmätä keskenään. Suunta on koordinointiyksityiskohta, ei tietoturvaparannus: se erottaa ohjauskanavan kaksi suuntaa eikä tee muuta.