عمومی، خصوصی، ایستا و اختصاصی ویژگی‌های مستقل آدرس هستند. یک نقشه استقرار بسازید که مسیریابی، فایروال‌ها، DNS رو به جلو، DNS معکوس و TLS را نیز پوشش دهد و هر تنظیم را با طرفی که آن را کنترل می‌کند بررسی کنید.
ویژگی‌های آدرس به پرسش‌های متفاوتی پاسخ می‌دهند
عمومی و خصوصی توصیف می‌کنند که یک آدرس برای مسیریابی به کجا در نظر گرفته شده است. ایستا و پویا توصیف می‌کنند که یک تخصیص در طول زمان چگونه رفتار می‌کند. اختصاصی و اشتراکی توصیف می‌کنند که یک آدرس درون یک سرویس چگونه استفاده یا تخصیص می‌یابد. این‌ها ویژگی‌های جداگانه‌اند: یک آدرس عمومی پایدار ممکن است به بسیاری از سایت‌ها خدمت کند و یک آدرس خصوصی می‌تواند به‌صورت پویا درون یک شبکه کنترل‌شده تخصیص یابد.
نقش هر آدرس را در استقرار بنویسید: نقطه ورود عمومی، پایگاه داده داخلی، مسیر مدیریت یا اتصال خروجی. سپس مشخص کنید چه کسی آن را تخصیص می‌دهد و چه چیزی می‌تواند تغییر کند. این کار مانع می‌شود که کار پیکربندی به فرضیاتی مانند «اختصاصی یعنی برای همیشه ثابت» یا «عمومی یعنی سرویس قابل دسترسی است» وابسته شود. دسترسی‌پذیری همچنین به مسیریابی، فایروال‌ها و شنونده برنامه بستگی دارد.
آدرس‌دهی خصوصی هنوز به مسیریابی و کنترل دسترسی نیاز دارد
RFC 1918 محدوده‌های IPv4 یعنی 10.0.0.0/8، 172.16.0.0/12 و 192.168.0.0/16 را برای شبکه‌های خصوصی رزرو می‌کند. آدرس‌های آن‌ها مقصدهای عمومی یکتای جهانی نیستند. یک شبکه ممکن است آدرس‌های خصوصی را برای اتصالات خروجی ترجمه کند یا شبکه‌های خصوصی را از طریق مسیرهای صریح متصل کند. یک سرویس ورودی پشت ترجمه به یک روش انتشار عامدانه نیاز دارد؛ تغییر تنها یک رکورد DNS آن مسیر را ایجاد نمی‌کند.
IPv6 انواع و دامنه‌های آدرس خود را دارد، از جمله آدرس‌دهی link-local و آدرس‌های unicast قابل مسیریابی جهانی. آن را جداگانه بررسی کنید، نه اینکه فرض کنید یک قاعده فایروال یا ترجمه IPv4 IPv6 را پوشش می‌دهد. یک آدرس خصوصی مکانیزم احراز هویت نیست و یک آدرس عمومی IPv6 دلیلی برای افشای هر سرویس نیست. دسترسی را از هر شبکه مرتبط آزمایش کنید و مدیریت را در مرز مناسب محدود کنید.
نام‌های پایدار و آدرس‌های پایدار به هم مرتبطند
DHCP پیکربندی آدرس را از طریق یک پروتکل تخصیص می‌دهد و می‌تواند از اجاره‌ها استفاده کند. یک آدرس تخصیص‌یافته پویا ممکن است مدتی بدون تغییر بماند؛ این پایداری آن را به یک تضمین قراردادی تبدیل نمی‌کند. وقتی برنامه‌ای به یک آدرس پایدار وابسته است، سیاست تخصیص و تغییر ارائه‌دهنده را بررسی کنید، نه اینکه آن را از اتصال دیروز استنباط کنید.
DNS پویا می‌تواند پس از تغییر آدرس یک نام را به‌روزرسانی کند، اما کلاینت‌ها ممکن است هنوز پاسخ قبلی را در حافظه نهان داشته باشند. همچنین نمی‌تواند بر شنونده غیرقابل دسترس، مسیر ورودی ناموجود یا ترجمه آدرس سطح اپراتور غلبه کند. زمانی از آن استفاده کنید که شبکه اتصال را مجاز می‌داند و برنامه تأخیرهای به‌روزرسانی را تحمل می‌کند. برای یک استقرار میزبانی‌شده، چرخه عمر آدرس مورد نظر را پیش از ساخت allowlistها یا یکپارچه‌سازی‌های خارجی حول آن مستند کنید.
| ویژگی | چه چیزی را تأیید کنیم | فرض اشتباه رایج |
|---|---|---|
| عمومی یا خصوصی | دامنه مسیریابی و مسیر دسترسی | یک آدرس به‌تنهایی سرویس را قابل دسترسی می‌کند |
| ایستا یا پویا | سیاست تخصیص و تغییر | یک اجاره بدون تغییر دائمی است |
| اختصاصی یا اشتراکی | تخصیص و استفاده مجاز | یک آدرس اختصاصی هویت ناشناس فراهم می‌کند |
| IPv4 یا IPv6 | هم پیکربندی مسیریابی و هم فایروال | تنظیمات یک پروتکل دیگری را پوشش می‌دهد |
DNS رو به جلو و DNS معکوس مالکان متفاوتی دارند
DNS رو به جلو نام‌ها را به داده‌هایی مانند رکوردهای آدرس A و AAAA نگاشت می‌کند. DNS معکوس از یک فضای نام مرتبط با آدرس و رکوردهای PTR برای مرتبط کردن یک آدرس با یک نام استفاده می‌کند. سازمانی که ناحیه DNS رو به جلو را کنترل می‌کند لزوماً همان سازمانی نیست که DNS معکوس را برای محدوده آدرس کنترل می‌کند. پیش از وعده دادن یک نام معکوس، مسیر پیکربندی درست را به دست آورید.
رکورد را از طریق resolver مناسب بررسی کنید و نتیجه را ثبت کنید. برای یک PTR که قصد دارد میزبان را شناسایی کند، همچنین بررسی کنید آیا رکورد رو به جلو متناظر به آدرس مورد انتظار اشاره می‌کند. DNS معکوس می‌تواند از شناسایی عملیاتی و برخی بررسی‌های سیستم ایمیل پشتیبانی کند، اما یک برنامه را احراز هویت نمی‌کند یا تحویل پیام را تضمین نمی‌کند. ارسال ایمیل همچنین به بررسی دامنه، اعتبار و احراز هویت خود نیاز دارد.
برای هر سایت HTTPS یک آدرس اختصاصی لازم نیست
مسیریابی میزبان HTTP و افزونه Server Name Indication در TLS به کلاینت‌ها و سرورهای پشتیبانی‌شده اجازه می‌دهد یک سایت یا گواهی را با نام انتخاب کنند. بنابراین چندین سایت HTTPS می‌توانند از یک آدرس استفاده کنند بدون اینکه برای هر دامنه یک آدرس عمومی لازم باشد. پیکربندی واقعی میزبانی و کلاینت‌های مورد نیاز تعیین می‌کنند که آیا این ترتیب مناسب است.
تنها زمانی یک آدرس اضافی انتخاب کنید که یک نیاز مستند آن را طلب کند، مانند جداسازی شبکه پشتیبانی‌شده یا یک سیستم خارجی که نقطه پایانی متمایز انتظار دارد. یک آدرس مصونیت از مشکلات اعتبار فراهم نمی‌کند یا شخص اداره‌کننده سرویس را شناسایی نمی‌کند. گواهی‌ها، مسیریابی نام میزبان و تخصیص آدرس را به‌عنوان بررسی‌های جداگانه نگه دارید. گواهی ارائه‌شده را از طریق نام میزبانی که کاربران واقعاً بازدید خواهند کرد بررسی کنید.
پیش از تغییر رکوردها از یک نقشه استقرار استفاده کنید
یک نقشه کوچک شامل هر نام میزبان، رکورد آدرس، شنونده، مسیر فایروال و طرف مسئول بسازید. مدیریت، پشتیبان‌گیری و هر allowlist خروجی را بگنجانید. بررسی کنید آیا پیکربندی SwissOctet گزینه آدرس مورد نیاز شما را فهرست می‌کند و پیش از تکیه بر آن درباره کنترل DNS معکوس بپرسید. گزینه‌های فهرست را به‌عنوان یک تخصیص زنده که قبلاً فراهم شده ارائه نکنید.
در طول یک جابه‌جایی، برنامه مقصد و تنظیمات TLS را پیش از هدایت کاربران به آنجا آماده کنید. حافظه‌های نهان DNS را در نظر بگیرید و یک مسیر بازیابی عملی نگه دارید. تفکیک رو به جلو، دسترسی‌پذیری واقعی برنامه و نام معکوس مورد انتظار را جداگانه بررسی کنید. نقشه یافتن خرابی‌ها را آسان‌تر می‌کند زیرا یک رکورد اشتباه، یک پورت بسته و یک گواهی نامنطبق مشکلات متفاوتی با مالکان متفاوت هستند.
چک‌لیست عملی شما.
- نقش آدرس، تخصیص و مالکیت را نقشه‌برداری کنید.
- IPv4 و IPv6 را جداگانه بررسی کنید.
- پیش از تکیه بر DNS، مسیریابی ورودی را بررسی کنید.
- مشخص کنید چه کسی رکوردهای PTR را کنترل می‌کند.
- نام میزبان، گواهی و برنامه را با هم آزمایش کنید.
جزئیاتی که اهمیت دارند.
آیا IP اختصاصی یک سرویس را ناشناس می‌کند؟+
خیر. این یک ترتیب تخصیص یا استفاده را توصیف می‌کند، نه هویت یا تضمین حریم خصوصی. حساب‌ها، ترافیک و داده‌های برنامه پیامدهای جداگانه دارند.
آیا می‌توانم رکوردهای PTR را از پنل DNS دامنه‌ام تنظیم کنم؟+
تنها اگر آن پنل ناحیه معکوس مرتبط را نیز کنترل کند. ارائه‌دهنده آدرس معمولاً آن ناحیه را کنترل می‌کند یا فرآیند درخواست جداگانه‌ای ارائه می‌دهد.
آیا هر دامنه HTTPS به آدرس خود نیاز دارد؟+
لزوماً نه. کلاینت‌ها و سرورهای پشتیبانی‌شده می‌توانند از مسیریابی مبتنی بر نام و TLS SNI استفاده کنند. میزبانی واقعی و نیازهای کلاینت را بررسی کنید.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- RFC 1918: تخصیص آدرس برای اینترنت‌های خصوصی www.rfc-editor.org
- RFC 2131: پروتکل پیکربندی میزبان پویا www.rfc-editor.org
- RFC 1035: پیاده‌سازی و مشخصات DNS www.rfc-editor.org
- RFC 4291: معماری آدرس‌دهی IPv6 www.rfc-editor.org
- RFC 6066: افزونه‌های TLS، شامل Server Name Indication www.rfc-editor.org
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.