Cloud Run ל-VPN מקומי: הגדרת יציאת VPC ישירה

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

חברו את הגרסה לפני שאתם מאבחנים את המנהרה

Cloud Run תומך ב-יציאת VPC ישירה, שמכניסה את התעבורה של השירות לתת-רשת ב-VPC שלכם בלי מחבר Serverless VPC Access. עבור שירות קיים העדכון נראה כך:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

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

בחרו את מצב היציאה שמתאים ליעד

private-ranges-only שולח את היעדים שהוא מסווג כפרטיים דרך ה-VPC. זה לא אומר «כל מה שניתן להגיע אליו דרך ה-VPN», והפער הזה מופיע כשהשירות המקומי נמצא בטווח שההגדרה לא מסווגת כך. אם היעד אינו מכוסה, all-traffic הוא המצב המתועד האחר, והוא שולח הכול דרך ה-VPC, כולל התלויות הציבוריות של השירות. בחרו במודע ורשמו את התוצאה ביומן השינויים.

שירות שכבר משתמש במחבר דורש הגירה ולא מתג, לכן תכננו אותה במקום להגדיר את שניהם.

נתבו את מקור Cloud Run, לא מקור של מכונה וירטואלית

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

עם ניתוב דינמי, ודאו מה Cloud Router באמת מפרסם ומה ה-VPC מייבא, כולל כל מדיניות פרסום מותאמת. נתיב שקיים במסוף אך אינו נבחר ליעד הזה זהה להיעדר נתיב.

שלושה תנאים שכולם חייבים להתקיים

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

• נתיב ב-VPC לעבר הקידומת המקומית דרך חיבור Cloud VPN המיועד.
• נתיב הפוך בצד המקומי עבור תת-הרשת של Cloud Run.
• היקף הגנה של חומת אש ו-IPsec שמתיר את המקור, היעד והפורט.

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

אל תוסיפו כתובת Cloud Run זמנית אחת לרשימת ההיתרים. השתמשו בטווח תת-הרשת ובתכנון הרשאה שמתאים ליישום.

בדקו את הגרסה ששירתה את הבקשה

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

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

חזרה לאחור ומה זה לא עושה

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

התכנון הזה מכסה חיבורים ש-Cloud Run יוזם ואת התשובות שלהם. הוא לא נותן לרשת המקומית שקע בר-כתובת בתוך השירות, כי חשיפה פנימה היא החלטת ingress.