کلاینت SoftEther هنگام بوت: AccountStartupSet و ترتیب دیمن

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

تأیید کنید که حساب برای شروع خودکار علامت خورده است

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

cd /opt/softether/vpnclient
./vpncmd

برای مدیریت کلاینت VPN گزینهٔ 2 را انتخاب کنید و با فشردن Enter سرور محلی را بپذیرید.

AccountStartupSet
office-hub
exit

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

تأیید کنید که سرویس بالا می‌آید، و به‌اندازهٔ کافی زود

در Linux کلاینت به‌صورت دیمن از پوشهٔ خودش اجرا می‌شود، و باید پیش از آنکه هر مرحلهٔ بوت بخواهد از حساب استفاده کند بالا باشد. قلاب کوتاهی که پوشه را عوض می‌کند و آن را اجرا می‌کند در سامانه‌هایی که هنوز rc.local را اجرا می‌کنند کافی است.

cd /opt/softether/vpnclient
./vpnclient start

جایی که rc.local دیگر نیست، یک واحد systemd با WorkingDirectory صریح و سیاست راه‌اندازی دوباره بنویسید. فایل دودویی پیکربندی خود را نسبت به جایی که از آن اجرا می‌شود بازمی‌یابد، پس واحدی بدون آن تنظیم می‌تواند با موفقیت بالا بیاید و هیچ نخواند. ترتیب نیمهٔ دوم مسئله است: تلاش برای اتصال که پیش از گوش‌دادن دیمن اجرا شود گهگاه شکست می‌خورد، و تشخیص آن بسیار دشوارتر از یک شکست پایدار است. سیاست راه‌اندازی دوباره حالت سوم را پوشش می‌دهد، جایی که دیمن ساعتی بعد بی‌صدا می‌میرد.

فهرست فرآیندها را بررسی کنید، نه اینکه به فایل pid باقی‌مانده از بوت قبلی اعتماد کنید.

تأیید کنید که آداپتر نشانی گرفته است

به‌محض اینکه حساب متصل شود، کلاینت یک آداپتر مجازی ارائه می‌دهد و آداپتر هنوز نشانی لازم دارد. هابی که SecureNAT اجرا می‌کند معمولاً به DHCP پاسخ می‌دهد؛ هابی که به یک LAN فیزیکی پل زده شده، در عوض انتظار دارد سرور همان LAN پاسخ دهد.

ip -brief address
dhclient vpn_vpn1

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

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

تأیید کنید که مسیر به جایی می‌رود که فکر می‌کنید

ترافیک می‌تواند با پیوند سالم و نشانی معتبر هم شکست بخورد. از هسته بپرسید برای مقصدی درون زیرشبکهٔ هاب از کدام واسط استفاده می‌کند، سپس آن پاسخ را با تونل مقایسه کنید.

ip route get 10.10.20.15

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

این تصمیمی دربارهٔ شماره‌گذاری است نه باگ کلاینت، و راه‌اندازی دوبارهٔ سرویس آن را تغییر نمی‌دهد. پیکربندی حل‌کننده نیمهٔ دیگر است: نشانی بدون سرور DNS کارآمد تونلی می‌سازد که همهٔ بررسی‌های پیوند را می‌گذراند و باز هم نمی‌تواند نامی را باز کند.

چهار بررسی را در یادداشت‌های بازسازی بنویسید

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

پرچم یک خط برای اعمال دوباره است و فراموش‌کردنش آسان.

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