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

מה משתנה במסלול

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

הממסר מקצה לאותו שרת שם בדומיין שלו, והלקוחות מוגדרים להתחבר לשם.

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

אילו פרוטוקולים שורדים את הממסר

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

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

מה הממסר לא עושה בשבילך

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

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

אימות אישורים ואימות משתמשים נשארים באחריות השרת, והממסר לעולם אינו מחליף אף אחד מהם.

הפעל אותו כתלות

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

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

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

מאמרים קשורים