גבולות של Cloud VPN שאי אפשר לכוונן: משך חיים של IKE ו-NAT של העמית

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

העמית שואל, המשיב מחליט

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

קראו את המצב של המנהרה עצמה לפני פתיחת קריאה, כי המצב המפורט בדרך כלל מציין את השלב שנכשל:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

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

36,000 שניות הן התקרה

פאזה 1 נעצרת ב-36,000 שניות. התקן שמוגדר ל-86,400 מבקש משהו שהמשיב לעולם לא יסכים לו, וניסיון חוזר לא משנה את דעתו. החזירו את ההצעה המרוחקת לתוך הטווח ואותה תצורה תתקיים; האסימטריה היא כל השיעור, כי אתם יכולים להוריד את הערך שלכם ולא יכולים להעלות את זה של Google.

רשמו את הערך שנבחר בהערות התכנון. אחרת המהנדס הבא יחזור על הניסוי של 24 שעות ויגיע לאותו קיר.

הקבוצה הנתמכת מתפרסמת לפי סוג שער וגרסת IKE ב סקירת Cloud VPN, אז קראו את הקטע לטופולוגיה שלכם ולא מדריך IKE כללי.

מנהרה שנופלת לפי לוח זמנים

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

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

הקבוצות מגיעות מסוג השער

קבוצות ההצפנה והשלמות אינן פרופיל לכל מנהרה שאתם עורכים כפי ש-strongSwan מאפשר. אתם בוחרים אותן לפי סוג שער וגרסת IKE, וחיפוש אחר פרופיל שלא קיים מבזבז אחר צהריים.

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

כתובת חיצונית אחת לכל התקן

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

שמרו גם על הכתובת החיצונית הזו יציבה. העבירו את ההתקן מאחורי NAT אחר והשיוך נשבר למרות שכל הצעה עדיין מתאימה. כדאי לרשום אילו ערכים של Google ואילו שלכם: משכי חיים, קבוצות ו-NAT אחד-לאחד קבועים אצלם, בעוד שהצעות, בוררים, ניתוב ועדיפויות BGP הם שלכם.