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

טבלת הניתוב בוחרת מנצח אחד

צלמו את הטבלה לפני ואחרי שהלקוח הארגוני מתחיל, וקראו את עמודת הממשק ולא רק את היעד. מסלול ברירת מחדל פשוט מהמנהרה החיצונית קל לעקור, מפני שזוג /1 ספציפי יותר מ-/0. הזוג המילולי 0.0.0.0/1 ו-128.0.0.0/1 מכסה את כל מרחב IPv4 בשני חצאים ומנצח כל ברירת מחדל בודדת. לאחר ההתקנה, המנהרה החיצונית עדיין מוצגת כמחוברת ואינה נושאת דבר.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

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

ip rule show

Windows מכריע בזה באמצעות מדדים

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

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

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

שני צופים, שתי תצפיות שונות

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

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

DNS ו-IPv6 הם המקומות שבהם השרשרת דולפת

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

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

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

מאמרים קשורים