آشنایی با معماری Large Scale NAT (LSN)

اگر از پست قبل به خاطر داشته باشید، توضیح داده شد که چندین سال از NAT به عنوان راهکاری در ساختارهای شبکه ی مشتریان برای کاهش نیاز به آدرس های IPv4 Public استفاده می شد.

زمانی که آدرس های IPv4 Public به مرز اتمام نزدیک شدند، ISP ها به دنبال جواب این سوال بودند که چطور می توانند ارتباط خود با مشتریانشان را حفظ کنند. پاسخ این پرسش این بود که اگر NAT در لبه ی مرزی ساختار مشتریان با Provider ها توانسته بود موفق عمل کند پس قطعا می تواند در لبه ی مرزی ساختار Provider ها با مشتریانشان نیز موفق عمل نماید. در واقع این پاسخ، ایده ی اصلی شکل گیری مفهومی با نام Large Scale NAT یا LSN بود.

معماری LSN به این صورت است که، ISP ها برای لینک هایی که به سمت مشتریان خود دارند به جای تخصیص آدرس IPv4 Public  از آدرس های IPv4 Private استفاده می کنند و برای لینک هایی که برای ارتباط آن ها با اینترنت است از آدرس IPv4 Public.

بنابراین اگر مشتری در روتر مرزی خود با Service Provider از NAT استفاده کرده باشد، پکتی که از سمت ساختار مشتری به سمت ISP ارسال می شود، ابتدا آدرس IPv4 Private آن به یک آدرس IPv4 Private دیگر که از سمت ISP به لینک بین آن و روتر مرزی مشتری اختصاص پیدا کرده، نگاشت می شود و در هنگام خروج پکت از ساختار Provider به سمت اینترنت،  آدرس آن به یک آدرس IPv4 Public ترجمه می شود. پس بنابراین دوبار ترجمه رخ می دهد: یک آدرس IPv4 Private به یک آدرس IPv4 Private دیگر و نهایتا به یک آدرس IPv4 Public ترجمه می گردد. به همین دلیل این عمل اصطلاحا NAT444 نامیده می شود.

خوبی این روش آن است که NAT ای که سمت مشتریان پیاده سازی شده هیچ نیازی به تغییر ندارد چرا که برای NAT مهم نیست که آدرس outside ای که باید نگاشت به آن انجام شود، باید Private باشد یا Public. بنابراین از دید تجهیز سمت مشتری، هیچ تغییری رخ نداده است.

اما این معماری قطعا مشکلاتی را نیز در پی خواهد داشت: به عنوان مثال تصور کنید که مشتری در ساختار خود از همان رنج آدرس IPv4 Private ای استفاده کرده باشد که Provider آن رنج را به لینک بین خود و مشتری اختصاص داده است، در این صورت overlap رخ خواهد داد. یا مثلا تصور نمایید که یک مشتری قصد ارسال پکتی را به یک مشتری دیگر که در پشت همان LSN ای که با آن ارتباط دارد، داشته باشد. معمولا فایروال ها یا ACL هایی که در روترها تعریف می شوند، مانع از ورود پکتی با آدرس IP Private به داخل ساختار شده و این پکت ها رو drop می کنند.

در این پست سعی شده تا بیشتر با معماری LSN، مزایا و معایب آن و هم چنین راهکارهایی که برای حل مشکلات این معماری ارائه شده است، آشنا شویم.

Large Scale NAT Architectures

مفهوم Carrier Grade NAT (CGN)

اگر از پست قبل به خاطر داشته باشید، Dual Stack ساده ترین روش برای حرکت به سمت استفاده از IPv6 بود. در این روش، در صورتی که در یک ساختار IPv6، تمام دستگاه ها قابلیت پشتیبانی از هر دوی ورژن های IPv4/IPv6 را داشته باشند قادر خواهند بود تا با هر مقصدی؛ چه IPv4 و چه IPv6؛ ارتباط برقرار نمایند. این روش زمانی که اکثر کاربران هنوز در حال استفاده از IPv4 باشند، روش مناسبی است.

اما مشکل این روش آن بود که به ازای هر اینترفیسی، همزمان یک آدرس IPv4 و یک آدرس IPv6 نیاز بود و این امر در حالی است که آدرس های IPv4 به پایان رسیده اند و قرار بر پیاده سازی  روشی برای توسعه ی IPv6  و نه افزایش نیاز به IPv4 ای است که دیگر وجود ندارد!

در گذشته برای کاهش نیاز به آدرس های IPv4 Public عموما از دو روش استفاده می شد:

  • یکی از راه ها استفاده از DHCP بود که شاید در آن زمان که تعداد دستگاه هایی که باید به صوت همزمان آنلاین می بودند، کم بود، روش موفقی محسوب می شد اما در حال حاضر که تعداد بیشماری دستگاه وجود دارد که همه همزمان آنلاین هستند، روش خوبی تلقی نمی شود.
  • راه حل بعدی استفاده از NAT44 بود که در واقع نگاشتی را بین آدرس های IPv4 Private، به یک آدرس IPv4 Public انجام می داد و به این ترتیب برای سازمان ها این امکان فراهم می شد که برای ارتباطات دستگاه های داخلی خود از آدرس های IPv4 Private استفاده کنند و اگر نیازی به ارتباط با اینترنت بود، از NAT استفاده می شد و نیاز به آدرس IPv4 Public کاهش پیدا می کرد.

اما این روش هم مشکلی مشابه روش استفاده از DHCP داشت. تعداد آدرس های IPv4 Public محدود بودند و اگر همزمان تعداد زیادی دستگاه نیاز به اتصال به اینترنت داشتند، این روش جوابگو نبود. بنابراین عملکرد NAT44 به گونه ای تغییر داده شد که از شماره پورت ها در هنگام نگاشت آدرس ها استفاده شود. همانطور که می دانید مشهورترین اصطلاح برای این روش Port Address Translation  یا PAT بود که اکنون دیگر PAT یک روش جداگانه محسوب نمی شود و تبدیل به عملکرد نرمال NAT44 گشته است.

اول این مبحث مطرح شد که روش Dual Stack در واقع مشکل IPv4 را حل نمی کرد چراکه نیاز به آدرس های IPv4 Public به تعداد زیاد، داخل Service Provider ها هم چنان وجود داشت و سپس همانطور که مطرح شد عملی که NAT انجام می داد آن بود که به شما این امکان را می داد که در داخل ساختار از آدرس های IPv4 Private استفاده کنید و بعد با داشتن چند آدرس محدود Public و استفاده از NAT، بین این آدرس ها نگاشت انجام دهید. پس آیا امکان پذیر نیست که ایده ی استفاده از NAT به داخل سرویس پروایدرها منتقل شود؟

در این مقاله به مسایلی که به آن ها اشاره شد پرداخته می شود و نهایتا به معرفی راهکار Carrier Grade NAT یا CGN ختم می گردد.

Understanding Carrier Grade NAT

معمای Dual Stack

اخباری که بر پایان عمر IPv4 اشاره می کنند روز به روز در حال افزایش هستند. خبری که این روزها باعث ترس عده ی زیادی شده، یک خبر جدید نیست بلکه از سال ها قبل هشدار این رویداد داده شده بود و روش هایی برای مدیریت این شرایط معرفی گردیده بود.

در هر حال، چه در اوج هوشیاری از این رویداد و چه بی خبر از آن، تمام سازمان ها باید به فکر دوره ی گذار از IPv4 به IPv6 باشند. این گذار احتمالا سخت و دشوار خواهد بود چرا که هنوز تعداد زیادی از کاربران  و دستگاه هایی که به اینترنت متصل می شوند از IPv4 استفاده می نمایند، ارتباط بسیاری از ISP ها با مشتریانشان و حتی با سایر ISP ها بر بستر IPv4 است، دسترسی به بسیاری از محتواها در دنیای اینترنت بر پایه ی IPv4 می باشد و … ادامه خواندن “معمای Dual Stack”

پایان عمر IPv4 در حوزه ی آمریکای لاتین و کارائیب!

نهایتا LACNIC (حوزه ی آمریکای لاتین و کارائیب) نیز طی گزارشی رسما اعلام کرد که فاز آخر اختصاص آدرس های IPv4 پابلیک رو اجرایی کرده و بعد از این فاز دیگه هیچ فازی برای اختصاص آدرسهای IPv4 پابلیک وجود نخواهد داشت.

تصویر: وبسایت MakeUseOf

این امر به این معنی هست که آدرس های IPv4 پابلیک LACNIC رو به پایان هستن و بر طبق شرطی که LACNIC گذاشته، این آدرس های باقی مونده  تنها به سازمان هایی اختصاص داده میشن که تا به حال هیچ آدرس IPv4 پابلیکی از جانب LACNIC به اون ها اختصاص پیدا نکرده باشه. به این ترتیب LACNIC توصیه کرده که سرویس پروایدرها باید برای ارتباطات خودشون با مشتریانشون به سمت فراهم سازی بستری برای استفاده از IPv6 حرکت کنند.
متن این اطلاعیه رو میتونید از لینک زیر مشاهده کنید:

http://www.lacnic.net/en/web/anuncios/2017-fase-final-de-agotamiento-de-ipv4

مهاجرت به IPv6: دیتاسنترهای فیسبوک

در بحث مهاجرت به IPv6 ، شاید بشه گفت دیتاسنترها اولین نقطه‌ای هستن که باید براشون برنامه‌ریزی کرد تا سرویس‌ها IPv6-enabled و در دسترس باشن. شرکتهای بزرگ راهکارهای حرکت به سمت IPv6 خاص خودشون رو دارن. در این میون شرکتی مثل فیسبوک از ایده های جالبی برای پیاده سازی IPv6 در دیتاسنترهای خودش استفاده کرده.

99 درصد ترافیک درون شبکه ای فیسبوک و نیمی از کلاسترهای اون ها IPv6 only هستن و این در حالی هست که تنها 15 درصد کابران فیسبوک از IPv6 استفاده می کنند و 85 درصد ترافیکی که به سمت سرورهای فیسبوک روونه میشه، IPv4 only هستن!

فیسبوک در استفاده از راهکارها و دیوایس های خاص خودش همیشه مشهور بوده، برای همین شاید براتون جالب باشه که بدونید چطور فیسبوک بدون هیچ تداخلی تونسته ترافیک IPv4 ای که بخش اعظمی از ترافیک ورودی به دیتاسنترهاش رو شامل میشه از بستری مبتنی بر IPv6 عبور بده. پیشنهاد می کنم این پست کوتاه که با زبانی بسیار ساده به توضیح این راهکارها پرداخته مطالعه کنید 🙂

https://code.facebook.com/posts/635645183305089/legacy-support-on-ipv6-only-infra