نقش فانوس دریایی در Nebula کار زیادی انجام می‌دهد که مردم آن را خودکار می‌پندارند، و پاسخ دادن به DNS یکی از آن‌ها نیست. سرویس‌دهی نام‌ها یک شنونده اختیاری است که خاموش آغاز می‌شود، و به همین دلیل میزبانی که درون overlay نام‌ها را خوب حل می‌کند ممکن است هیچ راهی برای حل لپ‌تاپ یک همکار نداشته باشد. پیش از روشن کردنش، تصمیم بگیرید چه کسی باید به آن برسد و به کدام نوع رکورد حاضرید پاسخ دهید، چون این دو پاسخ تفاوت دارند.

شنونده اختیاری است و به‌طور پیش‌فرض خاموش است

کشف و DNS دو سرویس جداگانه‌اند. فانوس به همتایان کمک می‌کند یکدیگر را پیدا کنند و می‌تواند افزون بر آن به پرسش‌های نام درباره میزبان‌هایی که می‌شناسد پاسخ دهد، اما آن بخش دوم باید صراحتاً در پیکربندی روشن شود.

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

رکوردهای A و TXT مخاطب یکسانی ندارند

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

QueryWhat it returnsWho can reach it
A record for a host nameThat host Nebula IPAny host that can reach the listener, overlay or not
TXT for a host IPCertificate informationOnly over the Nebula network

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

فقط درباره میزبان‌های خود فانوس پاسخ می‌دهد

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

وقتی نامی شکست می‌خورد که هیچ ارتباطی با overlay ندارد، ناحیه و حل‌کننده‌ای را بیابید که واقعاً مالک آن هستند. آمیختن یک حل‌کننده overlay در پیکربندی عمومی DNS یک میزبان شکست‌هایی می‌سازد که تصادفی به نظر می‌رسند، چون برخی نام‌ها حل می‌شوند و به بقیه هیچ چیز پاسخ نمی‌دهد.

به نقطه ورود bootstrap هم توجه کنید. نام میزبانی که برای رسیدن به نخستین فانوس استفاده می‌شود باید پیش از آنکه کشف بتواند به آن وابسته شود از مسیری معمولی حل شود، بنابراین مسئله مرغ و تخم‌مرغ اینجا دقیقاً شبیه یک overlay خراب به نظر می‌رسد. حتی به همان شکل هم گزارش می‌دهد: همتایی که هرگز بالا نمی‌آید و هیچ دلیل آشکاری هم نیست. پیش از دست زدن به گواهی‌ها حل نام را بررسی کنید، چون این ترتیب کسانی را می‌گیرد که از نیمه سخت‌تر شروع کرده‌اند.

نشانی اتصال را بررسی کنید، سپس از بیرون آزمایش کنید

lighthouse.dns.host و lighthouse.dns.port تعیین می‌کنند سرویس اختیاری کجا گوش می‌دهد. این مقادیر را در کنار دیوار آتش میزبان و سیاست شبکه بازبینی کنید، چون نشانی اتصال بیانیه قصد است و نه به‌خودی‌خود یک کنترل امنیتی.

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

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

آن را آگاهانه آشکار کنید

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

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

مقالات مرتبط