کدام نمونهٔ OpenVPN در واقع از پروفایل PiVPN شما استفاده می‌کند؟

PiVPN یک پیکربندی سرور و یک پروفایل کلاینت می‌نویسد و سپس خارج می‌شود؛ هرگز همان فرایندی نمی‌شود که ترافیک شما را حمل می‌کند. بنابراین دست‌دادن ناموفق، کلاینتی که نشانی پایانی اشتباه را می‌گیرد، یا سرویسی که پس از راه‌اندازی مجدد بد برمی‌گردد را نمی‌توان از منوهای نصب‌کننده توضیح داد. این نشانه‌ها به هر شبح OpenVPN که اکنون در حال اجراست، به پیکربندی‌ای که آن شبح واقعاً بارگذاری کرده، و به گزارشی که به آن نشان داده شده تعلق دارند. چهار فرمان فقط‌خواندنی معمولاً این را روشن می‌کند، و هیچ‌کدام گواهی‌ها یا کلیدهای شما را تغییر نمی‌دهد.

کمک‌کننده و شبح دو شیء متفاوت‌اند

سردرگمی آسان است: یک پوشه هم فایلی را نگه می‌دارد که کمک‌کننده ساخته، هم فایلی را که شبح می‌خواند، و گاهی نسخه‌ای کهنه از هر دو. کمک‌کننده یک اسکریپت آماده‌سازی است. بسته‌ها را نصب می‌کند، فایل‌های واحد را می‌نویسد و پروفایل کلاینت را چاپ می‌کند، و سپس کارش تمام می‌شود. آنچه می‌ماند یک ورودی در مدیر سرویس و یک خط فرمان است.

روی میزبان systemd از واحد فعال شروع کنید، نه از فهرست پوشه. نام به بسته‌بندی بستگی دارد: تصاویر Debian و Raspberry Pi OS معمولاً یک نمونهٔ الگو مانند openvpn-server@server ارائه می‌دهند، در حالی که نصب‌های قدیمی‌تر از openvpn@server استفاده می‌کنند. از مدیر بپرسید کدام در حال اجراست، نه اینکه از نام فایل حدس بزنید.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

در آن خروجی ExecStart= را بخوانید. فایل اجرایی و گزینه‌هایی را که مدیر واقعاً اجرا می‌کند نام می‌برد، از جمله هر --config مسیری؛ فایل پیکربندی‌ای که کنارش هست و هیچ فرمانی به آن ارجاع نمی‌دهد بخشی از تونل در حال اجرا نیست.

زنجیرهٔ پیکربندی‌ای را که شبح حل کرده دنبال کنید

OpenVPN برای یافتن تنظیمات پوشه‌ای را پویش نمی‌کند. فایلی را می‌خواند که با --config به آن داده شده، هر config دستور درونش را دنبال می‌کند و سپس گزینه‌های خط فرمان را اعمال می‌کند. راهنمای 2.6 این ترتیب را توضیح می‌دهد، و وقتی دو فایل دربارهٔ درگاه، دستگاه یا رمزنگاری اختلاف دارند اهمیت دارد.

ابتدا فراخوانی مؤثر را بیرون بریزید، سپس دستورهایی را ببینید که هویت و دسترسی‌پذیری را تعیین می‌کنند. هر دو فرمان فقط‌خواندنی و روی سرور زنده ایمن‌اند، هرچند دومی مسیرهایی را چاپ می‌کند که شاید در یک تیکت عمومی نخواهید.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

یک فایل .ovpn در پوشهٔ خانه یک اثر کلاینت است. شبح سرور هرگز آن را نمی‌خواند، پس ویرایش آن فایل برای رفع دست‌دادن ناموفق سمت سرور هیچ کاری نمی‌کند.

درج‌ها تلهٔ دیگرند. یک خط config فایل دومی را وارد می‌کند که گزینه‌هایش در همان نقطه پردازش می‌شود، پس یک دستور تک‌مقداری بعدی می‌تواند چیزی را که فایل اصلی ظاهراً می‌گوید کنار بزند. اگر فایل دیدنی درست به نظر می‌رسد و شبح همچنان رفتاری دیگر دارد، پیش از تغییر هر چیز فایل درج‌شده را بخوانید.

گزارش را با فرایند جفت کنید، نه با خطایی که به یاد دارید

دو مقصد گزارش رایج‌اند، و تنها یکی از آن‌ها ژورنال است. با log-append شبح در آن فایل می‌نویسد و ژورنال جز خطوط راه‌اندازی چیز کمی نگه می‌دارد. بدون آن، journalctl منبع رویدادهاست.

journalctl -u openvpn-server@server -n 80 --no-pager

یک تلاش اتصال را با یک بازهٔ زمانی هم‌بسته کنید. نشانی پایانی کلاینت را یادداشت کنید، سپس رویدادهای سرور را از همان ثانیه‌ها بخوانید. دست‌دادن TLS که هرگز به تبادل گواهی نمی‌رسد به دسترسی‌پذیری یا ناسازگاری پروتکل اشاره می‌کند، در حالی که رد احراز هویت پس از توافق پارامترهای تونل می‌رسد.

یک ورودی کهنهٔ گزارش چیزی را دربارهٔ پروفایلی که پنج دقیقه پیش بارگیری کرده‌اید ثابت نمی‌کند. فایل کلاینت را از نو بسازید، یک بار وصل شوید و فقط سطرهایی را بخوانید که در همان تلاش ظاهر شدند.

نخستین شکست مشخص را ثبت کنید، نه آخرین شکست کلی را. خطای bind، تبادل بیرونی بی‌پاسخ، رد گواهی و رد حساب هر یک شما را به لایه‌ای متفاوت می‌فرستد، و یک پایان مهلت در انتها اغلب رویداد سودمند بالای آن را پنهان می‌کند.

بازسازی تونل یک گام تشخیصی نیست

میان‌بر وسوسه‌انگیز برپا کردن تونل دومی ساده‌تر است: کلید ایستا، بدون گواهی، بدون احراز هویت اضافی. اغلب وصل می‌شود، و تنها ثابت می‌کند دو میزبان می‌توانند UDP یا TCP را میان خود رد و بدل کنند. دربارهٔ اینکه چرا استقرار گواهی‌محور شکست می‌خورد چیزی نمی‌گوید، و بی‌صدا مدل امنیتی‌ای را که از شما خواسته شده بود حفظ کنید جایگزین می‌کند.

همین دربارهٔ غیرفعال کردن tls-auth یا tls-crypt، سست کردن verify-x509-name، یا کنار گذاشتن عامل دومی برای گرفتن وضعیت سبز صادق است. تونلی که چون راستی‌آزمایی حذف شده وصل می‌شود نظامی دیگر است، نه نظامی تعمیرشده.

یک تغییر محدود در همان لایه‌ای که گزارش نام برد انجام دهید، همان واحد را دوباره راه‌اندازی کنید و همان یک تلاش اتصال را تکرار کنید. این مقایسه را صادق نگه می‌دارد و تغییری بر جای می‌گذارد که می‌توانید بازگردانید.

چه چیزی را به نفر بعدی بسپارید

چهار واقعیت را تا وقتی هنوز دارید بنویسید: نسخهٔ OpenVPN از openvpn --version، واحدی که فعال است، زنجیرهٔ پیکربندی با درج‌هایش، و پنجرهٔ گزارشی که یک تلاش را پوشش می‌دهد. آن چهار، شکایتی مبهم را به موردی قابل بازتولید تبدیل می‌کند.

پیش از اشتراک‌گذاری پاک‌سازی کنید. کلیدهای خصوصی، auth-user-pass و فایل‌های مشابه، مواد کلید ایستا و بسته‌های کامل کلاینت جایشان در تیکت نیست؛ نام گزینه‌ها و شکل زنجیره معمولاً برای یک جفت چشم دوم کافی است.

اگر زنجیره سالم است و گزارش هنوز به شبکه اشاره می‌کند، گام بعدی مسیر میان کلاینت و سرور است، نه نصب دوباره. این همان بخشی از ماجراست که کمک‌کننده هرگز صاحبش نبود.