digest مربوط به auth از کدام بسته‌های OpenVPN محافظت می‌کند؟
گزینه auth کمتر از آنچه یک پروفایل نشان می‌دهد را پوشش می‌دهد. پیش از تعیین سیاست digest، کانال، حالت AEAD و حفاظت کانال کنترل را بررسی کنید.
بیشتر بحث‌ها درباره digestهای OpenVPN از بسته اشتباه شروع می‌شود. خواندن auth SHA256 به‌عنوان «فقط همتایانی را بپذیر که SHA256 ارائه می‌دهند» نخستین چیزی است که باید از ذهن کنار گذاشت. این گزینه یک digest را برای بسته‌های مشخص نام می‌برد و اینکه آن بسته‌ها کدام‌اند به کانال و به AEAD بودن آن کانال بستگی دارد. چهار پرسش زیر را به ترتیب بررسی کنید؛ هر یک روشن می‌کند این تنظیم در استقرار شما چه معنایی می‌تواند داشته باشد.
کانالی را که این تنظیم باید محافظت کند نام ببرید
OpenVPN یک کانال کنترل دارد که ترافیک مصافحه TLS را حمل می‌کند و یک کانال داده که بار تونل را حمل می‌کند. digest مربوط به auth در هر دو نقش دارد، اما نه نقش یکسان، و پروفایل به‌ندرت این تفاوت را آشکار می‌کند. پیش از دست‌زدن به فایل پیکربندی بنویسید کدام یک از این دو را می‌خواهید محدود کنید.
جدول زیر نسخه کوتاه اینکه همان گزینه در هر بافت چگونه می‌نشیند است.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
پیش از تکیه بر کانال داده بررسی کنید که آیا AEAD است
اگر رمزنگار داده توافق‌شده AES-GCM یا CHACHA20-POLY1305 باشد، کانال داده خود را احراز هویت می‌کند و digest جداگانه کاری را که ممکن است تصور کنید انجام نمی‌دهد. هر دو ساختار AEAD هستند، بنابراین یکپارچگی با همان عملیاتی تولید می‌شود که بار را رمز می‌کند. این کاهش سطح نیست، اما به این معناست که سیاستی با توجیه «هر بسته داده HMAC-SHA256 است» در آن تونل واقعاً نادرست است. پیش از بازنویسی سیاست، مقدار توافق‌شده را در گزارش سرور یا خروجی وضعیت کارخواه تأیید کنید.
رمزار را که واقعاً توافق شده بررسی کنید نه فهرست پروفایل را، زیرا مذاکره ممکن است روی عضو دیگری از مجموعه بنشیند. data-ciphers AES-256-GCM:AES-128-GCM یک فهرست مذاکره است و هر دو ورودی AEAD هستند، بنابراین هیچ‌کدام digest مربوط به auth را برای حفاظت از بار مصرف نمی‌کند.
حفاظت کانال کنترل را تصمیمی مستقل بدانید
tls-auth یک HMAC به بسته‌های کانال کنترل می‌افزاید و digest خود را از تنظیم auth می‌گیرد، از این رو یک تونل AEAD می‌تواند هنوز digest معناداری پیکربندی‌شده داشته باشد. tls-crypt آرایش متفاوتی با حفاظت ثابت خودش است، پس فرض نکنید که هر ویژگی tls-auth را به ارث می‌برد. مستندات مکانیزمی را که برگزیده‌اید بخوانید نه اینکه فرض‌ها را میان آن‌ها منتقل کنید.
دو همتا باید بر آرایش و بر جهت کلید نیز توافق کنند. digestی که می‌خواند اما فایل کلیدی که در جهت اشتباه به کار رفته، مصافحه‌ای می‌سازد که به دلایلی شکست می‌خورد که تنظیم digest نمی‌تواند توضیح دهد.
auth را از مذاکره رمزنگار و گواهی‌ها جدا نگه دارید
سه تنظیم پیوسته با هم اشتباه می‌شوند: digest مربوط به auth، فهرست رمزنگارهای داده و الگوریتم امضای گواهی. تغییر اولی گواهی را دوباره صادر نمی‌کند، digest امضای آن را انتخاب نمی‌کند و روش کاربر-گذرواژه نمی‌سازد. تعریف‌های گزینه‌های پروتکل در منابع OpenVPN 2.6 هر یک را در بخش خودش توصیف می‌کنند، که یادآوری سودمندی است بر اینکه آن‌ها کلیدهای تنظیم مستقل‌اند.
وقتی همتایی پس از تغییر digest از اتصال خودداری می‌کند، علت معمولاً ناسازگاری در یکی از دو تنظیم دیگر است. پیش از تغییر هر یک، هر دو سو را بخوانید.
سیاست را بنویسید و آن را با پیکربندی‌های در حال اجرا مقایسه کنید
یک بیانیه در سطح ناوگان باید حالت‌های مجاز کانال داده و حفاظت انتخاب‌شده کانال کنترل را صریحاً در همان جمله نام ببرد. آن جمله آزمون‌پذیر است؛ «ما از SHA256 استفاده می‌کنیم» نیست. سپس آن را با پروفایل‌های مؤثر سرور و کارخواه مقایسه کنید نه با الگویی در یک مخزن.
با ثبت اینکه هر تونل واقعاً چه توافق کرد و کدام مکانیزم بسته‌هایش را احراز هویت کرد پایان دهید. یک خط auth قابل مشاهده در پروفایل تنها گواه قصد پیکربندی است و قصد ارزان‌ترین بخش بررسی است.