GCP Cloud VPN: בדקו שער, מנהרה וחומת אש לפי הסדר

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

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

שלושה אובייקטים, ורק אחד מהם מצפין

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

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

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

סוג הניתוב קובע מה מגיע לטבלת הניתוב

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

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

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

הדחייה המשתמעת יושבת מאחורי המנהרה

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

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

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

כיוון אחד שעובד הוא רמז לחומת אש

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

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

בוררים, מכסות, ואז ארבע הבדיקות

מנהרות שנוצרו במסוף מחזירות לפעמים בורר תעבורה מרוחק ריק מ-gcloud compute vpn-tunnels describe בעוד שהנתיבים שנוצרו נושאים את התעבורה כראוי. השוו את מה שה-API מתעד לטווחים שאתם באמת מגנים עליהם לפני שתחליטו שהמנהרה שגויה. יצירתה דרך ה-API או ה-SDK משאירה את הבורר מפורש.

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

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