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

لماذا توقفت القاعدة عن المطابقة

يصف RFC 4941 العناوين المؤقتة: ينشئ المضيف عناوين إضافية بمعرّفات عشوائية ثم يلغيها، وهو ما يمنع المراقب من ربط مضيف واحد عبر الزيارات. يطبّق Windows هذا السلوك، لذا ليس بالضرورة أن يكون عنوان المصدر أمس هو نفسه عنوان اليوم. لا يزال العنوان المتوقع موجودًا على الواجهة؛ لكنه ببساطة ليس العنوان الذي يفضّله اتصال صادر.

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

الخيار الأول: عنوان واحد ثابت وخصوصية أقل

الإصلاح المعتاد يعطّل آليتي التدوير على المضيف: netsh interface ipv6 set privacy state=disabled store=persistent و netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. أضف store=active إذا أردت أن يسري التغيير من دون انتظار إعادة التشغيل، واقبل أنك جعلت المعرّف قابلًا للتنبؤ عبر الشبكات.

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

الخيار الثاني: السماح ببادئة أو باسم

السماح بـ /64 بدلًا من العنوان الكامل يبقي التدوير سليمًا ويطابق ادعاء أضعف لكنه صادق غالبًا: هذا الجهاز على شبكتي المنزلية. يتوقف هذا عن كونه كافيًا في اللحظة التي تحتوي فيها تلك البادئة على مضيفين لا تقبلهم، وهي في اتصال منزلي عادة مجموعة أصغر مما يفترض الناس. الاسم المنشور عبر DNS الديناميكي أسهل في التشغيل، لأن السجل يتبع المضيف وتُقرأ السياسة كهوية لا كنطاق ينمو كلما أُضيف جهاز.

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

الخيار الثالث: دع النفق يوزّع العنوان

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

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

اختر مع إبقاء كلفة التتبع في الاعتبار

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

سجّل التغيير بجانب القاعدة التي يدعمها. من دون تلك الملاحظة، يجد المسؤول التالي مضيفًا بإضافات خصوصية معطلة ولا تفسير، فيعيد تمكينها أثناء تنظيف.

مقالات ذات صلة