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