tls-auth key-direction: 0 og 1 skal være forskellige, ikke ens
Med tls-auth skal de to ender have modsatte retninger, 0 og 1, eller begge skal udelade indstillingen. Det samme tal fejler, og tls-crypt bruger det aldrig.
Den ene side af tunnelen signerer kontrolkanalen med et nøgleslot, som den anden side aldrig kontrollerer, og forbindelsen dør med en godkendelsesfejl, før et eneste certifikat er udvekslet. Sådan ser en retningskonflikt med tls-auth ud, og den er deterministisk: de samme to filer fejler ved hvert forsøg, fra ethvert netværk. Intet i loggen navngiver den indstilling, du leder efter, og derfor genopbygger folk nøgler og genudsteder certifikater, som aldrig var ødelagte. Løsningen er at gøre de to ender komplementære eller lade dem begge være tovejs, i stedet for at svække verifikationen.
Fejlen sker før certifikaterne
Med tls-auth har begge parter den samme delte nøgle, og hver bruger et af to slots, der udledes af den: det ene slot signerer udgående kontrolpakker, det andet verificerer indgående. Retning 0 og retning 1 tildeler disse roller i omvendt rækkefølge, så parret skal være komplementært, for at HMAC-kontrollerne passer sammen. Når tildelingen vendes på den ene side, leder modtageren efter en signatur i det forkerte slot og afviser pakken. Sessionen slutter der, og derfor handler fejlen om pakkegodkendelse og ikke om noget, certifikatlageret ville producere.
Determinismen er vigtig for diagnostik, fordi et tids- eller ruteproblem efterlader et andet spor: uregelmæssige afbrydelser, en retning der fejler, eller en session der kun dør på et bestemt netværk. En retningskonflikt fejler ved det første håndtryk hver gang, og den fejler identisk på en anden maskine med de samme to filer. Læs loggen ved --verb 4 og find den første afviste pakke i stedet for den sidste linje. Hvis den afvisning sker før nogen certifikatudveksling, er den delte nøgle og dens retning de to ting, der er værd at kontrollere.
| 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 |
Hvor tallet bor
Manualen til OpenVPN 2.6 dokumenterer to steder for retningen: det andet argument til tls-auth, når nøglen ligger i sin egen fil, og en selvstændig key-direction-linje, når nøglen er indlejret i profilen. Begge sætter den samme værdi, så en profil bør bruge den ene form eller den anden, aldrig begge. Udeladelse er også et valg, og det sætter begge parter i et tovejsarrangement, der virker, når ingen af siderne angiver en retning. To parter med det samme tal er ikke i det arrangement: hver forventer at signere i det ene slot og verificere i det andet, og begge gør det på samme måde.
# 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
Den indlejrede form er et direktiv på sin egen linje, ikke et attribut på åbningstagget i nøgleblokken, og at tilføje et argument til det tag er en fejl, ikke en retningsændring. Placeringen betyder også noget: direktivet står uden for den blok, det hører til, så en værdi skrevet inde i blokken læses som nøglemateriale. Kopiér det arrangement, profilen distributør havde tænkt, i stedet for at opfinde en parring, for en profil, der virker mod én server, er måske allerede spejlet på den anden side.
Hvad indstillingen lader være
Den krypterer ikke applikationstrafik. tls-auth lægger en HMAC omkring kontrolkanalens pakker, mens datakanalen beskyttes af sessionsnøgler, der forhandles under håndtrykket, så et spørgsmål om gennemstrømning eller cipher har intet at gøre med retningstallet. Indstillingen tilføjer heller ikke et andet krypteringslag, og det er den antagelse, der sender folk på jagt efter en længere nøgle.
Den gælder ikke for tls-crypt, en anden kontrolkanalmekanisme med sine egne indstillinger og nøglehåndtering, og den siger intet om nogen sides certifikatidentitet. En fungerende retningsmatchning beviser derfor kun, at de to ender er enige om, hvordan kontrolkanalen godkendes, ikke at tillidskæden blev valideret.
Ret parret ind, og genopret forbindelsen
Sammenlign de to konfigurationer, før du ændrer nogen af dem, for at redigere den side, der allerede var korrekt, fordobler arbejdet. Grep nedenfor viser, hvilken mekanisme hver fil vælger; den detaljerede kørsel viser, om kontrolkanalen overhovedet blev godkendt. Gem begge output, så den næste ændring kan sammenlignes med en kendt tilstand.
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'
Genstart begge parter efter enhver ændring, fordi disse indstillinger læses én gang ved opstart, og genindlæsning af den ene side efterlader parret inkonsistent i hele den gamle sessions levetid. Hvis udrulningen i øjeblikket virker uden en konfigureret retning, genskaber tilføjelsen af indstillingen på den ene part den fejl, du startede med; lad dem enten begge være eller konfigurer begge. Ændr én ende ad gangen, og gem den forrige fil, så en regression er en tilbagerulning på to minutter i stedet for en genopbygning.
Notér mekanismen, nøglefilen og retningen for hver ende i udrulningsnoterne, for ellers læser den næste person to ens filer og antager, at tallene skal passe sammen. Retningen er en koordinationsdetalj, ikke en sikkerhedsopgradering: den adskiller kontrolkanalens to retninger og gør intet andet.