ولې Android له کورني IPsec VPN سره نښلوي خو Windows نه

تلیفون پرته له کوم شکایت روټر ته دننه کېږي، خو په همدې Wi-Fi کې لپ ټاپ نشي کولی. هماغه د ننوتلو معلومات، هماغه سرور، هماغه دقیقه. توپیر د پروتوکول ملاتړ دی، د پټنوم نه: روټر هغه پروفایل ښیي چې یو عملیاتي سیستم یې پلي کوي او بل هېڅکله نه درلود.

لومړی پروفایل وپېژنئ، بیا یې د هر کلاینټ له ریښتیني ژبې سره پرتله کړئ.

یو مینو، درې پروتوکولونه

د یو IPsec سرلیک لاندې مصرفوونکی فرم ویئر کولی شي درې بشپړ بېل تونلونه پټ کړي. لومړی XAUTH سره IKEv1 دی: ګډ ګروپي راز او پر سر یې کارننوم او پټنوم. دویم L2TP/IPsec دی، چېرې چې PPP د ګډ کلي په ساتل شوي IPsec انتقال دننه ګرځي. درېیم IKEv2 دی، چې د سندونو یا EAP په مرسته تصدیق کېږي.

ساحې ولولئ، لیبل نه. ګروپي راز او کارنلړلیک یعنی IKEv1 XAUTH. مخکې شریک شوی کلي او PPP حساب یعنی L2TP/IPsec. پرته له ګروپي راز سروري سند یعنی IKEv2.

د تلیفون او لپ ټاپ ترمنځ د ملاتړ تشه

Android کې IKEv1 XAUTH PSK کلاینټ دننه وي، او همدا لامل دی چې تلیفون د هغه روټر پر وړاندې بریالی کېږي چې بل څه نه وړاندې کوي. Windows کې نه وي: د هغه اصلي کلاینټ L2TP/IPsec او IKEv2 سمبالوي، او د فعالولو لپاره IKEv1 XAUTH انتخاب نشته. راز بیا لیکل مرسته نه کوي، ځکه چې ورک شوی برخه پروتوکول دی، د ننوتلو معلومات نه.

د Apple خوا خوځنده هدف دی. نوي macOS او iOS نسخې IKEv2 ته مخه کوي، زاړه د Cisco سټایل پروفایلونه په ځینو جوړښتونو کې پاتې کېږي، او تازه کول کولی شي هغه څه لرې یا سخت کړي چې تېره میاشت کار کاوه. هغه Mac چې پرون نښلېده او نن نه نښلوي، پرته له روټر بدلون، معمولاً همدا وي.

دوه تنظیمات چې سم پروفایلونه ماتوي

د Synology L2TP/IPsec پاڼه د Enable SHA2-256 compatible mode (96 bit) په نوم چیک بکس وړاندې کوي. د iOS 14 او macOS Big Sur څخه Apple کلاینټونه هغه پرې شوی حالت نه مني، نو د دوی لپاره باید بکس بند وي. که خلاص پاتې شي، تونل تصدیق کېږي او بیا لوېږي، چې د بدو معلوماتو په څېر ښکاري خو نه دی. جوړوونکی سویچ مستند کوي، او د عملیاتي سیستم تازه کول هغه شیبه ده چې دا اهمیت ته رسېږي.

Windows سندونه په دوو جلا زېرمو کې ساتي، او IKEv2 یوازې د ماشین هغه لولي. کلاینټ سند د خپل خصوصي کلي سره کمپیوټر حساب ته دننه کړئ؛ هغه سند چې ستاسو د کارن حساب لاندې وي په مدیریت کنسول کې ښکاري خو هېڅکله IKEv2 خدمت ته نه رسېږي. EAP-TLS یوازینی حالت دی چې کارن سند پکې کارېدلی شي، او لاسلیک کوونکی CA باید لا هم ماشین ته باوري وي. دلته غلطي د تصدیق ناکامۍ په څېر ښکاري، نه د ورک سند غوښتنې په څېر.

کله چې روټر هماغسې پاتې شي

یوازې XAUTH PSK وایي روټر درې لارې پرېږدي: د جوړوونکي کلاینټ، د درېیم اړخ کلاینټ چې لا هم پروفایل پلي کوي، یا د تونل پای IKEv2 وایي څه ته لېږدول. د بېلګې په توګه AVM د خپلو روټرونو لپاره Windows کلاینټ سافټویر او صادر شوی تنظیمات فایل خپروي. هغه لار ملاتړ کېږي، او مانا یې دا ده چې په هر لپ ټاپ کې د جوړوونکي وسیله نصب شي.

کله چې لپ ټاپونه ستاسو نه وي چې بیا یې جوړ کړئ، ملاتړ له ښکلا مهم دی.

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

له بهر څخه دننه تشخیص کړئ

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

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