tls-auth key-direction: 0 və 1 fərqli olmalıdır, uyğun deyil
tls-auth ilə iki tərəf əks istiqamətlərə, 0 və 1-ə ehtiyac duyur, ya da hər ikisi parametri buraxmalıdır. Eyni rəqəm uğursuz olur və tls-crypt ondan heç vaxt istifadə etmir.
Tunelin bir tərəfi nəzarət kanalını digər tərəfin heç vaxt yoxlamadığı açar yuvası ilə imzalayır və bir sertifikat belə mübadilə olunmadan bağlantı autentifikasiya xətası ilə ölür. tls-auth istiqamət uyğunsuzluğu belə görünür və deterministikdir: eyni iki fayl hər cəhddə, hər şəbəkədən uğursuz olur. Jurnalda axtardığınız parametrin adı çəkilmir, buna görə insanlar heç vaxt pozulmamış açarları yenidən qurur və sertifikatları yenidən verirlər. Həll iki tərəfi tamamlayıcı etmək və ya hər ikisini ikiistiqamətli buraxmaqdır, doğrulamanı zəiflətmək deyil.
Uğursuzluq sertifikatlardan əvvəl baş verir
İki tərəf tls-auth ilə eyni orta açarı saxlayır və hər biri ondan törədilən iki yuvadan birini istifadə edir: bir yuva çıxan nəzarət paketlərini imzalayır, digəri gələnləri yoxlayır. İstiqamət 0 və istiqamət 1 bu rolları əks qaydada təyin edir, ona görə HMAC yoxlamalarının üst-üstə düşməsi üçün cüt tamamlayıcı olmalıdır. Təyinat bir tərəfdə tərsinə çevrildikdə qəbuledici imzanı yanlış yuvada axtarır və paketi rədd edir. Sessiya orada bitir, buna görə xəta sertifikat anbarının yaradacağı hər hansı bir şeylə deyil, paket autentifikasiyası ilə bağlıdır.
Determinizm diaqnostika üçün vacibdir, çünki vaxt və ya marşrut problemi fərqli əlamət buraxır: fasiləli kəsilmələr, bir istiqamətin uğursuz olması və ya yalnız müəyyən şəbəkədə ölən sessiya. İstiqamət uyğunsuzluğu hər dəfə ilk əl sıxışmada uğursuz olur və eyni iki faylı saxlayan başqa maşında eyni cür uğursuz olur. Jurnalı --verb 4 ilə oxuyun və sonuncu sətir yerinə ilk rədd edilmiş paketi tapın. Əgər bu rədd hər hansı sertifikat mübadiləsindən əvvəl baş verirsə, orta açar və onun istiqaməti yoxlanmağa dəyər iki şeydir.
| 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 |
Rəqəm harada yaşayır
OpenVPN 2.6 təlimatı istiqamət üçün iki yer göstərir: açar ayrı faylda olduqda tls-auth parametrinin ikinci arqumenti və açar profildə daxil edildikdə ayrıca key-direction sətri. Hər ikisi eyni dəyəri təyin edir, ona görə profil bir forma və ya digərini istifadə etməlidir, heç vaxt hər ikisini deyil. Buraxma da bir seçimdir və heç bir tərəf istiqamət göstərmədikdə işləyən ikiistiqamətli düzülüşə qoyur. Eyni rəqəmi daşıyan iki tərəf bu düzülüşdə deyil: hər biri bir yuvada imzalamağı və digərində yoxlamağı gözləyir və hər ikisi bunu eyni cür edir.
# 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
Daxil edilmiş forma ayrı sətirdə direktivdir, açar blokunun açılış teqində atribut deyil və həmin teqə arqument əlavə etmək istiqamət dəyişikliyi deyil, xətadır. Yerləşmə də vacibdir: direktiv aid olduğu blokun xaricində durur, ona görə blokun içində yazılan dəyər açar materialı kimi oxunur. Uydurma cütlük yaratmaq yerinə profilin paylayıcısının nəzərdə tutduğu düzülüşü kopyalayın, çünki bir serverə qarşı işləyən profil artıq digər tərəfdə əks olunmuş ola bilər.
Parametrin toxunmadığı şeylər
Tətbiq trafikini şifrələmir. tls-auth nəzarət kanalı paketlərinin ətrafına HMAC qoyur, məlumat kanalı isə əl sıxışma zamanı razılaşdırılan sessiya açarları ilə qorunur, ona görə ötürmə qabiliyyəti və ya şifrə sualının istiqamət rəqəmi ilə heç bir əlaqəsi yoxdur. Parametr ikinci şifrələmə qatı da əlavə etmir; insanları daha uzun açar axtarmağa göndərən fərziyyə budur.
Bu, tls-crypt üçün keçərli deyil, öz parametrləri və açar idarəetməsi olan fərqli bir nəzarət kanalı mexanizmi və heç bir tərəfin sertifikat kimliyi haqqında heç nə demir. Buna görə işləyən istiqamət uyğunluğu yalnız hər iki tərəfin nəzarət kanalının necə autentifikasiya olunacağı barədə razılaşdığını sübut edir, etimad zəncirinin doğrulandığını deyil.
Cütü uyğunlaşdırın, sonra yenidən qoşulun
Hər hansı birini dəyişməzdən əvvəl iki konfiqurasiyanı müqayisə edin, çünki artıq düzgün olan tərəfi redaktə etmək işi ikiqat artırır. Aşağıdakı grep hər faylın hansı mexanizmi seçdiyini göstərir; ətraflı işə salma nəzarət kanalının ümumiyyətlə autentifikasiya olunub-olunmadığını göstərir. Hər iki çıxışı saxlayın ki, növbəti dəyişiklik məlum vəziyyətlə müqayisə olunsun.
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'
Hər hansı dəyişiklikdən sonra hər iki tərəfi yenidən başladın, çünki bu parametrlər başlanğıcda bir dəfə oxunur və bir tərəfi yenidən yükləmək cütü köhnə sessiyanın ömrü boyu uyğunsuz qoyur. Yerləşdirmə hazırda istiqamət konfiqurasiya edilmədən işləyirsə, parametri bir tərəfə əlavə etmək başladığınız uğursuzluğu təkrar istehsal edir; ya hər ikisini buraxın, ya da hər ikisini konfiqurasiya edin. Bir dəfə bir tərəfi dəyişin və əvvəlki faylı saxlayın ki, geriləmə yenidən qurma deyil, iki dəqiqəlik geri qaytarma olsun.
Hər tərəf üçün mexanizmi, açar faylını və istiqaməti yerləşdirmə qeydlərinə yazın, əks halda növbəti şəxs iki oxşar faylı oxuyub rəqəmlərin bir-birinə uyğun olması lazım olduğunu güman edəcək. İstiqamət koordinasiya detalıdır, təhlükəsizlik təkmilləşdirməsi deyil: nəzarət kanalının iki istiqamətini ayırır və başqa heç nə etmir.