להוסיף IPv6 פרטית למעבדת OpenVPN, נקודת ביקורת אחת בכל פעם

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

נקודת ביקורת ראשונה: החיבור שכבר עובד

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

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

נקודת ביקורת שנייה: בחרו את הקידומות הפנימיות

בחרו ULA /48 לאתר וגזרו ממנה שתי /64: אחת ללקוחות המנהרה, אחת למקטע ה-LAN שמחזיק את עומס העבודה IPv6. צרו את המזהה הגלובלי של 40 סיביות במקום להעתיק קידומת לדוגמה, ובדקו את שתי תתי-הרשתות מול כל רשת שהאתר כבר מנתב:

Outer transport: IPv4 OpenVPN UDP
IPv4 pool:       10.90.0.0/24
IPv6 VPN pool:   fd73:93bc:b6e9:77::/64
IPv6 LAN:        fd73:93bc:b6e9:60::/64
Server LAN IPv6: fd73:93bc:b6e9:60::1

שתי /64 עצמאיות מונעות גזירה של מאגר הלקוחות מתוך מקטע ה-LAN, וזה חשוב בהמשך כשתכתבו את נתיב החזרה. הערכים למעלה הם דוגמה מעובדת אחת, לא קידומת לשימוש חוזר.

נקודת ביקורת שלישית: הוסיפו את העוזר ואת דחיפת הנתיב

קראו את תצורת השרת הנוכחית לפני שמוסיפים משהו. עותק שני של הנחיה קיימת אינו מתמזג עם הראשון, והשגיאה שתיווצר נוקבת בשם ההנחיה ולא ב-IPv6. כשהעוזר IPv4 כבר קיים, שתי שורות מרחיבות אותו. כל אחת עונה על שאלה אחרת:

server-ipv6 fd73:93bc:b6e9:77::/64
push "route-ipv6 fd73:93bc:b6e9:60::/64"

הראשונה היא עוזר נוחות שמגדיר את הממשק ואת מאגר הלקוחות. השנייה נוקבת ביעד ה-LAN שאליו הלקוח צריך להגיע. הקצאת כתובת IPv6 ללקוח לא אומרת לו אילו רשתות קיימות מאחורי השרת, ולכן שתי השורות נחוצות.

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

נקודת ביקורת רביעית: העברה ונתיב התשובה

הפעילו העברת IPv6 בשרת דרך בעל התצורה של המערכת עצמה, לא בכתיבת זמן ריצה חד-פעמית שתשכחו. צורת זמן הריצה שימושית לבדיקה מהירה. תצורה מתמשכת שייכת לקובץ drop-in שבעל הרשת של ההפצה קורא:

sysctl -w net.ipv6.conf.all.forwarding=1

ההעברה משנה את התנהגות ה-IPv6 של המארח מעבר לניתוב מנות. מארח שקיבל הודעות נתב כלקוח מפסיק לעשות זאת באותו אופן ברגע שהוא מעביר. לכן מכונה שצינור ה-IPv6 שלה תלוי ב-RA זקוקה לתוכנית מפורשת לאותו צינור.

אחר כך תנו ל-LAN נתיב חזרה אל מאגר המנהרה. שער ה-IPv6 של עומס העבודה הוא הנתב של ה-LAN, לא שרת ה-VPN, ולכן הנתיב שייך לנתב הזה ומצביע לכתובת ה-LAN של השרת:

ip -6 route add fd73:93bc:b6e9:77::/64 via fd73:93bc:b6e9:60::1

שמרו על סוגי ICMPv6 שהקישור צריך, כולל משוב MTU של הנתיב. כלל חומת אש של IPv4 אינו מרמז על כלל IPv6, וחסימה גורפת של IPv6 שוברת גילוי שכנים באופן שנראה כמו תקלת ניתוב.

נקודת ביקורת חמישית: קראו את הלקוח, ואז בדקו

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

ip -6 addr show tun0
ip -6 route get fd73:93bc:b6e9:60::20

נתיב שבוחר במנהרה מוכיח שהלקוח יודע לאן לשלוח את המנה. הוא לא מוכיח שהשרת מעביר אותה, שלנתב ה-LAN יש את נתיב החזרה, או שהיישום רשאי להשיב.

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

פרסמו רשומת AAAA רק כשנתיב ה-IPv6 עונה מקצה לקצה. DNS שנשאל דרך IPv4 עדיין יכול להחזיר כתובת IPv6, ולכן שם שניתן לפתור אינו הוכחה שמשהו מאזין. הנחיית RFC 4193 ל-ULA מכסה את יצירת המזהה הגלובלי שהופך את הקידומות האלה לשלכם ולא להעתק.