היציאה של IPv6 מתה אחרי הפעלה מחדש של OpenVPN: בדקו מי הבעלים של הקידומת
IPv6 מפסיק לעבוד אחרי שהמנהרה נוצרת מחדש. החליטו מי הבעלים של הקידומת שהוקצתה, כתובות הלקוחות ונתיב החזרה לפני שאתם מפעילים מחדש משהו.
IPv6 מפסיק להעביר תעבורה ברגע ש OpenVPN מופעל מחדש, ו-IPv4 ממשיך לעבוד. ממשק המנהרה נוצר מחדש, ומשהו אחר שניהל את מצב ה-IPv6 שלו איבד או את הכתובת או את הנתיב שהופך את הקידומת לנגישה. שלושה חלקי מצב נפרדים מעורבים, ולכל אחד יש בעלים אחר: הקידומת שהוקצתה מהספק ותוקפה, הכתובות שנמסרות ללקוחות VPN, ונתיב המעלה שמחזיר את קידומת הלקוח הזו לשרת. זהו את הבעלים של כל חלק לפני שאתם נוגעים בדימון כלשהו, כי הפעלה מחדש של הלא נכון מסתירה את הבעיה ליום אחד ומחזירה אותה בחיבור הבא.
שלושה חלקי מצב של IPv6, שלושה בעלים
| State | Typical owner | What breaks when it is wrong |
|---|---|---|
| Delegated prefix and lifetime | Upstream router or provider via DHCPv6-PD | Clients keep addresses that the upstream no longer routes |
| Client addresses inside the tunnel | OpenVPN server config or a delegation daemon | No global address, or an address outside the routed prefix |
| Return route for the client prefix | Upstream router, or the server's own routing table | Outbound works, replies never arrive |
כתובת בעלת תחולה עולמית בתוך המנהרה אינה מספיקה בפני עצמה. נתבים במעלה הזרם עדיין חייבים לשלוח את הקידומת הזו חזרה אל שרת ה-VPN, והם לא יעשו זאת רק מפני שלשרת במקרה יש כתובת מתוכה.
זו גם הסיבה לכך שהעתקת /64 ציבורית לתוך מאגר מנהרה היא מסוכנת. קידומת שמנותבת לשרת אינה אותו דבר כמו קידומת שהמעלה מתייחס אליה כאל on-link, וגילוי שכנים לא ימלא את הפער.
קראו את מצב השרת לפני שאתם משנים משהו
תעדו את המצב פעמיים, פעם אחת כשה-IPv6 עובד ופעם אחת אחרי ההפעלה מחדש, ואז השוו. תצוגות לקריאה בלבד מספיקות, והן לא עולות דבר בחלון תחזוקה:
ip -6 addr show
ip -6 route show table all
ip -6 rule show
sysctl net.ipv6.conf.all.forwardingחפשו שלושה הבדלים מוגדרים: נתיב שנעלם, כתובת שעברה לתוקף מיושן או לא תקף, וקידומת שהשתנתה אחרי הקצאה מחדש בעוד תצורת ה-VPN עדיין מפרסמת את הישנה.
אם הכתובת נעלמה אבל הקידומת לא השתנתה, הדימון שמקצה אותה הפסיק לנהל את הממשק. אם הקידומת השתנתה אבל הכתובות לא, תצורת הלקוח מיושנת. שתי התקלות נראות זהות מהדפדפן ואין להן דבר משותף.
החליטו אם dhcpcd אמור לנהל את המנהרה
dhcpcd יכול לגלות ממשקים ולהקצות חלקים מקידומת DHCPv6 לממשקים במורד הזרם, והתצורה שלו יכולה למנות את יעדי ההקצאה במפורש. בלי יעד מפורש, ההתנהגות המתועדת שלו עשויה לכלול ממשקים אחרים, וכך מנהרה מקבלת כתובת שאיש לא תכנן.
שני תנאים אמורים לדחוף אתכם להשאיר ל-OpenVPN את הכתובות הסטטיות של המנהרה: השרת דוחף כתובות קבועות בתצורה שלו, ושם המנהרה משתנה בהתחברות מחדש. אם שניהם מתקיימים, הוציאו את המנהרה מדימון ההקצאה בכוונה, עם הערה שמסבירה למה.
אם לעומת זאת ההקצאה למנהרה מכוונת, הטמיעו את הטיפול בשינוי קידומת. פירוש הדבר להגיב כשהקידומת שהוקצתה או תוקפה משתנים, לעדכן את קידומת הלקוח שהשרת מפרסם, ולהוסיף שוב את הנתיב. הוצאת הממשק בתכנון כזה מסירה את הרכיב היחיד שיודע על הקידומת החדשה.
הפעלה מחדש של dhcpcd עשויה להיראות כמו תיקון כי היא יוצרת מצב מחדש, אבל היא גם מחדשת או מושכת תצורה לממשקים שלא חשבתם עליהם. השחזור הזה לא הופך אותה לדרישה אחרי כל הפעלה מחדש של VPN. היא גם מאפסת את המונים שהשתמשתם בהם כהוכחה. עדיפו טעינה ממוקדת של הממשק ששיניתם באמת.
אמתו IPv6 בנפרד מה-NAT של IPv4
ודאו שהעברה מופעלת ושנתיב המעלה מצביע על קידומת הלקוח בפועל, ואז צרו חיבור IPv6 חדש ומותר. בדקו גם את טבלת הנתיבים של IPv6 אצל הלקוח עצמו, כי לקוח שמציג כתובת ציבורית לא מוכיח שהבקשה שלו השתמשה במנהרה.
הסוואת IPv4 פותרת בעיה אחרת: נתיב החזרה למקורות פרטיים. היא לא עושה דבר לקידומת IPv6 שנשללה, והוספה שלה לא תחזיר את IPv6.
סיימו עם רישום הבעלות: איזה רכיב מקצה את הקידומת, איזה מקצה כתובות ללקוחות, איזה מחזיק את נתיב החזרה, ומה קורה לכל אחד מהם בהתחברות מחדש. ארבע שורות ב-runbook חוסכות לאדם הבא הפעלה מחדש של שלושה דימונים כדי למצוא את זה שחשוב.