שירות ה-VPN עם בידוד פיזי (air-gapped) של Google Distributed Cloud (GDC) תומך בהצפנות ובפרמטרים הבאים להגדרת שערי VPN שכנים.
הזמנה של הצעה
GDC VPN יכול לפעול כיוזם או כמשיב לבקשות IKE, בהתאם למקור התנועה כשנדרש שיוך אבטחה (SA) חדש.
כש-GDC VPN יוזם חיבור VPN, הוא מציע את האלגוריתמים לפי הסדר שמוצג בטבלאות הצפנה הנתמכות לכל תפקיד הצפנה. שער ה-VPN של העמית שמקבל את ההצעה בוחר אלגוריתם.
אם שער ה-VPN של העמית יוזם את החיבור, אז GDC VPN בוחר צופן מההצעה באמצעות אותו סדר שמוצג בטבלה עבור כל תפקיד צופן.
בהתאם לצד שיוזם את החיבור או לצד שמגיב, יכול להיות שצופן ההצפנה שנבחר יהיה שונה. לדוגמה, יכול להיות שהצופן שנבחר ישתנה עם הזמן כשנוצרים שיוכים חדשים של אבטחה (SA) במהלך רוטציית מפתחות.
כדי למנוע שינויים תכופים בבחירת הצפנה, צריך להגדיר את שער ה-VPN של עמית כדי להציע ולקבל רק הצפנה אחת לכל תפקיד הצפנה. הצפנה זו צריכה להיות נתמכת גם על ידי ה-VPN של GDC עם air gap וגם על ידי שער ה-VPN של העמית. אל תספקו רשימה של צפנים לכל תפקיד צופן. השיטה המומלצת הזו מבטיחה ששני הצדדים של מנהרת ה-VPN של GDC עם air gap תמיד יבחרו את אותו צופן IKE במהלך משא ומתן של IKE.
פיצול מנות IKE
GDC VPN תומך בפיצול IKE כפי שמתואר בפרוטוקול פיצול IKEv2: https://www.rfc-editor.org/rfc/rfc7383.
כדי לקבל את התוצאות הטובות ביותר, Google ממליצה להפעיל את פיצול ה-IKE, אם הוא עדיין לא מופעל, בשער ה-VPN של עמית.
אם לא הפעלתם פיצול של IKE, מנות IKE מ-GDC לשער VPN עמית שגדולות מה-MTU של השער יימחקו.
אי אפשר לפצל חלק מהודעות IKE, כולל ההודעות הבאות:
IKE_SA_INITIKE_SESSION_RESUME
מידע נוסף זמין בקטע Limitations (מגבלות) במאמר https://www.rfc-editor.org/rfc/rfc7383.
טבלאות הצפנה נתמכות
טבלאות הצפנה נתמכות מספקות את הכללים להחלפת תווים או קבוצות של תווים במהלך תהליכי ההצפנה והפענוח:
שלב 1
| תפקיד ההצפנה | הצפנה | הערות |
|---|---|---|
| הצפנה ויושרה |
|
ברשימה הזו, המספר הראשון הוא הגודל של פרמטר ה-ICV בבייט (אוקטט), והמספר השני הוא אורך המפתח בביטים. במסמכים מסוימים, פרמטר ה-ICV (המספר הראשון) מצוין בביטים (8 הופך ל-64, 12 הופך ל-96 ו-16 הופך ל-128). |
| פונקציה פסאודו-אקראית (PRF) |
|
במכשירים רבים לא נדרשת הגדרה מפורשת של PRF. |
| Diffie-Hellman (DH) |
|
|
| משך החיים של שלב 1 | 36,000 שניות (10 שעות) |
שלב 2
| תפקיד ההצפנה | הצפנה | הערות |
|---|---|---|
| הצפנה ויושרה |
|
ברשימה הזו, המספר הראשון הוא הגודל של פרמטר ה-ICV בבייט (אוקטט), והמספר השני הוא אורך המפתח בביטים. במסמכים מסוימים, פרמטר ה-ICV (המספר הראשון) מצוין בביטים (8 הופך ל-64, 12 הופך ל-96 ו-16 הופך ל-128). |
| פונקציה פסאודו-אקראית (PRF) |
|
במכשירים רבים לא נדרשת הגדרה מפורשת של PRF. |
| Diffie-Hellman (DH) |
|
|
| משך החיים של שלב 2 | 10,800 שניות (3 שעות) |
הגדרת IKE
אתם יכולים להגדיר IKE בשער ה-VPN של עמיתים לניתוב דינמי, לניתוב מבוסס-מסלול ולניתוב על סמך מדיניות.
מנהרות VPN של GDC חייבות להשתמש ב-IKE v2 כדי לתמוך בתנועת IPv6.
כדי להגדיר את שער ה-VPN ואת המנהרה של העמית ל-IKE, משתמשים בפרמטרים שבטבלה הבאה:
לפרוטוקולים IKEv1 ו-IKEv2
| הגדרה | ערך |
|---|---|
| מצב IPsec | מצב ESP+Auth Tunnel (אתר לאתר) |
| פרוטוקול אימות | psk |
| סוד משותף | נקרא גם מפתח ששותף מראש של IKE. כדי לבחור סיסמה חזקה, צריך לפעול לפי ההנחיות האלה. המפתח ששותף מראש הוא רגיש כי הוא מאפשר גישה לרשת שלכם. |
| התחלה | auto (אם מכשיר העמיתים יתנתק, החיבור יופעל מחדש באופן אוטומטי) |
| PFS (Perfect Forward Secrecy) | on |
| DPD (Dead Peer Detection) | מומלץ: Aggressive. הפרוטוקול DPD מזהה מתי ה-VPN מופעל מחדש ומשתמש במנהרות חלופיות כדי לנתב את התנועה. |
| INITIAL_CONTACT (לפעמים נקרא uniqueids) |
מומלץ: on (לפעמים נקרא restart).
מטרה: לזהות הפעלות מחדש מהר יותר כדי לצמצם את זמן ההשבתה שנתפס. |
| TSi (Traffic Selector - Initiator) | רשתות של תת-רשתות: הטווחים שצוינו בדגל רשתות מדור קודם: טווח הרשת. |
| TSr (Traffic Selector - Responder) | IKEv2: טווחי היעד של כל המסלולים שמוגדרים למנהרה הזו עם הערך IKEv1: באופן שרירותי, טווח היעד של אחד מהמסלולים שבהם הערך |
| MTU | יחידת השידור המקסימלית (MTU) של מכשיר ה-VPN של העמית לא יכולה לחרוג מ-1,460 בייט. מפעילים במכשיר את האפשרות 'פיצול מראש' כדי שהמנות יפוצלו קודם ואז יוכנסו לקפסולה. |
פרמטרים נוספים ל-IKEv1 בלבד
| הגדרה | ערך |
|---|---|
| IKE/ISAKMP | aes128-sha1-modp1024 |
| ESP | aes128-sha1 |
| אלגוריתם PFS | קבוצה 2 (MODP_1024) |