د Docker پورټونو خپرول د VPN په وړاندې: ځواب چېرته ځي

کوربه د بشپړ ټونل VPN له پورته کېدو وروسته هم SSH ته ځواب ورکوي، خو په همدې ماشین کې د Docker له لارې خپرول شوې خدمت خاموشه کېږي. په اورېدونکي کې هېڅ خرابي نشته: کانټینر روان دی، د پورټ نقشه شته، او پیکټ رسیږي. کانټینر روغ دی او غوښتنه واقعاً ورته رسیږي. توپیر دا دی چې Linux د خپلې لارې په ټاکلو کې ځواب له کومه ځایه پیلېږي، او همدا توپیر ټاکي چې لاندې دوه ډیزاینونو کې کوم یو ته اړتیا لرئ.

ټوپل د منزل NAT له لارې تعقیب کړئ

یو کوربه واخلئ 192.0.2.10 کې، چې TCP 2222 172.30.240.5:22 کې کانټینر ته خپروي. 198.51.100.25 څخه راغلې غوښتنه کانټینر ته له رسېدو مخکې ژباړل کېږي، او کانټینر د خپل ځان په توګه ځواب ورکوي.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

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

ولې یوازې کوربه ته ځانګړی قانون دا له لاسه ورکوي

هغه قانون چې WAN جدول یوازې 192.0.2.10 څخه راغلو پیکټونو لپاره ټاکي، د کوربه خپل ډیمونونه پوښي او دا لېږدول شوی ځواب په بشپړه توګه له لاسه ورکوي. د ځواب سرچینه پته 172.30.240.5 ده، نه کوربه.

ډېره زیاته سمونه دا ده چې له کانټینر څخه ټول څیزونه د WAN له لارې وګرځول شي، چې د کانټینر نااړوند بهر تلونکي اړیکې هم له VPN څخه معاف کوي. دا له غوښتل شوې تګلارې څخه بېله ده، او معمولاً وروسته چا ته حیرانتیا ورکوي.

له DNAT وروسته سمون بل هوک دی

د Docker د فایر وال اسناد یادونه کوي چې عادي کارن فلټر کول له DNAT وروسته منزل ویني, نو په عادي قانون کې د خپرول شوي پورټ 2222 سمون د کانټینر پورټ 22 له سمون سره یو شان نه دی. که اصلي ټوپل مهم وي، د دې پر ځای چې اټکل وکړئ کوم پورټ ښکاري، د ملاتړ شوي اصلي منزل میکانیزم وکاروئ.

دا د هوکونو ګډوډي داسې قوانین جوړوي چې سم ښکاري او هیڅکله نه سمون کېږي. د تګلارې له بیا لیکلو مخکې پر خود قانون شمېرونکي وګورئ. هغه قانون چې هیڅ لګېدنه نه لري تاسو ته وایي چې په داسې ځای کې ارزول کېږي چې پیکټ هیڅکله هلته نه رسیږي.

ډیزاین A: پرېکړه د اړیکې حالت په توګه وړل

د اړیکې نښه کولی شي د ننوتلو پرېکړه د ژباړې له لارې ووړي، خو باید د مهمې لارې پلټنې مخکې پیکټ ته بیرته ورکړل شي. پړاوونه دا دي:

1. د نښې ساحه او د قانون لومړیتوب ځانګړي کړئ چې له Docker، VPN یا بلې تګلارې مالک سره نه ټکر کېږي.
2. یوازې په پام کې نیول شوې نوې WAN اړیکه د DNAT څخه مخکې هغه ټکي کې وپېژنئ چې د اړیکو تعقیب شته وي.
3. پرېکړه پر اړیکې نښه ثبت کړئ، پرته له دې چې اصلي غوښتنه پخپله WAN جدول ته اړ کړئ.
4. د ځواب په لور، د لارښوونې مخکې یوازې خپلې نښې بټې پیکټ ته بیرته ورکړئ.
5. بشپړ WAN جدول په کافي اندازه ژر وټاکئ ترڅو د VPN قانون لومړی ونه شي ګټلی.

هغه جدول ته ریښتیني نښلول شوې لارې او ګېټوې ته اړتیا ده. همدارنګه د لارې نه شتون پر مهال ټاکل شوې چلند ته اړتیا ده. په ټونل کې خاموشه لوېدل تر ټولو بد پایله ده، ځکه ترتیب لا هم د کار کولو په څېر ښکاري. پر ځای یې په بند ډول ناکام شئ او ثبت یې کړئ.

ډیزاین B: پر کوربه پای ته رسول

په کوربه اړخ کې په قصد جوړ شوی فرنټ اینډ، لکه د TCP پراکسي یا د کانټینر مخې ته معکوس پراکسي، ځواب د کوربه له پتې څخه راوتونکی ساتي. بیا د کوربه لپاره لیکل شوي قوانین د تمې سره سم چلند کوي، او کانټینر په خپل خصوصي شبکه کې پاتې کېږي.

لګښت بل خوځنده برخه ده چې خپل ترتیب، د سرچینې پتې سمبالښت او د لاسرسي کنټرولونه لري. دا معمولاً ساده ملاتړ شوې پوله ده، او کله چې د لارښوونې تګلاره د یوې هغې کس له خوا وساتل شي چې کېدای شي ولاړ شي، نو ډېری وخت سم ځواب وي.

بدلون تایید کړئ، نه نیت

له عامه اړخ څخه نوې اجازه لرونکې اړیکه پرانیزئ او تایید کړئ چې ځواب د پام شوې برخې له لارې وځي. بیا وګورئ چې کانټینر پیل کړې نااړونده غوښتنه لا هم VPN تعقیبوي.

د یو قانون ازموینې لپاره د ماشین د اړیکو جدول مه تشوئ: شته ننوتنې خپله پخوانۍ نقشه ساتي، او تشول پر کوربه نور هر څه ماتوي. د پورټ خپرول د رسېدو وړتیا ټاکي. دا د ځواب لاره نه ټاکي. ټاکل شوی ډیزاین د خپلو جدول نومونو سره ولیکئ، ترڅو بل کس یې په یوه پېښه کې بیا کشف کړي نه.