SoftEther מאחורי NAT: מעבר ישיר או ממסר של VPN Azure?

שרת ה-SoftEther שלכם נמצא מאחורי נתב של ספק שאינכם יכולים לשנות, והלקוחות עדיין מתחברים, אז אתם מניחים שממסר נושא הכול. אם זה נכון תלוי באיזה מנגנון עשה את העבודה: שם DNS, מסלול UDP מתואם או מנהרה יוצאת אל ממסר. שלושתם יכולים ליצור לקוח מחובר, והם נכשלים בתנאים שונים. החליטו איזה מסלול אתם קונים לפני שנוגעים במשתמשים או ב-hubs.

שלושה מנגנונים, שלוש הבטחות שונות

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

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

החליטו לפי הלקוח והרשת

הבחירה מתחילה בלקוח, כי מעבר קיים רק במנגנון החיבור המקורי של SoftEther. OpenVPN, L2TP/IPsec ומאזיני SSTP באותו שרת לא יורשים אותו, למרות שהם חולקים מארח. הסתכלו על מה המשתמש יריץ, ואז על מה הרשת מתירה. רשת ארגונית שמתירה רק TCP 443 דוחפת אתכם אל ממסר באותו פורט, בעוד רשת שמעבירה את פורטי ה-UDP שהמעבר צריך יכולה לנסות מסלול ישיר; ודאו את שניהם מול מדיניות היציאה בפועל.

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

ודאו איזו תעבורה הסשן בחר

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

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList מציג אילו סשנים מחוברים, ו-SessionGet על אחד מהם מדווח על סוג החיבור, כולל אם הסשן הגיע דרך הממסר. רשומה שמתפרשת לתשתית הממסר אומרת לכם שהסשן עובר דרך צד שלישי, ואת זה ניתן לאשר על ידי חסימת המסלול בבדיקה. עם לקוח מקורי, האצת UDP יכולה להרחיק את מסלול הנתונים ממסלול הבקרה, כך שתצפית אחת לא מתארת את כל הסשן. שם DNS דינמי מיושן לאחר שינוי כתובת, וממסר שעונה כשמסלול ה-backend חסר, הם שני מצבי כשל ששווה לבדוק בנפרד. רשמו מה מדדתם ולא מה העיצוב התכוון.

תכננו למה המסלול הנבחר תלוי בו

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

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