אוטומציה של L2TP באנדרואיד: סקריפט יכול לבקש, לא לבנות

המיתוס הוא ש-L2TP באנדרואיד הוא עוד דבר שסקריפט shell יכול להפעיל: להוסיף נתיב, לקרוא לשירות הישן, וסיימנו. זה לא יכול להיות, כי ארבע שכבות שונות חייבות להסכים לפני שמנהרה מעבירה מנה. שכבת IPsec מגנה על הנתיב, L2TP נושא את ההפעלה, PPP מנהל משא ומתן על הקישור, ואנדרואיד חייב לרשום את התוצאה כ-VPN שהוא יכול לנתב סביבו. ראיתי את זה מנוסה פעמיים עם פקודות מועתקות, ובשני המקרים הנתיב היה קיים בעוד ששום דבר לא היה מוצפן.

מה שינוי נתיב באמת משיג

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

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

ארבעה בעלים, והסקריפט אינו אחד מהם

קחו אותם לפי הסדר. IPsec מקים ומתחזק את הנתיב המוגן ומאמת את העמיתים. L2TP נושא את ההפעלה מעליו, והשכבות הן הסיבה שהתקן מתייחס אליהם כמנגנונים נפרדים ולא כפרוטוקול אחד. בתוך זה, PPP מנהל משא ומתן על פרמטרי הקישור שהלקוח ישתמש בהם. אחר כך אנדרואיד מחזיק בצד הפלטפורמה: ממשק ה-VPN הרשום, היקף לפי אפליקציה, מצב always-on ומחזור החיים שמחליט מה קורה כשהאפליקציה נהרגת.

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

למה גם daemon אינו קיצור דרך

הפעלת daemon לינוקס עם הרשאות במכשיר נראית כמו החלק החסר, ולעתים קרובות היא אכן מעלה מנהרה. מה שהיא לא עושה הוא לרשום את המנהרה הזו באנדרואיד. הממשק קיים בתוך הקרנל, אבל בחירת ה-VPN של הפלטפורמה, הניתוב לפי אפליקציה, מדיניות always-on ומחזור החיים לא יודעים עליו, ושינויי הנתיב וה-DNS של ה-daemon עצמו מתחרים במנהל הרשת על אותן טבלאות.

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

איך נראים הנתיבים הנתמכים

אם הארגון יכול לעבור לפרופיל שאנדרואיד מספק בעצמו, נתיב הפלטפורמה הוא הישר. מ-API 30, VpnManager תומך באספקה ובקרה של פרופילי VPN של הפלטפורמה על ידי אפליקציות, עם תהליך הרשאה המצורף לאפליקציה הקוראת. זה לא ממיר L2TP: מודל הפרופיל שהוא מספק ל-IKEv2 לא מתרגם תצורת L2TP קיימת, ומעבר פרוטוקול הוא הגירה, לא שינוי שם. זהויות, נתיבים, DNS פרטי והרשאות גישה חייבים להיות מועברים בכוונה.

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

מה עושה אוטומציה נכונה

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

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

• IPsec ו-PPP מטופלים על ידי הלקוח, לא על ידי הנתיבים של הסקריפט.
• החיבור מופיע במצב ה-VPN של הפלטפורמה, ולכן היקף לפי אפליקציה ו-always-on חלים עליו.
• שום קריאת שירות פנימית, מספר טרנזקציה או ארגומנט מנוחש לא נושא אישור.
• כשל בכל שלב לא משאיר פרופיל חצי-רשום מאחור.