מצב גשר אינו העברת VPN: מה כל אחד משנה
מצב גשר משנה את תפקיד ההעברה של הנתב; העברה רק מאפשרת ל-VPN של לקוח לעבור דרכו. אף אחד מהם לא יוצר מנהרה, ולכן הם אינם ניתנים להחלפה.
מצב גשר והעברת VPN מוזכרים באותו שרשור פתרון תקלות מפני ששניהם מוצעים כתיקון ל-VPN שאינו מתחבר. הם מתארים תפקידים שונים של הנתב, ואף אחד מהם אינו יוצר מנהרת VPN בעצמו. גישור משנה כיצד התקן מצטרף למקטעי רשת או מי מבצע את הניתוב; העברה קובעת אם תעבורת ה-VPN של לקוח יכולה לעבור דרך שער. בחירה לא נכונה הופכת בעיה קטנה לאחה שלמה של הקצאת כתובות מחדש.
שתי תוויות, שני תפקידים שונים
הבדיקה פשוטה: האם אתם מנסים לשנות את צורת הרשת, או לתת לתעבורה שכבר קיימת לעבור דרכה? אלה בקשות שונות עם השלכות שונות.
ההשוואה בטבלה אחת:
| Setting | What it actually does |
|---|---|
| Bridge mode | Changes the device's forwarding role: a modem bridge hands routing and NAT downstream, a software bridge joins selected interfaces |
| VPN pass-through | Lets a client's VPN traffic cross the router; the credentials and encryption stay with the client |
| Router VPN client | Terminates the tunnel on the router, so the router becomes the endpoint |
| Router VPN server | Accepts inbound tunnels, which needs an upstream path that can reach it |
רק שתי האפשרויות האחרונות יוצרות מנהרה בנתב. גישור והעברה משאירים את נקודת הקצה במקום אחר, ולכן אף אחד מהם אינו יכול לתקן בעיה שנגרמת מלקוח חסר או משרת שאינו נגיש. קל לאבד את ההבחנה הזו מפני שההגדרות יושבות זו לצד זו באותו ממשק. רשמו איזו נקודת קצה מחזיקה במנהרה לפני שתפתחו את הדף הזה.
גם תיבת סימון של העברה אינה תיאור מלא של תמיכת פרוטוקולים. מעבר NAT מודרני ב-IPsec משתמש במיכלול UDP תקני, בעוד שתכונות עזר ישנות מתנהגות באופן התלוי במימוש.
תווית שיווקית שאומרת שיש תמיכת VPN אינה אומרת איזה מארבעת התפקידים האלה הכוונה.
מה מצב גשר משנה במכשיר שלכם
במודם או בנתב, אפשרות הגשר מעבירה בדרך כלל את אחריות הניתוב וה-NAT לשער אחר בהמשך הדרך. בהתקן תוכנה היא יכולה להיות חיבור ממשקים מקומיים נבחרים לתחום שידור אחד. ההיקף המדויק תלוי במוצר, ולכן קראו את התיעוד של הדגם ולא של המילה. שתי הפרשנויות משנות את הקצאת הכתובות, את גבולות חומת האש ואת הדרך שבה מגיעים לניהול.
זו הסיבה שגישור הוא תגובה ראשונה גרועה לכשל VPN. אפשר לאבד את נתיב הניהול בזמן שהבעיה המקורית עדיין אינה פתורה.
שמרו גיבוי תצורה לפני שינוי תפקיד הרשת, מפני שהכתובות עשויות לזוז יחד איתו.
בחרו את התפקיד לפני ההגדרה
כדי להוציא את תעבורת הבית דרך יציאה חיצונית, צריך לקוח VPN תואם בנתב, ולא גשר. כדי להתחבר חזרה הביתה ממקום אחר, צריך את תפקיד השרת וכן נתיב במעלה הזרם שיכול להגיע אליו. לשתי הדרישות האלה אין כמעט דבר משותף מלבד המילה VPN. החליטו מה אתם בונים לפני שתסתכלו בתפריט.
התקן יכול לתמוך בשני התפקידים ובכל זאת לא לתמוך בתפקיד שאתם צריכים בקצב שאתם מצפים לו.
התפקיד הוא החלטת תכנון; ההגדרה היא תוצאה שלו.
אם רק פרוטוקול אחד נכשל
כאשר פרוטוקול אחד נכשל מאחורי נתב שעובד אחרת, חקרו תחילה את התעבורה ואת נתיב ה-NAT של אותו פרוטוקול. שינוי כל מצב השער כדי לתקן לקוח אחד שקול לחיווט מחדש של בית בגלל נורה שבורה. בדקו אם התעבורה עטופה ב-UDP, אם תכונת העזר של הנתב חלה על אותו פרוטוקול ואם הכשל סימטרי. אחר כך החליטו אם החלפת תפקיד אכן מוצדקת.
RFC 3948 מתאר את מיכלול ה-UDP שמאפשר ל-IPsec לשרוד NAT, וזהו התקן שיש לבדוק לפני שסומכים על תיבת סימון של העברה.
רשמו מה שיניתם ולמה, מפני שהאדם הבא ימצא את המכשיר במצב גשר ויניח שזה היה מכוון. התוצאה הנכונה היא רשת שאתם בחרתם את צורתה, לא כזו שירשתם ממפגש פתרון תקלות.