DNS الخاص يعمل داخل VPC لكن لا يعمل عبر VPN
الاسم الخاص الذي يُحل داخل EC2 ولا يُحل عبر VPN هو مشكلة في مسار المُحلِّل. اقرأ شكل الفشل قبل تعديل سجل المنطقة.
يُحل اسم خاص من نسخة EC2 لكن لا يُحل من حاسوب محمول متصل عبر VPN، وتبدو المنطقة صحيحة في وحدة التحكم. الغريزة هي تعديل السجل، وهذا ليس المشكلة تقريبًا أبدًا. السجل يجيب شخصًا ما؛ إنه فقط لا يجيب حاسوبك المحمول. ما يختلف بين المتصلين هو أي مُحلِّل يسألان، وهل لذلك المُحلِّل مسار مدعوم إلى عرض DNS في VPC.
أبدأ بإثبات أن السجل موجود، ثم أقضي بقية الوقت على مسار الاستعلام. هذان نظامان منفصلان ويفشلان بأشكال مختلفة.
اقرأ شكل الفشل قبل أن تغيّر أي شيء
ثلاث نتائج تعني ثلاثة أشياء مختلفة، واستعلام واحد يفصل بينها: شغّل dig للاسم مقابل المُحلِّل الذي يستخدمه العميل فعليًا.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
المهلة إفادة عن الشبكة. NXDOMAIN إفادة عن عرض DNS. الإجابة العامة إفادة عن السياسة. تعديل سجل منطقة بينما توجد مهلة يرمي الدليل الوحيد المفيد في الحالة.
لماذا عنوان زائد اثنين في VPC ليس مُحلِّلًا بعيدًا
عنوان CIDR زائد اثنين خدمة محلية للموارد داخل VPC. توثّق AWS أن إعادة توجيه الاستعلامات من الشبكات المحلية، أو من خوادم DNS في VPC آخر، مباشرة إلى ذلك العنوان غير مدعومة وقد تنتج نتائج غير مستقرة.
هذا لا يعني أن التجربة لا تبدو ناجحة أبدًا. يعني أن السلوك ليس عقدًا يمكن وضعه في نص دعم. الاتجاه المدعوم هو نقطة نهاية Resolver واردة: زوج عناوين داخل VPC الخاص بك، يمكن الوصول إليه من الشبكة التي تتحكم بها، ويقبل الاستعلامات القادمة من خارج AWS.
ابنِ المسار بالترتيب الذي يفشل فيه بنظافة
يجب أن توجد ثلاث قفزات، ولكل منها طريقة فشلها الخاصة.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesيحتاج المُمرِّر إلى مسار إلى عناوين نقطة النهاية عبر VPN، ويجب أن يعمل مسار العودة أيضًا. بالنسبة إلى DNS التقليدي على المنفذ 53 تستجيب نقطة النهاية عبر UDP و TCP، لذا يجب السماح بالبروتوكولين ويجب أن يصمد كلاهما أمام أي فحص حالة في الوسط.
ثم افحص عرض DNS بشكل منفصل. المنطقة المستضافة الخاصة مرئية فقط لـ VPC المرتبطة بها، أو عبر ترتيب مشاركة متعمد. نقطة نهاية يمكن الوصول إليها لا تجعل في حد ذاتها كل منطقة خاصة قابلة للحل في سياق الحل الخاص بها.
نقطة النهاية الصادرة تخدم الاتجاه المعاكس ولن تستجيب لاستعلام قادم من حاسوبك المحمول.
تحقق من الطرفين
استعلم من العميل نحو المُمرِّر، ثم من المُمرِّر نحو نقطة النهاية. إذا فشل العميل بينما ينجح المُمرِّر، فالفجوة بينهما.
إذا فشل الاثنان، فانظر إلى سياسة الأمان على نقطة النهاية وإلى عنوان المصدر الذي تراه فعليًا. المُمرِّر خلف NAT يقدّم عنوان NAT بدلًا من عنوان VPN للحاسوب المحمول، وهذا الفرق وحده يكفي لإسقاط الاستعلام. إذا نجح الاثنان لكن التطبيق ما زال يفشل، فقد يستخدم التطبيق مُحلِّلًا مختلفًا عن الذي اختبرته.
أبقِ مساحات الأسماء العامة والخاصة منفصلة عن قصد. Split DNS سياسة تُهيّئها، وليس أثرًا جانبيًا لعملية بحث تعيد بيانات بالمصادفة.
ما لن أفعله
لن أضيف قاعدة NAT جعلت استعلامًا واحدًا يعمل وأسمي ذلك تصميمًا.
لن أوجّه كل عميل بعيد إلى عنوان زائد اثنين لأن اختبارًا واحدًا أعاد سجلًا مرة. ولن أوسّع سياسة الأمان لنقطة النهاية إلى مجمع VPN بأكمله عندما يحتاج مُمرِّر واحد إلى الوصول. إذا كانت المؤسسة تشغّل بالفعل مُمرِّرًا معتمدًا داخل VPC، فاقرأ ذلك التصميم أولًا، لأن نقطة النهاية الثانية التي تضيفها هي التي لا يوثّقها أحد.