OpenVPN TAP ב-macOS: בדקו את הלקוח לפני שמתחילים לאתר תקלות

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

שלב 1: ודאו שהפרופיל באמת מבקש TAP

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

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

אם הקובץ מכיל dev tap או dev tap0, הלקוח חייב לממש ממשק TAP. אם הוא מכיל dev tun, שאר המאמר הזה לא חל והתקלה נמצאת במקום אחר.

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

שלב 2: דעו מה מצב ההתקן באמת משנה

ממשק TUN נושא חבילות IP. הלקוח קורא וכותב חבילות הממוענות לעמית IP, ומערכת ההפעלה מנתבת אותן כמו כל ממשק אחר.

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

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

שלב 3: בחרו בין לקוח תואם לבין הגירה

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

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

מה שלא עובד זה לשנות את tap ל-tun בעותק המקומי ולקוות. השרת עדיין מגשר, הלקוח עכשיו מדבר IP, ושום דבר לא מסתדר.

שלב 4: אספו את העובדות לפני ששינוי שירות עובד

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

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

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

שלב 5: אמתו את ההגירה משני הקצוות

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

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

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

כשזה עדיין נכשל, קראו את השגיאה הראשונה

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

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