tls-auth key-direction: 0 و 1 باید متفاوت باشند، نه یکسان
با tls-auth دو طرف به جهت‌های مخالف نیاز دارند، 0 و 1، یا هر دو باید این تنظیم را حذف کنند. همان عدد شکست می‌خورد، و tls-crypt هرگز از آن استفاده نمی‌کند.
یک طرف تونل کانال کنترل را با شکاف کلیدی امضا می‌کند که طرف دیگر هرگز آن را بررسی نمی‌کند، و اتصال پیش از تبادل حتی یک گواهی با خطای احراز هویت می‌میرد. ناسازگاری جهت در tls-auth این‌گونه است و قطعی است: همان دو فایل در هر تلاش، از هر شبکه‌ای شکست می‌خورند. هیچ چیز در گزارش نام گزینه‌ای را که دنبالش هستید نمی‌آورد، به همین دلیل مردم کلیدها را از نو می‌سازند و گواهی‌هایی را دوباره صادر می‌کنند که هرگز خراب نبوده‌اند. راه‌حل این است که دو طرف را مکمل کنید یا هر دو را دوطرفه بگذارید، نه اینکه تأیید را ضعیف کنید.
شکست پیش از گواهی‌ها رخ می‌دهد
با tls-auth هر دو همتا همان کلید مشترک را دارند و هر کدام از دو شکاف مشتق‌شده از آن یکی را به کار می‌برد: یک شکاف بسته‌های کنترل خروجی را امضا می‌کند، دیگری بسته‌های ورودی را بررسی می‌کند. جهت 0 و جهت 1 این نقش‌ها را به ترتیب معکوس تعیین می‌کنند، پس جفت باید مکمل باشد تا بررسی‌های HMAC هم‌تراز شوند. وقتی تخصیص در یک طرف برعکس شود، گیرنده امضا را در شکاف اشتباه می‌جوید و بسته را رد می‌کند. نشست همان‌جا تمام می‌شود، به همین دلیل خطا به احراز هویت بسته مربوط است نه به چیزی که انبار گواهی تولید می‌کرد.
قطعیت برای عیب‌یابی مهم است، چون مشکل زمان یا مسیر اثر متفاوتی بر جای می‌گذارد: قطع‌وصل‌های متناوب، شکست یک جهت، یا نشستی که فقط در شبکه‌ای خاص می‌میرد. ناسازگاری جهت هر بار در نخستین دست‌دادن شکست می‌خورد و روی ماشین دیگری با همان دو فایل دقیقاً همان‌گونه شکست می‌خورد. گزارش را در --verb 4 بخوانید و نخستین بسته ردشده را پیدا کنید نه آخرین خط را. اگر آن رد پیش از هر تبادل گواهی رخ دهد، کلید مشترک و جهت آن دو چیزی هستند که ارزش بررسی دارند.
| 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 |
عدد کجا زندگی می‌کند
راهنمای OpenVPN 2.6 دو جا را برای جهت مستند می‌کند: آرگومان دوم tls-auth وقتی کلید در فایل جداگانه است، و خط مستقل key-direction وقتی کلید در پروفایل جاسازی شده است. هر دو یک مقدار را تنظیم می‌کنند، پس پروفایل باید یک شکل را به کار ببرد یا شکل دیگر، هرگز هر دو را. حذف هم یک انتخاب است و هر دو همتا را در چیدمان دوطرفه‌ای قرار می‌دهد که وقتی هیچ طرفی جهتی نام نمی‌برد کار می‌کند. دو همتای دارای همان عدد در آن چیدمان نیستند: هر کدام انتظار دارد در یک شکاف امضا کند و در دیگری بررسی کند، و هر دو این کار را یکسان انجام می‌دهند.
# 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
شکل جاسازی‌شده دستوری در خط خودش است، نه ویژگی روی برچسب گشایش بلوک کلید، و افزودن آرگومان به آن برچسب خطاست نه تغییر جهت. جای‌گذاری هم مهم است: دستور بیرون از بلوکی است که به آن تعلق دارد، پس مقداری که داخل بلوک نوشته شود به‌عنوان ماده کلید خوانده می‌شود. چیدمانی را که توزیع‌کننده پروفایل در نظر داشته کپی کنید، نه اینکه جفتی بسازید، چون پروفایلی که در برابر یک سرور کار می‌کند شاید از قبل در طرف دیگر آینه شده باشد.
آنچه گزینه دست‌نخورده می‌گذارد
این گزینه ترافیک برنامه‌ها را رمزنگاری نمی‌کند. tls-auth یک HMAC دور بسته‌های کانال کنترل می‌گذارد، در حالی که کانال داده با کلیدهای نشستی محافظت می‌شود که در دست‌دادن مذاکره می‌شوند، پس پرسش درباره توان عبور یا رمز هیچ ربطی به عدد جهت ندارد. تنظیم لایه دوم رمزنگاری هم اضافه نمی‌کند، و همین فرض است که مردم را به جست‌وجوی کلید بلندتر می‌فرستد.
به tls-crypt اعمال نمی‌شود، سازوکار دیگری برای کانال کنترل با گزینه‌ها و مدیریت کلید خودش، و هیچ چیزی درباره هویت گواهی هیچ همتایی نمی‌گوید. بنابراین تطابق جهتِ کارکننده فقط ثابت می‌کند دو طرف بر سر نحوه احراز هویت کانال کنترل توافق دارند، نه اینکه زنجیره اعتماد اعتبارسنجی شده است.
جفت را هم‌تراز کنید، سپس دوباره وصل شوید
پیش از تغییر هر یک، دو پیکربندی را مقایسه کنید، چون ویرایش طرفی که از قبل درست بود کار را دو برابر می‌کند. grep زیر نشان می‌دهد هر فایل کدام سازوکار را برمی‌گزیند؛ اجرای پرجزئیات نشان می‌دهد آیا کانال کنترل اصلاً احراز هویت شده است. هر دو خروجی را نگه دارید تا تغییر بعدی با وضعیت شناخته‌شده مقایسه شود.
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'
پس از هر تغییر هر دو همتا را دوباره راه‌اندازی کنید، چون این گزینه‌ها هنگام آغاز یک بار خوانده می‌شوند و بارگذاری دوباره یک طرف جفت را تا پایان عمر نشست قدیمی ناسازگار می‌گذارد. اگر استقرار اکنون بدون جهت پیکربندی‌شده کار می‌کند، افزودن تنظیم به یک همتا همان شکستی را بازتولید می‌کند که با آن شروع کردید؛ یا هر دو را رها کنید یا هر دو را پیکربندی کنید. هر بار یک سر را تغییر دهید و فایل قبلی را نگه دارید، تا پس‌رفت بازگردانی دو دقیقه‌ای باشد نه بازسازی.
سازوکار، فایل کلید و جهت هر سر را در یادداشت‌های استقرار ثبت کنید، چون در غیر این صورت نفر بعدی دو فایل مشابه می‌خواند و فرض می‌کند اعداد باید با هم همخوان باشند. جهت جزئیات هماهنگی است، نه ارتقای امنیتی: دو جهت کانال کنترل را از هم جدا می‌کند و کار دیگری نمی‌کند.