איזו כתובת חומת אש בענן רואה כשהפעלתם את ה-VPN
מנהרה מלאה משנה את כתובת המקור שמסד הנתונים שלכם רואה. העבירו את רשימת ההיתרים, את הנתיב הפרטי או את המנהרה המפוצלת, לא את פרטי ההזדהות.
מסד נתונים שעובד לפני שה-VPN מתחבר ונכשל אחר כך הוא לעתים רחוקות בעיית פרטי הזדהות. חומות אש בענן מתאימות כתובות מקור, ומנהרה מלאה מחליפה את זו שהן התאימו. הפער בין מה שאתם חושבים שהמחשב הנייד שלכם שולח לבין מה שהשרת מקבל הוא כל הבאג, ואפשר למדוד אותו בצעד אחד.
למה הופכת כתובת המקור
במנהרה מלאה כל מנה יוצאת דרך שער ה-VPN, כך שהשרת רואה את כתובת היציאה של השער ולא את החיבור הביתי שלכם. אם יש פרוקסי קדמי בנתיב, הכתובת שמגיעה היא שלו. שתיהן מקורות לגיטימיים, ואף אחת מהן אינה הכתובת בכלל המקורי שלכם.
כללי חומת האש של Azure SQL ברמת השרת וברמת מסד הנתונים מתאימים את כתובת הלקוח שמגיעה לשרת הלוגי, שאחרי מנהרה מלאה היא כתובת היציאה. קבוצת אבטחה של AWS שמתירה כתובת אחת מתנהגת באותו אופן. המנה נשלכת לפני האימות, ולכן השגיאה שאתם מקבלים נראית כמו כשל רשת ולא כמו בעיית הרשאות. בדיוק מפני זה אנשים מתחילים לאפס סיסמאות.
היכן נקבעת רשימת ההיתרים
קראו את הכלל שמתאים לנתיב שנכשל, לא את הכלל שאתם זוכרים שיצרתם. שימו לב להיקף שלו, לפורט, לפרוטוקול ולשאלה אם הוא מוערך לפני כל בדיקת זהות.
אחר כך החליטו איזו שכבה מחזיקה כדין בהחלטה. כלל כתובת עונה מהיכן מגיע התעבורה. נקודת קצה פרטית עונה אם השירות נגיש בכלל בנתיב פרטי. חריגה של מנהרה מפוצלת עונה אילו יעדים עוקפים את המנהרה. הם אינם ניתנים להחלפה, וכל אחד נכשל אחרת כשהמנהרה משתנה.
שלושה תיקונים, שלוש שכבות
כל אפשרות למטה מתקנת את הזרימה מסיבה אחרת, ובחירה בשגויה יוצרת חיבור שעובד עד שינוי השער הבא.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
הוספת כתובת היציאה היא השינוי הקטן ביותר והשברירי ביותר, מפני ששער חדש או אזור אחר מבטלים אותה בשקט. תעדו את הכתובת לצד הגדרת המנהרה כדי ששתיהן יזוזו יחד. טווח רחב זמני הוא אבחון ולא תיקון; להשאיר אותו במקומו זו הדרך שבה שירותים פנימיים נשארים חשופים.
מדוע פלטפורמה מנוהלת אינה יכולה להצטרף למנהרה
פלטפורמות יישומים כמו Heroku, AppHarbor או CloudBees מריצות את הקוד שלכם בסביבה בלי התקן tun או tap ובלי הרשאות ליצור אחד. מודל הכניסה שלהן הוא HTTP ולא שקע האזנה שרירותי. חבילת בנייה שמספקת קובץ בינארי של VPN עדיין אין לה היכן להניח את הממשק. הדפוסים שהם בני ביצוע הם כתובת יציאה סטטית שמסד הנתונים יכול להתיר, מוצר חיבור פרטי שהפלטפורמה מציעה, או פרוקסי ב-DMZ שאליו מגיעים דרך HTTPS.
הפרוקסי הזה הוא נתיב גישה עם אימות ותיעוד משלו. הוא אינו הופך את הפלטפורמה לחברה ב-VPN שלכם, ותיאור כזה יוצר כללים שאיש אינו יכול לבקר.
אמתו מהלקוח שנכשל
התחברו מחדש וחזרו על הנתיב המדויק של הלקוח. בדקו את כתובת המקור שהשירות מתעד, את המסלול שהלקוח בוחר לשם מסד הנתונים ואת תוצאת השאילתה בפועל, בסדר הזה. בדיקה מהשער מוכיחה שהשער עובד, מה שמעולם לא היה בספק. אם החיבור עכשיו מאומת והשאילתה עדיין נכשלת, הבעיה שנותרה היא הרשאת מסד הנתונים.
סקרו את הכללים האלה בכל פעם שהמנהרה משתנה. שער שהוחלף או טווח יציאה חדש שוברים את הנתיב בלי שום שינוי בתצורת היישום.