NAT בשרת ה-VPN או בנתב? שניהם יכולים לעבוד

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

המיתוס: מסלול לקוח בונה את היציאה

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

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

ציירו קודם את נתיב התשובה

כתבו את הנתיב עם כתובות אמיתיות לפני שנוגעים בהגדרה, וסמנו עליו את שתי נקודות התרגום האפשריות. המעבדה הזו משתמשת במאגר VPN של 10.70.0.0/24 עם לקוח אחד ב-10.70.0.37, בכתובת LAN של השרת 172.16.40.10, בנתב ב-172.16.40.1 וביציאה ציבורית 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

אפשרות א: תרגום בשרת ה-VPN

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

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

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

אפשרות ב: העברת המאגר לנתב

בסידור השני השרת מעביר קדימה את כתובת המקור האמיתית של הלקוח, והנתב מתרגם אותה. זה משאיר את מאגר הלקוחות גלוי בקצה, מה שעוזר אם הנתב הוא המקום שבו חיה מדיניות התעבורה, הרישום או הבדיקה. זה גם אומר שהנתב זקוק למסלול חזרה עבור 10.70.0.0/24 שמצביע אל 172.16.40.10, ובנוסף למדיניותו אינטרנט שכוללת באמת את הקידומת הזו; כלל שנכתב עבור תת-הרשת של ה-LAN אינו מתרחב בשקט אל המאגר.

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

הפכו את DNS, IPv6 והקבלה למפורשים

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

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

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