הבית והמשרד משתמשים שניהם ב-192.168.1.x: מה עכשיו?
כשהבית והמשרד חולקים את 192.168.1.0/24, ההתחברות מצליחה והתעבורה מגיעה להתקן הלא נכון. מחדשים את המספרים בצד שבבעלותכם, או משיגים תת-רשת מתורגמת.
עברו על ארבע בדיקות: לאיזו כתובת השם נפתר, איזה קידומת משתמשת הרשת המקומית, איזה מסלול בוחר הגרעין ליעד הזה, ומה עונה בקצה הרחוק. התחברות ה-VPN אינה אחת מהן, כי היא מושלמת ללא תלות במי מהרשתות מנצחת. בצעו את הבדיקות לפי הסדר והחפיפה תתגלה בשלב השני ולא ברביעי.
התחברות מוצלחת אומרת שהמנהרה פועלת; היא אינה אומרת דבר על היכן מצביעה כתובת מסוימת.
כתובת אחת, שתי מכונות
מארח בוחר נתיב מטבלת הניתוב וכללי המדיניות שלו, לפי כתובת היעד. שום דבר אינו אומר לו שבקשה לקפיצה 192.168.1.20 מיועדת לשרת המשרד ולא להתקן בחדר הסמוך. כששתי הרשתות באותו טווח פרטי, הנתיב הספציפי ביותר מנצח וכל השאר תלוי באיזו רשומה התקין חיבור מחדש במקרה. שום דבר בכתובת עצמה אינו נושא את ההבחנה הזו.
ip route get 192.168.1.20
החיפוש הזה מציין את הממשק ואת הקפיצה הבאה שהגרעין בחר, וזו הבדיקה השנייה ברשימה. השוו את הקידומת המקומית והמרוחקת לפני שתעשו משהו אחר. אם ה-LAN המקומי הוא 192.168.1.0/24 והאתר המרוחק גם הוא 192.168.1.0/24, החפיפה היא הממצא, ואף אפשרות לקוח אינה מתקנת אותה.
מחדשים את המספרים בצד שאתם שולטים בו
נתב אישי הוא בדרך כלל הצד הקל יותר להעברה. בחרו טווח שאינו מתנגש ברשתות המרוחקות שאתם באמת משתמשים בהן, וזכרו שגם 10.x.x.x אינו פנוי אוטומטית, כי אתרים רבים משתמשים בו. תכננו את השינוי: חכירות DHCP, כתובות שמורות, תורי הדפסה וכל דבר עם כתובת מקודדת קשיח זקוקים לתשומת לב. בצעו את המספור מחדש בחלון שבו תוכלו לשחזר את הנתב בלי ה-VPN.
בדקו את רשימת הקידומות המרוחקות קודם, לא אחר כך. בחירת טווח חדש שמתנגש באתר משרד אחר יוצרת את אותה בעיה עם יותר עבודה.
כשאף צד לא יכול להשתנות
אם אף אחת משתי הרשתות אינה ניתנת למספור מחדש, האפשרויות הנותרות נמצאות בשרת. שער יכול לתרגם רשת מרוחקת לתת-רשת אחרת עבור לקוחות VPN, באמצעות NAT מבוסס מדיניות או גרסה דו-כיוונית, כך שהלקוח רואה כתובת ייחודית. זהו תכנון שער ולא מתג שכל לקוח שולחני מספק, והוא משנה איזו כתובת משתמשים מקלידים ואילו שמות חייבים להתאים. מסלול שהועתק מפורום אינו יכול להבחין בין שני יעדים זהים.
טווחי כתובות פרטיים נשארים פרטיים; הבעיה היא שימוש חוזר, לא הטווחים עצמם.
הוכיחו איזו מכונה ענתה
openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject
לאחר כל שינוי, בדקו את משאב המשרד ואת ההתקנים המקומיים יחד. אם התקן ביתי מוכר עונה במקום שבו אמור להיות שרת המשרד, או שתעודת ה-TLS מציינת מארח שגוי, עצרו וזהו את היעד לפני שתמשיכו. קבלת תשובה מאותה כתובת אינה מוכיחה איזו מכונה שלחה אותה. בדיקת נושא התעודה היא אחד האותות המהימנים הבודדים הזמינים באותו שלב.
אל תחליפו כתובות פרטיות של המשרד בכתובות ציבוריות שרירותיות שאינכם שולטים בהן. זה מחליף חפיפה בבעיית ניתוב ובעלות שהיא גרועה יותר וקשה יותר להסבר.
רשמו את הקידומת המקומית, הקידומת המרוחקת והשינוי שפתר זאת. החפיפה הבאה תיראה אחרת אך תלך באותו דפוס.