GVC په Acquiring IP کې بند پاتې دی: دا د پاسورډ ستونزه نه ده

Global VPN Client په Acquiring IP کې ودریږي، او لومړی غبرګون دا وي چې پاسورډ بیا ولیکئ یا ک्लायنټ بیا نصب کړئ. هېڅ یو یې هغه پړاو نه لمس کوي چې ناکام شوی. تصدیق مخکې له دې بشپړ شوی و چې ک्लायنټ پته وغواړي، نو هغه څه چې تاسو په دې کرښه کې نیسي د ننوتلو معلومات نه دي. هلته تاسو یو نیمګړی DHCP تبادله نیسي، او دا په درې بېلو ځایونو کې بند پاتې کېدای شي.

تصدیق او د پتې ټاکل جلا پړاوونه دي

GVC لومړی ثابتوي چې تاسو څوک یاست، بیا د خپلې اړیکې لپاره ټاکل شوې تګلارې له مخې د خپل مجازي اډاپټر تنظیمات غواړي. دا هغه پرلهپسې ګامونه دي چې د ناکامۍ نښې یې بېلې دي. خراب ننوتلو معلومات معمولاً دمخه ناکام شي، د پتې کرښې پر ځای د تصدیق یا خبرو اترو پیغام سره.

همدا ترتیب تشریح کوي چې ولې د پاسورډ بیا تنظیمول، نوی ځایي کارن یا بیا نصبول دلته هېڅ نه بدلوي. ک्लायنټ لا دمخه اجازه لري؛ اوس هغه داسې لییز ته انتظار دی چې ګېټوې یا د هغې DHCP ملګری باید برابر کړي. حتی هغه تګلاره چې کارن ته اجازه ورکوي خو د پتې ساحه نه ټاکي هم دقیقاً همدا سکرین جوړوي.

نو لومړی ګټور پوښتنه دا نه ده چې ننوتلو معلومات سم دي که نه، بلکې دا ده چې کومه تګلاره ټاکل شوې او هغه تګلاره د مجازي اډاپټر د پتې په اړه څه وایي. د همکار د کار کوونکي سکرینشاټ پر ځای د هغې اړیکې ریښتینی ترتیب ولولئ.

لییز په رښتیا له کومه ځایه راځي

دوه ماډلونه عام دي. اوروژونکی کولای شي پخپله د VPN ک्लायنټونو لپاره DHCP ساحه وچلوي، یا غوښتنه داخلي شبکه کې بهرني DHCP سرور ته ولیږدوي. ماډل ټاکي چې کوم لاګونه مهم دي او له چا سره اړیکه ونیول شي.

په داخلي ماډل کې وګورئ چې ساحه لا هم شته، سم انټرفیس پورې اړه لري او خالي لییزونه لري. پای ته رسېدلې ساحه داسې ک्लायنټ جوړوي چې بشپړ تصدیق کوي خو هېڅکله پته نه اخلي، او د ګېټوې لاګ ممکن یوازې غوښتنه وښیي. په لېږدونې ماډل کې د لېږدونې هدف، VPN ک्लायنټ ساحې ته د بېرته تګ لار او هر داخلي DHCP اجازه باید سره سمون ولري.

له هر څه ازموینې مخکې ولیکئ چې ستاسو ځای پرځای کول کوم ماډل کاروي. په انټرنیټ کې نیمې متضادې سلاوې بل ماډل فرض کوي.

ټونل کېدای شي فعال وي او بیا هم لییز له لاسه ورکړي

جوړه شوې کنټرول اړیکه ثابتوي چې خبرې اترې بریالۍ شوې، نه دا چې د ټونل معلومات دواړو خواوو ته ځي. DHCP تبادله غواړي چې غوښتنه او ځواب د معلوماتو لاره تېره کړي، او همهلته د کوډ کولو تنظیمات، د VPN زون تګلاره او د MTU ستونزې دي.

د NAT traversal په اړه سلا د شرایطو د اهمیت ترټولو روښانه بېلګه ده. ځینې لارې غواړي چې دا فعال وي، نور یوازې د بند حالت کې کار کوي، او منځنی NAT د خبرو اترو شوې اړیکې سره یوځای ټاکي چې کوم یو. په تیاره کې یې بدلول پداسې حال کې چې د ک्लायنټ تنظیمات هم بدلوئ مانا دا ده چې نه پوهیږئ کوم بدلون نتیجه ورکړه. د انکپسولیشن له بدلولو مخکې خبرې اترې شوې لاره او شواهد ولیکئ.

د کور راؤټر بیا پیلول هم په همدې کټګورۍ کې دي. دا کله ناکله نښه لرې کوي، خو نه ښیي چې لییز ولې ناکام شو، او ستونزه په راتلونکې اړیکه کې بېرته راځي.

د لییز لاره په ترتیب سره وګرځوئ

له اډاپټر پیل کړئ او بهر ته لاړ شئ، ترڅو هر ګام یوازې د یو دلیل له امله ناکام شي:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

169.254.x.x ته ورته پته مانا دا ده چې اډاپټر شته او هېڅ ځواب یې نه دی ترلاسه کړی، چې د لییز سرچینې یا د معلوماتو لارې ته اشاره کوي. په VPN ساحه کې سمه پته خو غلط DNS ننوتنې بله خرابي ده: لییز کار وکړ او تګلارې نیمګړي تنظیمات ورکړل. هغه اډاپټر چې هېڅکله نه ښکاري مانا دا ده چې ک्लायنټ یې تر جوړولو ونه رسېد.

کله چې لییز ښکاره شي، ریښتینی سرچینه وآزمویئ نه دا چې په پتې کرښه کې بریا اعلان کړئ. که د فایل یا داخلي شبکې لاسرسی لا هم ناکام وي، بریالی لییز د شاهد په توګه وساتئ او د نومونو حل یا تګلارې ته لاړ شئ، ځکه چې اصلي خرابي مو له شا پرېښې ده.

د مجازي اډاپټر په اړه د SonicWall یادونه څو جلا څانګې لیست کوي، او د هغې زاړه سکرینشاټونه باید د اوسني مینو نقشې په توګه ونه لوستل شي. دا د هغه پړاو د تایید لپاره وکاروئ چې تاسو ته رسېدلي یاست، نه د بشپړ پلي کولو د چک لیست په توګه.