ערך הרישום NAT-T ב-Windows: לבדוק קודם את הטופולוגיה

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

מה הערך באמת בוחר

AssumeUDPEncapsulationContextOnSendRule קובע אם מימוש IPsec של Windows ינסה ליצור אסוציאציות עם עמית מאחורי התקן NAT. ברירת המחדל המתועדת 0 אינה מתירה מקרה זה, 1 מתיר אותו כשהשרת הוא הצד שמאחורי ה-NAT, ו-2 מכסה תרגום של שני הקצוות. אלו הצהרות טופולוגיה על מי נמצא היכן.

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

התאימו את הטופולוגיה לפני המספר

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

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

בדקו קודם את שלב הכשל

L2TP/IPsec מייצר לפחות שלושה כשלים שונים: העמית אינו נגיש, לא ניתן להקים הגנת IPsec, ו- אימות משתמש PPP נדחה לאחר שהמנהרה קיימת. חשבון שנדחה אינו מתוקן על ידי שינוי מדיניות NAT, ואי-התאמה של הצעות אינה מתוקנת על ידי אתחול מחדש.

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

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

ל-SSTP מעל HTTPS ול-IKEv2 המקורי יש יומנים משלהם ובקרות משלהם. שום דבר מהם אינו הופך למקרה NAT-traversal רק מפני שהם רצים גם ב-Windows.

בצעו את השינוי עם דרך חזרה

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

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