tls-auth key-direction: 0 ir 1 turi skirtis, o ne sutapti
Naudojant tls-auth abiem galams reikia priešingų krypčių, 0 ir 1, arba abu turi praleisti nustatymą. Tas pats skaičius nepavyksta, o tls-crypt jo niekada nenaudoja.
Viena tunelio pusė pasirašo valdymo kanalą raktų lizdu, kurio kita pusė niekada netikrina, ir ryšys miršta su autentifikavimo klaida dar neperdavus nė vieno sertifikato. Taip atrodo tls-auth krypties nesutapimas, ir jis yra deterministinis: tie patys du failai nepavyksta per kiekvieną bandymą, iš bet kurio tinklo. Žurnale niekas neįvardija parinkties, kurios ieškote, todėl žmonės per naujo kuria raktus ir iš naujo išduoda sertifikatus, kurie niekada nebuvo sugedę. Sprendimas yra padaryti abu galus papildančius arba palikti abu dvikrypčius, o ne silpninti tikrinimą.
Nesėkmė įvyksta prieš sertifikatus
Naudojant tls-auth abu partneriai turi tą patį bendrą raktą, ir kiekvienas naudoja vieną iš dviejų iš jo išvestų lizdų: vienas lizdas pasirašo išeinančius valdymo paketus, kitas tikrina įeinančius. Kryptis 0 ir kryptis 1 priskiria šiuos vaidmenis atvirkščia tvarka, todėl pora turi būti papildanti, kad HMAC patikros sutaptų. Kai priskyrimas vienoje pusėje apverčiamas, gavėjas ieško parašo netinkamame lizde ir atmeta paketą. Sesija ten baigiasi, todėl klaida susijusi su paketų autentifikavimu, o ne su tuo, ką sukurtų sertifikatų saugykla.
Determinizmas svarbus diagnostikai, nes laiko ar maršruto problema palieka kitokį pėdsaką: protarpiniai nutrūkimai, vienos krypties nesėkmė arba sesija, kuri miršta tik tam tikrame tinkle. Krypties nesutapimas nepavyksta per pirmąjį rankos paspaudimą kiekvieną kartą, ir jis nepavyksta identiškai kitame kompiuteryje su tais pačiais dviem failais. Skaitykite žurnalą su --verb 4 ir raskite pirmą atmestą paketą, o ne paskutinę eilutę. Jei tas atmetimas įvyksta prieš bet kokį sertifikatų mainą, bendras raktas ir jo kryptis yra du dalykai, kuriuos verta patikrinti.
| 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 |
Kur gyvena skaičius
Vadovas OpenVPN 2.6 dokumentuoja dvi vietas krypčiai: antrąjį tls-auth argumentą, kai raktas yra atskirame faile, ir atskirą key-direction eilutę, kai raktas įterptas į profilį. Abi nustato tą pačią reikšmę, todėl profilis turi naudoti vieną formą arba kitą, niekada abi. Praleidimas taip pat yra pasirinkimas, ir jis abu partnerius pastato į dvikryptę tvarką, kuri veikia, kai nė viena pusė nenurodo krypties. Du partneriai su tuo pačiu skaičiumi nėra toje tvarkoje: kiekvienas tikisi pasirašyti viename lizde ir tikrinti kitame, ir abu tai daro vienodai.
# 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
Įterptoji forma yra direktyva atskiroje eilutėje, o ne atributas raktų bloko atidarymo žymoje, ir argumento pridėjimas prie tos žymos yra klaida, o ne krypties pakeitimas. Vieta taip pat svarbi: direktyva yra už bloko, kuriam ji priklauso, todėl bloko viduje įrašyta reikšmė skaitoma kaip raktų medžiaga. Kopijuokite tvarką, kurią numatė profilio platintojas, o ne išgalvokite porą, nes profilis, veikiantis prieš vieną serverį, galbūt jau atspindėtas kitoje pusėje.
Ko parinktis neliečia
Ji nešifruoja programų srauto. tls-auth deda HMAC aplink valdymo kanalo paketus, o duomenų kanalą saugo sesijos raktai, suderėti rankos paspaudimo metu, todėl pralaidumo ar šifro klausimas neturi nieko bendra su krypties skaičiumi. Nustatymas taip pat neprideda antro šifravimo sluoksnio, ir būtent ši prielaida siunčia žmones ieškoti ilgesnio rakto.
Ji netaikoma tls-crypt, kitam valdymo kanalo mechanizmui su savo parinktimis ir raktų tvarkymu, ir nieko nesako apie jokio partnerio sertifikato tapatybę. Todėl veikiantis krypčių sutapimas įrodo tik tai, kad abu galai sutaria, kaip autentifikuoti valdymo kanalą, o ne kad patikimumo grandinė buvo patvirtinta.
Sulygiuokite porą, tada prisijunkite iš naujo
Palyginkite abi konfigūracijas prieš keisdami bet kurią, nes jau teisingos pusės redagavimas padvigubina darbą. Žemiau esantis grep parodo, kurį mechanizmą pasirenka kiekvienas failas; išsami eiga parodo, ar valdymo kanalas apskritai buvo autentifikuotas. Išsaugokite abu išvestis, kad kitą pakeitimą būtų galima palyginti su žinoma būsena.
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'
Paleiskite abu partnerius iš naujo po kiekvieno pakeitimo, nes šios parinktys nuskaitomos vieną kartą paleidžiant, o vienos pusės perkrovimas palieka porą nenuoseklią visą senos sesijos gyvavimo laiką. Jei diegimas dabar veikia be sukonfigūruotos krypties, nustatymo pridėjimas vienam partneriui atkuria nesėkmę, nuo kurios pradėjote; arba palikite abu, arba sukonfigūruokite abu. Keiskite po vieną galą ir išsaugokite ankstesnį failą, kad regresija būtų dviejų minučių grąžinimas, o ne perstatymas.
Užrašykite mechanizmą, raktų failą ir kryptį kiekvienam galui diegimo pastabose, nes kitaip kitas žmogus perskaitys du panašius failus ir manys, kad skaičiai turi sutapti tarpusavyje. Kryptis yra koordinavimo detalė, o ne saugumo patobulinimas: ji atskiria dvi valdymo kanalo kryptis ir nieko daugiau nedaro.