כיצד לבדוק את מצב IPv6 של Mac לאחר התנתקות ה-VPN

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

התחילו במשפחה שבאמת נשברה

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

שמרו על אותה רשת Wi-Fi ואותה נקודת גישה לאורך כל ההשוואה. רשת של בית קפה שהציעה IPv6 אתמול לא אומרת דבר על זו שאתם נמצאים בה כעת.

קראו את הכתובת לפני המסלול

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

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

קראו את טבלת המסלולים עבור היעד שנכשל

שאלו את הגרעין על היעד שנכשל, לא על מסלול ברירת המחדל. route -n get 2001:db8::25 מדפיס את הממשק ואת השער שנבחרו עבור אותה כתובת, ו- netstat -rn -f inet6 מציג את הטבלה כולה לשם השוואה. מסלול ברירת מחדל אומר שקיימת ברירת מחדל; הוא לא אומר שהיעד הזה משתמש בו.

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

הפרידו את מדיניות החסימה של הלקוח משארית

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

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

אספו ראיות, ואז שנו דבר אחד

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

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