איזו כתובת רושמים כלקוח RADIUS של NPS?
רשמו את מקור ה-backend האמיתי של השער, לא את שם המארח הציבורי ולא את מאגר הלקוחות. התאימו את הסוד המשותף, ואז אמתו בבקשה מבוקרת אחת.
שער VPN שמעביר את האימות ל-Windows NPS זקוק לאובייקט אחד בצד NPS לפני שכל מדיניות משתמש יכולה לפעול: רשומת לקוח RADIUS עבור השער. רוב הניסיונות הכושלים רושמים את הכתובת הלא נכונה, כי הכתובת שחשובה היא זו שהשער משתמש בה בנתיב ה-backend שלו, ולא שם המארח שהצוות מקליד באפליקציית ה-VPN. אם הערך הזה שגוי, NPS משליך את הבקשה בשקט, וזה נראה מצד הלקוח כמו סיסמה שגויה. שלושה תנאים קובעים איזו כתובת שייכת לשדה, לכן הבהירו אותם לפני פתיחת המסוף.
רשמו את השער, לא את המחשבים הניידים ולא את המאגר
אובייקט לקוח RADIUS מייצג את התקן גישת הרשת ששולח בקשות אימות. זהו שער ה-VPN, לא כל מחשב נייד שמריץ את הלקוח, ולא טווח הכתובות שמחולק בתוך המנהרות.
כתובות המנהרה האלה לא מופיעות לעולם כמקור של בקשת RADIUS, כי הבקשה עוברת בנתיב הרשת של השער עצמו. רישום רשומת מאגר לקוחות יוצר מדיניות שלעולם לא יכולה להתאים, בעוד הבקשה האמיתית מגיעה מכתובת ש-NPS לא שמע עליה מעולם. אותה מבוכה מובילה אנשים להוסיף את כתובת ה-IP הביתית של כל עובד, וזה גם בלתי ניתן לתחזוקה וגם שגוי.
שלושה תנאים קובעים את הכתובת שאתם מזינים
ראשית, מצאו את כתובת המקור שהשער באמת משתמש בה כלפי NPS. שער עם כמה ממשקים שולח לעיתים קרובות מממשק ניהול או backend ולא ממאזין ה-VPN הציבורי שלו. שנית, בדקו אם יש NAT בין השניים: אם הבקשה מתורגמת, NPS רואה את הכתובת המתורגמת, וזה הערך שיש לרשום. שלישית, אם שני שערים חולקים את התפקיד, כל מקור בקשה זקוק לרשומת לקוח משלו, כי אובייקט אחד עם כתובת אחת מכסה רק אחד מהם.
רשומה עם שני קצוות שומרת על הזוג מסודר. הטבלה שלהלן משתמשת בכתובות פרטיות להמחשה, לכן החליפו אותן באלה שהנתיב שלכם באמת משתמש בהן.
| At NPS | At the VPN gateway |
|---|---|
| RADIUS client address 10.20.0.10 | Authentication server 10.20.0.20 |
| Shared secret, agreed value | The same secret, same value |
| UDP 1812 permitted from 10.20.0.10 | UDP 1812 permitted toward 10.20.0.20 |
אמתו את המקור במקום לנחש אותו. צפו ביומן NPS או חומת האש במהלך ניסיון אחד, או קחו לכידה במארח NPS עם sudo tcpdump -ni any udp port 1812. הכתובת בלכידה ההיא היא התשובה היחידה שאפשר להגן עליה עבור רשומת הלקוח. אם לשער יש כמה מקורות אפשריים, רשמו כל אחד תחת שם ידידותי משלו.
הסוד המשותף הוא ערך בין השער ל-NPS
הסוד המשותף מאמת את הקשר בין ההתקנים. הוא אינו סיסמת משתמש והוא אינו מופץ לצוות ואינו מוטמע בפרופילי לקוח.
בחרו ערך אחד, הזינו אותו בשני המקומות, ואחסנו אותו במקום שבו נשמר גיבוי התצורה של השער. אי-התאמה יוצרת בקשה ש-NPS משליך בלי שגיאה שימושית, וזה לא ניתן להבחנה משרת בלתי נגיש ביומן השער. החליפו אותו בחלון תחזוקה ועדכנו את שני הקצוות באותו שינוי.
אמתו בבקשה מורשית אחת
השתמשו בחשבון מבוקר ותאמו ניסיון אחד בשני הצדדים. בשער, אשרו שהבקשה יצאה אל השרת המיועד; ב-NPS, אשרו שהיא הגיעה מהלקוח הרשום והתאימה למדיניות בקשת החיבור הצפויה. פקיעת זמן ודחייה אומרות דברים שונים, והתייחסות לשניהם כאל בעיית אישורים מבזבזת את השעה הבאה. לאחר מכן בדקו חשבון תקף אך לא זכאי וסיסמה שגויה, כי מדיניות שמקבלת הכול עוברת גם את המבחן הראשון.
לבסוף, בדקו מה השער עושה עם ההרשאה המוחזרת. רישום לקוח RADIUS רק מתיר להתקן להשתתף; הוא אינו מעניק לכל הפעלה שנוצרת גישה ל-LAN.
שמרו על פלט אבחון מצומצם: בלי סודות משותפים, בלי סיסמאות משתמש, בלי מטעני מנות מלאים בכרטיס תמיכה. אם התכנון דורש ששרת NPS יקרא מאפייני מדריך, ההרשאה הזו היא משימה מנהלית נפרדת מרישום הלקוח, וכשהיא חסרה היא נכשלת בדרך אחרת.