IPv6 דרך מנהרת OpenVPN: סיור בנתב הביתי

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

התחילו במקום שבו הלקוח נמצא

הביטו בלקוח לפני שנוגעים בשרת. ip -6 addr אמור להראות כתובת מנהרה מהמאגר, ו ip -6 route אמור להראות את הקידומת הנדחפת שמצביעה על התקן המנהרה. כשהכתובת קיימת אבל הנתיב לא, הדחיפה חסרה או שהלקוח התעלם ממנה. כשאין אף אחד מהשניים, השרת לא הקצה דבר בכלל.

לאחר מכן בדקו מה הלקוח חושב על העולם שבחוץ. נתיב ברירת מחדל דרך המנהרה תובע את כל תעבורת IPv6, בעוד נתיב עבור 2000::/3 תובע רק יוניקאסט גלובלי. שניהם יכולים להיות נכונים, והם עונים על שאלות שונות בנוגע לדליפה.

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

בדקו את המאגר שהשרת באמת יכול לנתב

שרת יכול להקצות רק מקידומת שהוא באמת שולט בה. אם הספק מאציל /56, הקצו /64 אחד למנהרה והשאירו את השאר ל LAN. ככל שהספק מוסר ב WAN רק /64 אחד ולא מנתב דבר נוסף, השאירו את קידומת ה LAN בשקט ותנו למנהרה טווח מקומי ייחודי, תוך קבלה שלקוחות לא יהיו להם יציאה גלובלית.

המאגר והדחיפה שייכים יחד. server-ipv6 2001:db8:80:10::/64 מקצה כתובות, ו push "route-ipv6 2000::/3" אומר ללקוחות מה לשלוח למנהרה. דחיפת 2000::/3 מכסה יוניקאסט גלובלי ומשאירה טווחי link-local ו multicast מחוץ למנהרה.

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

הפעילו העברה עבור המשפחה השנייה

העברת IPv4 אינה מרמזת על העברת IPv6. הגדירו net.ipv6.conf.all.forwarding=1 ושכפלו כל מה שמדיניות FORWARD של IPv4 כבר מתירה. בנתב ששרשרת ה FORWARD שלו מפילה כברירת מחדל, סט חוקים חסר נראה בדיוק כמו מנהרה מתה.

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

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

תופעת לוואי אחת תופסת את מי שבסוף מאשים את המנהרה. הפעלת העברה גורמת לליבה לדלג על תצורת כתובת דרך הודעת נתב אלא אם אומרים לה אחרת, ונתיב ברירת מחדל שנלמד כך נעלם איתה. או שנעצו נתיב ברירת מחדל מפורש בממשק ה WAN, או שהגדירו שם את accept_ra ל 2 בכוונה. אחרי כל אחד מהשינויים, אשרו שלנתב עדיין יש נתיב IPv6 שמיש החוצה לפני שתבדקו את הלקוחות שוב.

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

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

OpenVPN חושף את הכתובת שהוקצתה לוו client-connect, כך שהרשומות יכולות לעקוב אחרי המאגר האמיתי במקום רשימה שמתוחזקת ביד. הוו מוסיף ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0, וו client-disconnect מתאים מסיר אותו. בלי ההסרה טבלת הפרוקסי מתיישנת ולקוח מאוחר יותר יכול לרשת רשומה לכתובת שהוא מעולם לא קיבל. אשרו את המצב עם ip -6 neigh show proxy.

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

עקבו אחרי המסלול החוצה, קפיצה אחר קפיצה

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

שימו לב ל MTU של המנהרה, כי נתבי IPv6 בדרך לא יפלחו במקומכם. MTU גדול מדי מתגלה כשגיאת packet-too-big ו TLS תקוע במקום כשל נקי. הגדירו אותו במפורש ובדקו עם עומס קרוב לגבול.