د 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 سرور پته داسې تونل جوړوي چې هر د لینک ګوتې تېروي او لا هم نه شي کولای نوم خلاص کړي۔

څلور ګوتې د بیا رغونې یادښتونو کې ولیکئ

د حساب نوم، د خدمت د پیل امر او د انټرفیس نوم یو ځای ثبت کړئ، ځکه چې بیا رغول شوی کوربه د حساب معلومات بحراني کوي خو هغه هنګ نه چې ډیمون پیلوي۔ هغوی په بېلابېلو ځایونو کې ژوند کوي او معمولاً بېلابېل خلک یې بیک اپ اخلي۔

بیرغ یوه کرښه ده چې بیا پلي شي او هیرول یې اسانه دي۔

ترتیب وساتئ: بیرغ، خدمت، پته، لاره۔ هغه چک لیست چې له مینځ څخه پیل شي ډیر ډاډمن غلط ځوابونه تولیدوي۔