چرا یک رکورد SRV فقط به کلاینتی کمک می‌کند که خودش آن را جستجو می‌کند

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

رکوردی که هیچ‌کس جستجو نمی‌کند نمی‌تواند به کسی کمک کند

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

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

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

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

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

برچسبی را که کلاینت واقعاً می‌فرستد پیدا کنید

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

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

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

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

هدف نیز باید وجود داشته باشد

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

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

کشف، احراز هویت نیست

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

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