VPN כפול־מחסנית: הלקוח בוחר את משפחת הכתובות, לא אתם
שם אחד, שתי משפחות, שני נתיבים שונים. המנהרה יכולה להיות תקינה והבקשה עדיין להיכשל, כי הלקוח בחר מועמד שלא נותב מעולם.
המנהרה למעלה, אתרי IPv4 נטענים, ושם מארח אחד נגמר לו הזמן. המסקנה המיידית היא שה-VPN שבור או שהפרטים שגויים, ובדרך כלל אף אחד מהם אינו נכון. השם החזיר גם כתובת IPv4 וגם כתובת IPv6, היישום בחר אחת, ורק לאחד מאותם מועמדים היה נתיב עובד. הלקוח קיבל את החלטת הבחירה; המנהרה פשוט לא כיסתה את מה שהוא בחר.
בחירה אינה הבטחה לכיסוי
בחירת הכתובת המוגדרת כברירת מחדל, המתוארת ב-RFC 6724, קובעת איזה זוג מקור ויעד מארח יעדיף כשקיימים כמה. Happy Eyeballs מוסיף על כך אסטרטגיית חיבור: הוא מתחיל ניסיונות בשתי המשפחות ושומר את זו שעונה ראשונה, כדי שמשתמש לא ימתין שמשפחה שבורה תפוג.
אף אחד מהמנגנונים אינו יוצר נתיב. אם המנהרה שלכם נושאת IPv4 בלבד, מועמד AAAA הוא עדיין יעד לגיטימי שהלקוח עשוי לנסות, והכשל מופיע כטעינה איטית ולא כשגיאה, כי הדפדפן נסוג. המשתמש מדווח על אתר איטי, לא שבור, וכרטיס התמיכה יורש את העמימות הזו. שחזרו זאת עם משפחה קבועה והדוח הופך ספציפי.
הנסיגה הזו היא הסיבה שהתסמין אינו עקבי בין יישומים. דפדפן מסתיר את העיכוב; לקוח שורת פקודה עם משפחה קבועה מראה לכם את הכשל האמיתי מיד.
מצאו את המשפחה שהבקשה השתמשה בה בפועל
התחילו בשם, לא במנהרה. שאלו על שני סוגי הרשומות ורשמו מה חזר:
dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.comאם בקשת v4 מצליחה ובקשת v6 נכשלת, שחזרתם את הבעיה בצורה שאפשר לנפות. אם שתיהן מצליחות מהמעטפת והדפדפן עדיין נכשל, בדקו את הפותר של היישום עצמו או תשובה שמורה לפני שנוגעים במנהרה.
שמרו את המשפחה והיעד בהערות. כרטיס שאומר שהאתר לא נטען דרך ה-VPN אין מי שיכול לבדוק, ואילו כרטיס שאומר ש-AAAA נכשל ו-A עובד מצביע על נתיב מסוים.
בדקו את הנתיב של אותה משפחה
עבור המשפחה שנכשלת, שאלו את הליבה איזה נתיב היא תשתמש בו והשוו אותו לכתובות המוגדרות של המנהרה. ב-Linux, ip -6 route get עבור היעד מציג את הממשק והמקור שייבחרו.
לאחר מכן בדקו את המנהרה עצמה. עמיתי WireGuard נושאים רשימת IP מורשים, ורשומה עבור 0.0.0.0/0 אינה אומרת דבר על IPv6. אם ברשימת העמית אין קידומת IPv6, ללקוח אין סיבה לשלוח תעבורת AAAA לתוך המנהרה, והחבילה יוצאת דרך מה שהמארח היה עושה אחרת.
כללי חומת האש ומדיניות ה-NAT ראויים לאותה בדיקה לכל משפחה. כלל שנכתב עבור IPv4 אינו מכסה IPv6 בשום פלטפורמה, וזו הסיבה הנפוצה ביותר לכך שמשפחה אחת עובדת והאחרת לא.
אל תשביתו IPv6 כדי לפשט את צילום המסך
השבתת IPv6 בכל המערכת תעלים את התסמין ותותיר אתכם בלי אבחון. היא גם שוברת כל יעד שהוא IPv6 בלבד, ומסתירה את אותו באג ביישום הבא. אם מכונה באמת לא אמורה להשתמש ב-IPv6, זו מדיניות מכוונת עם בעלים ובדיקה. השבתה בזמן תקרית אינה אף אחת מהן.
החליטו מה הלקוח צריך לעשות עם המשפחה והגדירו זאת במפורש: העבירו אותה דרך המנהרה, או חסמו אותה בדרך נתמכת כך שהבחירה לא תציע מועמד בלתי נגיש. שתי הגישות לגיטימיות. השבתה גלובלית אינה אף אחת מהן, כי היא בכלל לא גישה.
מה לכתוב בכרטיס
רשמו ארבעה דברים: שם המארח, המשפחה שנכשלה, הנתיב שהליבה בחרה, ותוצאת בקשה ספציפית למשפחה. הסט הזה מספיק למישהו אחר לשחזר את הכשל בלי לנחש לאיזה משני הנתיבים התכוונתם.
כללי בחירת הכתובות של RFC 6724 מסבירים מדוע הלקוח העדיף את המועמד שהעדיף, ו-RFC 8305 מסביר את התנהגות המירוץ שהסתירה את העיכוב. אף אחד מהם לא ינתב חבילה עבורכם, וזה החלק שהמנהרה חייבת לעשות.