טריגר VPN לפי אפליקציה ב-Windows מול מנהרה מפוצלת: מה מבודד
פרופיל VPN של Windows שמופעל על ידי אפליקציה רק פותח מנהרה. מנהרה מפוצלת עם מסלולים מחליטה מה נכנס אליה, וכל אחת נכשלת אחרת עבור אפליקציה אחת.
שני הסדרי Windows נראים אותו דבר בהגדרות ומתנהגים אחרת לגמרי. האחד הוא פרופיל VPN שהועתק עם טריגר אפליקציה, כך שהפעלת קובץ הפעלה אחד מעלה את המנהרה. האחר הוא פרופיל מנהרה מפוצלת שרשימת המסלולים שלו מכסה במקרה את מה שהאפליקציה הזו מדברת איתו. הראשון עונה מתי המנהרה קיימת. השני עונה אילו מנות נכנסות אליה, ורק השני משאיר את שאר המכונה על הקישור הפיזי בזמן שהאפליקציה נשארת מחוברת.
הטריגר הוא כלל מחזור חיים, לא כלל ניתוב
Add-VpnConnectionTriggerApplication קושר נתיב קובץ הפעלה לשם פרופיל. כשהתהליך הזה מתחיל, מנהל החיבורים לגישה מרחוק מחייג לפרופיל, ו כשתנאי הטריגר מסתיים, החיבור עלול ליפול. שום דבר בחילופין הזה לא בודק sockets. הפקודה דורשת shell מוגבר, את הנתיב המלא לקובץ הבינארי ו -Force כשמחליפים רשומה קיימת. אשרו שהשיוך שרד עם Get-VpnConnectionTrigger במקום לסמוך על ההנחיה; מדריך Add-VpnConnectionTriggerApplication מפרט את הפרמטרים ואת הדוגמאות.
שני גבולות מסבירים את רוב הדיווחים ש„הטריגר לא עושה כלום”. טריגרים בנויים סביב פרופילים לכל המשתמשים, ולכן היקף הפרופיל הוא הדבר הראשון שצריך להסדיר, ונתיב האפליקציה חייב להתאים לקובץ הבינארי שרץ בפועל, לא לקיצור דרך או למפעיל שיוצר תהליך שני. הגבול השני מכוון: ברשת ש-Windows מסווג כמהימנה, הטריגר נשאר בטל, כי הפרופיל נועד לפעול מחוץ למשרד.
Add-VpnConnectionTriggerApplication -Name "APP_VPN" -ApplicationID "C:\Program Files\Vendor\app.exe" -Force
Get-VpnConnectionTrigger -Name "APP_VPN" | Format-List *
Get-VpnConnection -Name "APP_VPN" | Format-List Name,ConnectionStatus,SplitTunneling,AllUserConnectionהמנהרה המפוצלת מחליטה מה חוצה את המנהרה
כשהמנהרה המפוצלת כבויה, Windows מתקין מסלול ברירת מחדל מבוסס מחלקה עם מדד נמוך בממשק ה-VPN. כל socket עוקב אחריו, כולל הדפדפן ושירות העדכונים, ולכן טריגר בתצורה הזו מזיז את כל המכונה כל עוד הפרופיל מחובר. הטריגר עדיין רק כלל מחזור חיים; רדיוס ההשפעה בא מהמסלול.
כשהמנהרה המפוצלת פועלת, הפרופיל נושא רק את הקידומות שהשער דוחף או שאתם מוסיפים לממשק ה-VPN. כל השאר ממשיך להשתמש במסלול ברירת המחדל הפיזי. זהו הסידור שאנשים בדרך כלל מתכוונים אליו ב„אפליקציה אחת דרך יציאה נפרדת”, וזו החלטת ניתוב מתחילתה ועד סופה.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefixהיכן פיצול מנותב מפסיק לבודד את האפליקציה שלכם
הכשל הנפוץ הוא יעד שלעולם אינו מופיע ברשימת המסלולים של המנהרה. אפליקציה שמתחברת לכתובת אחת ואז מזרימה מ-CDN, או מפענחת תריסר נקודות קצה מתחלפות, תשים חלק מהחיבורים על ממשק ה-VPN ואת השאר על Wi-Fi. IPv6 הוא טבלה נפרדת, ולכן פרופיל שדוחף רק קידומות IPv4 יכול להיראות תקין בזמן שתעבורת ה-IPv6 של האפליקציה נשארת מקומית.
שני אפקטים קטנים יותר חשובים באותה מידה. ההתאמה הארוכה ביותר של קידומת מנצחת, ולכן מסלול on-link ספציפי יותר, /32 שנדחף עבור מארח ניהול או תת-הרשת של מתאם שני יכולים לגבור על המנהרה בדיוק עבור הכתובת שמעניינת אתכם. גם פתרון השמות קורה לפני הניתוב: אלא אם שרתי ה-DNS של הפרופיל או כלל NRPT מכסים את השם, האפליקציה יכולה לפתור דרך המתאם הפיזי ואז לחייג לכתובת שמעולם לא הייתה בתוך הקידומות המנהרתיות.
שלושה צורות, ומה כל אחת קונה
הטבלה היא החלק שהייתי מדביק על הקיר, כי ההחלטה היא על רדיוס ההשפעה ולא על תכונות. אם היעדים של האפליקציה הם קידומות יציבות שאפשר לפרט, הפיצול המנותב נותן בידוד עם טביעת הרגל הקטנה ביותר. אם לא, פרופיל מסלול ברירת מחדל מאחורי VM או התקן שני שומר על ההפרדה ביושר במחיר של הזזת יותר מתהליך אחד.
| Shape | What starts the tunnel | What enters it | Pick it when |
|---|---|---|---|
| Trigger plus routed split | Process start | Only pushed or added prefixes | The app's endpoints are stable prefixes and the host should stay direct |
| Trigger plus default route | Process start | Everything, machine-wide | You need one exit for all traffic and accept the wider scope |
| Separate VM or device | Guest boot or login | Everything inside that guest | The app's destinations rotate, or the host must keep its own public address |
מה שאף אחת מאלה לא מספקת הוא קישור ברמת socket במארח. ללקוח ה-VPN הקלאסי של Windows אין כלל שאומר שהתהליך הזה חייב להשתמש במתאם הזה; טריגרים ומסנני מסלולים חיים בשכבות שונות, והשכבה שבוחרת ממשק היא טבלת הניתוב. אם מדריך מבטיח אכיפה לפי אפליקציה רק מפרופיל שהועתק, שאלו איזה מסלול או איזה מסנן עושה את העבודה.
אמתו את הצמד במעבר אחד
בדקו את מחזור החיים ואת הניתוב בנפרד, בסדר הזה. סגרו את האפליקציה, אשרו שהפרופיל מדווח Disconnected, ואז הפעילו את האפליקציה ובדקו שהמצב השתנה. רק לאחר שהמנהרה למעלה צריך לשאול לאן הולך יעד מסוים, וכדאי להשתמש בכתובת שהאפליקציה מחייגת אליה בפועל ולא בניחוש.
$app = Get-Process app | Select-Object -First 1
Get-VpnConnection -Name "APP_VPN" | Select-Object ConnectionStatus
Get-NetTCPConnection -OwningProcess $app.Id -State Established | Select-Object RemoteAddress,RemotePort
Find-NetRoute -RemoteIPAddress 203.0.113.10Find-NetRoute מציין את הממשק ואת הקפיצה הבאה שתישא את היעד הזה. alias פיזי שם אומר שהמנהרה למעלה ושאינה רלוונטית לזרימה הזו: בדקו את הקידומות שנדחפו, אחר כך את המסלולים הספציפיים יותר, אחר כך IPv6. אם המצב לא משתנה כלל, הטריגר לא נורה, ונתיב קובץ ההפעלה, היקף הפרופיל ויומן הפעולה של לקוח ה-VPN הם שלושת המקומות לבחון.
נקו היטב כדי שהבדיקה הבאה תהיה כנה
הסירו בסדר ההפוך מזה שבניתם: קודם טריגר האפליקציה, אחר כך הפרופיל. מחיקת הפרופיל כשהטריגר נשאר משאירה שיוך תלוי שהופך את הניסיון הבא למבלבל, ו Remove-VpnConnection -Force לא תמיד מנקה רשומת ספר טלפונים שנוצרה מחוץ לפקודות.
רשומות לפי משתמש נמצאות ב rasphone.pbk של המשתמש תחת פרופיל Roaming; רשומות לכל המשתמשים נמצאות תחת ProgramData. בדקו את המאגר המתאים להיקף הפרופיל, חברו מחדש את הפרופיל ששמרתם ואשרו שהמסלולים וה-DNS שלו עדיין מתנהגים, כך שבדיקה מאוחרת תמדוד את השינוי שעשיתם ולא מצב שנשאר.
- המנהרה מתחילה בהפעלת התהליך, לא בכניסה.
- רק הקידומות המיועדות מופיעות בממשק ה-VPN.
- הכתובת המרוחקת האמיתית של האפליקציה נפתרת ל-alias של ה-VPN.
- לא נשאר טריגר תלוי לאחר הסרת הפרופיל.