أمن الشبكاتكيف تحدّد المعدل وتحظر إساءة استخدام IPv6 بحسب البادئة /64
حدّد معدل IPv6 بحسب البادئة لا العنوان: مشترك واحد يملك /64 كاملة. اجعل الحدود والحظر على /64، وتصعّد إلى /56 و/48، ودع السمعة تتلاشى.
تقريبًا كل محدِّد معدل وخانق تسجيل دخول وقائمة حظر IP في الإنتاج صُمم على IPv4، حيث النموذج الذهني بسيط: عنوان واحد، ومستخدم واحد تقريبًا. عُدَّ الطلبات لكل عنوان، واحظر العنوان، وامضِ. هذا النموذج صار خاطئًا بصمت. فحين تتضمن حركتك IPv6 (ونسبة كبيرة ومتنامية منها كذلك)، تتوقف الوحدة التي تعدّ عليها عن أن تقابل شخصًا، ويتسرب كل دفاع مبني على «عنوان واحد».
هذه ليست حالة هامشية دقيقة. إنها الفرق بين محدِّد معدل يعمل وآخر يمر منه المهاجم مباشرة بينما تُظهر لوحاتك صفًا مرتبًا من عناوين بطلب واحد لكل منها. والحل ليس مزيدًا من القواعد، بل عدّ الشيء الصحيح، وهي العادة نفسها وراء التحقق من زواحف الذكاء الاصطناعي والبوتات بنطاق IP، حيث تهم كتلة CIDR المنشورة أكثر من أي عنوان مفرد. وعدّ البادئات طبقة واحدة من كشف البوتات بعنوان IP؛ أما الطبقات الأخرى فتخبرك بنوع الشبكة التي تنتمي إليها البادئة.
عادة IPv4 التي تنكسر على IPv6
في IPv4 أسدت ندرة العناوين لك معروفًا. فهناك نحو 4.3 مليار عنوان فقط، وهي مكلفة، والترتيب الغالب بفارق كبير أن يحصل المشترك على عنوان عام واحد في كل مرة. فكان «الطلبات من هذا /32» و«الطلبات من هذا المستخدم» متقاربين بما يكفي لعدّهما شيئًا واحدًا. احظر /32 وستزعج في أسوأ الأحوال الأسرة أو NAT الذي خلفها.
يزيل IPv6 الندرة، ومعها الافتراض. العنوان 128 بتًا بدل 32 (ثماني مجموعات من أربعة أرقام سداسية عشرية)، وفلسفة التصميم عكس التقتير. فبدل تقنين العناوين المفردة، يمنح IPv6 كل عميل كتلة منها. وأصغر كتلة يحصل عليها أي أحد هائلة، وهذه الكتلة، لا العنوان المفرد، هي الهوية الحقيقية للمستخدم.
فإن كان محدِّدك لا يزال يعدّ لكل عنوان كامل في IPv6، فلا يحتاج المسيء إلى شبكة بوتات أو مجموعة بروكسي. يحتاج إلى تخصيص IPv6 عادي واحد وحلقة for.
مشترك واحد، 18 كوينتيليون عنوان
هذا هو الرقم الذي يعيد صياغة المشكلة كلها. أصغر كتلة قابلة للتوجيه يُخصَّص لمستخدم IPv6 النهائي عادةً هي /64: أول 64 بتًا هي الشبكة، وآخر 64 بتًا له يملؤها كما يشاء. وهذا يترك 2^64 عنوانًا قابلًا للاستخدام داخل الشبكة الفرعية لمشترك واحد:
2^64 = 18,446,744,073,709,551,616 عنوانًا: نحو 18.4 كوينتيليون، كلها تعود لمستخدم واحد، وكلها قابلة للتوجيه على حد سواء.
وحقيقتان تجعلان هذا أمرًا لا مفر منه لا شذوذًا. الأولى: الإعداد التلقائي للعناوين عديم الحالة (SLAAC)، الطريقة القياسية التي تعيّن بها مضيفات IPv6 عناوينها بنفسها، يتطلب /64 كاملة لكل شبكة فرعية؛ ولا يمكنك منح شيء أصغر لشبكة محلية عادية. والثانية: إرشادات تخطيط العناوين التي تتبعها سجلات الإنترنت الإقليمية (RFC 6177 / BCP 157) تطلب من مزودي الإنترنت منح كل موقع نهائي تخصيصًا سخيًا، عادةً /56 أو /48، وألا يقل أبدًا عن /64. الوفرة هي جوهر البروتوكول.
الآن جانب المهاجم. التنقل بين تلك العناوين ليس مكلفًا ولا ذكيًا. إنه خيار مقبس مدمج. فعلَم IP_FREEBIND في لينكس يتيح لعملية أن ترتبط بـأي عنوان داخل بادئة موجَّهة محليًا وترسل منه دون إعداد كل عنوان على واجهة أولًا، وأدوات عامة مثل مشروع freebind المرجعي الواسع تغلّف ذلك تمامًا في «استخدم عنوان مصدر جديدًا لكل اتصال». أعطه /64 موجَّهة وسيصدر حركة من 18 كوينتيليون مصدرًا متمايزًا دون كلفة.
لذلك فتحديد المعدل لكل /128 لا يبطئ هذا بأي معامل. كل طلب يبدو عنوانًا جديدًا تمامًا رُئي مرة واحدة. عدّادات محدِّدك لا تتجاوز الواحد أبدًا، وقائمة حظرك تمتلئ بملايين الإدخالات ذات الإصابة الواحدة ولا تطابق شيئًا، ويمضي الهجوم بكامل سرعته بينما يبدو على الورق موزعًا توزيعًا مثاليًا.
التسلسل الهرمي لتخصيص IPv6 وماذا يعني كل مستوى
لتحدّد المعدل للوحدة الصحيحة عليك أن تعرف ما الذي يمثله كل طول بادئة فعليًا. بادئات IPv6 مجرد كتل CIDR (الترميز /n نفسه كما في IPv4، حيث يغطي الرقم الأصغر عناوين أكثر)، لكن الحدود المتعارف عليها تحمل دلالة عمّن على الطرف الآخر.
| البادئة | تحتوي على | ماذا / من تمثل | هل يصح التجميع عليها؟ |
|---|---|---|---|
| /128 | عنوان واحد | واجهة مفردة، واحدة من كوينتيليونات المشترك. تُدوَّر مجانًا. | لا. هذا هو الخطأ. ليست وحدة أبدًا. |
| /64 | شبكة فرعية واحدة (2^64 عنوانًا) | الشبكة المحلية لمشترك واحد. أصغر كتلة مضمون أنها مستخدم واحد. | نعم. هذا هو مفتاح تحديد المعدل والحظر الافتراضي. |
| /56 | 256 × /64 | تخصيص نموذجي لمنزل أو شركة صغيرة من مزود الإنترنت. | نعم، عند الاستمرار: تخصيص عميل واحد بكامله. |
| /48 | 65,536 × /64 | تخصيص أكبر لموقع أو شركة. | نعم، عند الاستمرار؛ وما زال عادةً كيانًا واحدًا. |
| /32 | 4.3 مليار × /64 | تخصيص مزود إنترنت أو استضافة بكامله. | نادرًا. هذه شبكة كاملة، آلاف المستخدمين. |
يتضح شكل القرار من الجدول. /128 ليست الوحدة أبدًا. و/64 هي الأرضية: أضيق نطاق ما زال يقابل فاعلًا واحدًا، ولذلك فهي الافتراضي. وكل ما هو أوسع تصعيد لا تلجأ إليه إلا حين يكون لديك دليل على أن التخصيص الأوسع بكامله هو المشكلة.
القاعدة الأولى: حدّد معدل IPv6 بحسب البادئة، بدءًا من /64
التغيير الوحيد الذي يصلح معظم العطل هو التوقف عن العدّ لكل عنوان والبدء بالعدّ لكل /64. عمليًا، لكل طلب IPv6 وارد، استخرج /64 بالاحتفاظ بأول أربع مجموعات سداسية عشرية (64 بتًا) واستخدم تلك مفتاحًا لعدّادات تحديد المعدل وإحصاءات محاولات تسجيل الدخول وعمليات البحث في قوائم الحظر.
// Normalize any IPv6 address to its /64 aggregation key.
// The first 64 bits (4 hextets) identify the subscriber's subnet;
// the last 64 bits are theirs to rotate through, so we discard them.
function ipv6Key(addr) {
// Expand "2001:db8::1" to full form, take the first four groups.
const full = expandIPv6(addr); // 8 groups of 4 hex digits
return full.split(":").slice(0, 4).join(":") + "::/64";
}
// "2001:0db8:85a3:0000:0000:8a2e:0370:7334" -> "2001:0db8:85a3:0000::/64"
كل أداة حافة رئيسية تدعم هذا أصلًا، فنادرًا ما تحتاج إلى بنائه بنفسك:
- nginx: ابنِ مفتاح الحد من كتلة
map/geoتقنّع IPv6 إلى /64، ثم مرّره إلىlimit_req_zone/limit_conn_zoneبدل$binary_remote_addr. - HAProxy: اضبط قناع 64 بتًا على المصدر عند بناء مفاتيح stick-table، فيُجمَّع
srcعلى /64 بدل العنوان الكامل. - Cloudflare ومعظم شبكات CDN / جدران WAF: تعامل IPv6 أصلًا في كتل /64 لمنطق تحديد المعدل والتحدي الخاص بها؛ حاكِ هذه الدقة في قواعد الأصل لديك كي تتفق الطبقتان.
- محدِّد تطبيقك: استبدل
remote_addrالخام بمفتاح /64 أعلاه قبل أن يصل إلى Redis أو دلو الرموز أو العدّاد.
افعل هذا وحده فينهار هجوم التدوير المجاني إلى ما ينبغي أن يكون: يصبح 18 كوينتيليون عنوان عدّادًا واحدًا، ويُخنق المسيء تمامًا كأنه عنوان IPv4 مفرد. هذا أعلى أسطر الكود قيمة في الموضوع كله.
القاعدة الثانية: تصعّد إلى /56 و/48 عند الاستمرار
المفتاح على /64 يعالج المهاجم الذي يدوّر العناوين داخل شبكة فرعية واحدة. والخطوة التالية في السلم هي المهاجم الذي يدوّر الشبكات الفرعية، لأن المشترك كثيرًا ما يملك لا /64 واحدة بل /56 أو /48 كاملة منها، وأدوات من نوع freebind تستطيع التنقل عبرها أيضًا.
إشارة التوسيع هي الاستمرار: /64 جديدة تواصل الإساءة وتتشارك بادئة أصل واحدة. فحين ترى ذلك، يكون التخصيص كله كيانًا واحدًا وينبغي أن يُحدَّد نطاقه كواحد.
| ما تلاحظه | ماذا يعني | الإجراء |
|---|---|---|
| إساءة من /64 واحدة | شبكة فرعية واحدة هي المصدر. | حدّد معدل /64 أو احظرها. |
| /64 جديدة، و/56 نفسها، مرارًا | تخصيص منزل/شركة صغيرة واحد يدوّر الشبكات الفرعية. | صعّد العدّاد والحظر إلى /56. |
| إساءة موزعة عبر /48 | تخصيص موقع كامل عدائي. | صعّد إلى /48؛ وما زال عادةً عميلًا واحدًا. |
| كثير من /48 عبر /32 | ضوضاء من فضاء مزود إنترنت كامل. | لا تحظر /32؛ قيّم البادئات المفردة بدلًا من ذلك. |
فكّر فيه كعدّاد يتراكم صعودًا. حافظ على إحصاء /64 وحدةً أساسية، لكن تتبّع أيضًا الإساءة المجمَّعة على كل /56 و/48. وحين تتجاوز بادئة أصل عتبة لا يبلغها أي عميل مشروع منفرد (كثير من /64 الفرعية المتمايزة كلها مسيئة في نافذة زمنية قصيرة)، طبّق الحد على مستوى الأصل ودعه يغطي كل الفروع دفعة واحدة. بهذا تبقى متقدمًا على مهاجم يملك تخصيصًا كبيرًا دون أن تعاقب من يملكون تخصيصًا صغيرًا حسن السلوك.
القاعدة الثالثة: وسّع بحسب نوع الشبكة لا بالانعكاس
للتصعيد نمط فشل، وهو المكلف: وسّع أكثر من اللازم فيمحو حظر واحد آلاف المستخدمين الأبرياء. قد تكون /48 شركة واحدة، وقد تكون شريحة من مشغّل محمول. و/32 نادرًا ما تكون فاعلًا واحدًا؛ فهي عادةً مزود إنترنت أو استضافة كامل. تخبرك إشارة الاستمرار بأن البادئة الأصل معنية؛ ولا تخبرك كم شخصًا حقيقيًا خلفها. لذلك تحتاج أن تعرف أي نوع من الشبكات هي البادئة.
وهنا بالضبط يكسب استعلام IP مكانه في المسار. استدعاء واحد لـواجهة API لاستعلام IP على عنوان ممثِّل من البادئة المسيئة يخبرك هل تنظر إلى بنية مستأجرة يمكنك التجميع عليها بجرأة، أم إلى وصول استهلاكي يجب أن تعامله بلطف.
curl -H "x-api-key: YOUR_API_KEY" \
https://api.geoiphub.com/v1/lookup/2001:4860:4860::8888
الحقول التي تحكم إلى أي مدى يمكنك التوسع بأمان:
const res = await fetch(`https://api.geoiphub.com/v1/lookup/${addr}`, {
headers: { "x-api-key": process.env.GEOIPHUB_API_KEY },
});
const ip = await res.json();
ip.asn.asn_type; // "hosting" | "isp" | "mobile" | "cdn" ...
ip.asn.connection_type; // "datacenter" | "residential" | "mobile"
ip.asn.carrier; // set for cellular networks: a leniency signal
ip.detection.is_hosting; // true: infrastructure, aggregate up freely
ip.threat.is_cgnat; // shared address space; do not widen a hard ban
ip.scoring.fraud_score; // 0-100 composite, when you must decide per-address
ip.scoring.recommended_action; // "allow" | "review" | "step_up" | "block"
ip.scoring.detection_methods; // exactly which signals fired: your audit trail
وهذا ما يعيده الاستعلام لعنوان IPv6 حقيقي، هو Google Public DNS على 2001:4860:4860::8888، بُحث عنه بتاريخ 2026-10-05 (مختصر؛ تتغير النتائج بتحرك النطاقات):
{
"ip": "2001:4860:4860::8888",
"asn": {
"asn": 15169,
"org": "GOOGLE - Google LLC",
"asn_type": "hosting",
"connection_type": "datacenter",
"carrier": "none"
},
"detection": {
"is_proxy": false,
"is_vpn": false,
"is_tor": false,
"is_hosting": true,
"is_mobile": false
},
"threat": {
"is_cgnat": false
},
"scoring": {
"fraud_score": 15,
"recommended_action": "allow",
"detection_methods": ["datacenter_ip", "no_ptr_datacenter"]
}
}
نصفا الاستجابة يجيبان عن سؤالين مختلفين. فـ asn_type: "hosting" وconnection_type: "datacenter" وis_hosting: true تقول إن البادئة بنية تحتية، فتوسيع الحظر أبعد من /64 لن يصيب أسرًا. لكن scoring.fraud_score هو 15 وrecommended_action هو allow: ليس للعنوان نفسه إشارة VPN أو Tor أو إساءة، ولا يسرد detection_methods سوى datacenter_ip وno_ptr_datacenter. نوع الشبكة يخبرك إلى أي مدى يجوز لك التوسع؛ أما عدّاداتك الخاصة للاستمرار فعليها أن تقدم سبب التوسع أصلًا. بادئة استضافة لم تسئ أبدًا تبقى مفتوحة.
القراءة اتجاهية، وتعكس المبدأ نفسه وراء أسباب درجة المخاطر التي تضيف وتطرح: بعض الحقول تتيح لك التصرف بحزم أكبر، وبعضها يطلب منك الإمساك.
| نوع الشبكة | ما تحتويه البادئة الواسعة | إلى أي مدى تصعّد |
|---|---|---|
| استضافة / مركز بيانات | خوادم مستأجرة. المتسوقون الحقيقيون لا يعيشون هنا. | بجرأة. /48 عدائية من فضاء الاستضافة يجوز حظرها بالجملة. |
| مزود إنترنت سكني | منازل، لكل منها /64 خلف البادئة الأوسع. | بحذر. أبقِ الحظر بين /64 و/56؛ فقد تضم /48 أسرًا كثيرة. |
| محمول / خلوي | مشتركو المشغّل، وغالبًا يتشاركون فضاء أوسع. | بضيق. /32 لمشغّل تغطي أمة من الهواتف؛ لا تحظرها حظرًا صارمًا أبدًا. |
| CGNAT / مشترك | مشتركون كثيرون خلف فضاء عناوين مشترك. | قيّم ولا تحظر. عامله كعنوان IPv4 مشترك. |
وتعدّ Google Ads بالطريقة نفسها: فواجهتها تقبل 2001:db8::/48 كإدخال استبعاد IP واحد، لذلك تكلّف /48 واحدة من خانات استبعاد Google Ads الخمسمئة.
الانضباط هو الذي نعرض حجته كاملة في كشف الحركة المجهَّلة دون حظر العملاء الحقيقيين: على بادئة hosting أو datacenter يمكنك توسيع الحظر بثقة، لأن عملية دفع أو تسجيلًا ليس لهما سبب مشروع للصدور من رف خوادم. وهي العلامة نفسها التي نفصّلها في ما هو عنوان IP لمركز البيانات. وعلى بادئة mobile أو residential تُبقي النطاق ضيقًا وتدع درجة المخاطر، لا حظر CIDR واسع، يحمل العبء. التوسع بالانعكاس هو الطريقة التي يتحول بها محدِّد المعدل بصمت إلى انقطاع للمستخدمين الحقيقيين.
القاعدة الرابعة: دع سمعة البادئة تتلاشى
القاعدة الأخيرة عن الزمن. قوائم حظر IPv4 تتقادم أصلًا لأن العناوين يُعاد تخصيصها؛ وIPv6 يزيد الأمر سوءًا، لأن بادئات كاملة تُفوَّض وتُعاد وتُفوَّض من جديد، و/64 التي طرقت صفحة تسجيل الدخول لديك الشهر الماضي قد تعود اليوم لأسرة عادية. قائمة حظر دائمة على فضاء عناوين متغير تصبح ببطء قائمة أماكن لم يعد بإمكانك الوصول إليها بأمان.
لذلك لا تخزّن حكمًا دائمًا لكل بادئة. خزّن سمعة تتحرك:
- ارفع عند الإساءة. كل طلب مسيء يرفع درجة /64، ويرفع بزيادة أصغر أصليها /56 و/48.
- تلاشَ مع الوقت. إن بقيت البادئة هادئة تنخفض درجتها وفق جدول (ساعات لخنق ناعم، وأيام لحظر صارم) حتى تعود تحت عتبتك ويرتفع الحظر من تلقاء نفسه.
- تصرّف بالدرجة الحالية لا بالتاريخ. حدّد المعدل أو تحدَّ أو احظر بناءً على موضع السمعة الآن، فتتعافى البادئة التي تحسّنت أو أُعيد تخصيصها تلقائيًا بدل أن تبقى على قائمة لا يقلّمها أحد.
- احتفظ بالأدلة. خزّن الإشارات التي دفعت كل تغيير في الدرجة (
detection_methodsمن الاستعلام، ونمط الاستمرار) كي يكون الحظر الواسع قرارًا تستطيع تفسيره لا إدخالًا غامضًا.
التلاشي هو ما يُبقي المنظومة كلها صادقة. فهو يعني أن التصعيد العدواني أثناء هجوم لا يصبح ندبة دائمة، ويعني أن قائمة حظرك تعكس من هو عدائي الآن لا من كان عدائيًا مرة.
البدء هذا الأسبوع
- بدّل مفتاح المحدِّد إلى /64. في كل مكان تعدّ أو تحظر فيه الآن لكل عنوان، قنّع IPv6 إلى أول 64 بتًا أولًا. هذا التغيير وحده يسد ثغرة التدوير المجاني، وهو عادةً بضعة أسطر في nginx أو HAProxy أو تطبيقك.
- أضف عدّادات مجمَّعة لـ /56 و/48. تتبّع الإساءة المجمَّعة على البادئات الأصل كي يتخطى مهاجم يدوّر الشبكات الفرعية حدًا أوسع، دون أن توسّع افتراضيًا.
- استعلم عن الشبكة قبل أن توسّع. عند أي تصعيد يتجاوز /64، افحص
asn_type/connection_type: جمّع بحرية على الاستضافة، وابقَ ضيقًا على المحمول والسكني، ولا تحظر مشغّلًا أو نطاق CGNAT حظرًا صارمًا أبدًا. - قيّم الحالات الملتبسة. حيث تكون البادئة مشتركة أو استهلاكية، استخدم
fraud_scoreالمركّبة وrecommended_actionلكل عنوان بدل حظر CIDR فظ. - امنح كل حظر تلاشيًا. خزّن سمعة البادئة بعمر نصفي، وتصرّف بالدرجة الحالية، ودع الفضاء المعاد تخصيصه يتطهر تلقائيًا.
لم يجعل IPv6 منع الإساءة أصعب بقدر ما غيّر الوحدة. لم يعد العنوان هو المستخدم؛ بل /64. فعُدَّ تلك، وصعّد بالدليل، ووازن بنوع الشبكة، ودع الزمن يتولى الصفح. عندها يعود كل دفاع تثق به في IPv4 إلى العمل.
الأسئلة الشائعة
لماذا لا يمكن تحديد معدل عنوان IPv6 كما يُفعل مع عنوان IPv4؟
لأن البروتوكولين يمنحان كل مستخدم قدرًا مختلفًا جدًا من فضاء العناوين. في IPv4 يحصل المشترك عادةً على عنوان واحد، فتحديد المعدل لكل /32 (عنوان واحد) يحدّده لكل مستخدم. أما في IPv6 فيُخصَّص للمشترك الواحد اعتياديًا /64 كاملة. وهذا يساوي 2^64، أي نحو 18.4 كوينتيليون عنوان، وأدوات مثل IP_FREEBIND تتيح لعملية أن ترسل حركتها من أي عنوان في تلك الكتلة مجانًا. ولذلك فتحديد المعدل لعنوان /128 واحد (عنوان IPv6 مفرد) أو إدراجه في قائمة الحظر لا يوقف شيئًا: يستخدم المسيء ببساطة العنوان التالي من بين 18 كوينتيليون. الوحدة الصحيحة في IPv6 هي /64 لا /128.
على أي طول بادئة أحدّد معدل IPv6؟
ابدأ من /64. فهي أصغر كتلة مضمون أنها تعود لمستخدم نهائي واحد، لأن SLAAC تتطلب /64 كاملة لكل شبكة فرعية ويخصص مزودو الإنترنت /64 على الأقل لكل عميل. اجعل عداداتك وقوائم الحظر مفتاحها أول 64 بتًا من العنوان وعامل /64 كاملة بوصفها فاعلًا واحدًا. وحين تستمر الإساءة عبر عدة /64 من العميل نفسه، وسّع النطاق إلى /56 (256 من /64) ثم /48 (65,536 من /64)، وهما الحجمان المعتادان لتخصيص منزل كامل أو شركة.
هل حظر /64 كاملة في IPv6 آمن؟
في الغالب نعم، وهو أكثر أمانًا من حظر عنوان IPv4 واحد. فـ /64 مصممة لتكون الشبكة الفرعية لمشترك واحد، لذا نادرًا ما يلتقط حظرها عابرًا لا علاقة له كما يفعل عنوان CGNAT مشترك في IPv4. والخطر الحقيقي في البادئات الأوسع: فـ /48 أو /32 قد تكون مزود إنترنت كاملًا أو مشغّل اتصالات محمولة أو نطاق استضافة مشتركة يغطي آلاف المستخدمين غير المترابطين. وسّع النطاق فقط حين يبرره نوع الشبكة: بجرأة على بادئات الاستضافة ومراكز البيانات، وبحذر على بادئات المحمول والسكني.
كيف أعرف إلى أي مدى أوسّع الحظر؟
دع أمرين يقرران: الاستمرار ونوع الشبكة. الاستمرار: إن ظلت الإساءة تعاود الظهور من /64 جديدة داخل /56 أو /48 نفسها، فذلك التخصيص كله كيان واحد وتوسّع إليه. نوع الشبكة: إن أعاد الاستعلام ASN استضافة أو مركز بيانات فالبادئة بنية تحتية ويمكنك التجميع بسرعة؛ وإن كان مشغّل اتصالات محمولة أو مزود إنترنت سكنيًا فقد يقف خلف البادئة الأوسع مستخدمون حقيقيون كثيرون، فابقَ ضيقًا واعتمد على درجة المخاطر بدل الحظر الصارم.
هل يغيّر CGNAT وشبكات المحمول طريقة تعاملي مع IPv6؟
نعم، في الطرف الواسع. فـ /64 واحدة في IPv6 هي عادةً مشترك واحد حتى على المحمول، لذا يبقى تحديد المعدل لكل /64 صحيحًا. لكن مشغّلي المحمول ونشرات 464XLAT/NAT64 قد تضع مشتركين كثيرين تحت بادئة أوسع مشتركة، فحظر بعرض /48 أو /32 على ASN محمول قد يطيح بشريحة كبيرة من عملاء المشغّل. والقاعدة كما في IPv4: لا تحظر نطاقًا مشتركًا حظرًا صارمًا بسبب مسيء واحد. قيّمه، واحتفظ بالحظر الواسع لبادئات البنية التحتية.
كم ينبغي أن تبقى بادئة IPv6 محظورة؟
ليس إلى الأبد. فبادئات IPv6 يُعاد تخصيصها، و/64 التي أساءت إليك الشهر الماضي قد تكون عميلًا مختلفًا الشهر القادم. أرفق بكل بادئة سمعة متلاشية بدل إدخال دائم: ارفع درجتها عند الإساءة، ودعها تنخفض مع الوقت إذا لم يحدث سوء، وأسقط الحظر تلقائيًا حين تتلاشى دون عتبتك. فقائمة حظر دائمة على فضاء عناوين متغير تتحول ببطء إلى قائمة بعناوين لم يعد بإمكانك الوصول إليها بأمان.
الفريق الذي يقف وراء واجهة GeoIPHub API
بقلم فريق GeoIPHub، وهم من يبنون واجهة GeoIPHub API لاستخبارات IP وماسحها. تُعَدّ المسودات بمساعدة الذكاء الاصطناعي ويحررها الفريق، وأمثلة API استعلامات حقيقية على واجهة API الحية ما لم تُوصف بأنها توضيحية.
استخبارات IP