tls-auth key-direction: 0 un 1 jābūt atšķirīgiem, nevis vienādiem
Ar tls-auth abiem galiem vajadzīgi pretēji virzieni, 0 un 1, vai abiem jāizlaiž iestatījums. Viens un tas pats skaitlis neizdodas, un tls-crypt to nekad neizmanto.
Viena tuneļa puse paraksta vadības kanālu ar atslēgas slotu, kuru otra puse nekad nepārbauda, un savienojums mirst ar autentifikācijas kļūdu, pirms apmainīts pat viens sertifikāts. Tā izskatās tls-auth virziena neatbilstība, un tā ir deterministiska: tie paši divi faili neizdodas katrā mēģinājumā, no jebkura tīkla. Žurnālā nekas nenosauc opciju, kuru meklējat, tāpēc cilvēki no jauna veido atslēgas un izsniedz sertifikātus, kas nekad nav bijuši bojāti. Risinājums ir padarīt abus galus papildinošus vai atstāt abus divvirzienu, nevis vājināt pārbaudi.
Kļūme notiek pirms sertifikātiem
Ar tls-auth abām pusēm ir viens un tas pats koplietotais atslēga, un katra izmanto vienu no diviem no tās atvasinātajiem slotiem: viens slots paraksta izejošos vadības paketes, otrs pārbauda ienākošās. Virziens 0 un virziens 1 piešķir šīs lomas pretējā secībā, tāpēc pārim jābūt papildinošam, lai HMAC pārbaudes sakristu. Kad piešķīrums vienā pusē tiek apgriezts, uztvērējs meklē parakstu nepareizajā slotā un noraida paketi. Sesija tur beidzas, tāpēc kļūda attiecas uz pakešu autentifikāciju, nevis uz kaut ko, ko radītu sertifikātu krātuve.
Determinisms ir svarīgs diagnostikai, jo laika vai maršruta problēma atstāj citu pēdu: periodiski pārtraukumi, viena virziena kļūme vai sesija, kas mirst tikai noteiktā tīklā. Virziena neatbilstība neizdodas pirmajā rokasspiedienā katru reizi, un tā neizdodas identiski citā mašīnā ar tiem pašiem diviem failiem. Lasiet žurnālu ar --verb 4 un atrodiet pirmo noraidīto paketi, nevis pēdējo rindu. Ja šis noraidījums notiek pirms jebkādas sertifikātu apmaiņas, koplietotā atslēga un tās virziens ir divas lietas, ko ir vērts pārbaudīt.
| 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 dzīvo skaitlis
Rokasgrāmata OpenVPN 2.6 dokumentē divas vietas virzienam: otro tls-auth argumentu, kad atslēga ir atsevišķā failā, un atsevišķu key-direction rindu, kad atslēga ir iekļauta profilā. Abas nosaka vienu un to pašu vērtību, tāpēc profilam jāizmanto viena forma vai otra, nekad abas. Izlaišana arī ir izvēle, un tā abas puses ievieto divvirzienu izkārtojumā, kas darbojas, kad neviena puse nenosauc virzienu. Divas puses ar vienu un to pašu skaitli šajā izkārtojumā nav: katra sagaida parakstīšanu vienā slotā un pārbaudi otrā, un abas to dara vienādi.
# 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
Iekļautā forma ir direktīva atsevišķā rindā, nevis atribūts atslēgas bloka atverošajā tagā, un argumenta pievienošana šim tagam ir kļūda, nevis virziena maiņa. Arī izvietojums ir svarīgs: direktīva atrodas ārpus bloka, kuram tā pieder, tāpēc bloka iekšpusē rakstītā vērtība tiek lasīta kā atslēgas materiāls. Kopējiet izkārtojumu, ko bija domājis profila izplatītājs, nevis izgudrojiet pāri, jo profils, kas darbojas pret vienu serveri, varbūt jau ir atspoguļots otrā pusē.
Ko opcija atstāj neskartu
Tā nešifrē lietojumprogrammu datplūsmu. tls-auth liek HMAC ap vadības kanāla paketēm, bet datu kanālu aizsargā sesijas atslēgas, kas vienotas rokasspiediena laikā, tāpēc jautājumam par caurlaidību vai šifru nav nekāda sakara ar virziena skaitli. Iestatījums arī nepievieno otru šifrēšanas slāni, un tieši šis pieņēmums sūta cilvēkus meklēt garāku atslēgu.
Tā neattiecas uz tls-crypt, citu vadības kanāla mehānismu ar savām opcijām un atslēgu apstrādi, un neko nesaka par jebkuras puses sertifikāta identitāti. Tāpēc strādājoša virzienu atbilstība pierāda tikai to, ka abi gali vienojas, kā autentificēt vadības kanālu, nevis to, ka uzticības ķēde ir validēta.
Izlīdziniet pāri, pēc tam pievienojieties no jauna
Salīdziniet abas konfigurācijas pirms jebkuras maiņas, jo jau pareizās puses rediģēšana dubulto darbu. Zemāk esošais grep parāda, kuru mehānismu izvēlas katrs fails; detalizētā izpilde parāda, vai vadības kanāls vispār tika autentificēts. Saglabājiet abus izvades datus, lai nākamo izmaiņu varētu salīdzināt ar zināmu stāvokli.
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'
Pēc katras izmaiņas restartējiet abas puses, jo šīs opcijas tiek nolasītas vienreiz palaišanas laikā, un vienas puses pārlāde atstāj pāri nekonsekventu visu vecās sesijas dzīves laiku. Ja izvietojums pašlaik darbojas bez konfigurēta virziena, iestatījuma pievienošana vienai pusei atkārto kļūmi, ar kuru sākāt; vai nu atstājiet abas, vai konfigurējiet abas. Mainiet vienu galu vienlaikus un saglabājiet iepriekšējo failu, lai regresija būtu divu minūšu atgriešana, nevis pārbūve.
Pierakstiet mehānismu, atslēgas failu un virzienu katram galam izvietošanas piezīmēs, jo citādi nākamais cilvēks izlasīs divus līdzīgus failus un pieņems, ka skaitļiem jāsakrīt savā starpā. Virziens ir koordinācijas detaļa, nevis drošības uzlabojums: tas atdala divus vadības kanāla virzienus un neko citu nedara.