درباره ی فناوری اطلاعات، شبکه، امنیت شبکه و سه نقطه!
نویسنده: مینا رضائی
محقق و همیشه در حال یادگیری، عاشق نقاشی، گاهی هم نویسندگی یا تألیف کتابای بزرگ :)
(مسئولیت و صحت و سقم کلیه ی مطالب منتشر شده از جانب من تنها بر عهده ی خودم می باشد)
با استفاده از راهکار NAT64 دستگاه‌های موبایل IPv6-only توانایی برقراری ارتباط با سرورهای IPv4-only را داشتند. اما NAT64 به تنهایی جوابگوی نیازهای شبکه های موبایل نبود چرا که اکثر نرم‌افزارهای موبایل هم چنان بر مبنای IPv4 می باشند. به همین دلیل راهکار دیگری با نام 464XLATمعرفی گردید.
با استفاده از این مکانیزم آدرس IPv4 آن دسته از کاربران (بیشتر موبایل و نرم‌افزارهای موبایلی) که IPv6 را پشتیبانی نمی کنند، توسط نرم‌افزاری با نام Customer-side Translator یا به اختصار CLAT، به یک آدرس IPv6 با mask ای خاص، /96، ترجمه شده و پکت از طریق ساختار IPv6 به سمت PLATیا Provider-site Translator ارسال می شود.
PLAT با گشودن پکت IPv6 به آدرس های Private IPv4 مبدا و مقصد داخل پکت دست یافته و پکت را به مقصد مورد نظر ارسال می کند. به عبارتی در این روش کلاینت و سرور فقط از طریق Private IPv4 خود در بستری مبتنی بر IPv6 می توانند با یکدیگر ارتباط برقرار نمایند.
روش 464XLAT تنها از مدل های کلاینت-سروری پشتیبانی می کند و نمی‌توان از طریق آن یک ارتباط peer-to-peer بر اساس IPv4 Private را برقرار ساخت. ویدیوی زیر از RIPE NCC به تشریح عملکرد این مکانیزم می پردازد (به جهت سهولت دسترسی هم وطنان داخل کشور، این ویدیو در آپارات آپلود شده است).
یکی از مشکلات بر سر راه Mobile Provider ها فراهم کردن شرایطی است که هاست های IPv6-onlyبتوانند با سرورهای IPv4-onlyارتباط برقرار نمایند. NAT64مکانیزمی است بر پایه ی Network Address Translation (NAT) که با نگاشت آدرس IPv6 هاست متصل به پروایدر به یک آدرس IPv4، این مشکل را برطرف می سازد. ادامه خواندن “مکانیزم های مهاجرت به IPv6: راهکار NAT64”
از زمانی که احساس شد مسیریابی صرفا بر اساس مقصد همیشه خوب و دلخواه نیست، ایده ی تعیین شرایط مسیریابی در مبدا متولد گشت و برای تحقق این ایده، مدام راهکارهای مختلفی مطرح شد: از PBR تا رفتن به سمت MPLS و سپس پیشرفت آن به MPLS-TE و نهایتا معرفی روشی با نام Segment Routing.
به این ترتیب تعیین شرایط مسیریابی در مبدا یا به عبارت بهتر، انجام Source Routing که روزی تنها در حد یک ایده بود، روز به روز به یک واقعیت و منطق جدید در مسیریابی نزدیکتر شد. آنچه سبب شده تا ایده ی Source Routing بیشتر به واقعیت نزدیک شود، راهکار Segment Routing می باشد. برای درک بهتر عملکرد Segment Routing ابتدا بهتر است مروری بر عملکرد MPLS و MPLS-TE داشته باشیم.
MPLS و ارسال پکت ها
تکنولوژی MPLS، تکنولوژی با قدمتی تقریبا 20 ساله و آشنا برای مهندسین اینترنت می باشد. مبنا و اساس کار MPLS بر پایه ی دو مفهوم Control Plane و Forwarding Plane بوده و به صورت خلاصه نحوه ی عملکرد آن به این صورت است که:
به مجموعه ای از روترها که توانایی پردازش و تشخیص Label ها را داشته باشند اصطلاحا Label Switch Router یا به اختصار LSR گفته می شود. در دامنه ی MPLS که شامل مجموعه ای از LSR هاست، به هر کدام از LSR ها نقشی داده می شود. اولین LSR ای که در لبه ی دامنه ی MPLS قرار دارد و پکتی را از خارج این ساختار به داخل دامنه ی MPLS فوروارد می کند اصطلاحا Ingress LSRنامیده می شود و به روتری که در لبه ی انتهایی دامنه ی MPLS قرار دارد و پکتی را از داخل دامنه ی MPLS به خارج این ساختار ارسال می کند، اصطلاحا Egress LSR گفته می شود.
به مسیری که یک پکت از یک Ingress LSR تا یک Egress LSR طی می کند اصطلاحا LSPیا Label Switched Path گفته می شود که این مسیر یا بر اساس کوتاهترین مسیر محاسبه شده توسط IGP ها مشخص می گردد و یا بر اساس پارامترهای Traffic Engineering یا به اختصار TE. ادامه خواندن “MPLS و MPLS-TE مقدمه‌ای برای Segment Routing”
با کم رنگ شدن هر چه بیشتر IPv4در سال های اخیر، نیاز سازمان ها برای مهاجرت به سمت استفاده از IPv6 هر روز پر رنگ تر می شود به گونه ای که این نیاز در آینده ای نه چندان دور به امری حیاتی برای بقای یک کسب و کار در بازار تجارت جهانی محسوب خواهد شد.
با این حال هنوز هم بسیاری از دستگاه ها در دنیای اینترنت هم چنان از IPv4 استفاده می کنند و بسیاری از کاربران با مفهوم IP آشنا نمی باشند.
اینفوگرافیگی که در ادامه آمده جهت آشنایی و کمک به افرادی تهیه شده است که شناخت چندانی از IP و ضرورت مهاجرت به IPv6 ندارند ولی این روزها بیش از پیش با این مفاهیم روبه رو می شوند. ادامه خواندن “آشنایی با اصول اولیه ی IPv6 (اینفوگرافیک)”
مدتی بود که تقریبا در اکثر مقالاتی که میخوندم چشمم به اصطلاحی می افتاد به اسم DNSSEC. از اونجایی که چندان میونه ی خوبی با امنیت ندارم (امنیت هم با من میونه ی خوبی نداره 🙂 ) با خودم میگفتم خب DNS که تکلیفش معلومه چیه، SEC هم که یعنی Security، پس احتمالا باید مربوط باشه به یک توسعه ی امنیتی برای DNS. اما هرچی بیشتر زمان می گذشت تاکید بر این واژه بیشتر و بیشتر می شد. همین عامل باعث شد که من بالاخره بخوام پا در دنیای امنیت (البته صرفا برای مدتی کوتاه و برای یک بخش خیلی کوچیک از این دنیا 🙂 ) بذارم و به دنبال شناخت DNSSEC برم.
قبل از هرچیزی دوست دارم شما هم مثل من با تاریخچه ی شکل گیری و ظهور DNSSEC آشنا بشید چون نظرم این هست که دونستن تاریخچه‌ی هر چیزی ما رو در یافتن نیازها و ایده ی اصلی که منجر به ایجاد اون مفهوم شده و هم چنین درک درست عملکردش کمک میکنه.
***
زمانی که مفهوم اینترنت به گستردگی حال حاضر نبود، سیستم ها برای برقراری ارتباط با یکدیگر، مستقیما از IP بهره می گرفتند. پس از چندی تصمیم بر آن شد که سیستم ها با نام همدیگر را فرابخوانند. به همین جهت باید از مکانیزمی استفاده می شد که برای سیستم مشخص می گردید که IP متناظر با هر نام چیست. این مکانیزم استفاده از فایلی با نام host بود که در آن IP متناظر با هر نام درج می گردید و باید به هر سیستمی که قصد ارتباط با سایر سیستم ها با نام را داشت منتقل می شد. اما با گسترده تر شدن دنیای اینترنت و اضافه شدن میلیون ها Host به این ساختار، استفاده از فایل host و انتقال آن به هر سیستم عملا غیرممکن شد.
همین عامل سبب معرفی سرویسی با نام Domain Name Service (DNS)گردید. این سرویس طی دو RFC با شماره های 882(بررسی مشکلاتی که سبب ایجاد این سرویس گردید) و 883(بررسی مشخصات و ویژگی های عملکردی DNS) در سال 1983 معرفی شد.
نحوه ی عملکرد DNS در حالت نرمال:
DNS یک دیتابیس توزیع شده، سلسه مراتبی و داینامیک است که وظیفه ی آن نگاشت اطلاعاتی چون hostname، آدرس IP، رکوردهای text، اطلاعات تبادل mail (یا همان رکورد MX)، اطلاعات name server ها (NS record) و هم چنین اطلاعات کلید امنیتی به یکدیگر می باشد که هر کدام از این اطلاعات توسط یک Resource Record یا اصطلاحا RRمشخص می شوند.
اطلاعات مشخص شده در RR ها در zone های مختلف گروهبندی شده و داخل یک DNS server محلی نگهداری می شوند. این DNS سرور محلی می تواند از طریق معماری توزیع شده ی DNS، به صورت جهانی نیز در دسترس قرار گیرد. DNS هم میتواند از UDP برای انتقال اطلاعات خود بهره گیرد و هم TCP و به صورت پیش فرض از destination port 53 استفاده میکند.
آدرس های DNS از چندین label ساخته شده اند که هر label مشخص کننده ی سلسله مراتبی است که به ترتیب باید به سراغ آن ها رفت. این label ها از راست به چپ بررسی می شوند. به عنوان مثال آدرس .www.example.com دارای چهار label می باشد: “www“ که در این سلسله مراتب leaf محسوب می شود؛ “example” که یک دامنه است؛ “com“ که یک TLDیا Top Level Domain می باشد و نهایتا “.”که نشان دهنده ی Root Serverاست.
زمانی که در مرورگر خود آدرس www.example.com را وارد می کنید، در اولین گام سیستم عامل Cache خود را بررسی می کند تا شاید آدرس IP متناظر با آن را بیابد. در صورتی که هیچ رکوردی پیدا نکرد، recursive query ای را به سمت Recursive Resolver ارسال می کند.
در DNS از دو نوع query استفاده می شود: recursiveو iterative. تفاوت این دو query در آن است که:
recursive query حتما باید با ارسال یک response پاسخ داده شود
iterative queryنیازی به دریافت response یا پاسخ ندارد.
منظور از Recursive resolver می تواند به عنوان مثال DNS سروری که ISP برای شما فراهم کرده باشد و یا هر name server دیگری. Recursive Resolver در واقع از سایر DNS سرورهایی که می توانند به سوال آن در رابطه با IP آدرس www.example.com پاسخ دهند، آگاهی دارد. Recursive Resolver ابتدا با بررسی Cache خود اطمینان حاصل می کند که از آدرس IP آن Host اطلاع دارد یا نه. اگر نداشته باشد با بررسی label های آدرس .www.example.com از چپ به راست (اولین برچسب . می باشد) متوجه می شود که اولین مکانی که برای پیدا کردن آدرس IP مربوطه باید به سراغ آن برود Root Server است.
در حال حاضر سیزده Root Server در سراسر دنیا وجود دارد که در بردارنده ی اطلاعات DNS مربوط به Top Level Domain ها (TLD) می باشند. (لازم به ذکر است که ایران نیز یکی از میزبانان K.root-servers.net می باشد) TLD ها در واقع دامنه هایی چون .com، .org و … هستند. بنابراین Recursive Resolver با ارسال یک iterative query از Root Server در رابطه به com. سوال می پرسد و Root Server نیز در پاسخ، برای آن آدرس IP مربوط به TLD .com را ارسال می کند.
در گام بعد Recursive Resolver یک iterative request برای TLD ای که آدرس IP آن را از Root Server دریافت نمود، ارسال کرده و در رابطه با example.com می پرسد. TLDها، DNS Server هایی هستن که اطلاعات DNS مربوط به زیردامنه های خود را نگهداری می کنند (در اینجا example). زمانی که TLD درخواست را دریافت می کند آدرس IP مربوط به example.com را برای Recursive Resolver مربوطه ارسال می نماید.
در مرحله ی بعد Recursive Resolver با ارسال یک iterative query برای example.com آدرس IP متعلق به رکورد www.example.com را خواستار می شود. example.com نیز با ارسال آدرس IP مربوط به رکورد www.example.com به این query پاسخ میدهد. نهایتا Recursive Resolver که اکنون آدرس IP مربوط به www.example.com را یافته آن را برای سیستم شما ارسال کرده و صفحه ی مربوط به این آدرس در مرورگر شما باز می شود (البته با چشم پوشی از چند مرحله ی دیگر که بعد از این مراحل رخ می دهند و ارتباطی با DNS ندارند). تمام این اتفاقات در کم تر از چند ثانیه رخ می دهند. تصویر زیر نمایانگر مراحلی است که شرح داده شد:
