Cloud VPN אל VM ב-GCP: השתמשו בכתובת ה-IP הפנימית, לא בכתובת ה-NAT
לנקודת הקצה של השער, לכתובת הפנימית של ה-VM ולכתובת ה-NAT החיצונית אחת-לאחת יש שלוש משימות שונות. בדקו איזו מהן המסלול שלכם משתמש בה.
כאשר רשת מקומית מגיעה ל-VPC דרך Cloud VPN, היעד לשירות של Compute Engine הוא בדרך כלל הכתובת הפנימית של ה-VM. כתובת ה-IPv4 החיצונית אינה כתובת שנייה שאפשר להחליף באותו מסלול פרטי. רוב הבלבול בתחום הזה נובע מכך ששלוש כתובות עם שלוש משימות נתפסות כניתנות להחלפה, אז התחילו בשמות איזו מהן חבילה מסוימת משתמשת בה.
שלוש כתובות, שלוש משימות
תנו שם לכל השלוש לפני שאתם מאתרים תקלות באחת מהן, כי התשובה משנה את האובייקט שתבדקו לאחר מכן.
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
הראשונה שייכת למנהרה. השנייה שייכת לתכנון המסלול וחומת האש שלכם. השלישית שייכת לגישה נכנסת מהאינטרנט והיא ממופה, לא מחובר. תכנון שעובד עבור אחת מהן לא אומר דבר על השתיים האחרות.
מדוע הכתובת החיצונית אינה ממשק שני
מדריך הכתובות הוא הסמכות לשאלה כיצד נגישות פנימית וחיצונית נבדלות ב-Compute Engine. כתובת IPv4 חיצונית ב-Compute Engine היא מיפוי אחד-לאחד על כרטיס הרשת הפנימי היחיד של המופע, כך שהאורח לעולם לא רואה ממשק שני או כתובת שנייה בכרטיס הזה. מה שה-VM מדווח מבפנים הוא עדיין כתובת פנימית ראשית אחת.
לכן לקוח פרטי שמנתב דרך המנהרה אל 10.24.1.7 ולקוח שמכוון לכתובת החיצונית של ה-VM נמצאים במסלולים שונים. פתיחת כלל חומת אש לכתובת הציבורית לא משנה דבר במסלול ה-VPC שצריך לשאת את תעבורת המנהרה, ועריכת מסלול באורח לא מזיזה את המיפוי של הפלטפורמה. בחרו את הכתובת שהמסלול שלכם נוקב בה, ואז בדקו רק את האובייקטים ששולטים בה. המשמעת הזו מסירה את רוב הניחושים ממסלול פתרון התקלות הזה.
עברו את המסלול עם gcloud
התחילו מהמופע וקראו את שתי הכתובות מאותו אובייקט, כדי שתדעו על איזו מהן התיעוד שלכם מדבר:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"לאחר מכן אשרו את הניתוב ואת ההרשאה שהמסלול באמת תלוי בהם:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1קראו את הטווחים המוכרזים והנלמדים של המנהרה, את מסלול ה-VPC עבור תת-הרשת של עומס העבודה, ואת כלל חומת האש שמתיר את המקור המקומי. שלושת אלה חייבים להסכים לפני שמאזין באורח רלוונטי בכלל.
אחר כך בדקו את האורח: האם השירות מאזין בכתובת הפנימית, והאם מסלול החזרה שלו עובר שוב דרך ה-VPC? מאזין שנקשר רק לכתובת ציבורית ייכשל בבדיקה הזו גם כשכל אובייקט בצד הענן נכון.
קידומת ציבורית היא שאלה אחרת
שום דבר מהאמור אינו אומר שכל כתובת שנישאת בתוך VPN חייבת להיות RFC1918. אפשר למספר רשת מרוחקת כדין מתוך המרחב הציבורי, בתנאי שהפלטפורמה תומכת בניתוב ושבידי המפעיל סמכות הכתובת. זו בחירת תכנון רגילה.
זה אינו אותו דבר כמו להתייחס לכתובת NAT חיצונית רגילה כאילו הייתה כתובת תת-רשת פנימית אחרת. האחת היא קידומת שאתם מנתבים; האחרת היא מיפוי שהפלטפורמה מחילה על גישה נכנסת.
ל-IPv6 חיצוני ולסידורי כתובות שתוכננו במיוחד יש סמנטיקה משלהם. אם התוכנית שלכם תלויה באחד מהם, קראו את תיעוד הפלטפורמה לאותו תכונה במקום להכליל ממקרה ה-IPv4. מיפוי IPv4 הוא המקרה הנפוץ, לא היחיד, ולכל חריג יש כללים משלו.
טווחים חופפים הם בעיה אחרת
טווחים פרטיים חופפים הם סיבה אמיתית לכך שאנשים פונים לכתובת הציבורית, וזה המנוף הלא נכון. שינוי היעד לכתובת ה-NAT של ה-VM לא פותר את החפיפה; הוא משנה לאיזו כתובת החבילה טוענת שהיא מיועדת, בלי להגדיר כיצד מסלול החזרה עובד.
פתרו את החפיפה במכוון: ספרו מחדש, השתמשו בתכנון תרגום נתמך, או נתבו דרך רשת שבה הקידומות אינן מתנגשות. כל אחד מאלה הוא תכנון עם בעלים. כתובת NAT אינה תכנון.
תעדו את שני השדות בנפרד
רשמו את עמית המנהרה ואת יעד עומס העבודה כשני שדות runbook נפרדים, כל אחד עם המסלול וכלל חומת האש שתומכים בו. מנהרת IPsec שעולה רק אומרת לכם שהצדדים מסכימים; היא לא אומרת דבר על הכתובת שבה עומס העבודה נגיש, ולא על האם המסלול הפרטי שלו שלם.
אמתו עם לקוח אמיתי בצד השני: פתרו את השם, אשרו שהוא מחזיר את הכתובת הפנימית, התחברו ובדקו את תעבורת החזרה. תיעוד כתובות ה-IP של Compute Engine הוא ההפניה להבחנה בין פנימי לחיצוני ששימשה לעיל.