tls-auth key-direction: 0 ja 1 peavad erinema, mitte kattuma
Tls-authi puhul vajavad mõlemad otsad vastassuunalisi suundi, 0 ja 1, või peavad mõlemad seade vahele jätma. Sama number ebaõnnestub ja tls-crypt ei kasuta seda kunagi.
Tunneli üks pool allkirjastab juhtkanali võtme pesaga, mida teine pool kunagi ei kontrolli, ja ühendus sureb autentimisveaga enne, kui ükski sertifikaat on vahetatud. Selline näeb välja tls-auth suunalahknevus, ja see on deterministlik: samad kaks faili ebaõnnestuvad igal katsel, igast võrgust. Logis ei nimetata valikut, mida otsite, seetõttu loovad inimesed võtmeid uuesti ja annavad välja sertifikaate, mis polnud kunagi katki. Lahendus on muuta kaks otsa täiendavaks või jätta mõlemad kahesuunaliseks, mitte nõrgendada kontrolli.
Tõrge saabub enne sertifikaate
tls-auth korral on mõlemal poolel sama ühine võti ja kumbki kasutab ühte kahest sellest tuletatud pesast: üks pesa allkirjastab väljuvaid juhtpakette, teine kontrollib sissetulevaid. Suund 0 ja suund 1 määravad need rollid vastupidises järjekorras, seega peab paar olema täiendav, et HMAC-kontrollid klapiksid. Kui määramine ühel pool pööratakse, otsib vastuvõtja allkirja valest pesast ja lükkab paketi tagasi. Sessioon lõpeb seal, seetõttu puudutab viga paketi autentimist, mitte midagi, mida sertifikaadihoidla toodaks.
Determinism on diagnoosimisel oluline, sest aja- või teeprobleem jätab teistsuguse jälje: katkendlikud katkestused, ühe suuna tõrge või sessioon, mis sureb ainult kindlas võrgus. Suunalahknevus ebaõnnestub igal korral esimesel kätlusel ja ebaõnnestub samamoodi teisel masinal samade kahe failiga. Lugege logi --verb 4 juures ja leidke esimene tagasilükatud pakett, mitte viimane rida. Kui see tagasilükkamine toimub enne mis tahes sertifikaadivahetust, on ühine võti ja selle suund need kaks asja, mida tasub kontrollida.
| 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 |
Kus number elab
Juhend OpenVPN 2.6 dokumenteerib suuna jaoks kaks kohta: tls-auth teine argument, kui võti on eraldi failis, ja eraldiseisev key-direction rida, kui võti on profiili sisse lisatud. Mõlemad seavad sama väärtuse, seega peaks profiil kasutama üht vormi või teist, mitte kunagi mõlemat. Vahelejätmine on samuti valik ja paneb mõlemad pooled kahesuunalisse paigutusse, mis töötab, kui kumbki pool suunda ei nimeta. Kaks sama numbriga poolt ei ole selles paigutuses: kumbki ootab allkirjastamist ühes pesas ja kontrolli teises, ja mõlemad teevad seda ühtemoodi.
# 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
Sisestatud vorm on direktiiv omaette real, mitte atribuut võtmebloki avamissildil, ja argumendi lisamine sellele sildile on viga, mitte suunamuutus. Paigutus loeb samuti: direktiiv asub väljaspool plokki, kuhu see kuulub, seega ploki sees kirjutatud väärtust loetakse võtmematerjalina. Kopeerige paigutus, mida profiili levitaja silmas pidas, selle asemel et paar välja mõelda, sest ühe serveri vastu töötav profiil võib olla teisel pool juba peegeldatud.
Mida valik puutumata jätab
See ei krüpteeri rakendusliiklust. tls-auth paneb HMAC-i juhtkanali pakettide ümber, andmekanalit kaitsevad aga kätlusel kokku lepitud sessioonivõtmed, seega läbilaskevõime või šifri küsimusel pole suunanumbriga mingit pistmist. Seade ei lisa ka teist krüpteerimiskihti, ja just see eeldus saadab inimesi pikemat võtit otsima.
See ei kehti tls-crypt kohta, teistsugune juhtkanali mehhanism oma valikute ja võtmekäitlusega, ja see ei ütle midagi ühegi poole sertifikaadi identiteedi kohta. Toimiv suundade kattumine tõestab seega ainult, et mõlemad otsad on ühel meelel, kuidas juhtkanalit autentida, mitte et usaldusahel oleks valideeritud.
Joondage paar ja ühendage uuesti
Võrrelge mõlemat konfiguratsiooni enne, kui ühtegi muudate, sest juba õige poole muutmine kahekordistab töö. Allolev grep näitab, millise mehhanismi iga fail valib; üksikasjalik käivitus näitab, kas juhtkanal üldse autentiti. Hoidke mõlemad väljundid alles, et järgmist muudatust saaks teadaoleva seisuga võrrelda.
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'
Taaskäivitage mõlemad pooled pärast iga muudatust, sest neid valikuid loetakse käivitamisel üks kord ja ühe poole uuesti laadimine jätab paari ebajärjekindlaks kogu vana sessiooni elueaks. Kui juurutamine töötab praegu ilma seadistatud suunata, taasesitab seade lisamine ühele poolele tõrke, millega alustasite; kas jätke mõlemad rahule või seadistage mõlemad. Muutke korraga üht otsa ja hoidke eelmist faili alles, et regressioon oleks kaheminutiline tagasipööramine, mitte ülesehitamine.
Kirjutage mehhanism, võtmefail ja suund iga otsa kohta juurutusmärkmetesse, sest muidu loeb järgmine inimene kaks sarnast faili ja eeldab, et numbrid peavad omavahel kokku langema. Suund on koordineerimise detail, mitte turvalisuse uuendus: see eraldab juhtkanali kaks suunda ega tee midagi muud.