د یو څخه زیاتو کلینټونو لپاره د IKEv2 تنظیمات پلان کړئ
یو کارکوونکی ډیسکټاپ پروفایل یوازې یو کلینټ آزمولی دی۔ د هویت تړون سره موافق شئ، یو ملاتړ شوی تقاطع وټاکئ، بیا د هر پلیټفارم لپاره نوي کول او خوب وآزمویئ۔
په یو ډیسکټاپ کې کارکوونکی پروفایل د یو کلینټ بریالۍ آزمونه ده۔ دا د پلیټفارمونو ترمنځ ځای پرځای کول نه دي، او که ورته داسې چلند وشي، پیژندل شوی ملاتړ بڼه رامنځته کیږي: Windows نښلول کیږي، تلیفون د هویت په څیړنه کې ناکام کیږي، او مدیریت شوی لیپ ټاپ هر ځل چې ویښ شی بیا نښلول کیږي۔ توپیرونه ریښتیني دي او ډیری یې د وړاندوینې وړ دي، نو ځکه باید پلان یو میټریکس وي نه د سکرین انځور۔
لومړی د هویت تړون وټاکئ
له الګوریتمونو بحث مخکې د سرور هویت، د سند باور او د کلینټ د تصدیق طریقه مستند کړئ۔ دا درې ټاکي چې کلینټ کولی شي تصدیق کړي که نه، او پلیټفارمونه همدا برخې په بېلابېل ډول بیانوي۔
وګورئ چې هر پلیټفارم تمه شوي پیژندونکي ته څنګه نوم ورکوي او د موضوع بدیل نومونه څنګه اداره کوي۔ هغه پروفایل چې په یو کلینټ کې د سرور نوم مني، ممکن په بل کې ورته سند رد کړي، ځکه د پیژندونکي ساحه له بل ارزښت څخه ډکیږي۔
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
بیا کریپټوګرافیک تقاطع وټاکئ
د هر ملاتړ شوي کلینټ وړاندیزونه پرتله کړئ او یو عصري تقاطع وټاکئ چې ګیټوی هم اجازه ورکوي۔ د یو زوړ وسیله نښلولو لپاره ډیره لویه زړه لیست فعاله نه کړئ، ځکه هغه لیست د راتلونکو ټولو لپاره د ګیټوی ډیفالټ کیږي۔ ولیکئ چې هر زوړ انتخاب ولې لا هم شته۔ که هیڅوک نشي هغه وسیله نومولی چې ورته اړتیا لري، دا اړتیا نه ده۔
په پلان کې IKE او CHILD تنظیمات جلا وساتئ۔ هغه وړاندیز چې د IKE تبادلې لپاره منل شوی وي، په اتوماتيک ډول د ساتل شوي ترافیک لپاره منل شوی نه دی، او دواړه جلا جلا خبرې اترې کیږي۔ هغه ګیټوی چې په یوه پوړ کې وړاندیز مني، لا هم کولی شي په بل پوړ کې یې رد کړي، او لاګ به داسې ناکامي وښیي چې لکه لومړی پوړ بریالی شوی وي۔
د تصدیق شوې پروسې له لارې اسناد برابروئ، او د کارونکي پټ نوم، شریکه پټه او د کلینټ شخصي کیلي په خپلو ساحو کې وساتئ۔ په ورته نوم لرونکو صندوقونو کې آزموینه او تېروتنه هغه لار ده چې کارکوونکې آزمونه بیا نه تولیدیدونکې آزمونې ته اړوي۔
د ژوند دوره وآزمویئ، نه ثابته حالت
د هر کلینټ لپاره لومړنی تصدیق، پلان شوی اپلیکیشن، DNS حل او د پتې کورنیو پوښښ وآزمویئ۔ بیا هغه برخې تمرین کړئ چې یوازې وروسته ښکاري: نوي کول، خوب او نورمال شبکه بدلون۔
د MOBIKE ملاتړ او د بیا تصدیق چلند ممکن له هغه ثابتې پایلې توپیر ولري چې همدا اوس مو اندازه کړه۔ هغه مهال پیښه او د اړیکې حالت ثبت کړئ، نه یوازې دا چې انټرفیس په پای کې نښلول شوی ښکاري۔
تعریف کړئ چې مستقیم ترافیک کولی شي څه وکړي کله چې VPN شتون نه لري۔ دا یوه پالیسي پریکړه ده چې له دې جلا ده چې کلینټ بیا نښلول کیږي که نه، او ډیری ځای پرځای کول لومړۍ پوښتنه له پامه غورځوي او دویمې ته ځواب وایي۔ ځواب د پروفایل نومونو ترڅنګ په ځای پرځای کولو یادښتونو کې ولیکئ۔ یو څوک به ورته د خنډ په وخت کې اړتیا ولري، او د بیا جوړولو وخت به نه لري۔
کله چې یو پلیټفارم موافق نه وي، د سرور هویت څیړنې وکاروئ
کله چې پروفایل په یو پلیټفارم کې کار کوي او بل یې نوم ردوي، هغه پیژندونکی چې کلینټ واقعاً لیږلی و د سند لرلو پیژندونکو سره پرتله کړئ۔ دا پرتله کول ډیری دا حالتونه د سیفر لیستونو بدلولو څخه ګړندي حل کوي۔
آزمول شوی میټریکس د ترتیب سرچینې او د تازه کولو پروسې سره یوځای وساتئ۔ کله چې د زوړ کلینټ ملاتړ پای ته ورسیږي، د راتلونکي پلټنې لپاره د ګیټوی په دننه کې کمزوري سازګاري تنظیمات پټ پرېښودلو پرځای د هغه استثنا په قصد سره لرې کړئ۔ د strongSwan IKEv2 اسناد د دې لپاره ګټور مرجع دي چې تبادلې څنګه ترتیب کیږي۔