שני VPN של Windows בו-זמנית: איזה פרופיל שומר על נתיב ברירת המחדל?

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

רק רשומה אחת יכולה להיות ברירת המחדל הטובה ביותר

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

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

פתרון שמות הוא עימות שני ועצמאי, ותיקון טבלת הניתוב לבדו לא יפתור אותו.

מה תיבת הסימון מתקינה, ומה היא מסירה

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

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

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

בחרו לפי מה שכל מנהרה חייבת לשאת

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

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

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

הוסיפו את הקידומות החסרות ובדקו את התוצאה

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

> route add 172.22.0.0 mask 255.255.0.0 172.20.4.1
> route print -4
> Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric

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

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

> Get-DnsClientServerAddress -AddressFamily IPv4
> Resolve-DnsName files.corp.internal -Server 172.20.4.1

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

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