OpenConnect vpnc-script: کدام فایل اجرا می‌شود؟
کمک‌کننده‌ای که مسیرها و DNS را نصب می‌کند از سرویس‌گیرندهٔ تونل جداست. پیش از جایگزین‌کردن آن با نسخه‌ای از انجمن، مسیری را که سرویس‌گیرندهٔ در حال اجرا استفاده می‌کند پیدا کنید.
OpenConnect می‌تواند دست‌دادن تونل را کامل کند و با این حال شما را بدون مسیر به زیرشبکهٔ خصوصی رها کند، چون سرویس‌گیرنده و کمک‌کننده‌ای که وضعیت شبکهٔ محلی را تغییر می‌دهد دو برنامهٔ متفاوت‌اند. احراز هویت ثابت می‌کند که دروازه نشست را پذیرفته است؛ اما هیچ چیزی دربارهٔ اینکه کدام رابط، کدام مسیرها یا کدام تنظیمات حل‌کننده بعد از آن نصب شده‌اند ثابت نمی‌کند. بیشتر گزارش‌های گیج‌کننده از جایگزین‌کردن کمک‌کننده با نسخه‌ای از یک پاسخ قدیمی می‌آید، که رفتار هر اتصال روی دستگاه را تغییر می‌دهد. پیش از ویرایش هر بخشی از آن، کمک‌کننده‌ای را که سرویس‌گیرندهٔ در حال اجرا واقعاً فراخوانی می‌کند پیدا کنید.
دو برنامه، دو مسئولیت
سرویس‌گیرنده مالک انتقال، احراز هویت و دستگاه تونل است. یک کمک‌کنندهٔ جداگانه مالک آن چیزی است که پس از وجود تونل در سیستم محلی رخ می‌دهد: نشانی‌دهی روی رابط، مسیرها برای زیرشبکه‌هایی که دروازه اعلام کرده است، و پیکربندی حل‌کننده. مستندات کمک‌کنندهٔ OpenConnect آن جداسازی و محیطی را که کمک‌کننده دریافت می‌کند توصیف می‌کند. این تمایز هنگام خرابی اهمیت دارد، چون رمز عبور ردشده و مسیر ناپدید دو رویداد یکسان نیستند، حتی وقتی رومیزی برای هر دو یک گفت‌وگو نشان می‌دهد.
نگه‌داشتن این جداسازی در ذهن همچنین توضیح می‌دهد چرا یک اتصال می‌تواند موفقیت گزارش کند در حالی که نام‌های خصوصی هنوز حل نمی‌شوند. تونل در هر دو حالت برپاست و تنها مرحلهٔ یکپارچه‌سازی محلی تفاوت دارد.
کمک‌کننده‌ای را که سرویس‌گیرندهٔ در حال اجرا استفاده می‌کند پیدا کنید
مسیر هنگام ساخت بسته تعیین می‌شود و می‌تواند در هر فراخوانی بازنویسی شود، بنابراین فایلی که از توزیع دیگری به یاد دارید ممکن است هیچ ارتباطی با این اتصال نداشته باشد. از فرایند در حال اجرا بپرسید، نه از مستنداتی که تصادفاً باز کرده‌اید.
openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/nullاگر خط فرایند آرگومان --script را حمل کند، آن فایل بر پیش‌فرض کامپایل‌شده اولویت دارد. مسیرهای قدیمی‌تر مانند /etc/vpnc/vpnc-script می‌توانند وجود داشته باشند و بی‌استفاده بمانند، و به همین دلیل حذف یا ویرایش آن‌ها در یک ساخت جدید هیچ چیز را تغییر نمی‌دهد. تاریخ تغییر را هم بررسی کنید، چون کمک‌کننده‌ای که سال‌ها کسی به آن دست نزده نشانهٔ قویی است که پیش‌فرض بسته‌بندی‌شده کار را انجام می‌دهد.
یکپارچه‌سازی NetworkManager مالک سوم است، با کمک‌کننده و تنظیمات نمایهٔ خودش. گذاشتن یک اسکریپت دوم مسیر یا حل‌کننده روی آن یکپارچه‌سازی مسیرها را تکراری می‌کند و حل‌کننده‌ای باقی می‌گذارد که دو برنامه ادعا می‌کنند آن را مدیریت می‌کنند. برای هر اتصال یک مالک انتخاب کنید و دیگری را پیش از آزمایش غیرفعال کنید.
اولین عملیات ناموفق را بخوانید، نه آخرین هشدار
پیکربندی رابط، نصب مسیرها، انتخاب حل‌کننده و پاک‌سازی وضعیت کهنه گام‌های جدایی هستند، و هشداری که در آخر چاپ می‌شود غالباً شکایت پاک‌سازی است نه خرابی‌ای که اتصال را شکست. رو به بالا بخوانید تا اولین عملیات مشخصی که شکست خورده است. خطای کمک‌کننده‌ای که یک فایل یا یک نشانی را نام می‌برد بیش از ده خط سروصدای برچیدن ارزش دارد.
نتیجهٔ محلی موردنظر را با نتیجهٔ مشاهده‌شده مقایسه کنید: دستگاه تونل وجود دارد، مسیری به یک نشانی خصوصی شناخته‌شده از آن می‌گذرد، و حل‌کننده برای یک نام خصوصی پاسخ می‌دهد. کمک‌کننده‌ای که در دو مورد اول موفق است و در سوم شکست می‌خورد به سیاست حل‌کننده اشاره دارد نه به مسیریابی. کمک‌کننده‌ای که اصلاً دستگاه را پیکربندی نمی‌کند احتمالاً هرگز اجرا نشده است، و این پرسشی دربارهٔ مجوزهاست نه شبکه. پیش از بازنویسی هر منطقی، بیت اجرایی و حساب سرویس را تأیید کنید.
اتصال، اتصال دوباره و قطع اتصال را بررسی کنید
راه‌اندازی تنها نیمی از قرارداد است، چون همان کمک‌کننده باید هنگام بسته‌شدن تونل وضعیتی را که در اختیار دارد بازگرداند یا حذف کند. کمک‌کننده‌ای که مسیرها را اضافه می‌کند و هرگز حذفشان نمی‌کند دستگاهی با مسیری کهنه باقی می‌گذارد که از نشست بیشتر عمر می‌کند.
ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'سه خط اول را در حال اتصال اجرا کنید، قطع اتصال کنید، سپس دوباره اجرا کنید و تأیید کنید که مسیر و ورودی حل‌کننده رفته‌اند. خط چهارم نشان می‌دهد آیا کمک‌کننده اصلاً فراخوانی شده و سرویس از کدام مسیر اجرایی استفاده کرده است. آن جفت خروجی را در تیکت ثبت کنید، چون مقایسهٔ قبل و بعد است که یک باگ پاک‌سازی را آشکار می‌کند.
کمک‌کننده را بسته‌بندی‌شده و برای حساب سرویس اجراپذیر نگه دارید، چون اسکریپتی که در پوستهٔ شما اجرا می‌شود ممکن است با این حال تحت یک سیاست سرویس محدود رد شود. وقتی سفارشی‌سازی واقعاً لازم است، هدف و مالک آن را مستند کنید و در هر ارتقا آن را با نسخهٔ بسته‌بندی‌شده مقایسه کنید. یک انشعاب توضیح‌داده‌نشده از یک کمک‌کننده یکی از معدود چیزهایی است که می‌تواند یک اتصال کارا را یک سال بعد از کار بیندازد.