בדף הזה מפורטות הנחיות למפעילי רשתות. מטרת ההנחיות היא לוודא שאפליקציות VPN (רשת וירטואלית פרטית) לצרכנים ולעסקים יספקו חוויית שימוש טובה ברשתות שלהן. Android מספק למפתחים את המחלקה VpnManager כדי שיוכלו ליצור פתרונות VPN, שבהם צרכנים ועסקים ישתמשו להצפנת תקשורת או לניתוב לרשתות שונות.
אנחנו ממליצים למפעילי רשתות לפעול לפי ההנחיות הבאות:
- תמיכה בפרוטוקול IPv6 Encapsulating Security Payload (ESP) (שדה 50 לכותרת הבאה) בחבילות ברשת, כדי לוודא שלתנועה הזו יש ביצועים דומים לחיבורים של פרוטוקול User Datagram (UDP) או פרוטוקול העברת נתונים מבוקרת (TCP). צריך לאפשר הפעלה של סשנים של ESP במכשירים, או להגדיר ערך גבוה מאוד של זמן קצוב לתפוגה ולהעביר אותם בקצב קווי.
- הגדרת זמנים קצובים לתפוגה של תרגום כתובות רשת (NAT) ושל חומת אש עם שמירת מצב באורך של 600 שניות לפחות לחיבורי UDP ביציאה 4500. זה יעזור לוודא שפתרונות ה-VPN יוכלו לשמור על חיבור יציב בלי עלויות מוגזמות של צריכת חשמל.
תמיכה בחבילות של פרוטוקול ESP (שדה 50 לכותרת הבאה) של IPv6
Encapsulating Security Payload (ESP) הוא פורמט החבילות שמוגדר כחלק מהפרוטוקולים של Internet Protocol Security (IPSec) להצפנה ולאימות של חבילות בפתרון VPN. מערכת Android OS מטמיעה את פרוטוקול האבטחה הזה בפתרון ה-VPN המובנה שלה.
ברשתות עם תמיכה ב-IPv6, חבילות ESP מועברות ישירות דרך חבילות IPv6 עם ערך 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 לטווח ארוך (לדוגמה, כדי לקבל התראות, הודעות צ'אט ושיחות אודיו או וידאו נכנסות). רוב אפליקציות ה-VPN של IPsec משתמשות ב-ESP שעבר אנקפסולציה בחבילות UDP של IPv4 עם יציאת יעד 4500, כפי שמתואר ב-RFC 3948.
כדי לשמור על החיבור הזה, המכשיר צריך מדי פעם לשלוח חבילות לשרת. החבילות האלה צריכות להישלח בתדירות גבוהה יותר מזמני התפוגה הקצובים של ה-NAT וחומת האש שהוגדרו על ידי מפעיל הרשת. שליחת הודעת keep-alive בתדירות גבוהה דורשת הרבה חשמל בצד הלקוח, ויש לה השפעה משמעותית על חיי הסוללה. ההודעות האלה גם מובילות לתנועת אותות משמעותית ברשת, אפילו כשהמכשיר לא פעיל.
מומלץ למפעילים להגדיל את ערכי הזמן הקצוב לתפוגה של NAT ושל חומת אש עם שמירת מצב, כדי למנוע פגיעה בסוללה. לגבי אנקפסולציית UDP של IPsec (יציאה 4500), הזמן הקצוב המומלץ לתפוגה הוא 600 שניות או יותר.
ברשתות סלולריות, ערכי הזמן הקצוב לתפוגה של UDP NAT הם בדרך כלל נמוכים, כי המחסור בכתובות IPv4 מחייב גורמי שימוש חוזר גבוהים ביציאות. עם זאת, כשנוצר חיבור VPN, הרשת של המכשיר לא צריכה לתמוך בחיבורי TCP לטווח ארוך, כמו אלה שמשמשים להעברת התראות נכנסות. לכן, מספר החיבורים לטווח ארוך שהרשת צריכה לתמוך בהם זהה או נמוך יותר כשה-VPN פועל בהשוואה למצב שבו ה-VPN לא פועל.