כתובות פרטיות IPv6 או רשימת הרשאות RDP: בחרו את הפשרה

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

למה הכלל הפסיק להתאים

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

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

אפשרות אחת: כתובת יציבה אחת, פחות פרטיות

התיקון הרגיל מכבה את שני מנגנוני הסבב במארח: netsh interface ipv6 set privacy state=disabled store=persistent ו-netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. הוסיפו store=active אם אתם רוצים שהשינוי יחול בלי להמתין לאתחול, וקבלו שהפכתם את המזהה לצפוי לרוחב רשתות.

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

אפשרות שתיים: לאפשר קידומת או שם

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

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

אפשרות שלוש: תנו למנהרה להקצות את הכתובת

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

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

בחרו תוך מבט על עלות המעקב

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

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