سجلات DNS
تسرد هذه الصفحة سجلات DNS المراد إنشاؤها لنشر DuoKey محلي. تُقسّم السجلات إلى خارجية (قابلة للحل بواسطة عملاء Microsoft 365 / Office وأي مستخدمين عن بُعد) وداخلية (قابلة للحل داخل شبكة شركتك والمجموعة).
يجب أن يكون اسم مضيف نقطة نهاية مفتاح DKE متطابقًا في ثلاثة أماكن: سجل DNS، وSAN شهادة TLS، وعنوان URL لنقطة نهاية DKE المكوّن على تصنيف حساسية Microsoft Purview. عدم التطابق هو السبب الأكثر شيوعًا لفشل DKE — راجع استكشاف أخطاء DKE وإصلاحها.
الحل بأفق منقسم (Split-horizon)
يجب أن يصل عملاء Office إلى نقطة نهاية DKE أينما يُفتح المحتوى المحمي — على شبكة الشركة، وللمستخدمين عن بُعد، من الإنترنت. استخدم DNS بأفق منقسم بحيث يُحلّ نفس اسم المضيف إلى نقطة الدخول الصحيحة من كل شبكة، مع بقاء اسم المضيف وشهادة TLS متسقين.
سجلات DNS الخارجية
أنشئ هذه في منطقة DNS العامة / الخارجية (قابلة للحل بواسطة عملاء Office والمستخدمين عن بُعد). وجّهها إلى عنوان IP الافتراضي (VIP) للدخول العام أو الوكيل العكسي.
| اسم المضيف (مثال) | النوع | الهدف | الغرض |
|---|---|---|---|
dke.example.com | A / CNAME | VIP الدخول العام / الوكيل العكسي | نقطة نهاية مفتاح DKE — يجلب عملاء Office المفتاح هنا (يجب أن يطابق عنوان URL لتصنيف Purview) |
cockpit.example.com | A / CNAME | VIP الدخول العام | واجهة المسؤول/المستخدم لـ Cockpit (فقط في حال الوصول خارجيًا) |
cockpit-api.example.com | A / CNAME | VIP الدخول العام | واجهة Cockpit API (فقط في حال الوصول خارجيًا) |
إذا كان جميع المستخدمين يفتحون المحتوى المحمي بـ DKE فقط من داخل شبكة الشركة، فيمكن أن تكون نقطة نهاية DKE داخلية فقط (بلا سجل عام). أكّد سيناريو الوصول عن بُعد قبل اتخاذ القرار.
سجلات DNS الداخلية
أنشئ هذه في منطقة DNS الداخلية (شبكة الشركة / المجموعة).
| اسم المضيف (مثال) | النوع | الهدف | الغرض |
|---|---|---|---|
*.apps.<cluster>.example.local | A / wildcard | VIP موجّه الدخول | مسارات تطبيقات OpenShift (Cockpit، KMS، إلخ) |
api.<cluster>.example.local | A | VIP موازن تحميل مستوى التحكم | خادم OpenShift API |
dke.example.com | A / CNAME | VIP موازن التحميل الداخلي | نقطة نهاية DKE (العرض الداخلي لاسم الأفق المنقسم) |
cockpit.example.local | A / CNAME | VIP موجّه الدخول | واجهة Cockpit (الوصول الداخلي) |
cockpit-api.example.local | A / CNAME | VIP موجّه الدخول | واجهة Cockpit API (الوصول الداخلي) |
dke-kms-api.example.local | A / CNAME | VIP موازن التحميل الداخلي | واجهة DKE/KMS API (الوصول الداخلي) |
openbao.example.local | A | VIP / أجهزة OpenBao الافتراضية | محرك الأسرار |
postgres.example.local | A | VIP / الأساسي لـ PostgreSQL | قاعدة البيانات |
gitlab.example.local | A / CNAME | جهاز GitLab الافتراضي | المصدر والسجل (GitOps) |
argocd.example.local | A / CNAME | VIP موجّه الدخول | وحدة تحكم GitOps (ArgoCD) |
harbor.example.local | A / CNAME | Harbor الداخلي (المرآة) | سجل الصور المعزول عن الشبكة |
grafana.example.local | A / CNAME | VIP موجّه الدخول | لوحات معلومات القابلية للملاحظة |
vmselect.example.local | A / CNAME | VIP موجّه الدخول | نقطة نهاية استعلام VictoriaMetrics (اختياري، داخلي) |
vlogs.example.local | A / CNAME | VIP موجّه الدخول | نقطة نهاية استعلام VictoriaLogs (اختياري، داخلي) |
المكونات التي تتواصل مع بعضها داخل المجموعة (Redis، ووسيط الرسائل، وvmagent/vmstorage/vminsert، وVector، والاستدعاءات الداخلية بين الخدمات) تستخدم اكتشاف خدمة Kubernetes — لا يلزم أي سجل DNS خارجي/داخلي. أنشئ سجلات فقط لنقاط النهاية التي يصل إليها البشر أو الأنظمة الخارجية بالاسم.
التوصيات
- TTL: استخدم TTL معتدلًا (مثل 300–3600 ثانية). خفّضه مؤقتًا قبل تغيير مخطط له لعنوان VIP/نقطة نهاية لتسريع الانتشار.
- VIP مفحوص الصحة: وجّه السجلات إلى VIP موازن تحميل يفحص صحة الواجهات الخلفية، وليس إلى عقدة واحدة.
- الشهادات: تأكد من أن كل اسم مضيف يمكن الوصول إليه خارجيًا هو SAN على شهادة TLS الخاصة به (راجع أمن الشبكة ← TLS).
- حافظ على استقرار الأسماء: يتطلب تغيير اسم مضيف نقطة نهاية DKE لاحقًا تحديث تصنيف Purview، والشهادة، وإعادة التحقق من العملاء.
التحقق
# Resolve from a client network
nslookup dke.example.com
dig +short dke.example.com
# Confirm the DKE endpoint answers over TLS with the public key (JSON)
curl -I https://dke.example.com/<keyname>
إذا فشل الحل أو اختبار نقطة نهاية المفتاح، راجع استكشاف أخطاء DKE وإصلاحها ← الخطوة 1.