لماذا لا يفيد سجل 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 الاختيار بين الأهداف، وقراءتها كآلية تفويض هي الطريق الذي يحوّل سجلًا مفيدًا إلى افتراض أمني. انشر عن قصد، واذكر التسمية في وثائقك، وتعامل مع العميل باعتباره المكوّن الذي يقرر ما إذا كان أي من ذلك مهمًا.