ממשק utun ב-VPN של Mac פעיל אבל התעבורה נכשלת? בדקו את ifconfig

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

מה באמת מכילה שורת utun

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

קריאה של ממשק בודד היא המקום שבו יושבות הפרטים השימושיים. מנהרה מחוברת נראית בדרך כלל כך:

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

שלושה שדות נושאים את התשובה. UP ו-RUNNING אומרים שהליבה מוכנה להשתמש בממשק. POINTOPOINT יחד עם כתובת העמית --> הם החתימה של מנהרה ולא של קישור פיזי. הערך mtu מסביר מחלקה שלמה של דיווחים מסוג «מתחבר ואז נתקע», כי ממשקי utun עולים בדרך כלל עם MTU מוקטן, 1380 בכמה גרסאות macOS, והלקוח יכול לעקוף אותו. רשימת השדות קצרה מספיק כדי לעבור עליה פעם אחת בתוך מדריך ifconfig שאפל מספקת.

מצאו את התהליך שמאחורי הממשק

ל-ifconfig אין שום מושג של אפליקציה בעלים. שני לקוחות VPN, שירות מערכת ומנהרה שנשארה מהשבוע שעבר כולם מייצרים רשומות שנראות זהות ברמה הזו. ב-Mac שלי, utun0 עד utun3 היו קיימים לפני שהגדרתי משהו; Continuity ו-iCloud Private Relay משתמשים גם הם במנהרות, ואף אחד מהם אינו החיבור שאתם מטפלים בו.

עבור מנהרות שרושמות תצורה במערכת, scutil --nc list הוא ההצלבה המהירה ביותר. הוא מדפיס כל תצורה עם הסטטוס ומזהה השירות שלה, וזו שמחוברת מסומנת כך:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

לקוחות שמריצים תהליך מנהרה משלהם במקום לרשום תצורה לא מופיעים שם לעולם. Tunnelblick ומופע של openvpn משורת הפקודה נכללים בקבוצה הזו, ולכן בדקו גם את טבלת התהליכים: ps -Ao pid,comm | grep -i openvpn. ברגע שתהליך מחזיק במנהרה, מספר ה-utun שייך לאותו תהליך ולאף אחד אחר.

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

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

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

ping -D -s 1372 10.8.0.5

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

הוכיחו שהיעד בוחר במנהרה

השאלה החשובה אינה אם utun4 קיים, אלא אם התעבורה לכתובת אחת מסוימת יוצאת דרכו. route -n get עונה על זה עבור יעד בודד ומדפיס את השער ואת הממשק שבהם ישתמש:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

אם אותה פקודה מדווחת על en0, תצורת המנהרה המפוצלת שלכם עושה את מה שנאמר לה ושום כמות של בדיקת ממשקים לא תשנה זאת. השתמשו ב-netstat -rn -f inet כשאתם צריכים את המסלול הראשי ואת כל הטבלה במבט אחד.

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

netstat -ib | grep utun4

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

כשאין utun בכלל

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

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

השאירו את צד הקריאה לקריאה בלבד. sudo ifconfig utun4 down מנתק את המנהרה, ובפרופיל מנהרה מלאה הוא לוקח איתו גם את הסשן המרוחק שלכם, וזה חילוף גרוע כשרק אספתם ראיות. שום דבר שאתם צריכים כאן לא דורש root: קריאת דגלים, כתובות ומונים עובדת כמשתמש רגיל.

עברו על הבדיקות לפי הסדר בפעם הבאה שמנהרה ב-Mac מתנהגת רע: ודאו ש-utun הופיע עם ifconfig -l, קראו את הדגלים, הכתובות וה-MTU שלו, שייכו אותו לתהליך, שאלו את route -n get איזה ממשק היעד משתמש בו, ואז צפו ב-netstat -ib זז. כל שלב שולל שכבה אחרת, והראשון שחוזר שגוי הוא המקום שבו שייך התיקון.