تخطيط IPv6 لمركز WireGuard بين موقعين: البادئة والأقران والمسارات
اعمل على مركز IPv6 خاص لشبكتين محليتين: اختر بادئة، واحجز عناوين النفق، ثم اترك AllowedIPs يوضح أي قرين يملك كل شبكة فرعية.
شبكتان محليتان ومركز WireGuard واحد وخطة عناوين IPv6 عليها أن تجيب عن ثلاثة أسئلة منفصلة: أي بادئة، وأي عنوان ينتمي إلى كل موجّه، وأي قرين يملك أي شبكة فرعية. إذا أخطأت في واحد منها حصلت على نفق يصافح ولا يوجّه شيئًا. تعمل الخطة أدناه على تصميم خاص بموقعين بهذا الترتيب. وهي لا توفر عمدًا وصولًا إلى internet عبر IPv6.
حدّد الغرض من البادئة
البادئة المحلية الفريدة من fd00::/8 هي الخيار الطبيعي عندما يكون الهدف هو الوصول الخاص بين المواقع. تبقى مستقرة بغض النظر عن مزود الخدمة الذي يخدم كل موقع، ولا تُعلن في جدول التوجيه العالمي، لذلك لا يمكنها تسريب ترقيمك الداخلي إلى internet.
الخاصية نفسها هي القيد. لا توفر ULA مسار عودة عامًا، لأن أي جهة أعلى لا تعرف كيف توجّهه إلى بوابتك. إذا كان الشرط يشمل خروجًا إلى internet عبر IPv6 فأنت بحاجة إلى تخصيص من مزود يوجّهه إليك، وهذا قرار تصميم منفصل بحجم بادئة خاص به.
لا تفترض أن كل عملية نشر تحتاج إلى /48. RFC 6177 ابتعد عن حجم واحد إلزامي للموقع الطرفي، والحجم الصحيح يتبع عدد الشبكات التي ستديرها. أنشئ ULA بإجراء RFC 4193 بدلًا من اختراع بادئة قد تستخدمها منظمة أخرى أيضًا. اكتب النتيجة في خطة العناوين قبل تكوين أي جهاز، لأن بادئة لم يسجّلها أحد هي بادئة سيعيد شخص آخر استخدامها.
قسّم البادئة إلى أدوار
يستخدم المثال أدناه fd7c:2e91:4a00::/48، والجدول منظم حسب مكان كتابة كل كتلة لا حسب الموقع. اعتبر القيم نموذجًا وأنشئ قيمك الخاصة قبل نشر أي شيء.
| Where it is written | What appears there | Block used | What it establishes |
|---|---|---|---|
| Hub wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::1/128 | The hub's own tunnel identity |
| Hub wg0.conf, Site A peer | Two ranges in one AllowedIPs line | ::2/128 and :10::/64 | That A owns its tunnel address and its LAN |
| Hub wg0.conf, Site B peer | Two ranges in one AllowedIPs line | ::3/128 and :20::/64 | That B owns its tunnel address and its LAN |
| Site A wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::2/128 | A's identity as the hub sees it |
| Site B wg0.conf, interface address | A single host address on the tunnel | fd7c:2e91:4a00:ff00::3/128 | B's identity as the hub sees it |
كتل الشبكة المحلية هي /64 لأن SLAAC العادي يتوقع معرّف واجهة بطول 64 بت. تقسيم شبكة محلية إلى كتلة أصغر يكسر هذا الافتراض على معظم المضيفين، والتكلفة التشغيلية لا تستحق التوفير في العناوين في خطة خاصة. تأتي كتلتا الشبكة المحلية من منتصف /48، ما يترك النطاق المنخفض حرًا للمواقع اللاحقة.
عناوين النفق دلو إداري، وليست شبكة على الوصلة. تحصل كل واجهة على /128 واحدة منه، فلا يفترض أي مضيف شبكة فرعية مشتركة على النفق ولا يعمل اكتشاف الجيران حيث لا حاجة إليه. أبقِ الأدوار منفصلة وسجّلها في خطة عناوين المؤسسة حتى لا يعيد موقع لاحق استخدام كتلة.
أعطِ كل موجّه عنوان نفق واحدًا
خصّص /128 واحدة لكل موجّه واحتفظ بالمفاتيح ونقاط النهاية الحالية للمركز العامل. القيم الثلاث أدناه تختلف فقط في جزء المضيف.
Hub: Address = fd7c:2e91:4a00:ff00::1/128
Site A: Address = fd7c:2e91:4a00:ff00::2/128
Site B: Address = fd7c:2e91:4a00:ff00::3/128تصف /128 العنوان الوحيد المخصص لتلك الواجهة. وهي لا تقول شيئًا عن عدد الوجهات التي قد يوجّهها القرين، لأن الوصول يُعبَّر عنه في AllowedIPs لا في بادئة الواجهة.
يحتاج كل موجّه موقع أيضًا إلى عنوان في كتلة شبكته المحلية وإلى طريقة لتوزيعه، عادةً إعلانات الموجّه من أجل SLAAC. لا يرسل WireGuard تلك الإعلانات نيابة عنك، ولا يجسر الشبكتين المحليتين. موجّه الموقع موجّه في الاتجاهين.
ضع ملكية الشبكة الفرعية في AllowedIPs
مدخل القرين الخاص بالموقع A في المركز يملك عنوان نفق A وشبكة A المحلية، وهذا الاقتران هو بيان الملكية كله. لا شيء آخر في قسم القرين هذا يحتاج إلى وصف الموقع.
AllowedIPs = fd7c:2e91:4a00:ff00::2/128, fd7c:2e91:4a00:10::/64مدخل القرين الخاص بالموقع B يملك الزوج المطابق، والتماثل هنا أهم من الإيجاز. اقرأ السطرين معًا يصبح تقسيم الملكية ظاهرًا بنظرة واحدة.
AllowedIPs = fd7c:2e91:4a00:ff00::3/128, fd7c:2e91:4a00:20::/64هذان قسمان منفصلان للقرين، وليسا قائمتين تتنافسان على قرين واحد. يستخدم WireGuard AllowedIPs في الاتجاهين: يختار القرين لوجهة صادرة، ويرفض حزمة واردة لا يطابق مصدرها النطاق المخصص للقرين الذي فك تشفيرها. منح /48 كاملة لكلا القرينين سيعطّل الفحص الثاني ويطمس أي موقع يملك أي كتلة. هذا التمييز هو ما يجعل عنوان المصدر الخاطئ ظاهرًا بدل أن يُقبل بصمت.
لا يحتاج كل موقع إلا إلى الوجهات التي يمكن الوصول إليها عبر قرين المركز: يسرد الموقع A عنوان المركز وعنوان نفق الموقع B وشبكة B المحلية، ويسرد الموقع B المجموعة المقابلة. القوائم غير متماثلة عن قصد، لأن كل موجّه يرى جانبًا مختلفًا من الطوبولوجيا. اكتب الاثنتين من خطة العناوين لا من تكوين الموقع الآخر، وهكذا يبقى نطاق قديم بعد إعادة الترقيم.
مع wg-quick تنشئ هذه النطاقات مسارات أيضًا. مع systemd-networkd أو إعداد يدوي أضف المسارات المكافئة بنفسك؛ وإلا فسيحمل النفق حزمًا لا يرسلها النواة إليه أبدًا.
أكمل إعادة التوجيه واختبر الاتجاهين
فعّل إعادة توجيه IPv6 على المركز وعلى موجّهي الموقعين، واسمح بالخدمات المطلوبة بين المواقع في سياسة التوجيه. أبقِ رسائل ICMPv6 Packet Too Big قابلة للاستخدام، لأن إسقاطها يكسر اكتشاف MTU للمسار وينتج توقفًا في النقل الكبير يبدو كأعطال تطبيقات. المركز الذي يعيد التوجيه دون السماح من جدار الحماية يسقط الحزمة بين التوجيه والنفق. نمط الفشل هذا يستحق المعرفة، لأن النفق يبقى قائمًا وتموت بعض التدفقات فقط.
sysctl net.ipv6.conf.all.forwarding
ip -6 route
ping -6 -c 3 fd7c:2e91:4a00:20::1اختبر من مضيف في الموقع A إلى مضيف في الموقع B ثم في الاتجاه المعاكس. ping إلى عنوان نفق المركز يختبر القفزة الأولى فقط وسينجح حتى عندما تكون مسارات الشبكة المحلية خاطئة. تدفق المضيف إلى المضيف هو ما يثبت الخطة.
يمكن أن يعمل اتصال WireGuard الخارجي عبر IPv4 بينما يكون الترافيك الداخلي IPv6، وهذا الاستقلال مفيد أثناء التهجير. إذا أُضيف خروج IPv6 عالمي لاحقًا، فأعد النظر في تخصيص المزود واختيار عنوان المصدر وتوجيه العودة كخطوة تصميم جديدة؛ تبقى الخطة الخاصة أعلاه صالحة لترافيك الموقع إلى الموقع.