גשר מקומי של SoftEther או SecureNAT: מה להפעיל
גשר מקומי מציב את ה-hub על מקטע Ethernet אמיתי, בעוד SecureNAT ממציא כתובות משלו. בחרו אחד, ואז בדקו את השער ואת הפותר.
פתחו את SoftEther Manager, וההחלטה האמיתית הראשונה לגבי hub אינה תיבת סימון אלא שאלת טופולוגיה. גשר מקומי מחבר את ה-hub הזה למתאם פיזי ומאפשר למקטע הקיים לספק את הכתובות, בעוד SecureNAT נותן ל-hub ראוטר וירטואלי, NAT ו-DHCP משל עצמו. הבחירה ביניהם משנה מהיכן מגיעות הכתובות ואיזה התקן עונה עבורן. הפעלה של שניהם בתקווה שאחד ינצח היא הדרך שבה מעבדה עובדת הופכת לשרשור תמיכה.
התחילו מה-hub שאתם באמת עורכים
Manager מציג עץ של שרתים ו-hubs, וזו נקודה חשובה: הגדרת ה-hub המוגדר כברירת מחדל היא קלה, בעוד שהלקוחות מתחברים ל-hub אחר בעל שם שונה. לחצו על ה-hub, קראו את שמו וודאו שהחיבורים הרשומים מתחתיו הם הלקוחות שאתם מנסים לשרת. הבדיקה האחת הזו מונעת את רוב הבלבול שמיוחס לאחר מכן לפרוטוקול.
לאחר מכן החליטו מה הלקוח צריך מהקצה המרוחק. התנהגות Ethernet משותפת עם שידור ושירותי LAN מצביעה על גשר, גישה פרטית מנותבת לטווח כתובות קטן מצביעה על SecureNAT, ויציאה לאינטרנט היא החלטת ניתוב שכל אחד מהסידורים יכול לשאת רע.
כתבו את התשובה לפני שאתם לוחצים על משהו, כי שתי ההגדרות אינן ניתנות להחלפה וביטול לוקח יותר זמן מההחלטה. שתי דקות של כתיבה חוסכות שעה של התחברות מחדש.
מה גשר מקומי עושה לכתובות
גשר מקומי מחבר את ה-hub למתאם פיזי, ולכן ה-hub הופך לחלק ממקטע ה-Ethernet הזה. הלקוחות מקבלים כתובות ממה שכבר משרת את המקטע, והשער שלהם הוא הראוטר של המקטע. מנקודת המבט של הלקוח הוא הצטרף ל-LAN של המשרד, עם כל הנגישות וכל החשיפה שזה מביא עמו.
המשמעות היא גם שהגשר צריך מתאם אמיתי עם תמיכת מנהל התקן מתאימה, ושהמנהל חייב להיות מורשה להרחיב את המקטע הזה. התחברות VPN מוכיחה אימות, לא זכות להציב מארח ב-VLAN ייצורי. בדקו ששם מנהל ההתקן תואם למתאם שאתם מתכוונים אליו, כי גישור של הפורט הלא נכון מוריד מקטע במהירות. אם רשימת המתאמים ריקה או שהגשר מדווח על כשל, הסיבה קשורה בדרך כלל למנהל התקן או להרשאות ולא להצפנה.
קראו את טבלת הגשרים משורת הפקודה כשהעץ הגרפי אינו חד משמעי. הפלט נוקב בשם המתאם, מה שהעץ לא תמיד עושה.
vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionListרשימת גשרים ריקה עם חיבורים פעילים היא תמונה שימושית: הלקוחות נמצאים בתוך ה-hub הווירטואלי ושום דבר עוד לא מרחיב אותו למקטע.
מה SecureNAT מוסיף ומה הוא מסתיר
SecureNAT נותן ל-hub ראוטר וירטואלי, פונקציית NAT ושירות DHCP, הכול בתוך תהליך SoftEther. הלקוחות מקבלים כתובות מטווח ה-DHCP הווירטואלי, הראוטר הווירטואלי עונה עבור שער ברירת המחדל, ותעבורה שצריכה לצאת מתורגמת. שום מתאם פיזי אינו מעורב, ולכן זה עובד על מארח עם כרטיס רשת אחד ובלי תצורת מתג.
המחיר הוא שהכתובות הווירטואליות שייכות ל-hub ולא לשום דבר אחר. מכונה ב-LAN של המשרד לא יכולה לנתב לכתובת SecureNAT של לקוח בלי עזרה, וכל מה שרושם כתובות מקור רואה את הכתובת המתורגמת של מארח SoftEther. אם כללי הגישה או נתיב הביקורת שלכם תלויים בכתובת האמיתית של הלקוח, זהו שינוי תכנון ולא פרט. זה גם קובע אם כלל כתובת מקור יראה את הלקוח בכלל.
הוא גם שרת DHCP. הפעלה שלו במקטע שכבר יש בו כזה, או גישור של אותו מקטע בו זמנית, יוצרת שני עונים והקצאות בלתי צפויות. המדריך מתייחס לשתי הפונקציות כאל בחירות נפרדות בדיוק מהסיבה הזו.
בדקו מה ה-hub משרת כעת לפני שתפעילו משהו אחר. כל פקודה מדפיסה את המצב הנוכחי ולא את המבוקש.
vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGetלהפעיל אחד בלי לשבור את השני
בחרו את הסידור, הפעילו אותו והשאירו את השני כבוי. hub עם גשר ועם SecureNAT פעילים בו זמנית הוא hub עם שתי תשובות אפשריות לאותה שאלה, והלקוח יאמין לזו שמגיעה קודם. כשאתם עוברים מאחד לשני, השביתו את הפונקציה הישנה וחברו את הלקוח מחדש במקום להניח שההגדרה החדשה חלה על חיבור קיים.
סדרו את השינוי כך שמאגר הלקוחות לא יחפוף לטווח ה-LAN. תת-רשתות חופפות הן הסיבה השנייה בשכיחותה למנהרה שמתחברת ואז לא מגיעה לשום מקום, והן בלתי נראות עד שתשוו את שתי תוכניות הכתובות זו לצד זו.
לאחר מכן התחברו מחדש מהלקוח וקראו מה הוא קיבל, כי תמונת ה-hub את החיבור אינה תמונת הלקוח את הרשת של עצמו. התחברות מחדש היא הדרך האמינה היחידה לכפות הקצאה חדשה.
בדקו את השער ואת הפותר בלקוח
אימות מוצלח אומר שהפרטים עובדים וה-hub קיבל את החיבור. הוא לא אומר דבר על כך אם הלקוח מגיע לשום מקום, כי זה תלוי בכתובת, במסכה, בשער ובשרת ה-DNS שהוא קיבל. קראו את ארבעת הערכים האלה בלקוח לפני שתגעו שוב בהגדרת שרת.
ב-Windows פרטי המתאם מציגים את ההקצאה ואת הפותר, וטבלת הניתוב מראה אם המנהרה היא באמת נתיב ברירת המחדל.
ipconfig /all
route print -4
nslookup intranet.corp.internalבלקוח Linux אותו מידע מגיע מקבצי הכתובות, הניתוב והפותר. נתיב ברירת המחדל הוא הערך שקובע אם התעבורה יוצאת בכלל דרך המנהרה. אם השער מצביע לראוטר המשרד בזמן שהמנהרה מצפה לשאת את התעבורה, הטופולוגיה מגושרת בשם ושבורה בפועל. תקנו תחילה את מקור הכתובות, בדקו שוב את היישום, ורק אז שקלו לשנות את המצב השני.