استخدام نطاقات فرعية DDns شائعة قد يؤدي إلى تقليل خدمة الإنترنت للشركات
Categories:
قضيت ثلاثة أشهر في مواجهة مشكلة انقطاع IPv6 وفشل نفق IPv6، وأخيرًا حددت السبب، وسأشارككم التفاصيل.
المنشور الأول للحصول على مساعدة حول مشكلة انقطاع IPv6
كان يمكن الوصول إلى IPv6 بشكل طبيعي دون أي تغيير في الإعدادات، وكل الأجهزة لديها عناوين IPv6 مستقلة، ولكن لا يمكن الاتصال بالشبكة IPv6.
curl 6.ipw.cn لا يعيد أي نتيجة، ping6 وtraceroute6 2400:3200::1 ينقطعان.
جسر مودم الضوء إلى موجه، يمكن الحصول على عنوان IPv6 الخاص بالموجه، وهو عنوان يمكن الوصول إلى IPv6.
يمكن الحصول على بادئة /56، وأجهزة أسفل الموجه يمكنها الحصول على عناوين IPv6 المخصصة 240e:36f:15c3:3200::/56، ولكن لا يمكنها الاتصال بمواقع IPv6.
أعتقد أن مشغل الشبكة لم يقم ببناء مسار 240e:36f:15c3:3200::، ولكن لا يمكن التأكد.
ذكر أحد المستخدمين أن السبب قد يكون بسبب ارتفاع حركة التحميل PCDN، ولكن حركة التحميل صغيرة جدًا ولا يوجد PCDN مفعل.
قد يكون أيضًا بسبب استخدام Cloudflare و Aliyun ESA للإعادة.
المنشور الثاني للتأكيد على السبب المباشر
تم التأكد من أن بعض مشغلي شركات الاتصالات في بعض المناطق يخفضون الخدمة بسبب ارتفاع عدد اتصالات HTTP/HTTPS الواردة على IPv6، ويتضح ذلك من:
- IPv6 وهمية، يمكن الحصول على بادئة
/56لـ IPv6، وتوزيع IPv6 للأجهزة أسفل الموجه طبيعي، ولكن tracert يفتقر إلى المسارات، مما يؤدي إلى عدم الاتصال الفعلي لـ IPv6. - جدار ناري وهمي، اختبار الاتصال Tailscale يظهر أنه اتصال مباشر، ولكن التأخير مرتفع جدًا، والسرعة الفعلية للشبكة بطيئة جدًا.
بعد إيقاف التوجيه العكسي لـ Cloudflare و Aliyun ESA، وبعد عدة إعادة تشغيل للراوتر، يمكن استعادة IPv6 والاتصال المباشر الحقيقي.
انقطاع الاتصال لا يزال يحدث بعد إيقاف التوجيه العكسي
حتى بعد إيقاف التوجيه العكسي وإيقاف رجوع Cloudflare و Aliyun ESA، لا يزال يحدث انقطاع الاتصال بشكل عرضي، مع مدة طويلة نسبيًا.
قد يكون هناك تسرب للنطاقات أو استخدام نطاقات فرعية شائعة للمسح، وهجوم HTTP طويل الأمد.
بعد تعطيل تحليل DNS للنطاقات الفرعية DDns، وبعد فترة من الزمن، عاد IPv6 إلى وضعه الطبيعي، وعاد نفق tailscale إلى الاتصال المباشر الطبيعي.
منذ ذلك الحين لم يحدث أي انقطاع في الاتصال.
الحل النهائي
أقترح هنا على الجميع عدم استخدام النطاقات الفرعية الشائعة لـ DDns، مثل:
- home.example.com
- nas.example.com
- router.example.com
- ddns.example.com
- cloud.example.com
- dev.example.com
- test.example.com
- webdav.example.com
بعض هذه النطاقات كانت أستخدمها دائمًا، ربما يتم مسحها من قبل الآخرين باستمرار، مما يؤدي إلى تقليل خدمة الإنترنت للشركات، وعدم القدرة على استخدام IPv6 العام بشكل طبيعي، وعدم القدرة على إقامة نفق اتصال مباشر دائمًا.
الجميع يعرف أهمية إخفاء عنوان IP في أمان الشبكة، وهنا أقترح إضافيًا حماية نطاق DDns الخاص بك، حيث أنه في الأساس يعرض أيضًا عنوان IP.
ولكن ماذا لو لا يزال هناك حاجة لعرض الخدمة؟
هناك حلين عمليين:
- حل العودة، وهو خدمة تحويل، حيث يذهب الطلب أولاً إلى VPS ثم إلى خادم المنزل. نظرًا لتحول حركة المرور، فإن التأخير وعرض النطاق الترددي سيتأثران إلى حد ما.
- حل DDns، وهو حل اتصال مباشر، وتجربة الاتصال ستكون أفضل بكثير، ويُقترح هذا الحل. عادةً لا يتجاوز المستخدمون الأفراد حد عدد الاتصالات، ولكن إذا تم نشر النطاق بشكل علني، فإن عدد الاتصالات سيزداد بسرعة بسبب البوتات المنتشرة.
حل العودة (التوجيه العكسي)
Cloudflare Tunnel
استخدم Cloudflare Tunnel، وبهذه الطريقة لن يتم زيارة العشرات أو المئات من عناوين IP كما هو الحال مع العودة العادية.
Tailscale أو ZeroTier
إنشاء VPN خاص، مع VPS أمامه، والوصول إلى خدمات الشبكة الداخلية من خلال VPN، وبهذه الطريقة يمكن تجنب ارتفاع عدد الاتصالات المتزامنة.
حل DDns (الاتصال المباشر)
التحليل العام
إنشاء سلسلة عشوائية مثل GUID، لاستخدامها كنطاق فرعي لـ DDns، على الرغم من أنه من المستحيل تقريبًا تذكرها، إلا أن التأثير على الاستخدام الفعلي للفرد ليس كبيرًا، ويمكن تقييم ذلك بشكل مستقل.
التحليل الخاص
استخدم خدمة DNS شخصية، مثل:
لاستخدام تحليل DDns.
بهذه الطريقة، فقط الأشخاص القادرون على الاتصال بخادم DNS الخاص بك يمكنهم الحصول على عنوان IP المخصص للنطاق المحدد.
في هذا السيناريو، يمكن استخدام النطاقات الفرعية الشائعة لـ DDns، ولكن يجب تجنب تسريب عنوان خدمة DNS الخاصة بك.
ملاحظات إضافية
تنتشر شائعات في الشارع، أن استخدام speedtest كنطاق فرعي له تأثير تسريع خرافي.