איך לבדוק IPv6 דרך VPN עם משאב משלך

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

שלב 1: הצהירו איזה מסלול IPv6 אתם בודקים

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

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

שלב 2: אשרו שהמארח בוחר במסלול הזה

ip -6 route get 2001:db8:1::10 מדפיס את המסלול, את כתובת המקור ואת הממשק שהגרעין היה משתמש בו, ועל העובדה הזו נשען שאר הבדיקה.

קיומו של ממשק אינו זהה לבחירה בו. למארחים עם ערימה כפולה יש טבלת עדיפויות, הקובץ /etc/gai.conf ב-Linux יכול לשנות איזו משפחה מנצחת עבור שם שמתפרש לשתיהן.

שלב 3: השתמשו ביעד ובשם לגיטימיים

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

הריצו את הבקשה בצורה שמראה את הכתובת שבה השתמשה: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. האפשרות -6 כופה את המשפחה, וכך אתם מפרידים בין IPv6 לא עובד לבין IPv6 לא הועדף.

לבדיקת נגישות טהורה שבה ICMPv6 מותר, ping -6 -c 3 2001:db8:1::10 מספיק. הוא מוכיח את המסלול ושום דבר מעליו.

שלב 4: התאימו בין שני הקצוות

כשיש לכם גישה לשני הקצוות, הריצו tcpdump -ni any ip6 and host 2001:db8:1::10 בלקוח ואת המקבילה במשאב, עם חותמות זמן, ואשרו שאותו זרם מופיע בשניהם. זה מה שהופך תוצאה סבירה לראיה: תצוגת הלקוח לבדה אינה יכולה להבחין בין תשובה מהמשאב לתשובה ממשהו שבאמצע. שמרו על לכידה צרה ליעד אחד כדי שהפלט יישאר קריא ושהישיבה הלא-קשורה של אף אחד לא תגיע לקובץ.

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

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

שלב 5: רשמו מה הבדיקה לא הוכיחה

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

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