Access Server پس از تغییر نام رابط شبکه اتصالش را از دست داد: کلیدها را اصلاح کنید

یک رابط شبکه را تغییر نام داده‌اید، یا ماشینی را بازیابی کرده‌اید که آداپترش با نامی دیگر بازگشته است، و اکنون دیمن OpenVPN Access Server بالا نمی‌آید. رابط وب ممکن است هنوز پاسخ دهد یا ندهد، بسته به اینکه کدام مؤلفه به نام قدیمی مقید بوده است. سرویس خراب نشده و پیکربندی از دست نرفته؛ یک تنظیم هنوز به رابطی اشاره می‌کند که میزبان دیگر آن را ندارد.

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

آنچه نشانه واقعاً می‌گوید

دیمنی که نمی‌تواند مقید شود معمولاً در گزارش خود می‌گوید: نشانی در دسترس نیست یا رابط وجود ندارد. پیام مشخص است: نشانی‌ای را که دیمن امتحان کرده نام می‌برد؛ آن را با ip -br addr روی میزبان مقایسه کنید تا بدانید رابط تغییر نام داده، حذف شده یا بدون نشانی قدیمی بالا آمده است.

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

پیش از ویرایش، پیکربندی را بپرسید

Access Server پیکربندی خود را از طریق CLI خودش ارائه می‌دهد. نمای مستند این است:

sacli ConfigQuery

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

آن خروجی نمای پیکربندی سرور است، نه نسخه پشتیبان کامل. ویژگی‌های کاربر و گروه جداگانه پرسیده می‌شوند، پس اتصال سالم هویت‌ها را بازیابی نمی‌کند و هویت بازیابی‌شده شنونده را درست نمی‌کند. هر دو را دو سند جداگانه ثبت کنید.

مشخص کنید کدام شنونده خراب است

Access Server بیش از یک شنونده اجرا می‌کند. دیمن‌های OpenVPN ترافیک تونل را حمل می‌کنند، سرویس وب درگاه مدیریت و مشتری را، و مؤلفه‌های دیگر ممکن است پورت‌های خود را داشته باشند. درخواست ناموفق مرورگر نمی‌گوید کدام‌یک شکست خورده، و شماره پورت در پیام خطا هم نمی‌گوید.

کلیدهای اتصال دیمن برای هر دیمن مستند شده‌اند، و در آموزش رسمی مقدار، شناسه رابط است هرچند نام کلیدها به ip_address ختم می‌شود. آن جمله را دو بار بخوانید. آموزش همچنین انتظار دارد دیمن‌های UDP و TCP یک رابط را شریک شوند، پس اصلاح تنها یک کلید تعمیر ناقص است.

تنظیم نام‌دار را تغییر دهید، نه ردیف‌های منطبق

آموزش ConfigPut را روی کلیدهای مشخصی مانند vpn.daemon.0.server.ip_address و vpn.daemon.0.listen.ip_address مستند می‌کند. از روش خود محصول با نام کلید و مقدار جدید، در نحو مستند نسخه خود، استفاده کنید و فقط کلیدهای شنونده‌ای را که تشخیص داده‌اید تغییر دهید.

کاری که نباید بکنید جست‌وجوی پایگاه داده برای هر ردیفی است که مقدارش با نام قدیمی رابط برابر است و جایگزینی همه آن‌ها. این فرض می‌کند نام قدیمی فقط در تنظیمات شنونده بوده، که طرح چنین تضمینی نمی‌دهد. همچنین تغییر را غیرقابل بازبینی می‌کند.

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

اعمال کنید و ثابت کنید مسیر کار می‌کند

پس از اصلاح مقدار، آن را از طریق چرخه عمر مستند محصول اعمال کنید ( چرخه عمر ). آموزش پس از تنظیم کلیدها از sacli start استفاده می‌کند؛ این با راه‌اندازی مجدد کامل میزبان یا بازنشانی پایگاه داده یکی نیست.

ss -lntup | grep -E '1194|443'
sacli ConfigQuery | grep -i ip_address

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