ولې IKEv2 په Android کې په غیر معیاري UDP پورټ کې ناکامېږي

ګیټوی د یو دلیل له مخې په UDP 4443 کې IKEv2 ته ځواب وایي، په پروفایل کې د Server په نوم ساحه ده، تاسو د کوربه نوم او پورټ لیکئ، او تلیفون راپور ورکوي چې سرور ته نه شي رسیدلی یا ادرس نه شي حل کولی۔ هیڅ شی بند نه دی۔ د Android اصلي فورم کوربه تمه کوي، او په Windows کې هم همداسې ده۔ دودیز پورټ د سرور تنظیم کیدو څخه دمخه د کلاینټ وړتیا ده، او یوازې ځینې کلاینټونه تاسو ته اجازه درکوي چې څرګند یې کړئ۔ درې برخې په ترتیب سره وګورئ: کلاینټ څه ویلای شي، سرور څه ته غوږ نیسي، او ایا دواړه خواوې پاکټونه په یو شان فریم کوي۔

تلیفون په حقیقت کې څه ولېږل

د نوم لپاره جوړ شوي ساحه کې host:port سټرینګ د نوم په توګه حل کیږي۔ حل کوونکی د vpn.example.net:4443 لپاره هیڅ نه بیرته راولي، او هغه تېروتنه چې تاسو یې وینئ په پورټ کې د وخت پای نه دی، بلکې د نوم حل یا نه رسیېدو ناکامي ده۔ دا توپیر مهم دی، ځکه چې د لنډ نوم یا بل شبکې سره بیا هڅه هغه سټرینګ چې فورم یې تجزیه کولی نه شي هیڅکله نه سمېږي۔

په Android کې اصلي IKEv2 پروفایل، لکه د Windows جوړ شوی VPN کلاینټ، په معیاري IKE پورټونو ټینګ دی۔ هیڅ یو یې د پورټ ساحه نه ښیي، او د پروفایل سمون یې نه زیاتوي۔ که د آپریټر اورېدونکی واقعیا په 4443 کې وي، نو جوړ شوی کلاینټ غلط توکی دی، نه غلط تنظیم شوی۔

هغه کلاینټ وکاروئ چې پورټ ښیي

د strongSwan Android کلاینټ په خپلو پرمختللو پروفایل تنظیماتو کې د تنظیم وړ سرور پورټ مستند کوي، له همدې کبله په دې ډیزاین لپاره په نږدې هر کار کوونکي نسخه کې ښکاري۔ هغه ملاتړ د هماغه کلاینټ دی: بله IKEv2 اپلیکیشن، یا د هماغه اپلیکیشن د پلورونکي څانګه، کیدای شي هماغه ساحه نه ښیي، حتی که لاندې strongSwan ډیمون یې ملاتړ کوي۔

له آپریټر څخه ټول سیټ یوځل وغواړئ: د ګیټوی نوم، UDP پورټ، د تصدیق طریقه، او هغه سرور هویت چې کلاینټ یې باید تمه ولري۔ دودیز پورټ د سندونو تایید بندولو یا پروتوکولونو بدلولو دلیل نه دی۔ پورټ هغه ځای ولیکئ چې نصب شوی کلاینټ یې تمه لري، او که هغه کلاینټ داسې ساحه نه لري، ځواب بل تصویب شوی کلاینټ دی، نه اټکل شوې لار۔

سرور دوه پورټونه لري، او دواړه باید سره سمون ولري

IKE په UDP 500 کې پیل کیږي، او NAT تیریدل معمولا IKE او پوښل شوی ESP په UDP 4500 ته لېږدوي۔ دا په strongSwan کې جلا تنظیمات دي، نو هغه سرور چې یو دودیز پورټ ته لېږدول شوی باید دواړه په یو شان ارزښت بدل کړي:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

کله چې یو پورټ دواړه رولونه ترسره کوي، ډیمون باید په هماغه ساکټ کې IKE له ESP-in-UDP څخه وپیژني، کوم چې د IKE پیغام څخه دمخه راتلونکي څلور بایټ غیر-ESP نښان له لارې کوي۔ له همدې کبله کلاینټ نشي کولی په دودیز پورټ کې خبرې وکړي او بیا په چوپتیا 4500 ته دوام ورکړي، او له همدې کبله “یوازې پورټ بدل کړئ” جمله د فریمنګ یوه شرط پټوي۔

فارورډ کول اورېدونکی نه دی

4443 عادي IKE اورېدونکي ته فارورډ کول هغه ناکامي ده چې نږدې بریالۍ ښکاري۔ لومړی تبادله رسیږي، سرور ځواب وایي، او بیا اړیکه ودریږي یا کیلي په هیڅ شي کې بیا جوړوي، ځکه چې ځواب له بل پورټ څخه وځي او وروسته پوښل شوی ترافیک هغه حالت سره چې دواړو خواو جوړ کړی هیڅکله سمون نه لري۔ هغه قاعده چې د اورېدونکي په نه لیږدولو سره د منزل پورټ بیا لیکي، په دقیق ډول همدا نیمګړی-خلاص نتیجه ورکوي۔

لار باید UDP هم له سره تر سره اجازه ورکړي۔ د TCP 443 د هوټل یا آپریټر شبکې له لارې تیریدل د UDP پورټ کې د IKEv2 په اړه هیڅ نه وایي، حتی که شمیره یوه وي۔ چېرې چې یوازې TCP 443 اجازه لري، هلته دودیز UDP پورټ IKEv2 په HTTPS نه بدلوي، او سم ځواب کیدای شي بله لاسرسي لار وي، نه بله پورټ تجربه۔

د ازموینې پر مهال درې پړاوونه جلا کړئ

کله چې کلاینټ یو ځل هڅه کوي په سرور کې ثبت کړئ۔ هغه غوښتنه چې هیڅکله نه رسیږي د پای نقطې یا فایر وال پوښتنه ده؛ هغه غوښتنه چې پرته له ځواب رسیږي د اورېدونکي یا پالیسي پوښتنه ده؛ او هغه ځواب چې وروسته یې چوپتیا وي د فریمنګ یا هویت پوښتنه ده۔

tcpdump -ni eth0 -vv udp port 4443

بیا د کلاینټ څرخیدونکی اشاره نه، بلکې پیغام یې ولولئ۔ د وړاندیز تېروتنه معنی لري چې الګوریتمونه سره نه سمون لري، د تصدیق ناکامي معنی لري چې هویتونه یا سندونه سره نه سمون لري، او پرته له ځواب تکراري بیا لېږل معنی لري چې په هغه پورټ کې هیڅ ځواب نه وایي۔ یو ځل یو پړاو وازموئ او د هڅو ترمنځ یوه ساحه بدل کړئ؛ د NAT تیریدو په اړه د strongSwan اسناد هغه نښان او پورټ چلند تشریح کوي چې ثبت یې تاسو ته ښیي۔