OpenVPN بدون گواهی مشتری: سیاست سرور، نه پروفایل
حذف خطوط گواهی و کلید هیچ چیز را تغییر نمی‌دهد اگر سرور هنوز آن‌ها را می‌خواهد. شرط را به سمت سرور منتقل کنید و بررسی‌های خود مشتری روی سرور را نگه دارید.
خطوط گواهی و کلید را حذف می‌کنید، پروفایل را تحویل می‌دهید و اتصال همچنان با خطای گواهی شکست می‌خورد. پروفایل هرگز چیزی نبود که آن شرط را تحمیل کند. سرور تصمیم می‌گیرد که آیا گواهی مشتری اجباری است یا نه، و هیچ ویرایشی در سمت مشتری آن را مذاکره نمی‌کند. پس اصلاح، تغییری در سیاست سرور است که آگاهانه انجام می‌شود و هر چیزی که به آن وابسته است در همان مرحله به‌روز می‌شود.
پروفایل همان سیاست نیست
Community OpenVPN 2.6 با گواهی‌های اجباری مشتری عرضه می‌شود، زیرا verify-client-cert به‌طور پیش‌فرض require است. تنظیم آن روی none همان چیزی است که تقاضای گواهی را متوقف می‌کند و احراز هویت مشتری را به هر ترتیبی از نام کاربری و گذرواژه که سرور از قبل اجرا می‌کند می‌سپارد. راهنماهای قدیمی به client-cert-not-required متوسل می‌شوند، املای کهنه همان ایده، پس دستوری را به کار ببرید که نسخه نصب‌شده شما مستند می‌کند. در هر حال تغییر روی سرور رخ می‌دهد و هیچ پروفایل مشتری نمی‌تواند آن را انجام دهد.
قطعه زیر کل تغییر سمت سرور است و به‌تنهایی پیکربندی احراز هویت کارآمدی نیست. verify-client-cert none شرط گواهی را برمی‌دارد، در حالی که username-as-common-name نام حساب را به هویتی تبدیل می‌کند که فراخوانی‌های بعدی و فایل‌های هر مشتری می‌بینند. هیچ‌یک از دو خط گذرواژه را بررسی نمی‌کند، پس یک راستی‌آزما هنوز باید وجود داشته باشد.
verify-client-cert none
username-as-common-nameآن راستی‌آزما یک افزونه یا اسکریپتی است که auth-user-pass-verify آن را اجرا می‌کند و باید پیش از آنکه هر یک از خطوط بالا معنایی داشته باشد در جای خود باشد. برعکس کردن ترتیب پنجره‌ای به شما می‌دهد که سرور در آن نه گواهی می‌خواهد و نه حسابی را بررسی می‌کند.
چه چیزی هنوز سرور را تأیید می‌کند
کنار گذاشتن گواهی مشتری به معنای کنار گذاشتن TLS نیست. سرور گواهی و کلید خود را نگه می‌دارد و مشتری اعتماد CA و بررسی‌های نام میزبان را نگه می‌دارد که مانع گفتگو با یک کلاهبردار می‌شود. حذف remote-cert-tls server یا بسته CA چون مشتری دیگر گواهی ندارد خوانش نادرست رایج و جدی است، و مرجع 2.6 صریح است که دو جهت مستقل‌اند. یکی سرور را به مشتری اثبات می‌کند؛ دیگری مشتری را به سرور.
پروفایل می‌تواند بلوک tls-auth یا tls-crypt را هم داشته باشد. این یک کلید مشترک کانال کنترل با چرخه توزیع و چرخش خودش است، پس فایلی بدون خطوط گواهی یا کلید به‌طور خودکار برای انتشار امن نیست. تا وقتی آن را نخوانده‌اید مانند یک راز با آن رفتار کنید.
فایل گواهی که از یک پروفایل کارآمد کپی شده به‌تنهایی چیزی را اثبات نمی‌کند؛ مالکیت یعنی داشتن کلید خصوصی متناظر با آن، که استقرار احرازشده با گواهی آن را بررسی می‌کند. فایلی که گواهی دارد فایلی نیست که بتوان با آن احراز هویت کرد.
راستی‌آزما باید چه کار کند
با برداشتن شرط گواهی، همه چیز بر راستی‌آزما تکیه می‌کند: یک افزونه یا اسکریپتی که auth-user-pass-verify آن را اجرا می‌کند. باید اعتبارنامه‌های نامعتبر را رد کند، حساب‌های غیرفعال یا فاقد شرایط را رد کند و وقتی به بک‌اند خود نمی‌رسد بسته شکست بخورد. username-as-common-name اغلب در کنار آن فعال می‌شود و هویتی را تغییر می‌دهد که فراخوانی‌های بعدی و فایل‌های پیکربندی هر مشتری می‌بینند. گذرواژه را بررسی نمی‌کند و حساب فاقد شرایط را واجد شرایط نمی‌کند. این‌ها کارهای جداگانه‌اند و اشتباه گرفتن‌شان همان راهی است که یک مهاجرت آزمون مسیر خوش را می‌گذراند و در نخستین رخداد واقعی شکست می‌خورد.
موارد منفی را به همان دقت مورد مثبت بیازمایید. پروفایلی که درخواست گذرواژه نشان می‌دهد فقط اثبات می‌کند مشتری می‌تواند درخواستی رسم کند، در حالی که سروری که گذرواژه اشتباه را می‌پذیرد چیزی بسیار بدتر را اثبات می‌کند. یک حساب غیرفعال و یک اعتبارنامه منقضی هم به مجموعه آزمون بیفزایید، نه فقط یک گذرواژه بد.
سیاست، پروفایل و نگاشت را با هم تغییر دهید
سه چیز را هماهنگ کنید: دستور سرور، پروفایل مشتری و نگاشت هویت هر مشتری. اگر جداگانه تغییرشان دهید، مشتریان پیش از تأیید شکست می‌خورند یا با نامی متصل می‌شوند که مدیر انتظارش را نداشت، و این بدتر است چون شبیه موفقیت به نظر می‌رسد. اتصالی که با هویت اشتباه موفق می‌شود سخت‌تر از اتصالی که شکست می‌خورد به چشم می‌آید.
برای این مسیر دو حساب آزمایشی نگه دارید، یکی معتبر و یکی بدِ شناخته‌شده، و پس از هر تغییر در راستی‌آزما هر دو را به کار ببرید. حساب معتبر مسیر خوش و نگاشت هویت را اثبات می‌کند؛ حساب بد اثبات می‌کند که رد کردن هنوز کار می‌کند. هیچ‌یک از دو آزمون چیزی درباره قواعد واجد شرایط بودن نمی‌گوید، پس اگر استقرار چنین قواعدی دارد حسابی بیفزایید که باید به دلایل سیاستی رد شود. پس از هر تغییر هر سه را اجرا کنید، زیرا راستی‌آزمایی که شروع به پذیرش همه چیز کند دقیقاً شبیه یک ورود کارآمد است.
ثبت کنید سرور در واقع کدام روش‌های احراز هویت را می‌پذیرد، نه آن‌هایی که پروفایل پیشنهاد می‌کند. آن سابقه به پرسشی پاسخ می‌دهد که مردم پیوسته می‌پرسند، یعنی چه کسی می‌تواند به این سرویس متصل شود. همچنین از مدیر بعدی عمر بیشتری می‌کند، که وگرنه آن را از یک ضبط بسته دوباره کشف خواهد کرد.