نام DNS خصوصی یا فقط یک IP؟ پیش از اشتراک‌گذاری تصمیم بگیرید

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

شرط یکم: کلاینت‌ها چه مسیر resolver دارند؟

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

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

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

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

شرط دوم: سرویس چه منبعی دریافت می‌کند؟

قواعد پذیرش بر پایه نشانی‌ها نوشته می‌شوند، پس پرسش سودمند این است که سرویس پس از مسیریابی و ترجمه کدام نشانی را می‌بیند. برای یک سرویس نمونه در 10.20.30.40، کلاینت‌های دفتر از 10.20.30.0/24 می‌آیند و کلاینت‌های راه دور از مجموعه‌ای جدا مانند 10.99.0.0/24.

اگر دروازه‌ای مجموعه راه دور را ترجمه کند، سرویس مترجم را می‌بیند، و قاعده‌ای که برای 10.99.0.0/24 نوشته شده مطابقت نخواهد کرد.

این را از سمت سرویس بخوانید نه از سمت کلاینت. گزارش شنونده یا ضبط بسته در میزبان سرویس منبعی را نشان می‌دهد که واقعاً رسیده است؛ نشانی خود کلاینت تنها گمانی درباره چیزی است که از مسیر جان به در برده است.

شرط سوم: نام به سرویس بسته است یا به میزبان؟

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

برای یک سرویس داخلی واحد، یک رکورد مستقیم معمولاً خوب است و استدلال درباره‌اش ساده‌تر.

برای هر چیزی که جایگزین، بازسازی یا مقیاس‌بندی خواهد شد، یک جبهه پایدار ارزش پیکربندی اضافه را دارد. آزمون ساده است: اگر می‌توانید بک‌اند را بدون گفتن به کاربران جایگزین کنید، نام به سرویس بسته است؛ اگر نمی‌توانید، به میزبان بسته است.

دو تصمیم را جداگانه بیازمایید

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

curl -sv --max-time 5 https://files.corp.example/health

سپس یک بار منبعی ممنوع را بیازمایید و نتیجه را ثبت کنید.

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

کجا تصمیم معمولاً اشتباه می‌شود

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

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

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