Tunnelning bir tomoni boshqa tomon hech qachon tekshirmaydigan kalit sloti bilan boshqaruv kanaliga imzo chekadi va bitta ham sertifikat almashinmasdan ulanish autentifikatsiya xatosi bilan o'ladi. tls-auth yo'nalishining nomuvofiqligi shunday ko'rinadi va u deterministik: o'sha ikki fayl har bir urinishda, har qanday tarmoqdan muvaffaqiyatsiz bo'ladi. Jurnalda siz izlayotgan parametrning nomi yo'q, shuning uchun odamlar hech qachon buzilmagan kalitlarni qayta yaratadilar va sertifikatlarni qayta chiqaradilar. Yechim ikki tomonni to'ldiruvchi qilish yoki ikkalasini ham ikki yo'nalishli qoldirish, tekshiruvni zaiflashtirish emas.

Muvaffaqiyatsizlik sertifikatlardan oldin sodir bo'ladi

tls-auth bilan ikkala tomon ham bir xil umumiy kalitni saqlaydi va har biri undan olingan ikki slotdan birini ishlatadi: bir slot chiquvchi boshqaruv paketlariga imzo chekadi, ikkinchisi kiruvchilarni tekshiradi. Yo'nalish 0 va yo'nalish 1 bu rollarni teskari tartibda belgilaydi, shuning uchun HMAC tekshiruvlari mos kelishi uchun juftlik to'ldiruvchi bo'lishi kerak. Bir tomonda belgilash teskari bo'lsa, qabul qiluvchi noto'g'ri slotda imzo izlaydi va paketni rad etadi. Sessiya shu yerda tugaydi, shuning uchun xato paket autentifikatsiyasiga tegishli, sertifikat ombori ishlab chiqaradigan narsaga emas.

Determinizm diagnostika uchun muhim, chunki vaqt yoki yo'l muammosi boshqa iz qoldiradi: uzilishli uzilishlar, bir yo'nalishning muvaffaqiyatsizligi yoki faqat ma'lum tarmoqda o'ladigan sessiya. Yo'nalish nomuvofiqligi har safar birinchi qo'l siqishda muvaffaqiyatsiz bo'ladi va o'sha ikki faylga ega boshqa mashinada ham xuddi shunday muvaffaqiyatsiz bo'ladi. Jurnalni --verb 4 da o'qing va oxirgi qator o'rniga birinchi rad etilgan paketni toping. Agar bu rad etish har qanday sertifikat almashinuvidan oldin sodir bo'lsa, umumiy kalit va uning yo'nalishi tekshirishga arziydigan ikki narsa.

What you seeWhat it rules outNext check
Authentication error before any certificate is sentThe data channel is irrelevant; the control channel never authenticatedCompare tls-auth and its direction on both ends
Certificate or handshake failure after the control channel authenticatesThe shared key and its direction already agreeCheck the CA, the certificate dates and the hostname
Session completes but throughput or cipher warnings appearDirection was never the problemCompare the data-channel cipher settings
Startup stops on an options errorThe number itself is not the issueRe-read the inline versus external directive syntax

Raqam qayerda yashaydi

Qo'llanma OpenVPN 2.6 yo'nalish uchun ikki joyni hujjatlashtiradi: kalit alohida faylda bo'lganda tls-auth ning ikkinchi argumenti va kalit profilga kiritilganda alohida key-direction qatori. Ikkalasi ham bir xil qiymatni belgilaydi, shuning uchun profil bir shaklni yoki ikkinchisini ishlatishi kerak, hech qachon ikkalasini ham emas. O'tkazib yuborish ham tanlov, va u ikkala tomonni hech bir tomon yo'nalishni aytmaganida ishlaydigan ikki yo'nalishli tartibga qo'yadi. Bir xil raqamga ega ikki tomon bu tartibda emas: har biri bir slotda imzo chekishni va ikkinchisida tekshirishni kutadi, va ikkalasi ham buni bir xil qiladi.

# 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

Kiritilgan shakl o'z qatoridagi direktiva, kalit blokining ochilish tegidagi atribut emas, va o'sha tegga argument qo'shish xato, yo'nalishni o'zgartirish emas. Joylashuv ham muhim: direktiva o'zi tegishli blokdan tashqarida turadi, shuning uchun blok ichida yozilgan qiymat kalit materiali sifatida o'qiladi. Profil tarqatuvchisi ko'zda tutgan tartibni nusxalang, juftlik o'ylab topish o'rniga, chunki bir serverga qarshi ishlaydigan profil boshqa tomonda allaqachon aks etgan bo'lishi mumkin.

Parametr nimaga tegmaydi

U ilova trafigini shifrlamaydi. tls-auth boshqaruv kanali paketlari atrofiga HMAC qo'yadi, ma'lumot kanali esa qo'l siqishda kelishilgan sessiya kalitlari bilan himoyalanadi, shuning uchun o'tkazuvchanlik yoki shifr haqidagi savolning yo'nalish raqamiga aloqasi yo'q. Sozlama ikkinchi shifrlash qatlamini ham qo'shmaydi, va odamlarni uzoqroq kalit izlashga yuboradigan aynan shu taxmin.

U tls-crypt ga taalluqli emas, o'z parametrlari va kalit ishlovi bilan boshqa boshqaruv kanali mexanizmi, va hech bir tomonning sertifikat identifikatsiyasi haqida hech narsa demaydi. Shuning uchun ishlaydigan yo'nalish mosligi faqat ikki tomon boshqaruv kanalini qanday autentifikatsiya qilishni kelishganini isbotlaydi, ishonch zanjiri tasdiqlanganini emas.

Juftlikni tekislang, so'ng qayta ulanng

Har qanday birini o'zgartirishdan oldin ikki konfiguratsiyani solishtiring, chunki allaqachon to'g'ri tomonni tahrirlash ishni ikki barobar oshiradi. Quyidagi grep har bir fayl qaysi mexanizmni tanlashini ko'rsatadi; batafsil ishga tushirish boshqaruv kanali umuman autentifikatsiya qilinganini ko'rsatadi. Ikkala chiqishni ham saqlang, keyingi o'zgarish ma'lum holat bilan solishtirilishi uchun.

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'

Har qanday o'zgarishdan keyin ikkala tomonni qayta ishga tushiring, chunki bu parametrlar ishga tushirishda bir marta o'qiladi va bir tomonni qayta yuklash juftlikni eski sessiyaning butun umri davomida nomuvofiq qoldiradi. Agar joylashtirish hozir yo'nalish sozlanmasdan ishlayotgan bo'lsa, parametrni bir tomonga qo'shish siz boshlagan muvaffaqiyatsizlikni qayta hosil qiladi; yo ikkalasini qoldiring, yo ikkalasini sozlang. Bir vaqtda bir uchini o'zgartiring va oldingi faylni saqlang, regressiya qayta qurish emas, ikki daqiqalik qaytarish bo'lsin.

Har bir uchun mexanizm, kalit fayli va yo'nalishni joylashtirish qaydlariga yozing, aks holda keyingi odam ikki o'xshash faylni o'qib, raqamlar bir-biriga mos kelishi kerak deb o'ylaydi. Yo'nalish muvofiqlashtirish tafsiloti, xavfsizlikni yaxshilash emas: u boshqaruv kanalining ikki yo'nalishini ajratadi va boshqa hech narsa qilmaydi.

O'xshash maqolalar