אף נתיב לא מתקן מאגר VPN שחופף לרשת המקומית שלך

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

למה נתיב נוסף לא יכול לפצל קידומת אחת

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

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

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

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

קראו את המאגר שהלקוח באמת קיבל

קראו מה הלקוח קיבל, לא את דף השיווק של הספק. העלו את רמת הפירוט של יומן לקוח OpenVPN והנתיבים שהשרת דוחף יופיעו בו, ויחשפו את קידומות המנהרה; במקומות אחרים המאגר מופיע בפרטי החיבור או על המתאם עצמו. בקשו מהספק את הרשימה המלאה של הטווחים הפרטיים שהוא משתמש בהם, כי /24 אחד היום יכול להיות שניים מחר. להימנע מבלוקי RFC 1918 הנפוצים אינו אותו דבר כמו להימנע מההקצאה שבאמת ניתנה לכם.

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

מספור מחדש הוא התיקון שאתם יכולים לעשות

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

1. קודם מלאי: הכתובת של הנתב עצמו, טווח ה-DHCP, ההזמנות, העברות הפורטים וכל התקן שכתובתו הוקלדה ביד.
2. אחר כך שנו את קידומת ה-LAN של הנתב ואת טווח ה-DHCP יחד בתוך חלון תחזוקה, וחדשו חכירות קוויות לפני אלחוטיות.
3. לאחר מכן תקנו את הכתובות הקבועות: מדפסות, אחסון רשת, כל דבר עם שער מקודד.
4. לבסוף, חברו מחדש את לקוח ה-VPN ואשרו שכתובת המנהרה לא מתנגשת יותר ב-LAN.

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

מה כינוי יכול לעשות ומה לא

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

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

כתבו את הקידומות שנבחרו במקום שאנשים באמת מסתכלים בו: הערות הרשת, שדה ההערה של הנתב, דף הקליטה. מישהו יבחר שוב 192.168.1.0/24, וההתנגשות תחזור יחד איתו.