ללקוחות VPN ב-RRAS דרוש מאגר IPv4 משלהם ונתיב חזרה

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

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

הקצו את הטווח לפני פתיחת הקונסולה

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

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

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

החלפת השיטה אינה הוספת טווח

ל-RRAS יש שיטת הקצאה וקבוצת טווחים. מעבר מ-DHCP למאגר סטטי הוא שינוי שיטה. הוספת בלוק נוסף כשהמאגר הסטטי כבר פעיל היא שינוי טווח.

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

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

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

Get-VpnIPAddressRange

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

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

ה-LAN זקוק לנתיב חזרה

נניח שה-LAN הוא 10.60.0.0/24 ושרת ה-RRAS הוא 10.60.0.10 בו. מארח ב-LAN הזה שמשיב ללקוח ב-10.250.50.0/24 זקוק לנתיב אל המאגר דרך שרת ה-RRAS. בלי הנתיב הזה הבקשה מגיעה והתשובה מתה.

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

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

הוכיחו את המאגר החדש במכשיר אחד לפני הוצאת הישן משימוש

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

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

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

בדקו את התוצאה בשלוש תצפיות

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

מהלקוח, אשרו את הכתובת ואת הנתיב למארח LAN אחד:

ipconfig | findstr /i "IPv4"
route print -4

ממארח ה-LAN, אשרו את נתיב התשובה ואת המדיניות במעבר אחד. אם ping נכשל אבל היישום עובד, החלק החסר הוא כנראה כלל ICMP ולא הנתיב. אם שניהם נכשלים, קראו את הנתיב במארח לפני עריכת ה-VPN. תיעדו את שלוש התוצאות בטיקט השינוי כדי שהאדם הבא יתחיל מראיות.

מאמרים קשורים