Адреси за поверителност на 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 там, където платформата го поддържа, тъй като то запазва идентификатор за всеки префикс, без да разкрива извлечения от хардуера. Включете отново разширенията, когато списъкът за разрешаване бъде заменен.

Запишете промяната до правилото, което поддържа. Без тази бележка следващият администратор намира хост с изключени разширения за поверителност и без обяснение и ги включва отново по време на почистване.