האם תעבורת IPv6 צריכה לעבור דרך ה-VPN או ישירות?
החליטו אם ::/0 שייך בתוך המנהרה, לפי שלושה תנאים: תמיכת היציאה, נגישות נקודת הקצה ורשתות מקומיות בלבד.
שני אנשים ביקשו ממני בחודש שעבר תוצאות הפוכות: האחד רצה ש-VPN יכסה את IPv6, והשני רצה שמדפסת המשרד תמשיך לעבוד. נתיב בודד ::/0 לא יכול לספק את שניהם בעצמו. האם הנתיב הזה שייך בתוך המנהרה תלוי בשלושה תנאים, והראשון פוסל אותו ברוב היציאות המסחריות. אם היציאה אינה נושאת IPv6, ניתוב נתיב ברירת המחדל לתוכה מסתיר את התעבורה שלכם במנהרה שאין לה לאן לשלוח אותה.
שלושה תנאים קובעים את התשובה
נתיב ברירת המחדל הוא שורה אחת, ::/0, והוא מתאים לכל יעד IPv6 בלי נתיב ספציפי יותר (RFC 4291). התקנתו קלה. ההחלטה אם כדאי לכם מגיעה לשלושה תנאים.
תנאי ראשון: ליציאה שאליה אתם מתחברים יש IPv6 עובד והיא מוכנה להעביר אותו. תנאי שני: הלקוח שלכם יכול לשמור נתיב לנקודת הקצה של המנהרה, שבדרך כלל נמצאת בתוך הטווח שאתם עומדים לנתב. תנאי שלישי: אתם יכולים לנקוב ביעדי IPv6 המקומיים שחייבים להישאר מחוץ למנהרה.
כל תנאי נכשל בדרכו, ולכן ניחוש עולה ערב שלם. תנאי ראשון שנכשל נותן לכם שקט וטבלת ניתוב שנראית נכונה. תנאי שני שנכשל הורג את לחיצת היד שניות ספורות אחרי שהיא מתחילה. תנאי שלישי שנכשל משאיר מנהרה עובדת ועמית לא מרוצה ליד המדפסת.
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
האם היציאה באמת נושאת IPv6?
ממשק מנהרה עם כתובת IPv6 לא מוכיח דבר על הצד השני. פרופילים מסחריים רבים הם IPv4 בלבד מבפנים: השרת נותן לכם כתובת v4 וזורק את כל השאר. התקינו מעל זה נתיב ברירת מחדל מ-AllowedIPs והליבה תשלח בשמחה IPv6 לממשק שהצד השני שלו לא רואה אותו לעולם.
בדקו מהלקוח כשהמנהרה פעילה. ping -6 -c 3 2001:4860:4860::8888 ו-ip -6 route get 2001:4860:4860::8888 עונים על שאלות שונות: אם חוזרת תשובה, ואיזה התקן הליבה בחרה. כשהשני נוקב בשם המנהרה שלכם והראשון לא מחזיר דבר, הבעיה ביציאה, לא בנתיב.
אם אתם מפעילים את היציאה בעצמכם, בדיקת הלקוח יכולה לעבור והנתיב עדיין ייגמר במבוי סתום. ודאו ש-net.ipv6.conf.all.forwarding=1 מוגדר בשער ושחומת האש שלו מקבלת מנות שמועברות החוצה מהמנהרה. מנה שמנותבת כראוי ליציאה שמסרבת להעביר הלאה נראית מצד הלקוח בדיוק כמו באג ניתוב.
האם הלקוח יכול לשמור על הנתיב לנקודת הקצה?
זה המקרה שתפס אותי במחשב נייד עם נקודת קצה של WireGuard שעובדת רק ב-IPv6. כתובת נקודת הקצה היא כתובת גלובלית רגילה, ולכן היא נופלת בתוך ::/0. נתבו את כל הקידומת לממשק ומנות לחיצת היד ירדפו אחרי עצמן אל תוך המנהרה שהן עדיין מנסות לבנות. המנהרה לא עולה לעולם, ושום דבר בפלט הלקוח לא אומר למה.
wg-quick מטפל בזה בלינוקס. הוא גוזר נתיבים מ-AllowedIPs, מתקין אותם בטבלה משלו ומוסיף כלל מדיניות כך שתעבורה לנקודת הקצה תיפתר קודם דרך הטבלה הראשית: הכלל suppress_prefixlength 0 שתמצאו ב-ip -6 rule. לכן wg-quick up מצליח היכן ש-ip -6 route add default dev wg0 שנכתב ביד מנתק אתכם.
בדקו את שני המצבים עם ip -6 route get <endpoint-v6>, לפני ואחרי העלאת המנהרה. אם התשובה משתנה להתקן המנהרה שלכם, הסרתם את הנתיב שהמנהרה צריכה. כשאתם כותבים את הנתיבים בעצמכם, הוסיפו נתיב מארח לנקודת הקצה דרך השער המקורי, או התחברו לנקודת הקצה דרך IPv4 והשאירו את IPv6 למטען.
מה חייב להישאר מחוץ למנהרה?
נתיבים ספציפיים יותר מנצחים את ברירת המחדל, ולכן קידומת על הקישור או טווח ULA עם נתיב משלו ממשיכים לעבוד בלי מאמץ נוסף. זו הסיבה השקטה לכך שכל כך הרבה תצורות IPv4 עם מנהרה מלאה שורדות: קידומות ה-LAN ספציפיות יותר מברירת המחדל ולעולם לא נכנסות למנהרה.
זה נשבר כשאפשר להגיע להתקן מקומי דרך כתובת גלובלית, וזה נורמלי למדפסת שקיבלה קידומת ציבורית מאותו נתב, ל-NAS או לטלוויזיה. הכתובות האלה מתאימות ל-::/0 ולשום דבר אחר, ולכן הן עוברות למנהרה עם כל השאר ונעלמות.
החליטו לפי יעד, לא לפי פרוטוקול. אם שניים או שלושה מארחים מקומיים חשובים, תנו לקידומות שלהם נתיב החוצה דרך הממשק הפיזי, או הסירו אותם מהקבוצה שנדונה. אם הרשימה ממשיכה לגדול, התשובה הכנה היא ניתוב מפוצל ל-IPv6 עם רשימת חריגים כתובה, לא ברירת מחדל שאתם ממשיכים לתקן.
אם התשובה היא לא, חסמו אותו
להשאיר את IPv6 בלי נתיב זה לא אותו דבר כמו להשאיר אותו בשקט. מארח עם ברירת מחדל עובדת של IPv6 ממשיך להשתמש בה בזמן שהמנהרה נושאת IPv4, ולכן התעבורה יוצאת לצד ה-VPN וכל שירות שמעדיף IPv6 רואה את הכתובת האמיתית שלכם. זו דליפה, לא מנהרה מפוצלת.
בחרו אחת ורשמו איזו בחרתם. נתבו את ברירת המחדל וקבלו את הפשרות שלמעלה, או השביתו את IPv6 למשך קיומה של המנהרה. השמטת הקידומת מ-AllowedIPs לא מספיקה בפני עצמה, כי מערכת ההפעלה שומרת על ברירת המחדל שלה. בלינוקס הגרסה הגסה היא sysctl -w net.ipv6.conf.all.disable_ipv6=1; הגרסה העדינה מפילה את IPv6 מחוץ למנהרה בכלל חומת אש. לקוחות טלפון כוללים מתג חסימת IPv6 מפורש שעושה את אותה עבודה.
אמתו את זה כמו דליפה
העלו את המנהרה וקראו את המצב במקום לסמוך על המתג. ip -6 route show default אמור להראות ברירת מחדל אחת, ו-ip -6 route get ליעד מחוץ ל-LAN שלכם אמור לנקוב בשם התקן המנהרה. חזרו על שניהם אחרי ניתוק: ברירת מחדל ששורדת את המנהרה היא הבאג שחיפשתם.
אחר כך בדקו את הכיוון השני. ממארח ברשת המקומית, הגיעו ללקוח בכתובת ה-IPv6 המקומית שלו. אם זה מפסיק לעבוד, תנאי שלישי מעולם לא התקיים, יהיה אשר יהיה מה שטענה טבלת הניתוב אז.
רשמו את התוצאה במקום שבו האדם הבא ימצא אותה: אילו קידומות נשארות מקומיות, למה, ומה הלקוח עושה אחרי ניתוק. שתי שורות ב-runbook חוסכות מהמהנדס הבא לגלות מחדש את לולאת נקודת הקצה בחצות.