TAP או TUN? לקוחות OpenVPN באנדרואיד ושרתים מגושרים
TAP נושא מסגרות Ethernet, TUN נושא מנות IP, ואפליקציית אנדרואיד מקבלת רק את הסוג השני. השוו בין השניים, ואז תקנו את צד השרת.
פרופיל שעובד במחשב נייד נכשל בטלפון. הצעד המתבקש הוא לשנות מילה אחת בקונפיגורציה של הלקוח. המילה הזו לא תעזור, כי שני הקצוות לא מדברים על אותו סוג תעבורה.
TAP נושא מסגרות Ethernet. TUN נושא מנות IP. אפליקציית VPN באנדרואיד מקבלת ממשק IP, מה שהופך אחד משני הסידורים לאפשרי והשני ללא, בין אם הקונפיגורציה אומרת אחרת.
ההשוואה קצרה, אבל היא קובעת אם אפשר לתקן את זה בטלפון או שצריך לשנות את השירות.
שני סוגי מנהרות עם מטענים שונים
ממשק TAP מתנהג כמו מתאם Ethernet. הוא נושא מסגרות, כלומר ARP, שידור וכל דבר אחר ש-LAN נושא מתחת ל-IP. זה מה שמאפשר גישור: המנהרה מרחיבה תחום שידור והלקוחות מתנהגים כאילו חוברו למתג.
ממשק TUN נושא מנות IP הממוענות אליו. אין שכבת קישור לנהל משא ומתן, אין ARP ואין שידור. הניתוב קובע מה נכנס למנהרה, והקונפיגורציה בצד השרת משתמשת בתת-רשת ולא בגשר.
שני הקצוות חייבים להסכים איזה משני הדברים הם עושים. החלפת dev tap ב-dev tun בצד אחד לא ממירה את השירות; היא יוצרת לקוח שמצפה למנהרה מנותבת ושרת שעדיין דוחף מסגרות, ולחיצת היד יכולה להצליח בזמן ששום דבר שמיש לא עובר.
מה אנדרואיד באמת נותנת לאפליקציה
ממשק ה-VpnService של הפלטפורמה נותן לאפליקציה ממשק וירטואלי למנות IP, מוגדר בכתובות, בנתיבים וב-MTU. אין מתאם Ethernet בממשק הזה, ואין דרך לאפליקציה להמציא אחד.
לכן OpenVPN Connect מתעד תמיכה בחיבורי TUN מנותבים באנדרואיד ולא בגישור TAP. שאלות נפוצות של אנדרואיד הוא ההצהרה מצד הלקוח על הגבול הזה, והיא תואמת את ממשק הפלטפורמה.
כלי רשת עם הרשאות root, קושחה מותאמת אישית או מוצר שמיישם שכבת תרגום מפורשת הם סידורים אחרים. המקרה הרגיל הוא זה שכדאי לתכנן סביבו: אפליקציה שיכולה לייבא את הקובץ שלכם ולרוץ כמשתמש רגיל, עם ממשק IP ושום דבר מתחתיו.
איך זה נראה כשמנסים בכל זאת
החיבור בדרך כלל נוצר. זה מה שהופך את הכשל למבלבל: הלקוח מדווח על חיבור, יומן השרת מראה עמית, ואף יישום לא עובד.
תעבורה הממוענת לכתובת שהוקצתה לטלפון לא מגיעה, כי השרת מגשר מסגרות לכתובת MAC שלטלפון מעולם לא הייתה. גילוי התלוי בשידור נשאר ריק. אם ה-LAN מסתמך על DHCP דרך הגשר, הטלפון לא יקבל חכירה בדרך הזו, וכתובת שהוקצתה ידנית בתת-הרשת המגושרת עדיין לא יוצרת את הממשק החסר.
חלק מהלקוחות נכשלים מוקדם יותר, בייבוא הפרופיל, כשהם רואים סוג התקן שאינם יכולים ליישם. כל אחת משתי ההתנהגויות אומרת אותו דבר, ואף אחת מהן לא מתוקנת בהוספת נתיבים, בשינוי DNS או בהרחבת טווח הכתובות של המנהרה.
מה צד השרת חייב לשנות
התיקון שייך למי שמפעיל את שירות ה-VPN, והוא בדרך כלל תוספת ולא הגירה. הפעילו מופע OpenVPN שני עם התקן מנותב, תת-רשת לקוחות משלו וקונפיגורציה בצד השרת שמקצה כתובות ודוחפת את הנתיבים שהטלפונים צריכים. המופע המגושר הקיים ממשיך לשרת את ההתקנים שבאמת צריכים Ethernet.
שני פרטים הופכים את זה לעובד בפועל. ה-LAN צריך נתיב חזרה לתת-הרשת החדשה של הלקוחות, שמצביע על מארח ה-VPN, אחרת תשובות לא יחזרו לעולם. והחומת אש במארח המנהרה חייבת להעביר בין ממשק המנהרה ל-LAN, וזה השלב שמוחמץ לרוב כשבדיקה מהמארח עצמו מצליחה.
אם המפעיל לא יכול להוסיף שירות, החלופה היא התקן שיכול להצטרף לגשר, כלומר מחשב נייד או נתב שפועל בשם הטלפון. זהו פתרון עוקף עם עלות ניהול משלו, לא קונפיגורציה של אנדרואיד.
החליטו מתוך היישום, לא מתוך המנהרה
שאלו למה הטלפון באמת צריך להגיע, ואז מפו את זה. שיתוף קבצים או אתר אינטראנט שנגישים בשם או בכתובת הם דרישת IP, ומנהרה מנותבת מספקת אותה ברגע ש-DNS מפענח את השם והנתיב קיים. כלי גילוי שסורק את תחום השידור המקומי אינו דרישת IP, ושום כמות של ניתוב לא תמלא אותו.
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
הטבלה הזו היא גם הבקשה לשלוח. נקבו בשם היישום, בכתובת או בשם שהוא משתמש בהם, ובשאלה אם הוא תלוי בגילוי. מפעיל יכול לפעול לפי התיאור הזה, מה שאיש לא יכול לעשות עם טלפון שלא מתחבר.
לבסוף, השאירו את שירות TAP עבור ההתקנים שזקוקים לו במקום לגרום לכל לקוח לחקות מתאם LAN. שני שירותים עם מטרות ברורות קלים יותר לתמיכה מאחד שעובד חצי עבור כולם.