כתובת IP ייעודית של VPN לא מפרסמת את האתר שלך
כתובת יציאה ייעודית לא אומרת דבר על מסירה נכנסת. בדקו את חוזה ההעברה, השלימו את צד המקור ואז פרסמו פורט גבוה.
קניית IP ייעודי אצל ספק VPN מרגישה כמו קניית דלת כניסה. הכתובת יציבה, המנהרה פעילה, והאתר עדיין לא נטען לאף אחד מבחוץ. מה שקניתם הוא הקצאה, לא כלל העברה נכנסת. את שניהם מוכרים באותו חנות ומגדירים במקומות שונים לגמרי.
הכתובת היא הקצאה, לא כלל העברה
רשמו את הכתובת הציבורית הנכנסת או שם המארח, את התעבורה המותרת, את הפורט החיצוני שהוקצה ואת היעד בצד הלקוח שאליו הספק מוסר. אחר כך ודאו שהשרת, הפרוטוקול ותכונת החשבון שבחרתם אכן תומכים בהעברה, ושהספק מתיר אירוח עליו.
המילה ייעודי מתארת הקצאת כתובת. היא לא אומרת שתעבורה נכנסת בלתי מבוקשת מותרת, ותוספים שונים של אותו מפעיל יכולים להיות בעלי יכולות שונות. הכתובת הייעודית ומוצר השרת הייעודי הם שני התוויות שהכי מתבלבלים ביניהם, ועמודי התמיכה בדרך כלל מפרטים איזה מהם מעביר.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
חוזה לדוגמה נראה כך: הספק מוסר TCP 203.0.113.60:45000 אל שירות ה-HTTPS של המכשיר המחובר שלכם בפורט 8443. זהו תיאור של מיפוי שמישהו אחר הגדיר, לא כלל שאתם יכולים ליצור בקצה שלהם על ידי הקלדתו בחומת האש שלכם.
השלימו את צד המקור
אם אפליקציית האינטרנט רצה על לקוח ה-VPN עצמו, היא זקוקה למאזין בפורט שנמסר ולהרשאת קלט מקומי מוגבלת לאותו פורט. אם הלקוח מעביר את החיבור הממופה למארח אחר, הוא זקוק לתרגום היעד, למדיניות ההעברה ולנתיב תשובה שעומד בהלוך ושוב.
תכננו את כללי הגישה סביב כתובת המקור שנתיב הספק באמת מציג. היא לא תמיד המבקר המקורי, והיא גם לא תמיד שרת ה-VPN, וזה חשוב כשאתם כותבים כלל שרק אחת מהכתובות האלה תתאים לו.
תרגום פורטים גם לא הופך HTTP ל-HTTPS. הפורט הציבורי ופורט האפליקציה המקומי יכולים להיות שונים באופן חופשי, אבל הסכימה, זהות התעודה והפניות ההפניה חייבים עדיין להתאים לשירות שאנשים באמת מגיעים אליו. אם התעודה נוקבת בשם המארח הציבורי, שמרו על השם הזה בכל צעד. אי-התאמה כאן מופיעה כאזהרת דפדפן ולא ככשל ניתוב, מה ששולח אנשים ליומנים הלא נכונים לשעה.
פרסמו את הפורט הגבוה ביושר
אם המבקרים מתחברים ישירות והספק הקצה פורט גבוה, תנו להם את הכתובת המלאה. רשומת כתובת DNS רגילה לא יכולה להוסיף פורט לבקשת HTTPS שמשתמשת כברירת מחדל ב-443, ושום כוונון TTL לא משנה את זה.
חזית אינטרנט יכולה לפתור זאת על ידי קבלת מבקרים בפורט הרגיל ויצירת חיבור משלה לפורט המקור המועבר. ואולם פורטי ה-proxy המוגדרים כברירת מחדל של Cloudflare הם רשימה מוגדרת, ופורט שהוקצה באופן שרירותי לא הופך לפורט קצה נתמך רק מפני שהוספתם רשומת DNS עם proxy.
שינוי פורט היעד של המקור הוא פעולה שונה משינוי פורט המבקר. Origin Rules של Cloudflare מתעדים דריסת פורט יעד לחיבור ה-backend, מוגבלת לכלל, לסכימה ולשם מארח נתמכים. דריסת פורט אינה ממסר כללי ל-UDP שרירותי או לפרוטוקולים אחרים.
כשחזית מסיימת TLS, אמתו את שני הצעדים: התעודה מהדפדפן לחזית והחיבור מהחזית למקור. צעד ה-VPN לא מחליף אף אחת משתי הבדיקות, וכתובת פנימית שדולפת להפניות או לעוגיות היא הסימן הרגיל לכך שרק אחד מהשניים הוגדר מתוך מחשבה על השם הציבורי.
שמרו על המיפוי חי
ספקים אחדים מקצים פורט אחר לאחר התחברות מחדש, ומיפוי מושכר יכול לדרוש חידוש באמצעות פעולה בצד הספק. עקבו אחר המנגנון שהספק שלכם מתעד, ועדכנו את המאזין, הכללים המקומיים, ה-DNS או כלל החזית רק במקום שבו החוזה הנוכחי דורש זאת.
כתובת ציבורית סטטית לא הופכת את חכירת הפורט לסטטית. כתובת ופורט שעדיין מוצגים בלוח בקרה אינם הוכחה שהפעילות החיה מחזיקה במיפוי, ולכן הבדיקה היא בקשה חדשה מבחוץ ולא צילום מסך.
אחר כך חזרו על המקרים שאתם מצפים להם: התחברות מחדש רגילה, ואובדן VPN. אם האובדן אמור להפוך את המקור ללא זמין, אל תתנו לכלי עדכון לפרסם מחדש בשקט נתיב ISP ישיר ברקע. ואם חוזה ההעברה לא יכול לעמוד בדרישות היציבות של האתר, בחרו סידור פרסום אחר במקום לקנות עוד תווית כתובת ולקוות שהיא תתנהג כמו שרת.