strongSwan ESP-in-UDP: کله چې د پیدا کولو لپاره NAT نه وي

د NAT کشف د پتو ژباړه مومي، نه د فایر وال پالیسي. د NAT پرته د سایټ نښلون بیا هم ښکاره ESP-in-UDP غوراوي ته اړتیا لرلی شي.

د NAT کشف یوه پوښتنې ته ځواب وایي: ایا په لاره کې پتې یا پورټونه بدل شوي؟ دا ځواب نه وایي چې ایا فایر وال د IP 50 پروتوکول اجازه ورکوي۔ هغه سایټي ګیټوې چې هېڅ ژباړه نه لري بیا هم د داسې پالیسۍ شاته کېدای شي چې native ESP غورځوي، او دا اړتیا باید تر پیدا کولو مخکې تنظیم شي۔ میکانیزم ESP-in-UDP دی، او دا پرېکړه ده، نه داسې بدیل چې پخپله ښکاره شي۔

کشف په پتو باندې حساب دی، د فایر وال پلټنه نه

IKEv2 د NAT کشف پېلورډونه لېږدوي چې د سرچینې او منزل پتو او پورټونو هشونه لري۔ هره خوا چې ترلاسه کړي د هغه سره پرتله کوي چې په سیمه ییز ډول یې ویني، او ناسم والی ورته وایي چې یو څه پاکټ ژباړلی دی۔ په دې تبادله کې هېڅ شی نه ازموي چې ایا منځنی روټر 50 پروتوکول مخې ته لېږي۔

عملي پایله په روښانه ډول ویل ارزښت لري۔ هغه تونل چې له native ESP سره کار کاوه پخپله نوی محدودوونکی فایر وال نه مومي، او کله چې IKE بریالی پاتې شي د هغه بله هڅه د معلوماتو په پړاو کې ناکامه شي۔ تاسو به جوړ شوي IKE امنیتي اړیکې ووینئ او هېڅ خوندي ټرافیک نشته، چې تر تار پر کېدو پورې د لارښوونې نیمګړتیا په څېر ښکاري۔

نو انکپسولیشن د هغه نښلون ځانګړنه ده چې تاسو یې تنظیموئ، نه هغه پایله چې خواوې د شبکې له چلند څخه پرې سلا کوي۔

encap تبادله څنګه بدلوي

په نوي strongSwan ځای پر ځای کولو کې، چې د swanctl.conf له لارې اداره کېږي، په نښلون کې encap = yes ترتیبول د NAT کشف تبادلې ته اغېزه کوي تر څو دواړه خواوې د ESP لپاره UDP انکپسولیشن وکاروي۔ بیا خوندي پاکټونه د UDP دننه، معمولاً په 4500 پورټ کې سفر کوي، او دواړه سرونه باید پر دې ترتیب سلا شي۔

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

د strongSwan د NAT-traversal لارښود دا چلند بیانوي، په دې کې د MOBIKE کارولو پر مهال د پورټ څپېدلو تعامل هم شامل دی۔

هغه ترتیبول وکاروئ چې ستاسو backend ته اړه لري

strongSwan دوه کنفیګریشن backend لري، او کیلي د دوی ترمنځ توپیر لري۔ swanctl.conf نښلون encap اخلي، پداسې حال کې چې زوړ ipsec.conf نښلون forceencaps اخلي۔ د یو backend کلیمه بل ته اچول داسې کنفیګریشن جوړوي چې پرته له شکایت لوډېږي او هېڅ نه بدلوي، چې له تېروتنې هم بدتر دی۔

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

بدلون د نښلون د مالک له لارې پلي کړئ او اړیکه په کنټرول شوي کړکۍ کې بیا جوړه کړئ۔ لا دمخه نصب شوی child تر بدلېدو پورې خپل اوسنی انکپسولیشن ساتي، نو یوازې د فایل سمول نه ثابتوي چې نوی ترتیب کارېږي۔

تړل شوي معلومات وګورئ، نه یوازې پورټ

کله چې خوندي ټرافیک بهېږي په ګیټوې کې ثبت کړئ، بیا یې د strongSwan خپلې انځور سره پرتله کړئ:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP د IP 50 پروتوکول په څېر ښکاري او د UDP سره هېڅ نه ورته دی۔ تړل شوی ESP د 4500 پر سر UDP ډیټاګرامونو په څېر ښکاري چې پېلورډ یې IKE نه دی۔ په هماغه پورټ کې IKE ټرافیک د انکپسولیشن ثبوت نه دی، ځکه MOBIKE کولی شي IKE هلته ولېږدي او د معلوماتو لاره native پاتې شي، نو پورټ شمېره نه، پېلورډ ولولئ۔

د لارې MTU هم په یاد ولرئ۔ پوښ اضافي لګښت زیاتوي، او هغه لاره چې native ESP لېږدوله کېدای شي د پاکټونو لویېدو سره سمون ته اړتیا ولري۔ اړین ICMP سمبالښت باید لا دمخه د ډیزاین برخه وي؛ انکپسولیشن هغه تړاو نه لره کوي۔

بدلون ومنئ کله چې د تونل دننه نوی اپلیکیشن ټرافیک په دواړو سرونو کې د تړل شوي ESP په څېر په ثبت کې ښکاره شي، او کله چې داخلي خدمت او د هغه د بېرته راستنېدو لار لا هم کار وکړي۔ له دې کم هر څه هغه کنفیګریشن دی چې په فایل کې سم ښکاري۔

اړوندې مقالې