מסנן תעבורת VPN או כלל IPsec: היכן Windows אוכף פורט

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

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

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

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

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

הגבלת גישה ודרישת הגנה נפרדות

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

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

בנו את רשימת המסננים כקבוצה מלאה

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

TrafficFilterList/0/Protocol            = 6
TrafficFilterList/0/RemoteAddressRanges = 10.60.4.20/32
TrafficFilterList/0/RemotePortRanges    = 443
RouteList/0/Address                     = 10.60.4.0/24

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

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

הוכיחו את שתי התוצאות בשתי בקשות

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

Test-NetConnection 10.60.4.20 -Port 443
Test-NetConnection 10.60.4.20 -Port 445
Get-NetIPsecRule -DisplayName *Vpn*
Get-VpnConnection -Name Corp

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

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