څنګه د NAT تېرېدل ESP په UDP کې نغاړي

د یوه روټر شاته دوه کلینټونه له یوه IPsec ګېټوې سره خبرې کوي، او یو یې دوامداره غورځي او بل یې وصل پاتې کېږي۔ اصلي ESP د 50 شمېرې IP پروتوکول دی چې پورټونه نه لري، نو کله چې څو کلینټونه یوه پته شریکه کړي، ژباړونکی هغه څه نه لري چې نقشه پرې وتړي۔ د NAT تېرېدل دا تشه په 4500 کې ESP د UDP په داخل کې نغاړلو سره ډکه کوي، او هغه سرلیک د راتلونکو نښو ډېره برخه تشریح کوي۔ دا هغه وسیله هم ښیي چې باید بدله شي۔

ولې د معلوماتو پوړ 4500 پورټ ته ځي

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

نغاړنه یو پاکټ دی، د پروتوکول بدلون نه: ESP خپل سرلیک، د بشپړتیا کتنه او کوډونه ساتي، او UDP یوازې هغه پورټونه برابروي چې ژباړونکی یې غواړي۔ پورټ 500 د IKE تبادله وړي؛ 4500 د کشف وروسته نغاړل شوې داده، او ډېری وختونه وروستي IKE پیغامونه هم وړي۔ هیڅ پورټ جریان TCP اړیکه نه جوړوي، دا انګیرنه د کپچر لوستونکو ډېری خلک ګمراه کوي۔

دواړه پړاوونه په ترتیب سره وګورئ

لومړی کنټرول تبادله ثابته کړئ، بیا د معلوماتو لاره، او دواړه په خپلو یادښتونو کې جلا وساتئ۔ هغه کپچر چې په 500 کې ترافیک ښیي او په 4500 کې هېڅکله نه، معمولاً مانا دا ده چې د معلوماتو لاره فلټرېږي، نو سمون باید په کلینټ کې نه، بلکې په فایر وال قاعده کې وي۔

tcpdump -ni any 'udp port 500 or udp port 4500' سره دواړه پورټونه وګورئ، او تر هغه چې غونډه ژوندۍ ده په روټر کې د ژباړې جدول ولولئ۔ هغه جدول هغه سرچینه پورټ ښیي چې ګېټوې به یې واقعاً وویني، او په لپ ټاپ کې کپچر په ډیزاین سره ورسره نه سمون خوري: لپ ټاپ 500 ګڼي او ګېټوې ژباړل شوی سرچینه پورټ سره 4500 ویني، او دواړه سم دي۔ همغه جریان، د ژباړې دمخه او وروسته:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

هغه نښې چې نغاړنه یې تشریح کوي، او دوه چې نه یې کوي

هغه روټر چې کنټرول تبادلې ته اجازه ورکوي او نغاړل شوې داده بندوي د «تونل پورته دی خو هېڅ نه تېرېږي» راپور جوړوي۔ د نقشې جدولونه پای ته رسېږي، نو بې‌کاره غونډې ته هغه ژوندی ساتونکی ترافیک ته اړتیا وي چې خواوې یې په قصد لیږي، او هغه پاکټونه د روغتیا کتنې نه دي۔ کله چې د یوې ګېټوې شاته څو کلینټونه یوځای ناکام شي، د هغې ګېټوې ژباړه او هر پخوانی تېرېدنې خصوصیت وګورئ۔ نغاړنه هغه اپلیکیشن نه تشریح کوي چې د تونل له پورته کېدو وروسته په هر کلینټ کې ناکام شي، او نه د بند پاڼې سرټیفیکټ خبرداری؛ دواړه له دې پرت پورته دي۔

د دوو کلینټونو لپاره په یو وخت کې د نقشې جدول ولولئ: که دواړه یو شان ژباړل شوی پورټ ښیي، وسیله دوی هغسې نه جلا کوي لکه ګېټوې چې غواړي۔ هغه تېرېدنې حالت چې اصلي ESP یوازې یو هوسټ ته ورکوي، د څو ژباړل شوو کلینټونو خدمت سره برابر نه دی، که څه هم پلورونکي دواړه له IPsec سره دوستانه بولي۔ دوه ځله NAT د نقشې یو پرت او یو بل پای ټکی زیاتوي، خو وتونکې اړیکې په اتوماتيک ډول نه پرې کوي۔

ژوندی ساتونکی ترافیک په عملیاتي لارښود کې خپل کرښه لري، ځکه چې په بې‌کارۍ موده کې د ځواب لاره پرانیستې ساتي۔ هغه چېرې چالان کړئ چې پلورونکی یې سند کوي، او کله چې غونډه لومړي کارولو ته نه، بلکې څو دقیقو چوپتیا وروسته مړه شي لومړی هماغه وګورئ۔

د نقشې مالک بدل کړئ، بیا یو ځل بیا ازموینه وکړئ

د پورټ اټکل کولو پر ځای په دواړو خواوو کې د NAT تېرېدنې ملاتړ شوي تنظیمات تعقیب کړئ۔ په یو کلینټ کې د سیمه‌ایز سرچینه پورټ سمول نشي کولی په بل سر کې اورېدونکې خدمت بدل کړي، او معمولاً جوړه شوې نقشه ماتوي۔ که کلینټ د هغې وسیلې شاته وي چې تاسو نه کنټرولوئ، بدلون د هغې مالک دی۔

له هر بدلون وروسته دواړه پړاو کتنې تکرار کړئ او تایید کړئ چې د معلوماتو پاکټ تېرېږي، نه یوازې دا چې د حالت سکرین شین شو۔ ټاپلونه، د نقشې جدول پایله او د قاعدې بدلون په یوه یادښت کې وساتئ، تر څو بل کس بیا له کنټرول تبادلې پیل نه کړي۔ د strongSwan یادښتونه د NAT تېرېدنې په اړه دواړو پړاوونو شاته د پوښلو او ژوندي ساتلو تنظیمات رانغاړي۔