נתיב סטטי ב-FRITZ!Box: כוונו אותו לכתובת ה-LAN של שער ה-VPN
ה-FRITZ!Box צריך את הקידומת המרוחקת ואת כתובת ה-LAN של תיבת ה-VPN, לא כתובת מנהרה. כווננו נכון את שלושת השדות ואת נתיב החזרה.
ב-LAN הביתי שלכם יש FRITZ!Box כנתב ברירת מחדל ותיבה קטנה של לינוקס שלידה שעושה את עבודת ה-VPN. התיבה מגיעה לרשת המשרד, והמחשב הנייד שמאחורי ה-FRITZ!Box לא. נתיב סטטי פותר זאת בשלושה שדות, והקשיים האמיתיים היחידים הם לסרב לשים כתובת מנהרה בשדה השער. השער הוא הנתב הבא ב-LAN שלכם, ותמיד היה כזה.
כתבו את שלושת השדות לפני פתיחת הממשק
קחו LAN 192.168.50.0/24, FRITZ!Box בכתובת 192.168.50.1, ותיבת VPN עם כתובת קבועה 192.168.50.2 שכבר יש לה נתיב מוגן עובד אל 10.40.0.0/16. הנתיב אומר: עבור הקידומת המרוחקת הזו, מסרו את החבילה להתקן בכתובת ה-LAN הקבועה. נקודת הקצה הציבורית של שרת ה-VPN המרוחק וכתובת המנהרה הפנימית שלו שניהם לא רלוונטיים כאן, כי ה-FRITZ!Box אף פעם לא שולח אליהם דבר ישירות.
| שדה | ערך | מה הוא מכנה |
|---|---|---|
| רשת IPv4 | 10.40.0.0 | רשת היעד המרוחקת |
| מסכת תת-רשת | 255.255.0.0 | כמה גדול היעד הזה |
| שער | 192.168.50.2 | הנתב הבא ב-LAN הביתי |
הקצו את כתובת ה-LAN הזו מחוץ למאגר ה-DHCP, אחרת השער שהגדרתם יהיה יום אחד של טלפון.
היכן ה-FRITZ!Box שומר את הנתיב
FRITZ! פותח את בקרות נתיבי IPv4 תחת רשת ביתית, ואז רשת, ואז הגדרות רשת, כאשר התווית והקינון המדויקים תלויים בדגם ובגרסת FRITZ!OS. הפעילו את התצוגה המתקדמת אם טבלת הנתיבים מוסתרת, הוסיפו רשומה אחת עם הערכים שלמעלה והחילו. שווה להציץ במדריך לדגם הספציפי שלכם, כי אותה פונקציה עברה מקום יותר מפעם אחת בין גרסאות. שימו לב לניסוח המדויק של הרשומה שאתם שומרים, כי רשומה בטבלה ממעטת לספר איזה מסך יצר אותה.
זו אינה אותה פונקציה כמו כשה-FRITZ!Box עצמו מסיים VPN. נתיב מצביע על התקן אחר; ה-VPN המובנה הוא ההתקן.
השער חייב לנתב, לא רק להגיע
מארח שמגיע לרשת המרוחקת אינו נתב אוטומטית לשאר ה-LAN. תיבת ה-VPN זקוקה להעברת IP מופעלת, למדיניות חומת אש שמתירה העברה בין ממשק ה-LAN למנהרה, ולנתיב שמחזיר את התשובה ל-LAN במקום לצאת בנתיב ברירת המחדל שלה. הפעלת ההעברה ושכחת כלל חומת האש היא התיקון-למחצה הנפוץ ביותר, ומנקודת המבט של הלקוח זה נראה כמו כשל ניתוב.
בדקו זאת מצד ה-FRITZ!Box באמצעות פינג לכתובת ה-LAN של תיבת ה-VPN, ואז מלקוח באמצעות מעקב נתיב לכתובת מרוחקת ואישור שהקפיצה השנייה היא התיבה הזו.
נתיב חזרה וטווחים חופפים
הצד המרוחק זקוק לנתיב עבור 192.168.50.0/24 בחזרה דרך המנהרה, אלא אם אתם מתרגמים את המקור בכוונה בתיבת ה-VPN. שימור ותרגום הם מדיניויות שונות עם יומנים שונים וכללי גישה שונים, והנתיב הסטטי שהוספתם זה עתה לא בוחר ביניהם. טווחים חופפים הם בעיה קשה יותר: אם ה-LAN שלכם והרשת המרוחקת חולקים קידומת, נתיב מארח אחד לא יכול להבדיל ביניהם, ותוכנית הכתובות חייבת להשתנות.
הוספת נתיב ספציפי יותר במקום אחר ב-LAN, או לקוח VPN שני במחשב הנייד, תנצח בשקט את הרשומה ב-FRITZ!Box.
בדקו מלקוח רגיל, ואז בדקו את הכשל
הריצו את הבדיקה ממכונת LAN מורשית רגילה, לא מתיבת ה-VPN, כי התיבה כבר עבדה ולא מוכיחה דבר. הגיעו לשירות מרוחק ובדקו את התשובה, ואז ודאו שיעדי אינטרנט לא קשורים עדיין לוקחים את נתיב ברירת המחדל ואינם נגררים דרך המנהרה. החלפת נתיב ברירת המחדל כדי להגיע לתת-רשת אחת היא שינוי גדול בהרבה מהרשומה בת שלושת השדות שאיתה התחלתם.
לבסוף, נתקו את ה-VPN וראו מה קורה. הנתיב הסטטי נשאר בטבלה בעוד השער שלו איבד את הנתיב המוגן, ולכן התעבורה נכשלת בתיבה במקום ליפול חזרה לאינטרנט, וכל דרישה לחסום תעבורת גיבוי שייכת למדיניות של התיבה עצמה, לא לנתיב שמור.