VPN ב-FRITZ!Box מתחבר אבל שום דבר לא עונה: WireGuard או IPSec
מנהרה מחוברת של FRITZ!Box שאינה מגיעה ל-LAN היא בעיית כתובות. בדקו את ארבעת שדות IPSec או את ה-peer של WireGuard לפני ייבוא חוזר.
המנהרה מדווחת שמחובר, הסמל ירוק, ושום דבר ברשת הביתית לא עונה. זו התלונה הנפוצה ביותר על גישה מרחוק ב-FRITZ!Box, וכמעט אף פעם לא המנהרה עצמה אשמה. תוכנית הכתובות, זהות תת-הרשת או טבלת הניתוב של הלקוח שגויות. מה מהם תדבגו בסוף תלוי בבחירה שלכם ב-WireGuard או ב-IPSec Fernzugang הישן יותר, אז התחילו בלדעת מה בעצם הגדרתם.
המנהרה עולה וה-LAN נשאר שקט
מנהרה שמתבססת מוכיחה שהמפתחות ונקודת הקצה נכונים. אבל היא לא מוכיחה שהלקוח קיבל כתובת שהקופסה יכולה לנתב אליה, ולא שהלקוח יודע אילו קידומות שייכות למנהרה. אלה שתי הצלחות נפרדות, ורק השנייה מאפשרת להגיע למדפסת.
בדקו קודם את כתובת הלקוח, ואחר כך את טבלת הניתוב שלו.
אם הכתובת שהוקצתה נמצאת מחוץ לתת-הרשת של ה-LAN, לקופסה אין לאן לנתב בחזרה. אם היא נמצאת בתוך טווח ה-DHCP, הקופסה עלולה להעניק את אותה כתובת להתקן מקומי. שני המקרים יוצרים מנהרה שמתחברת ו-LAN שמתעלם מכם.
מה כל אפשרות באמת מגדירה
אפשרות IPSec מייצרת קובץ תצורה למשתמש אחד, הכולל את המפתח המשותף מראש ואת הכתובות. אתם מייבאים אותו ללקוח שמדבר באותו פרופיל, ובחלונות זה בדרך כלל אומר את הכלי של היצרן ולא את הלקוח המובנה. אפשרות WireGuard מייצרת peer להתקן אחד: צמד מפתחות, כתובת בתוך המנהרה ונקודת קצה.
ההבדל הזה קובע את מודל התחזוקה שלכם. כל התקן WireGuard הוא peer נפרד עם מפתח משלו, כך שביטול טלפון שאבד פירושו מחיקת peer אחד בזמן שהאחרים ממשיכים לעבוד. IPSec מבטל על ידי שינוי הסוד המשותף או תצורת המשתמש, וזה גס יותר ומשפיע על כל התקן שמשתמש בו.
אף אחת מהאפשרויות אינה מיושנת. מסלול IPSec נשאר הנתמך בכל מקום שבו הצד המרוחק אינו יכול להריץ WireGuard.
שדות IPSec שמייצרים מנהרה מתה
ארבעה ערכים חייבים להתאים ל-LAN שלכם, ושלושה מהם נכשלים באופן שנראה כמו מנהרה שבורה.
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
כתובת הרשת היא זו שתופסת אנשים. תת-רשת מזוהה לפי הכתובת הראשונה שלה, שבדרך כלל מסתיימת באפס, והזנת כתובת מארח שם מייצרת תצורה שנראית סבירה לחלוטין ולעולם אינה מתחברת. טווח ה-DHCP חשוב מסיבה אחרת: לקוחות המנהרה מוקצים בדרך כלל מעליו, כך שטווח שצורך את כל תת-הרשת לא משאיר דבר לחלוקה.
תת-רשתות חופפות הן המקרה הקלאסי האחר. אם ה-LAN המרוחק שאליו אתם מצטרפים משתמש באותה קידומת כמו ה-LAN שאתם יושבים עליו, הניתוב לא יכול להבחין בין השניים, ומספור מחדש של צד אחד הוא התיקון האמיתי היחיד. שום כמות של תצורת לקוח לא פותרת את זה.
למה WireGuard נכשל אחרת
ל-WireGuard אין מפתח משותף מראש שאפשר להקליד לא נכון, ולכן הכשלים שלו מתקבצים סביב הגדרת ה-peer במקום. רשימת IP מורשים שמשמיטה את קידומת ה-LAN יוצרת מנהרה שלא נושאת דבר, כי הלקוח לעולם לא שולח לתוכה תעבורה שמיועדת ל-LAN. מפתח ציבורי ישן באחד הצדדים יוצר לחיצת יד שלעולם אינה מושלמת. נקודת קצה חסרה או פורט שגוי יוצרים שקט במקום שגיאה.
השוו את שני הצדדים שדה אחר שדה במקום לייבא את הקובץ שוב ולקוות.
הכשל המשותף היחיד הוא התנגשות תת-רשתות. WireGuard יבנה בשמחה מנהרה לרשת שחופפת לרשת המקומית שלכם, ואז טבלת הניתוב מחליטה איזו משתי הקידומות הזהות תנצח.
הוכיחו את זה מבחוץ, ואז שמרו דרך חזרה פנימה
בדקו מחיבור סלולרי, אף פעם לא מתוך ה-LAN, כי מבפנים אתם בודקים מסלול שאינו כולל את המנהרה כלל. רשמו איזה פורט כל אפשרות משתמשת בו לפני שתפעילו אותה, והעבירו את הפורט הזה לקופסה.
שמרו את הקובץ שנוצר במקום שאתם מגיעים אליו בלי המנהרה, ותוך כדי רשמו את השם החיצוני של הקופסה.
תצורה שמעולם לא נבדקה מבחוץ היא תוכנית ולא מסלול גישה מרחוק שעובד. בדקו מארח LAN אחד לפי כתובת ולא לפי שם, כדי שכשל DNS לא ייחשב בטעות לכשל ניתוב.