קידומת סניף IPv6: iroute-ipv6 או route-ipv6 בשרת?

שתי הנחיות עם כמעט אותו שם מופיעות בכל דוגמה שעובדת, והעתקה של האחת בלי השנייה יוצרת מנהרה שנראית תקינה ומאבדת בשקט את קידומת הסניף. הן עושות עבודה שונה משני צדי אותו גבול: האחת מלמדת את גרעין השרת היכן גרה קידומת, והשנייה מלמדת את OpenVPN איזה לקוח מאומת נושא אותה. אם שתיהן נכונות, הקידומת זורמת; אם אחת, לחבילות יש מסלול אבל אין בעלים.

שתי הנחיות, שתי עבודות שונות

route-ipv6 היא התקנת מסלול רגילה: השרת מוסיף מסלול גרעין שמצביע על הקידומת לממשק המנהרה שלו. iroute-ipv6 שייכת להקשר ספציפי ללקוח ומכריזה על בעלות פנימית, כך שהדמון יודע שתעבורה לקידומת הזו צריכה להישלח ללקוח מסוים ולא לעמית שמסלול גרעין במקרה מציין.

האחת עוסקת בטבלת ההעברה של הגרעין, האחרת במודל הניתוב הפנימי של הדמון. שמירה עליהן בנפרד מסבירה למה תצורה שנראית שלמה עדיין יכולה לאבד את הקידומת. היא גם מסבירה למה אותה רשת מופיעה פעמיים בכל דוגמה שעובדת. אף אחת משתי השורות אינה מיותרת.

בהתקנת userspace המסורתית שתיהן נדרשות והן משלימות זו את זו. מסלול גרעין לבדו משאיר את הדמון בלי יכולת לבחור עמית. iroute לבדו משאיר את הגרעין בלי דרך למנהרה. מכאן מגיע גם רוב הבלבול סביב קבצים לכל לקוח: הקובץ אינו רשומה בטבלת הניתוב, ורשומת המסלול אינה הצהרת בעלות.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

לאן שייכת כל אחת

המסלול נכנס לתצורה המנוהלת של השרת, שם הוא חל על תהליך השרת הזה. ה-iroute נכנס לקובץ הספציפי ללקוח, הנקרא על שם הזהות המאומתת של התקן הסניף.

שם קובץ שאינו תואם לזהות בפועל לא נקרא לעולם, והתסמין זהה ל-iroute חסר. בדוק את הזהות שהשרת אימת, ואחר כך בדוק את שם הקובץ תו אחר תו.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

החזק את ה-pool ואת קידומת הסניף בנפרד, כי החפיפה ביניהם יוצרת חידה שאף הנחיה לא יכולה לפתור.

מה צריך לקוח אחר

לקוח שני שאמור להגיע לסניף הזה צריך הכרזה, לא בעלות. דחוף את הקידומת ללקוחות שאתה מתכוון אליהם, בהקשר הלקוח או הקבוצה שמתאים לתצורה שלך.

אל תשלח אותה לסניף עצמו, כי להתקן הזה כבר יש את הקידומת כרשת מחוברת.

שליחה לכולם היא בחירה עם השלכות: אז כל לקוח מאמין שהסניף נגיש דרך המנהרה, כולל לקוחות שמעולם לא התכוונת לתת להם את הגישה הזו. הכרזה היא בפועל החלטת גישה, למרות שההנחיה נראית כמו עבודת שרברבות. ה-הפניה לאפשרויות השרת מתעדת את iroute-ipv6 כבעלות ספציפית ללקוח, וזה ההבדל שכדאי לשמור.

מסלול החזרה בהתקן הסניף

בעלות עוזרת רק אם הסניף מעביר חבילות וה-LAN שלו יודע איך לענות. הפעל העברת IPv6 בהתקן הסניף ואשר שהמארחים ב-LAN שלו שולחים תעבורה עבור pool ה-VPN חזרה אל הסניף ולא למסלול ברירת מחדל שלא מכיר את ה-pool.

מסלול החזרה הזה הוא המקבילה ל-IPv6 של בעיית המסלול החסר שאנשים נתקלים בה עם IPv4.

בדוק אותו ממארח ב-LAN בשאילתה לכתובת pool ה-VPN, לא מהסניף עצמו. שאילתה שנעשתה בנתב עונה על שאלה אחרת מזו של המשתמשים שלך, והשתיים חולקות לעתים קרובות מספיק כדי שהפקודה הנוספת תהיה שווה.

כשהזוג עדיין לא מספיק

יש פריסות שלא משתמשות במסלול הזה בכלל. מסלול הנתונים של הגרעין ושרתים מנוהלי מוצר יש להם טיפול מסלולים נתמך משלהם, ודוגמת userspace עשויה לא לעבור ישירות.

אשר איזה מסלול נתונים הבנייה שלך משתמשת בו לפני שאתה מעתיק הנחיות ממדריך שנכתב עבור האחר.

ולבסוף, זכור את טווח הכתובות: קידומת מקומית ייחודית כמו fd00:7a::/64 היא פרטית מלכתחילה ואינה אומרת דבר על נגישות IPv6 ציבורית. התייחס אליה כאל גישה פנימית, והחזק את היציאה לאינטרנט כשאלה נפרדת עם מדיניות משל עצמה.