השער מארח דף ניהול משלו: כתובת פנימית או ציבורית

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

הדף נטען מבחוץ ולא דרך המנהרה

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

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

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

שמרו על נגישות נקודת הקצה החיצונית

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

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

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

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

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

תנו לשירות שם פרטי

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

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

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

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

התאימו את המדיניות למקום שבו התהליך רץ

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

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

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

בדקו גישה פרטית ונתיב ציבורי שנדחה

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

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

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

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