✌🏻 🕶️ 🔺 IPv6 - أنت تفعل ذلك بشكل خاطئ 💆🏽 👩🏼‍💼 🛀🏽

هناك الكثير من المفاهيم الخاطئة والأساطير حول IPv6. غالبًا ما يسيء مقدمو الاستضافة فهم كيفية استخدامها والتفكير في الأساليب القديمة من عالم IPv4. على سبيل المثال ، عند وجود مثمن من عناوين IPv6 ، يبيع المضيف العناوين للعملاء بشكل فردي ، بدلاً من تخصيص شبكة كاملة / 64 ، على النحو التالي من التوصيات.

يحدث أن يقوم المضيفون بتعيين عناوين IPv6 لعملاء مختلفين داخل نفس الشبكة / 64. في الوقت نفسه ، تعتبر الخدمات الكبيرة ، مثل Google ، جميع العناوين داخل النطاق / 64 كعميل واحد. ونتيجة لذلك ، قد يعاني العملاء بسبب أنشطة زميل في الفرقة.

يتيح لك توفر عناوين IPv6 تعيين عناوين خارجية كاملة للموارد الداخلية ، مثل الحاويات أو عملاء VPN. للقيام بذلك ، يجب على المضيف تزويد العميل بشبكة توجيه منفصلة. لسوء الحظ ، لا يمكن لأحد تقريبًا القيام بذلك.

في هذه المقالة ، سنقوم بتحليل الأخطاء الرئيسية في استخدام موفري IPv6.

القصة: RFC 3177

في عام 2001 ، أوصت التوصيات بشأن تخصيص العناوين (آسف للتشريح ، وهذا مهم) لتسليط الضوء على:

/ 48 بشكل عام
/ 64 إذا كان وراءها شبكة فرعية واحدة فقط
/ 128 إذا كان جهاز واحد فقط

تحدد الوثيقة المسيئة RFC 2119 ، التي تحكم تطبيق مستويات مختلفة من الامتثال الإلزامي للتعليمات ، "موصى به" على النحو التالي:
تعني الكلمات "ينبغي" أو "مستحسن" أنه قد تكون هناك أسباب معقولة في ظروف معينة لعدم التصرف بهذه الطريقة ، ومع ذلك ، اختيار خط مختلف من السلوك يجب أن يكون قرارًا متوازنًا مع الفهم الكامل للعواقب.
ربما لم يكن لدى أي شخص فهم كامل للعواقب في ذلك الوقت ، ربما لم يتم تحديد "ظروف معينة" ، ولكن بطريقة أو بأخرى ، اتبع الجميع التوصيات.

بشكل عام ، في وقت كتابة الوثيقة ، كانت حركة مرور IPv6 نادرة للغاية وتم العثور عليها ، في الغالب ، في المعاهد والشبكات الشخصية لهواة الفضوليين. بدأت بعض المشاكل الحقيقية في التراكم والتحليل ، ولكنها استغرقت الكثير من الوقت.
بدأ إعادة التفكير في عام 2005. وأخيرًا ، تم إيقاف هذه التوصيات في عام 2011.

الوعي بالمشكلة: RFC 6177

تنص سياسة العنونة الجديدة بشكل صريح على أن / 48 مجرد أمنية وليست مطلبًا. لم يتم إعطاء أي إشارة لأرقام محددة ، ومع ذلك ، يشار إلى أن / 64 أو أقصر يعمل في ظل الظروف العادية.

سعى المنطق الرئيسي في التوصية بحجم إصدار الكتلة / 48 للمستهلك النهائي إلى تحقيق ثلاثة أهداف.

أولاً ، يجب أن تكون مساحة العنوان المعينة كافية لأغراض المستهلك وقابلة للتوسعة بسهولة ، بدون قرفصاء الحديد. نعم ، هذا بالضبط ما يقوله ، فقط في النسخة الإنجليزية - القفز من خلال الأطواق. أحد الأسباب المهمة للتبديل إلى IPv6 هو تغيير حجم الوجهة الحالي من "عنوان واحد" إلى "شبكات فرعية متعددة".

ثانياً ، كان ينبغي أن يتم تغيير المزود مع الحد الأدنى من المشاكل. إذا كان بإمكانك حفظ مخطط عنوان الشبكة الفرعية القديم عند الانتقال إلى مساحة عنوان جديدة ، فإن هذا سيوفر الكثير من العمل

. ثالثًا ، يجب أن يغطي تخصيص الكتلة / 48 الزيادة في احتياجات مساحة العنوان للمستهلك النامي.

على الرغم من استيفاء جميع هذه الشروط ، أصبح من الواضح أن التوصية / 48 كانت ، بعبارة ملطفة ، زائدة عن الحاجة.

رقم التعريف الشخصي / 64 كوحدات الإصدار

بالإضافة إلى أمر التوزيع ، كانت هناك نقاط أخرى. اتضح أن العديد من ميزات IPv6 لا تعمل إذا كانت بادئة الشبكة ليست / 64. وهي لا تعمل:

اكتشاف الجيران (ND)
اكتشاف الجيران الآمن (إرسال)
بعض أجزاء Mobile IPv6
Multihoming الموقع بوساطة IPv6
أشياء صغيرة مختلفة

كان العامل الإضافي هو حقيقة أن العديد من التقنيات التي يتم تصميمها تعتمد بدقة على بادئة الشبكة هذه.

لم يكن التهديد بكسر معيار المكتشف الجديد هو السبب في كتابة توصيات جديدة. كان هناك رأيان حول الصحة المشكوك فيها أيضًا بشعبية كبيرة.
أولاً ، تقوم العديد من الأجهزة بتطبيق توجيه IPv6 برمجياً ، مع عكازات ودراجات ، وبالتالي فهي غير جاهزة للانتقال الكامل إليها. يمكن أن تزيد الزيادة المحتملة في التأخير بسبب ذلك عدة مرات ، إن لم يكن ترتيبًا من حيث الحجم. سيقلل التعريف الافتراضي للشبكة الفرعية / 64 بشكل كبير من هذه التأخيرات.

ثانيًا ، يعد التحول إلى معيار جديد دائمًا ألمًا للدعم الفني ومسؤولي النظام. كان من المفترض أن تؤدي البادئة الفردية / 64 إلى تقليل هذا الألم إلى قيمة مقبولة.

الوضع على الجبهات

كما حدث بالفعل في وقت سابق من عام 2001 ، فإن العديد من مشغلي الإنترنت الكبار يعتبرون التوصية / 64 معيارًا. من ناحية ، هذا جيد ، من ناحية أخرى ، ليس جيدًا.

بالنسبة للعديد من أنظمة التصنيف ، على سبيل المثال ، للتعرف على البريد العشوائي ، سيتم اعتبار جميع العناوين من كتلة واحدة على أنها تنتمي إلى مرسل واحد غير مرغوب فيه. من الناحية النظرية ، يجب أن يجعل ذلك الحياة أسهل للمستخدم ، في الواقع ، العكس تمامًا.

في كثير من الأحيان ، لا يهتم مقدمو الخدمات بأشياء مثل التعلم عن الممارسات الشائعة. يمكن إصدار العناوين وفقًا لأي مبدأ ، على الأقل حتى وفقًا لبرجك.

هناك العديد من المشاكل النموذجية ، وكلها تنبع من انتهاك التوصيات من قبل المزود من جهة ، والالتزام الصارم بها من قبل بعض المنظمات الأخرى من جهة أخرى.
يمكن أن يؤدي إصدار العناوين من كتلة واحدة إلى العديد من المستخدمين إلى حقيقة أنهم سيتم اعتبارهم جميعًا كمستخدم فعلي واحد ، على سبيل المثال ، الأجهزة الموجودة في شبكة المؤسسة.

إذا بدأ العديد من الأشخاص من هذه الكتلة بالبحث عن القطط في نفس الوقت ، فقد تقرر Google أن هذه البوت نت سترسل طلبات بحث احتيال أو بعض الأشياء الأخرى غير الجيدة. من وجهة نظره ، كل هذا مستخدم واحد. النتيجة المنطقية هي كلمة التحقق معقدة بشكل متزايد.

هذه ، كما تعلمون ، هي الإجابة الأكثر ضررًا على عملية احتيال افتراضية.
الوضع العكسي هو إصدار عناوين لمستخدم واحد من كتل مختلفة. إذا كان مستخدمو هذه الكتل يندرجون في القائمة السوداء لشخص ما ، فإن عناوين المستخدم النزيه ستقع معهم. قصة مثيرة للاهتمام بشكل خاص: تم حظر بعض عناوينك من قبل شبكة إعلانية ، وبعضها تم حظره من قبل أخرى.

بالإضافة إلى ذلك ، من الممكن مفاجآت غير سارة أخرى. على سبيل المثال ، تلقيت كتلة / 64 لاستخدامك ، ولكن هذه كتلة ديناميكية كعنوان ديناميكي - اليوم 2001: DA8: 1D01: FA13 :: / 64 ، غدًا 2001: DA8: 1D01: FC15 :: / 64. مغامرات جديدة كل يوم!
هناك فرصة كبيرة لمواجهة مجموعات مختلفة من هذه المشاكل والمكعبات المنحنية الأخرى في الملحق.

إصدار IPv6 من خادمنا

إذا كان لدينا quintillion من عناوين IP ، فلماذا لا نعطي عناوين IP حقيقية ، على سبيل المثال ، لعملاء VPN بحيث يذهبون إلى الإنترنت بدون NAT ويمكنهم قبول الاتصالات الواردة من العالم. يبدو الأمر رائعًا ، ولكن من الناحية العملية ، ليس الأمر بهذه السهولة. سيتطلب هذا شبكة IPv6 منفصلة يتم توجيهها عبر عنوان IP المعين لواجهة الخادم.

لنفترض أن الخادم قد تم تعيين عنوان له 2a01:baba::c0fee:dead/64، فإن عملاء VPN سيحتاجون إلى شبكة منفصلة ، مثل 2a01:baba:fafa:0f0f::/64التوجيه عبر العنوان 2a01:baba::c0fee:dead/64.

لسوء الحظ ، فإن عددًا قليلاً جدًا من موفري الاستضافة لديهم الأدوات لإصدار مثل هذه الشبكات للعملاء ، ولهذا السبب يجب عليك استخدام العكازات مثل ND Proxy .

استنتاج

إن قراءة توصيات IETF ليست النشاط الأكثر إثارة للاهتمام ، ولكنها مفيدة للغاية. من الواضح أن ملئها بأمسيات شتوية طويلة لا يستحق ذلك ، ولكن إهمال قراءة الأقسام المهمة لك أمر غير مرغوب فيه أيضًا.

عند اختيار مزود ، تأكد من أنه يشارك وجهة النظر هذه.

يجب أن تفهم أن النهج الخاطئ لتخصيص العناوين لا يضر بالمزود ، وبالنسبة لمعظم العقود ، لا يمكن أن يكون الأساس للتعويض.
ومع ذلك ، قد يتحول هذا إلى عامل رئيسي بالنسبة لك ، على الرغم من أنك لا تشك في ذلك حتى الآن.