IPv6 דרך שרת VPN של IPv4 עדיין דורש יציאת IPv6
העברת IPv6 בתוך מנהרת IPv4 היא החצי הקל. היציאה עדיין זקוקה ל-upstream אמיתי של IPv6, לקידומת מקור שמישה ולנתיב חזרה עבור המאגר.
המנהרה עולה, הלקוח מקבל כתובת IPv6 מהמאגר, ובכל זאת כל יעד IPv6 מגיע לפסק זמן. שום דבר לא שבור במנהרה: IPv6 רוכב היטב בתוך תעבורת IPv4, וזה מעולם לא היה החלק הקשה. הכתובת שהנפקת היא הבטחה שהשרת אינו יכול לקיים, כי ליציאה אין upstream של IPv6 שאליו לשלוח אותה. התיקון שייך ליציאה, לא לפרופיל הלקוח.
התסמין: כתובת ואין נתיב
בדיקה בצד הלקוח מראה כתובת IPv6 שנראית גלובלית על התקן המנהרה ונתיב שמצביע לתוכה, ולכן זה נקרא בטעות כתקלה בלקוח. התעבורה נכנסת למנהרה, השרת מפרק את המעטפת, ואז החבילה נוחתת על מארח שטבלת הניתוב שלו אינה כוללת נתיב ברירת מחדל ל-IPv6 לשום מקום אמיתי. בהתאם למחסנית תקבל אי-הגעה מיידית או השלכה שקטה, ובשני המקרים הלקוח רואה פסק זמן שנראה בדיוק כמו חומת אש.
קרא את טבלת הניתוב של השרת עצמו לפני שאתה נוגע בלקוח, כי שם נמצא החצי החסר של הנתיב. שרת עם נתיב ברירת מחדל אחד של IPv4 כבר נתן לך את התשובה.
עקוב אחר החבילה לאחר פירוק המעטפת
בתוך המנהרה החבילה היא IPv6 רגילה והמקור שלה הוא כתובת הלקוח. השרת מסיר את מעטפת התעבורה ואז מחזיק חבילת IPv6 מקורית שיש להעביר לקפיצה הבאה ב-IPv6. נתיב ברירת מחדל של IPv4 אינו יכול לשאת אותה, ותרגום שלה ל-IPv4 הוא פונקציה אחרת שאיש לא פרס. זו כל התקלה, ואין לה שום קשר לשאלה אם מאזין ה-VPN ענה דרך IPv4.
המכניקה של עטיפת IPv6 מעל IPv4 מתוארת ב-RFC 4213, והפרט החשוב שם הוא שנקודות הקצה עדיין זקוקות לקישוריות IPv6 אמיתית בצד השני של המנהרה. עטיפת כותרת אינה יוצרת upstream משום דבר.
שתי שכבות מנהרה, שתי בדיקות בלתי תלויות
אמת כל שכבה בנפרד, כי מנהרה חיצונית שעובדת מסתירה מנהרה פנימית שבורה. בדוק את הנתיב החיצוני בפינג IPv4 מהלקוח לשרת ואשר את הפורט שאתה משתמש בו. לאחר מכן בדוק את הנתיב הפנימי בשרת, שבו ip -6 route חייב להציג נתיב ברירת מחדל או נתיב ספציפי שנלמד מ-upstream אמיתי, ו ip -6 addr חייב להציג קידומת מקור שה-upstream מקבל. כל דבר פחות מזה הוא קישוט על הממשק.
כתובת מקומית-ייחודית, או קידומת שנראית גלובלית ששום דבר אינו מנתב חזרה אליה, תופיע בשמחה על ממשק ולא תלך לשום מקום. הנגישות הציבורית ניתנת על ידי ה-upstream, לא על ידי צורת הכתובת.
אותו דבר חל בלקוח: ip -6 route get 2001:4860:4860::8888 אמור לציין את התקן המנהרה, ואם הוא מציין את הפיזי, הלקוח כלל אינו משתמש ב-VPN עבור IPv6.
קידומת מקור, גודל ו-ICMPv6
שאל את ה-upstream אילו קידומות מקור יקבל להעברה, והשתמש באחת מהן עבור מאגר הלקוחות. ספק שנותן לך /64 עבור הממשק של השרת עצמו אינו בהכרח מנתב אליך /64 שני או בלוק גדול יותר, וההבדל הוא אחר צהריים של דיבוג שקריאת תמיכה פותרת בשאלה אחת. שאל בכתב ושמור את התשובה עם התצורה.
תקצב את העטיפה הנוספת שהמחסנית שלך באמת משתמשת בה, והשאר את ICMPv6 עובד, כולל Packet Too Big. כותרת שנייה מקטינה את המטען השמיש, כך שנתיב שעונה לפינגים קטנים עדיין עלול להיכשל בהעברת קובץ, וחומת אש שמפילה את כל ה-ICMPv6 הופכת בעיית גודל ניתנת לתיקון לחור שחור. בדוק העברה גדולה אחת לפני שאתה מכריז על השירות.
מה שהוא בעיה אחרת לגמרי
הגעה ליישום שהוא IPv4 בלבד מלקוח שהוא IPv6 בלבד היא תרגום, לא מנהרה, ודורשת משהו כמו פריסה מכוונת של NAT64. היעד לא יבין כותרת מנהרה נוספת רק מפני שהוספת אחת. שירותי מעבר היסטוריים ראויים לאותה הקפדה: RFC 7526 ביטל את מודל ממסר ה-anycast של 6to4, ולכן מדריך שנכתב סביבו מתאר משהו שאין לו עוד ממסר ציבורי מתוחזק.
אם לשרת אין upstream שמיש של IPv6, האפשרויות הן upstream נתמך, יציאה אחרת, או החלטה מתועדת ש-IPv6 נשאר מחוץ למנהרה. מה שאינו מקובל הוא לומר ללקוחות שקיים שירות IPv6 בעוד החיבור הרגיל שלהם ל-IPv6 עוקף בשקט את ה-VPN.