למה ה-URL שלך צריך רשומת כניסה בפורט 80 או 443, ולא 45000

הקלד שם מארח בדפדפן והסכימה קובעת את פורט היעד: 80 עבור http, 443 עבור https. שום דבר בתשובת DNS לא עוקף זאת, ושום כלל העברה במכונה שלך לא יכול להמציא מאזין בקצה של הספק. כשספק VPN נותן לך פורט ציבורי גבוה כמו 45000, URL מפורש עובד ו-URL נקי לא. הפער נמצא בנקודת הכניסה, לא בתוך היישום.

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

ראה לאן הבקשה באמת הולכת

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

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

למה כלל מקומי לא יכול לתקן את הקצה

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

גם DNS לא יכול לשאת את הפורט. מפרט HTTP מגדיר את ברירות המחדל של הסכימה, ורשומת A או AAAA מחזירה כתובת בעוד CNAME מחזיר שם אחר. הדפדפן עדיין משרשר את פורט הסכימה, ולכן רק פורט מפורש ב-URL משנה את היעד.

אפשרות ראשונה: לשמור על הפורט המפורש

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

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

אפשרות שנייה: לקבל רשומת כניסה אמיתית בפורט ברירת המחדל

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

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

אפשרות שלישית: לשים frontend מלפנים

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

זה גם משנה את מה שאתה מפעיל. ה-frontend מחזיק ב-TLS הציבורי, במדיניות הגישה, ביומנים ובזמינות, ועליו להגביל את בחירת ה-backend לשירות המיועד. אם הקפיצה מ-frontend ל-backend משתמשת ב-HTTPS, שמור על אימות תעודה בקפיצה הזו.

שמור על מקור אחד

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

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