په شبکې د نومونو فضا کې WireGuard: ولې ساکټ وروسته پاتې شو

انټرفېس په هغه نومونو فضا کې لیسټ شوی چې تاسو غوښتل، اپلیکیشن ورسره تړلی دی، او بیا هم هېڅ د تونل ترافیک نه ښکارې. دا د Linux کرنل د WireGuard وسیلې نښه ده چې په یوه نومونو فضا کې جوړه شوې او بلې ته انتقال شوې: انټرفېس انتقال شو او د هغې کوډ شوی UDP ساکټ انتقال نه شو. دواړه باید د داخلی ترافیک اهمیت مخکې په سم ښای کې وی. کتنه چېته دې کله چې یو نه، دوه بافتونه باید وګورئ، ښکارې دې.

نښه: سمه نومونو فضا، خو بسته نه

د نومونو فضا په داخل کې تونل روغ ښکارې. وسیله شته، پتې ټاکل شوې دی او د همکار ترتیب هم شته. له بهر، تمه شوې UDP تبادله هېڅ کله په هغه انټرفېس کې نه ښکارې چې تاسو یې ګورئ، او بل لوری راپور ورکوي چې لاس ورکول نه دې شوې.

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

دا د انتقال خرابی نه ده او د همکار غلط ترتیب هم نه دی. کرنل تطبیق همداسې کار کوي او د WireGuard لپاره د نومونو فضا اسناد د جوړولو قاعده مستقیمه بیانوي.

ولې ساکټ زېږېدونکی ښای لری

د WireGuard وسیله د خپل کوډ شوي انتقال لپاره یو UDP ساکټ لری، او هغه ساکټ په هغه نومونو فضا کې خلاصیږی چې وسیله پکې جوړېږی. د لینک امر له لارې د انټرفېس انتقال لیدل شوی وسیله انتقالوي خو انتقال هغه ښای پرېږدی چې پیل شوی وه. بیا دوه شیان جودا جودا مالکان لری.

پایله اسانه له نظره غورږیږی ښکارې چې دواړه نیمې برخې په مختلفو ښایونو کې کتل کېږی. داخلی لار په هغه نومونو فضا کې ټاکل کېږی چې اپلیکیشن پکې ښی، او بهرنی لار هغه ښای ټاکل کېږی چې ساکټ پکې اوسیږی. یوازې یو له دوی کتل یو ښای باوری خو غلطه نتیجه ورکوي. دواړه کتل په اومره چې په یوه تېرېدو کې پېږینه پای ته رسوي.

هغه هماغه ښای جوړه کړئ چې ساکټ غواړئ

حل دا دی چې وسیله له بهره جوړه کړئ او انتقال یې کړئ، بلکه د هدف نومونو فضا په داخل کې یې جوړه کړئ. فرض کوو چې منل شوی نومونو فضا د مخکې شته او نوم نه کارول کېږی:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

اوس انټرفېس او د هغې ساکټ دواړه دې بافت ارتې دی، نو لاندینی لار او تطبیقیدونکې د فلټر قواعد هغه دی چې هلته ترتیب شوی. که ډیزاین روښانه لوری بل ښای غواړی، لومړی بنسټیز انټرفېس په نومونو فضا کې کېږدئ او بیا تونل جوړه کړئ. ترتیب د ډیزاین برخه دې، د تطبیق تفصیل نه دی.

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

د لار دواړې خواوې ولولئ

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

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

که داخلی پلټنه د تونل له لارې حله شوه او بهرنۍ ثبت کوډ شوی تبادله وښای، دواړې نیمې برخې سره سمون لری. که ثبت خالی وی، ساکټ لا هم بل ښای دی، یا د هغې د نومونو فضا لاندینۍ لار په پای ټکې نه رسیږی.

یوه بله کتنه هم باید په ریکارډ کې وی: وسیله له بیا پیل کېدو وروسته ښنګه جوړېږی. هغه مدیر چې انټرفېس د بل جوړولو بافت سره بیا جوړوي، د ساکټ زېږېدونکی ښای بدلوي. یو وار بریالۍ شوی لاسی انتقال د اداره شوی لار په اړه شاهد نه دی.