תכנון IPv6 לרכזת WireGuard עם שני אתרים: קידומת, עמיתים, מסלולים
עברו על רכזת IPv6 פרטית לשני LAN: בחרו קידומת, הקצו כתובות מנהרה, ואז תנו ל-AllowedIPs להביע איזה עמית מחזיק בכל תת-רשת.
שני LAN, רכזת WireGuard אחת ותוכנית כתובות IPv6 שעליה לענות על שלוש שאלות נפרדות: איזו קידומת, איזו כתובת שייכת לכל נתב, ואיזה עמית מחזיק באיזו תת-רשת. טעות באחת מהן יוצרת מנהרה שעושה לחיצת יד ואינה מנתבת דבר. התוכנית שלהלן עוברת על עיצוב פרטי לשני אתרים בסדר הזה. היא במכוון אינה מספקת גישה לאינטרנט דרך IPv6.
החליטו למה מיועדת הקידומת
קידומת מקומית ייחודית מ-fd00::/8 היא הבחירה הטבעית כשהמטרה היא נגישות פרטית בין אתרים. היא נשארת יציבה ללא תלות בספק שמשרת כל מיקום, והיא אינה מוכרזת בטבלת הניתוב העולמית, ולכן אינה יכולה להדליף את המספור הפנימי שלכם לאינטרנט.
אותה תכונה היא המגבלה. ULA אינו נותן מסלול חזרה ציבורי, כי אין ספק במעלה הזרם שיודע לנתב אותו לשער שלכם. אם הדרישה כוללת יציאה לאינטרנט דרך 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 |
בלוקי ה-LAN הם /64 כי SLAAC רגיל מצפה למזהה ממשק של 64 סיביות. פיצול LAN לבלוק קטן יותר שובר את ההנחה הזו ברוב המארחים, והעלות התפעולית אינה שווה את החיסכון בכתובות בתוכנית פרטית. שני בלוקי ה-LAN מגיעים מאמצע ה-/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 ולא בקידומת הממשק.
כל נתב אתר זקוק גם לכתובת בבלוק ה-LAN שלו ודרך להפיץ אותה, בדרך כלל הכרזות נתב עבור SLAAC. WireGuard אינו שולח את ההכרזות האלה במקומכם, והוא אינו מגשר בין שני ה-LAN. נתב האתר הוא נתב בשני הכיוונים.
שימו את הבעלות על תת-הרשת ב-AllowedIPs
רשומת העמית של הרכזת עבור אתר A מחזיקה בכתובת המנהרה של A וב-LAN של 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 ואת ה-LAN של 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 לכתובת המנהרה של הרכזת בוחן רק את הקפיצה הראשונה ויעבור גם כשמסלולי ה-LAN שגויים. זרם המארח-למארח הוא זה שמוכיח את התוכנית.
חיבור ה-WireGuard החיצוני יכול לרוץ מעל IPv4 בזמן שהתעבורה הפנימית היא IPv6, והעצמאות הזו שימושית במהלך הגירה. אם יוסיף בעתיד יציאה עולמית ל-IPv6, עיינו מחדש בהקצאת הספק, בבחירת כתובת המקור ובניתוב החזרה כשלב עיצוב חדש; התוכנית הפרטית שלמעלה נשארת תקפה לתעבורה בין אתרים.