VPN פעיל ו-localhost מפסיק לעבוד: שם, פרוקסי או כריכה?

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

כאשר localhost מתורגם לאזור הארגוני

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

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

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

הגדרות פרוקסי שלוכדות לולאה

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

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

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

כתובת הכריכה קובעת מי יכול להתחבר

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

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

היכן כלי ניפוי באגים מצפה ל-LAN

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

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

עצור בשלב הראשון שנכשל

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

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