سلام دوستان . در این ارسال به یک نکته ای در خصوص SRC nat و یا Source Nat خواهیم پرداخت . نکته ای که در مفاهیم واقع شده و ربطی به سیستم عامل و یا روتر استفاده شده ندارد ( مثلا چه میکروتیک و یا چه یک توزیع لینوکسی و … ) . در تعریف Source Nat می گیم که قسمتی از header که مربوط به آی پی مبدا و یا پورت مبدا می باشد , ادیت شده و با آی پی و یا پورت تعیین شده جایگزین می شود . قصد پیاده سازی Source Nat رو نداریم فقط قسمت هایی که نیاز است رو یاد آوری می کنم تا در آخر نکته ی خودمون رو بیرون بکشیم .

فرض ها :

روتر : میکروتیک با آی پی آدرس 192.168.50.1 برای اینترفیس ether1 و آی پی آدرس 10.10.10.1 برای اینترفیس ether2

سرور : دبیان 7 با آی پی آدرس 192.168.50.50 برای اینترفیس eth0 . فاقد هر گونه gateway و rout

کلاینت 1 : دبیان 7 با آی پی آدرس 10.10.10.21 برای اینترفیس eth0 . روتر میکروتیک به عنوان gateway اضافه شده است

کلاینت 2 : دبیان 7 با آی پی آدرس 10.10.10.22 برای اینترفیس eth0 . روتر میکروتیک به عنوان gateway اضافه شده است

توپولوژی شبکه :

از اون جایی که در داخل وب سرور هیچ GW و route ای ست نشده است , وب سرور نمی تواند inter face دوم روتر یعنی ether2 با آی پی 10.10.10.1 را ببیند . طبیعتا کلاینت های موجود در این محدوده را هم نمی تواند ببیند .

در داخل کلاینت ها روتر میکروتیک به عنوان GW اضافه شده است . پس می توانند inter face اول روتر یعنی ether1 با آی پی 192.168.50.1 را ببینند . هم چنین می توانند وب سرور را تا حدودی ببینند اما به صورت ناقص !

دلیل ناقص بودن ارتباط کلاینت ها با وب سرور این است که پکت های درخواستی از سمت کلاینت ها به دست سرور می رسد اما در بازگشت دچار مشکل می شوند چرا که سرور نمی تواند کلاینت ها را در شبکه ببیند .

در بعضی از مواقع نتیجه ی مطلوب ما همین است ! یعنی دوست نداریم که کلاینت و یا شبکه ای بتوانند با وب سرور به طور مستقیم در تماس باشند . دقیقا همان چیزی که در سناریو بالا اتفاق می افتد اما نکته ی اصلی بحث ما این جا است که :

ظاهرا کلاینت ها نمی توانند به وب سرور دسترسی داشته باشند اما این به این معنا نیست که پکت های کلاینت دست وب سرور نمی رسد ! این موضوع خودش رو اون جایی نشون می ده که تعداد زیادی کلاینت و یا روتر دیگر داشته باشیم آن وقت ترافیک عظیمی از سمت کلاینت ها به سمت روتر و وب سرور جاری می شود ! توجه داشته باشید که در ظاهر عملا ارتباط با وب سرور میسر نیست اما در لایه های پایین تر , پکت های کلاینت ها و … به وب سرور می رسد و روتر نیز عمل مسیر یابی ( به شکلی یک طرفه ) را انجام می دهد . پس این یک اطلاف انرژی است و باید جلوی آن گرفته شود !

برای مشاهده ی اظهارات بالا کافیست یک برنامه ی پکت کپچر را در سرور اجرا کرده و در یکی از کلاینت ها اقدام به ping گرفتن از سرور کنیم :

1. در کلاینت شماره ی 1 اقدام به پینگ کردن سرور می کنیم :

ping 192.168.50.50 -c 4

2. گفته شد که سرور می تواند پکت هایی که از سمت کلاینت می آید را ببیند اما نمی تواند پاسخی برای آن ها ارسال کند . پس نتیجه می گیریم که 4 تا پکت ICMP از طرف کلاینت بدون پاسخ خواهیم داشت . پس :

tcpdump -i eth0 icmp -c 4

برای جلوگیری از این قضیه کافیست در فایروال جلوی ارتباط کلاینت ( ها ) و یا شبکه های دیگر را بگیریم و تمامی بسته های ارسالی احتمالی را Drop کنیم . پس برای سناریو بالا به شکل زیر در روتر میکروتیک خودمون عمل می کنیم :

[admin@OSLearn] > ip firewall filter add chain=forward src-address=10.10.10.0/24 dst-address=192.168.50.50 action=drop

اگه از یک توزیع گنو لینوکسی جهت روتر استفاده کرده بودیم . کافی بود با یک رول iptables جلوی این ترافیک اضافی را بگیریم . به شکل زیر :

root@elab:~# iptables -t filter -A FORWARD -s 10.10.10.0/24 -d 192.168.50.50 -j DROP

توجه داشته باشید که آدرس مبدا رو کل شبکه ی 10.10.10.0/24 و آدرس مقصد رو فقط وب سرور با آدرس آی پی 192.168.50.50 قرار داده ایم .

ربط این موضوع با Source Nat : دیده شده که در مواقعی برای گروهی از کلاینت ها و یا برای شبکه ای خاص عمل Source Nat انجام می شود تا با وب سرور در تماس باشند و دیگر دستگاه ها که احتیاجی به برقراری ارتباط ندارند , رها می شوند چرا که این طور به نظر می رسد که دیگر سیستم ها با وب سرور در تماس نیستند . ( همون طور که خواسته بودیم ) اما در این ارسال دیدیم که این طور نیست و باید جلوی پکت های احتمالی ای که به سمت سرور فرستاده می شود را گرفت .

ممنون که تا آخر این مقاله با ما بودید . با تشکر

منبع : او اس لرن | http://OSLearn.ir