عبارت‌هایی مثل 10.20.0.0/22 در طراحی VPC، نوشتن قانون Security Group، تعریف Pod CIDR در Kubernetes و تنظیم مسیرها در روتر مدام استفاده می‌شوند. برای کار با آن‌ها نیازی به حفظ‌کردن جدول نیست؛ یک قاعده‌ی ساده برای محاسبه‌ی تعداد میزبان و مرز بلوک‌ها کافی است. این راهنما آن قاعده را همراه با مثال‌های واقعی از VPC و Kubernetes و فهرستی از اشتباه‌های رایج ارائه می‌کند.
CIDR یعنی چه و عدد بعد از اسلش چیست؟
یک آدرس IPv4 چهار بایت (۳۲ بیت) است. CIDR با نوشتن /n مشخص می‌کند n بیت اول، بخش «شبکه» است و بقیه‌ی بیت‌ها برای شماره‌گذاری میزبان‌ها در همان شبکه‌اند. پس /24 یعنی سه بایت اول شبکه و یک بایت آخر مال میزبان‌ها؛ و /16 یعنی دو بایت اول شبکه.
همین عدد را می‌توان به شکل «ماسک زیرشبکه» هم نوشت: n بیت اول ۱ و بقیه ۰. مثلاً /24 برابر 255.255.255.0 و /22 برابر 255.255.252.0 است.
محاسبه‌ی تعداد میزبان در ذهن
بیت‌های میزبان 32 − n تا هستند، پس شبکه 2^(32−n) آدرس دارد. دو آدرس از آن‌ها برای کار شبکه رزرو است: آدرس شبکه (همهی بیت‌های میزبان صفر) و broadcast (همه یک). بنابراین:
usable_hosts = 2^(32 - n) - 2
/24 → 2^8 - 2 = 254
/22 → 2^10 - 2 = 1022
/16 → 2^16 - 2 = 65534جدول زیر پرکاربردترین پیشوندها را نشان می‌دهد:
| پیشوند | ماسک | کل آدرس | میزبان قابل‌استفاده |
|---|---|---|---|
| /8 | 255.0.0.0 | 16,777,216 | 16,777,214 |
| /16 | 255.255.0.0 | 65,536 | 65,534 |
| /20 | 255.255.240.0 | 4,096 | 4,094 |
| /22 | 255.255.252.0 | 1,024 | 1,022 |
| /24 | 255.255.255.0 | 256 | 254 |
| /26 | 255.255.255.192 | 64 | 62 |
| /27 | 255.255.255.224 | 32 | 30 |
| /28 | 255.255.255.240 | 16 | 14 |
| /29 | 255.255.255.248 | 8 | 6 |
| /30 | 255.255.255.252 | 4 | 2 |
| /31 | 255.255.255.254 | 2 | 2 (نقطه‌به‌نقطه) |
| /32 | 255.255.255.255 | 1 | 1 |
آدرس شبکه همیشه روی «مرز» قرار میگیرد
اندازهی هر بلوک توان ۲ است و شروع آن باید مضربی از اندازه‌اش باشد. مثلاً یک بلوک /26 (۶۴ آدرس) فقط می‌تواند از .0، .64، .128 یا .192 شروع شود. به همین دلیل 10.0.0.10/26 «آدرس شبکه» نیست؛ شبکه‌ای که این میزبان در آن است 10.0.0.0/26 است. بیشتر ابزارها و فایروال‌ها در این حالت خطا می‌دهند یا بی‌سروصدا رنج را «گرد» می‌کنند، که منبع اشتباه‌های گیج‌کننده است.
رنج‌های خصوصی که باید بشناسید
| رنج | اندازه | کاربرد معمول |
|---|---|---|
| 10.0.0.0/8 | ≈ 16.7M | شبکه‌های بزرگ سازمانی و VPC ابرها |
| 172.16.0.0/12 | ≈ 1M | شبکه‌ی پیش‌فرض Docker (172.17.0.0/16) در همین رنج است |
| 192.168.0.0/16 | ≈ 65K | شبکه‌های خانگی و آزمایشگاهی |
| 100.64.0.0/10 | ≈ 4M | CGNAT؛ فضای ویژه‌ی اپراتورها، نه شبکه‌ی خصوصی معمولی |
| 169.254.0.0/16 | 65K | Link-local؛ اگر این را روی یک کارت می‌بینید یعنی DHCP پاسخ نداده |
172.17.0.0/16) گاهی با شبکه‌ی شرکت همپوشانی پیدا می‌کند و دسترسی به بعضی سرورها را بدون علت آشکار قطع می‌کند. در این حالت در daemon.json مقدار default-address-pools را عوض کنید.تقسیم یک شبکه به بخش‌های نابرابر (VLSM)
فرض کنید شبکه‌ی 10.0.0.0/24 دارید و چهار بخش لازم است: ۱۰۰ سرور، ۵۰ دستگاه مدیریت، ۲۰ دستگاه Wi-Fi مهمان و یک لینک نقطه‌به‌نقطه بین دو روتر. روش درست این است که از بزرگ‌ترین بخش شروع کنید و هرکدام را در کوچک‌ترین بلوکی که جا می‌شود بگذارید:
| بخش | نیاز | بلوک | رنج |
|---|---|---|---|
| سرورها | 100 | /25 (126) | 10.0.0.0 – 10.0.0.127 |
| مدیریت | 50 | /26 (62) | 10.0.0.128 – 10.0.0.191 |
| Wi-Fi مهمان | 20 | /27 (30) | 10.0.0.192 – 10.0.0.223 |
| لینک روتر | 2 | /30 (2) | 10.0.0.224 – 10.0.0.227 |
اگر ترتیب را برعکس می‌کردید، مثلاً اول /30 و بعد /25 را می‌گذاشتید، بلوک /25 باید روی مرز .128 می‌رفت و فضایی که در میان می‌ماند بی‌استفاده می‌شد. ابزار زیر دقیقاً همین ترتیب‌دهی را برای شما انجام می‌دهد و اگر شبکه‌ی اصلی کوچک باشد هشدار می‌دهد.
در ابر و Kubernetes چه چیزی فرق می‌کند؟
- آدرس‌های رزرو‌شده: ابرهای عمومی در هر زیرشبکه چند آدرس را برای خودشان نگه می‌دارند (در AWS پنج آدرس). برای یک زیرشبکه‌ی
/28این یعنی فقط ۱۱ آدرس واقعاً قابل‌استفاده است. - VPC را بزرگ بگیرید. اندازهی VPC را بعداً به‌سختی می‌شود تغییر داد. یک
/16برای شروع معمولاً کافی و ارزان است، چون آدرس خصوصی هزینه ندارد. - Pod و Service CIDR در Kubernetes: این دو رنج با شبکه‌ی گره‌ها، شبکه‌ی شرکت و هم‌دیگر نباید همپوشانی داشته باشند. تغییر این رنج‌ها بعد از ساخت کلاستر دشوار و پرهزینه است.
- همپوشانی با VPN: قبل از وصل‌کردن دو شبکه (VPN، peering، Direct Connect) رنج‌ها را مقایسه کنید؛ دو شبکه‌ی همپوشان هرگز مسیریابی نمی‌شوند.
اشتباه‌های رایج
- فراموش‌کردن دو آدرس رزرو. «۲۰ سرور دارم، پس /27 (۳۲ آدرس) کافی است» درست است، اما «۳۰ سرور دارم، /27 کافی است» خیر؛ فقط ۳۰ میزبان قابل‌استفاده است و فضایی برای رشد نمی‌ماند.
- رشد را در نظر نگرفتن. اگر قرار است سال بعد دو برابر شوید، همین حالا یک پیشوند کوچک‌تر (بلوک بزرگ‌تر) بگیرید.
- همپوشانی ناخواسته. رنج‌ها را در یک جدول مرکزی (حتی یک فایل در Git) ثبت کنید.
- مبهم‌نوشتن رول‌های فایروال.
/32یعنی فقط یک میزبان و/0یعنی «همهی اینترنت»؛ تفاوت یک رقم می‌تواند یک رخنه باشد. - اشتباه گرفتن ماسک و wildcard. در ACLهای بعضی روترها (مثل Cisco) از wildcard mask استفاده می‌شود که معکوس ماسک است (
0.0.0.255به‌جای255.255.255.0).
/64 است و نیازی به صرفه‌جویی در آدرس نیست؛ دغدغه‌ی اصلی، طرح‌ریزی سلسله‌مراتب است نه تعداد میزبان.یک تمرین سریع
بدون ابزار حساب کنید: 172.16.40.0/21 از کجا تا کجاست؟ بلوک /21 یعنی ۲۰۴۸ آدرس، که در بایت سوم ۸ واحد را میگیرد (چون ۲۴ − ۲۱ = ۳ بیت از بایت سوم میزبان است). بایت سوم باید مضرب ۸ باشد؛ ۴۰ مضرب ۸ است، پس شبکه از 172.16.40.0 شروع و در 172.16.47.255 تمام می‌شود. حالا جوابتان را با ابزار بالا مقایسه کنید.
جمع‌بندی
سه نکته را به خاطر بسپارید: تعداد میزبان قابل‌استفاده 2^(32−n) − 2 است، بلوک‌ها همیشه روی مرز اندازهی خودشان قرار می‌گیرند، و رنج‌های شبکه باید پیش از ساخت زیرساخت ثبت و بررسی شوند. اگر روی Kubernetes کار می‌کنید، بعد از طراحی رنج‌ها سراغ نوشتن مانیفست‌ها بروید؛ و اگر مشکلی در رسیدن به یک سرویس دارید، چک‌لیست عیب‌یابی DNS و SSL ترتیب درست بررسی را نشان می‌دهد.