שני לקוחות VPN על שולחון אחד: מה מתנגש ומה עובד

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

שלב 1: גלו איזה לקוח שולט ביציאה

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

ip route get 1.1.1.1
ip route show default
route print

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

עצרו אם שני הלקוחות דורשים את אותה קידומת עם אותו מדד. הליבה תבחר באחד, והשני ייראה מחובר בעודו לא נושא דבר.

שלב 2: בדקו את הפותר ואת הקידומות החופפות

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

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

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

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

שלב 3: בחרו תבנית הפרדה שמחזיקה מעמד

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

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

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

בחרו תבנית אחת ורשמו מדוע. ערבוב מרחב שמות ליישום אחד עם מנהרה מפוצלת לשאר יוצר מחדש את ההתנגשות המקורית בצורה שקשה יותר לאיתור.

שלב 4: אמתו את שתי הרשתות מאותו מושב

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

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

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

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