SSTP ו-IKEv2 משתמשים בבקרות תעודה שונות של RRAS

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

תנו שם לפרוטוקול לפני התעודה

מאזין SSTP מציג תעודת TLS ללקוח שמתנהג כמו HTTPS. חיבור IKEv2 נכנס מאתר לאתר מכריז על זהות שרת ומאמת תעודות עמיתים מול שורש מהימן. הגדרת אתר-לאתר לכל ממשק נושאת זהות מכונה משל עצמה.

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

SSTP הוא קישור HTTPS

בפריסות Remote Access נתמכות, Set-RemoteAccess חושף פרמטר SslCertificate המשמש לקישוריות SSTP ולתפקיד DirectAccess הקשור ל-HTTPS.

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

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

ל-IKEv2 הנכנס יש פרמטר משל עצמו

Set-VpnAuthProtocol מגדיר אימות IKEv2 נכנס מאתר לאתר, ו-CertificateAdvertised מספק תעודה כאשר מצב אימות המנהרה משתמש בהן. זו אינה פקודה כללית לבחירת תעודת שרת כלשהי במארח.

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

הזהות של ממשק אתר-לאתר בודד מוגדרת דרך Set-VpnS2SInterface. היא אינה תעודת SSTP אוטומטית, גם כאשר שתיהן יושבות באותו מאגר באותה מכונה.

בחנו תחילה את המועמד

תצוגה ממוקדת של מאגר המכונה המקומית מציגה מטא-נתונים ציבוריים בלי לייצא דבר פרטי:

Get-ChildItem Cert:\LocalMachine\My |
    Select-Object Thumbprint, Subject, HasPrivateKey, NotAfter

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

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

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

חידוש אינו הפעלה

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

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

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