DS-Lite חוסם אחסון IPv4 נכנס, לא VPN יוצא

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

איזה צד מתחיל את החיבור

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

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

עקבו אחרי בקשה יוצאת

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

Client's IPv4 VPN packet
  → Customer B4
  → IPv4 carried over the provider's IPv6 network
  → AFTR address translation
  → IPv4 VPN server

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

התצורה של הלקוח עצמו שגרתית באותה מידה. היא צריכה נתיב IPv4 עובד לשרת, שה-B4 וה-AFTR מספקים, והיא צריכה ששם המארח של השרת יפוענח לכתובת IPv4.

למה אחסון נכנס הוא המקרה שנכשל

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

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

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

אבחנו לפני שמשנים את תוכנית הגישה

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

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

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

קראו את שינויי הספק בעיון

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

ההוראה להפעיל ערימה כפולה היא דו-משמעית עד שמישהו מאשר מה הספק באמת מספק. התייחסות אליה כדרישה אוניברסלית ללקוחות VPN של IPv4 הופכת השערה למדיניות.

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