בדף הזה מפורטות הנחיות למפעילי רשתות, שמטרתן להבטיח שאפליקציות של רשתות וירטואליות פרטיות (VPN) לצרכנים ולעסקים מספקות חוויית משתמש טובה ברשתות שלהם. Android מספקת למפתחים את המחלקה VpnManager כדי ליצור פתרונות VPN, שבהם צרכנים וארגונים משתמשים כדי להצפין את התקשורת שלהם או לנתב אותה לרשתות שונות.
אנחנו ממליצים למפעילי הרשתות לפעול לפי ההנחיות הבאות:
- תמיכה בחבילות של פרוטוקול IPv6 Encapsulating Security Payload (ESP) (Next Header 50) ברשת, כדי להבטיח שהביצועים של התנועה הזו יהיו דומים לביצועים של חיבורי User Datagram Protocol (UDP) או Transmission Control Protocol (TCP). צריך לאפשר סשנים של ESP נכנסים למכשירים, או להגדיר להם זמן קצוב לתפוגה גבוה מאוד ולהעביר אותם בקצב של קווי תקשורת.
- הגדרת זמן קצוב לתפוגה של תרגום כתובות רשת (NAT) ושל חומת אש סטטית של 600 שניות לפחות לחיבורי UDP ביציאה 4500, כדי להבטיח שפתרונות VPN יוכלו לשמור על קישוריות מהימנה בלי להוביל לעלויות חשמל מוגזמות.
תמיכה בפרוטוקול IPv6 ESP (Next Header 50) packets
encapsulating Security Payload (ESP) הוא פורמט המנות שמוגדר כחלק מקבוצת הפרוטוקולים Internet Protocol Security (IPSec) כדי להצפין ולאמת מנות בפתרון VPN. מערכת ההפעלה Android מטמיעה את פרוטוקול האבטחה הסטנדרטי הזה בפתרון ה-VPN המובנה שלה.
ברשתות עם תמיכה ב-IPv6, חבילות ESP מועברות ישירות בחבילות IPv6 עם שדה Next Header (כותרת הבאה) של 50. אם רשת לא תומכת בצורה נכונה בסוגי המנות האלה, זה עלול לגרום לחוסר קישוריות לפתרונות VPN שמטרתם להשתמש בפרוטוקול הזה ללא מכסה נוספת של המנות. יכול להיות שהמנות האלה יידחו ברשת בגלל הגדרות חומת האש. לחלופין, ייתכן שמנות ESP ייפגשו בנתיבים איטיים ברשת, עם ירידה משמעותית בביצועי תעבורת הנתונים בהשוואה לחיבורי TCP או UDP.
ארגון התקינה בנושאי האינטרנט (IETF) ממליץ לאפשר ל-IPsec לעבור דרך חומות אש שמשמשות שירותי גישה לאינטרנט של צרכנים. לדוגמה, ראו RFC 6092 סעיף 3.2.4. אפשר לאפשר חבילות ESP לעבור בבטחה דרך חומות אש בשני הכיוונים, כי אם מכשיר מקבל חבילה מסוג ESP שלא משויכת לאיחוד אבטחה קיים, המכשיר משחרר את החבילה. כתוצאה מכך, המכשיר לא צריך לשלוח חבילות keepalive כדי לשמור על קישוריות ה-VPN, וכך לחסוך בחיי הסוללה. אנחנו ממליצים לאפשר לחבילות ESP להגיע למכשירים בכל שלב, או להגדיר זמן קצוב לסיום סשנים של ESP רק אחרי תקופות ארוכות של חוסר פעילות (לדוגמה, 30 דקות).
אנחנו ממליצים למפעילי הרשתות לתמוך בחבילות של פרוטוקול ESP (חבילות IPv6 עם כותרת הבאה של 50) ברשתות שלהם ולהעביר את החבילות האלה בחומרה במהירות הפס. כך אפשר להבטיח שפתרונות VPN לא יתמודדו עם בעיות קישוריות, וגם לספק ביצועים דומים לאלה של חיבורי UDP או TCP.
הגדרת זמן קצוב מספיק לתפוגה של NAT ושל חומת אש סטטית
כדי לשמור על מהימנות החיבור, פתרון VPN צריך לשמור על חיבור לטווח ארוך לשרת ה-VPN שמספק קישוריות יוצאת ונכנסת (לדוגמה, כדי לקבל התראות דחיפה נכנסות, הודעות צ'אט ושיחות אודיו או וידאו). רוב האפליקציות של IPsec VPN משתמשות ב-ESP בתוך חבילות IPv4 UDP עם יציאת יעד 4500, כפי שמתואר ב-RFC 3948.
כדי לשמור על החיבור הזה, המכשיר צריך לשלוח מנות לשרת מדי פעם. חבילות הנתונים האלה צריכות להישלח בתדירות גבוהה יותר מאשר זמן הקצאת הזמן לתפוגה של NAT ושל חומת האש שהוגדרו על ידי ספק הרשת. שליחת בקשות keepalive תכופות צורכת הרבה חשמל בצד הלקוח, ויש לה השפעה משמעותית על חיי הסוללה. הם גם יוצרים תנועה משמעותית של אותות ברשת, גם אם המכשיר לא פעיל.
כדי למנוע השפעה על הסוללה, אנחנו ממליצים לאופרטורים להגביר את זמני הזמן הקצוב לתפוגה של חומת האש ושל מצב חומת האש. הזמן הקצוב המומלץ לקנזקולציה של IPsec UDP (יציאה 4500) הוא 600 שניות או יותר.
ברשתות ניידות, לרוב מגדירים זמן קצוב קצר לתפוגה של NAT ב-UDP כי מחסור בכתובות IPv4 מחייב שימוש גבוה ביציאות. אבל כשנוצר VPN, רשת המכשיר לא צריכה לתמוך בחיבורי TCP לטווח ארוך, כמו אלה שמשמשים לשליחת התראות נכנסות. לכן, מספר החיבורים לטווח ארוך שהרשת צריכה לתמוך בהם הוא זהה או נמוך יותר כשה-VPN פועל בהשוואה למצב שבו ה-VPN לא פועל.