הטלפון לא מצליח לפתוח את הדף: בדקו את כתובת ההאזנה

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

עברו על ה-socket, הגדרת ה-bind, כלל חומת האש וה-URL, בדיוק בסדר הזה.

ה-socket עונה על שאלה צרה יותר

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

מכאן נובעות שתי מלכודות שמות. בדפדפן של הטלפון, localhost פירושו הטלפון, לא המחשב הנייד. כתובת ה-wildcard היא ערך bind, לא משהו שמקלידים ב-URL. מי שיבדוק עם אחד מהשניים ידווח על כשל שהרשת לא הייתה מעורבת בו כלל.

IPv6 מוסיף מקרה שלישי, כי socket יכול לקבל IPv4 ו-IPv6 בהתאם לאפשרויות שקל לפספס. קראו את משפחת הכתובות ברשימה. רשומת wildcard למשפחה אחת אינה מתארת את האחרת.

קראו את כתובת ההאזנה

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

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

כתובת מקומית של 127.0.0.1 מכריעה את השאלה: שום שינוי בחומת האש לא יעזור, כי היישום לא מאזין בממשק ה-VPN. wildcard או כתובת ה-VPN פירושם שה-socket תקין ושהגבול הבא חל.

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

שנו את ה-bind דרך היישום

השתמשו באפשרות כתובת ההאזנה המתועדת של ה-framework והפעילו מחדש את התהליך. אם המחשב הנייד מחזיק בכתובת הפרטית 10.77.0.1, ה-URL של הטלפון הופך ל-http://10.77.0.1:8080/ וכתובת זו חייבת להיות מנותבת דרך ה-VPN; שום דבר אחר בהגדרה לא משתנה.

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

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

פתחו כלל אחד, לא את כל הרשת

ברגע שה-socket מקבל בכתובת ה-VPN, חומת האש מחליטה אם הבקשה תגיע. הגבילו את הכלל ליישום הזה, לפרוטוקול הזה, לפורט המקומי הזה ולמקור המרוחק המורשה, ואמתו איזה פרופיל פעיל במתאם ה-VPN.

השתמשו בכתובת המקור ש-Windows רואה באמת, כולל כל תרגום שהשער מבצע, כי כלל שנכתב לכתובת הלקוח המקורית לא יתאים לכתובת מתורגמת.

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

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