שתי כתובות IP ציבוריות על מכונת Azure VPN אחת: מה עושה כל אחת

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

החלטה 1: היכן המנהרה מסתיימת

כתובת IP ציבורית של Azure משויכת לתצורת IP פרטית בכרטיס הרשת; זו אינה כתובת שמוסיפים בתוך מערכת ההפעלה של האורח. יש לקרוא את המיפוי במקום להניח אותו: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. איזו כתובת פרטית שתחזיר השאילתה הזו, היא הכתובת שהאורח חייב להחזיק בפועל.

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

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

החלטה 2: באיזה מקור משתמש הלקוח המועבר

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

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

החלטה 3: איזו שיטת יציאה של Azure מנצחת

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

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

לשקע המנהרה יש החלטת מקור משלו

Address של WireGuard תחת wg-quick מקצה כתובת לממשק WireGuard; זו אינה הוראת קישור UDP חיצונית. מקור השקע המוצפן עוקב אחר טבלת המסלולים, ולכן מסלול מדיניות או מסלול ברירת מחדל שני יכול להזיז אותו בלי לגעת בכתובת הממשק.OpenVPN: האפשרות local ו-UDP multihome מתנהגים אותו דבר: הם נוגעים למאזין ולתשובותיו, לא למקור האינטרנט של כל לקוח מועבר.

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

מה לקבל, ובאיזה סדר

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

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