פיצול ה-/64 שלכם לא מנתב IPv6 ללקוחות VPN

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

המיתוס: חלק מה-/64 שלכם כבר נגיש

הסיפור מפתה: לשרת יש /64 ציבורי, חתכו אותו לשניים, מסרו את החצי השני לבריכת ה-VPN, והלקוחות האלה כבר באינטרנט. פיצול הקידומת אכן מקצה כתובות בלי התנגשויות. אבל הוא לא משנה איך רשת ה-upstream מחליטה לאן צריך ללכת חבילה לאחת מהכתובות האלה.

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

זו כל התקלה: הכיוון קדימה עובד כי השרת שלכם שולח אותו, וכיוון החזרה מת במרחק קפיצה אחת כי ה-upstream מעולם לא ידע שהלקוח קיים.

מה מסירה על הקישור באמת דורשת

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

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

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

מה מסירה בניתוב דורשת

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

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

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

שני נתיבים בלתי תלויים להצליח בהם

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

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

שמרו על תנועת הבקרה ש-IPv6 תלוי בה פועלת תחת כל מדיניות שתחילו. הודעות Packet Too Big הן הקורבן הקלאסי של חומת אש שמתירה רק TCP ו-UDP, והשלכתן מייצרת חיבורים שמתבססים ואז נתקעים בהעברות גדולות יותר.

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

תעדו את העיצוב כדי שבנייה מחדש תשחזר אותו

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

ואז בדקו את כיוון החזרה במפורש, עם חבילה שחייבת לחזור מבחוץ. מדריך openvpn(8) מכסה את האפשרויות server-ipv6 ו-redirect, ואישור הניתוב מהספק שלכם מכסה את החצי שהמדריך לא יכול.