آشنایی با مفهوم نود شبکه و نام‌گذاری‌ها

آدرس MAC در ظاهر شناسه‌ای ثابت برای هر کارت شبکه است، اما در چند سال اخیر این فرض تغییر کرده است. سیستم‌عامل‌های مدرن موبایل و رایانه می‌توانند برای هر شبکه بی‌سیم آدرس تصادفی بسازند.

نتیجه این است که یک نود واحد ممکن است در شبکه‌های مختلف با هویت‌های متفاوت دیده شود و مدیر شبکه نتواند به آدرس سخت‌افزاری تکیه کند.

آدرس MAC شش بایتی است. سه بایت نخست شناسه سازنده (OUI) نام دارد و سه بایت بعدی را سازنده به هر کارت اختصاص می‌دهد. در بایت اول بیتی به نام «محلی مدیریت‌شده» وجود دارد که مشخص می‌کند آدرس را سازنده داده یا نرم‌افزار ساخته است.

آدرس‌های تصادفی همیشه این بیت را روشن دارند و به همین دلیل قابل تشخیص‌اند.

برای تشخیص سریع به رقم دوم آدرس نگاه کنید. اگر یکی از ارقام 2، 6، A یا E باشد، آدرس محلی مدیریت‌شده است. مثلاً آدرسی که با 3A شروع می‌شود تصادفی است، در حالی که آدرسی که با 00 یا 3C آغاز می‌شود معمولاً همان آدرس واقعی سخت‌افزار است.

انگیزه اصلی این ویژگی حریم خصوصی است. وقتی دستگاه دنبال شبکه‌های شناخته‌شده می‌گردد، آدرس ثابتش در محیط‌هایی مانند فرودگاه یا مرکز خرید قابل ردیابی است.

اپل از iOS 14 قابلیت آدرس خصوصی Wi-Fi را عرضه کرد، اندروید از نسخه ۱۰ و ویندوز ۱۰ نیز گزینه آدرس سخت‌افزاری تصادفی را اضافه کردند.

این تغییر برای مدیران شبکه چالش ایجاد می‌کند. فیلتر MAC، رزرو آدرس در DHCP و گزارش‌های مصرف بر پایه آدرس ثابت برای دستگاه‌های شخصی دیگر قابل اتکا نیستند. در بیشتر پیاده‌سازی‌ها آدرس تصادفی برای هر SSID ثابت می‌ماند، اما با فراموش کردن شبکه یا تغییر تنظیمات ممکن است عوض شود.

راهکار عملی این است که شناسایی دستگاه‌های کاری را به گواهی دیجیتال و احراز هویت 802.1X منتقل کنید. برای دستگاه‌های ثابت مانند پرینتر یا دوربین که آدرس تصادفی ندارند، رزرو DHCP همچنان کارآمد است. در شبکه مهمان هم سیاست‌ها را بر اساس نقش کاربر بنویسید، نه آدرس سخت‌افزاری.

هنگام مستندسازی نودها ذکر کنید که آدرس ثبت‌شده سخت‌افزاری است یا تصادفی. این یادداشت ساده در عیب‌یابی زمان زیادی صرفه‌جویی می‌کند، چون همان نود ممکن است در لاگ‌های روز بعد با آدرسی دیگر ظاهر شود.

در مستندات رسمی IPv6، واژه «نود» تعریف دقیقی دارد. طبق RFC 8200، نود هر دستگاهی است که IPv6 را پیاده‌سازی کرده باشد. همین تعریف باعث می‌شود لپ‌تاپ، سرور، روتر و حتی یک سنسور کوچک همگی نود حساب شوند، به شرط آنکه پشته IPv6 داشته باشند.

استاندارد نودها را به دو دسته تقسیم می‌کند. روتر نودی است که بسته‌هایی را که مقصدشان خودش نیست فوروارد می‌کند. هاست هر نودی است که روتر نباشد. این تفکیک به نوع سخت‌افزار ربطی ندارد و فقط به رفتار نرم‌افزاری نود بستگی دارد.

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

یک ویژگی مهم IPv6 این است که هر رابط شبکه همزمان چند آدرس دارد. آدرس لینک‌محلی با پیشوند fe80::/10 اجباری است و بدون نیاز به تنظیم ساخته می‌شود. علاوه بر آن، رابط می‌تواند یک یا چند آدرس سراسری داشته باشد و در گروه‌های چندپخشی مانند «همه نودها» (ff02::1) عضو شود.

چون یک نود چند آدرس دارد و آدرس‌ها با تغییر پیشوند ISP عوض می‌شوند، نام‌گذاری بر پایه آدرس شکننده است. بهتر است نود را با نام DNS و رکورد AAAA معرفی کنید و آدرس را فقط یک ویژگی قابل تغییر بدانید.

به جای ARP نیز پروتکل Neighbor Discovery وظیفه کشف همسایه‌ها را بر عهده دارد.

تفکیک هاست و روتر از نظر امنیتی هم اهمیت دارد. هاست‌ها نباید بدون اجازه فوروارد کنند و پیام‌های Router Advertisement را فقط از روترهای مجاز بپذیرند. در شبکه‌های کاری، ویژگی RA Guard روی سوئیچ جلوی روترهای جعلی را می‌گیرد که می‌توانند ترافیک نودها را منحرف کنند.

نام کامل یک نود در DNS، یعنی FQDN، از چند برچسب تشکیل می‌شود که با نقطه جدا شده‌اند. برای مثال در نام web01.dc1.example.com، عبارت web01 نام میزبان و بقیه نام دامنه است. نقطه پایانی نام که معمولاً نوشته نمی‌شود، ریشه DNS را نشان می‌دهد و نام را مطلق می‌کند.

هر برچسب حداکثر ۶۳ کاراکتر و کل نام در شکل متنی حداکثر ۲۵۳ کاراکتر می‌تواند باشد. کاراکترهای مجاز در نام میزبان سنتی فقط حروف انگلیسی، ارقام و خط تیره‌اند. خط تیره نباید در ابتدا یا انتهای برچسب بیاید.

DNS به بزرگی و کوچکی حروف حساس نیست، پس Web01 و web01 یک نام‌اند.

محدودیت قدیمی‌تری هم در محیط‌های ویندوزی دیده می‌شود. نام NetBIOS حداکثر ۱۵ کاراکتر است و بسیاری از سازمان‌ها هنوز نام رایانه را به همین طول محدود می‌کنند تا با نرم‌افزارهای قدیمی سازگار بماند. اگر چنین سیستم‌هایی ندارید، می‌توانید نام‌های بلندتر انتخاب کنید، اما کوتاه و خوانا بودن همچنان مزیت است.

انتخاب پسوند شبکه داخلی اشتباه رایج دیگری است. پسوند local در پروتکل mDNS برای کشف خودکار دستگاه‌ها رزرو شده و استفاده از آن برای DNS سازمانی مشکلات حل‌نشدن نام ایجاد می‌کند. ابداع پسوند دلخواه مانند corp هم خطر برخورد با دامنه‌های واقعی را دارد.

بهترین روش، استفاده از زیردامنه‌ای از دامنه‌ای است که مالکش هستید، مانند internal.example.com. ICANN نیز در سال ۲۰۲۴ پسوند internal را برای کاربردهای خصوصی کنار گذاشت تا هیچ‌گاه به‌عنوان دامنه سطح بالای عمومی واگذار نشود.

در عمل از search domain استفاده می‌شود تا کاربر بتواند فقط web01 را تایپ کند و سیستم پسوند را خودکار اضافه کند. این راحتی گاهی نتیجه‌های غیرمنتظره می‌دهد، چون نام کوتاه ممکن است در چند دامنه وجود داشته باشد.

در اسکریپت‌ها و تنظیمات سرویس‌ها همیشه FQDN کامل را بنویسید تا رفتار قابل پیش‌بینی بماند.

در Kubernetes هر Node یک شیء ثبت‌شده در API است و هویت آن با نامش مشخص می‌شود. این نام باید یک DNS subdomain معتبر باشد: حروف کوچک انگلیسی، ارقام، خط تیره و نقطه، با حداکثر ۲۵۳ کاراکتر.

در بیشتر نصب‌ها kubelet هنگام عضویت، نام میزبان ماشین را به‌عنوان نام Node ثبت می‌کند.

نام Node پس از ثبت قابل تغییر نیست. اگر نام میزبان ماشین بعداً عوض شود، kubelet آن را یک Node جدید می‌بیند و Node قدیمی در وضعیت NotReady باقی می‌ماند.

به همین دلیل پیش از افزودن ماشین به خوشه، نام میزبان را نهایی کنید و آن را یکتا و بدون ابهام انتخاب کنید.

در محیط‌های ابری نام‌ها معمولاً خودکار و شبیه ip-10-0-1-5.ec2.internal تولید می‌شوند. این نام‌ها برای انسان معنایی ندارند و با خودکارمقیاس‌پذیری ممکن است هر روز Node تازه‌ای با نام تازه بسازند. در چنین خوشه‌هایی نام را مثل شناسه موقت ببینید و مفهوم را در برچسب‌ها ثبت کنید.

برچسب‌ها (Labels) مهم‌ترین ابزار هویت‌دهی هستند. برچسب kubernetes.io/hostname نام میزبان را نگه می‌دارد و topology.kubernetes.io/zone منطقه دسترس‌پذیری را مشخص می‌کند. برچسب‌های دلخواه مانند disk=ssd یا team=payments هم می‌توانند با nodeSelector و affinity به زمان‌بند بگویند Podها را کجا اجرا کند.

Taint ها مکمل برچسب‌اند. Taint روی Node مانع اجرای Podهایی می‌شود که Toleration مربوطه را ندارند. Nodeهای کنترل‌پلین معمولاً به همین روش از بارهای عادی محافظت می‌شوند. استفاده از Taint برای Nodeهای گران‌قیمت مانند GPU نیز از مصرف بی‌هدف آن‌ها جلوگیری می‌کند.

یک قرارداد ساده برای سازمان‌ها این است که نام را کوتاه و فنی نگه دارند و اطلاعات مدیریتی مثل محیط، تیم و نوع سخت‌افزار را در برچسب‌ها بنویسند. با این کار فیلتر کردن در kubectl و داشبوردهای مانیتورینگ ساده می‌شود و تغییر ساختار سازمانی نیازی به تغییر نام ندارد.

در شبکه‌های کوچک، تنظیم دستی آدرس هر نود ممکن است کافی باشد، اما با رشد تعداد دستگاه‌ها خطاها زیاد می‌شود. دو نود با آدرس یکسان باعث قطعی‌های متناوب و عیب‌یابی دشوار می‌شوند.

به همین دلیل بیشتر سازمان‌ها تخصیص آدرس را به DHCP می‌سپارند و فقط تعداد محدودی نود حیاتی را به‌صورت ثابت تنظیم می‌کنند.

DHCP آدرس را برای مدت مشخصی (lease) به نود قرض می‌دهد. نود می‌تواند در درخواست خود نام میزبانش را هم ارسال کند. در قابلیت رزرو، سرور بر اساس شناسه کلاینت همیشه همان آدرس را به همان نود می‌دهد.

این روش برای پرینتر و سرور مناسب‌تر از تنظیم دستی است، چون مدیریت در یک نقطه انجام می‌شود.

DDNS حلقه بعدی است. وقتی سرور DHCP پس از تخصیص آدرس، رکوردهای A یا AAAA و PTR را در DNS به‌روزرسانی کند، نود بدون دخالت انسان با نام قابل دسترس می‌شود.

باید دقت کنید که فقط سرور DHCP مجاز به تغییر رکوردها باشد، وگرنه یک دستگاه مخرب می‌تواند نام نودهای مهم را بدزدد.

هنگامی که تعداد زیرشبکه‌ها زیاد می‌شود، صفحه‌گسترده دیگر پاسخگو نیست. ابزارهای IPAM مانند NetBox یا phpIPAM فهرست آدرس‌ها، زیرشبکه‌ها، VLANها و مالک هر نود را در یک منبع واحد نگه می‌دارند. این منبع می‌تواند به‌عنوان مرجع حقیقت برای اسکریپت‌های خودکارسازی استفاده شود.

برنامه‌ریزی محدوده‌ها از همان ابتدا اهمیت دارد. برای مثال می‌توانید بخشی از هر زیرشبکه را به تجهیزات زیرساختی، بخشی به سرورها و بخشی به استخر DHCP اختصاص دهید.

با این الگو، فقط از دیدن آدرس یک نود می‌توان نقش تقریبی آن را حدس زد و فیلتر کردن در فایروال ساده‌تر می‌شود.

در نهایت هر تغییر در IPAM باید ثبت و قابل پیگیری باشد. وقتی نودی برچیده می‌شود، آدرس و رکوردهای DNS آن را هم آزاد کنید. رکوردهای رهاشده یکی از شایع‌ترین دلایل ارجاع به سرورهای قدیمی و نشت اطلاعات درباره ساختار داخلی شبکه هستند.

در شبکه‌های بلاکچین، همه نودها وظیفه یکسانی ندارند و انتخاب نوع نود به مصالحه میان منابع مصرفی و میزان اعتماد بستگی دارد. نود کامل (Full Node) تمام بلوک‌ها را دانلود و تک‌تک تراکنش‌ها را طبق قوانین شبکه بررسی می‌کند. این نود برای درستی داده‌ها به هیچ طرف دیگری اعتماد نمی‌کند.

بهای این استقلال، منابع سخت‌افزاری است. زنجیره بیت‌کوین صدها گیگابایت فضا اشغال می‌کند و همگام‌سازی اولیه ممکن است روزها طول بکشد. برای کاهش حجم می‌توان از نود هرس‌شده (Pruned Node) استفاده کرد که پس از اعتبارسنجی، بلوک‌های قدیمی را حذف می‌کند ولی همچنان قوانین را اعمال می‌کند.

نود سبک (Light Node) راه دیگری می‌رود. این نود فقط سرایند بلوک‌ها را دریافت می‌کند، که هر کدام حدود ۸۰ بایت است، و برای اطمینان از وجود یک تراکنش از اثبات درخت مرکل (Merkle Proof) کمک می‌گیرد.

کیف پول‌های موبایلی معمولاً به همین روش کار می‌کنند چون فضا و باتری محدودی دارند.

نود سبک اما بخشی از اعتماد را به نودهای کامل همسایه واگذار می‌کند. اگر همه همسایگان آن مخرب باشند، ممکن است اطلاعات ناقص یا گمراه‌کننده دریافت کند. بنابراین نود سبک برای پرداخت‌های روزمره مناسب است، ولی کسب‌وکاری که مبالغ بزرگ دریافت می‌کند معمولاً نود کامل شخصی راه‌اندازی می‌کند.

نود آرشیوی (Archive Node) در اتریوم نمونه دیگری است. این نود علاوه بر بلوک‌ها، وضعیت تاریخی تمام حساب‌ها را در هر بلوک نگه می‌دارد و فضای آن به چند ترابایت می‌رسد. تحلیلگران و ارائه‌دهندگان API از آن برای پرس‌وجوهای تاریخی استفاده می‌کنند، نه کاربران عادی.

در شبکه‌های اثبات سهام، نود اعتبارسنج (Validator) نقش ویژه‌ای دارد. این نود در تأیید بلوک‌ها شرکت می‌کند و در ازای آن پاداش می‌گیرد. در اتریوم، اجرای یک اعتبارسنج مستلزم سپرده ۳۲ اتر است و رفتار نادرست می‌تواند به جریمه (Slashing) منجر شود.

بنابراین این نود علاوه بر زیرساخت پایدار، نیازمند مدیریت دقیق کلید است.