IPv6 adatvédelmi címek vagy RDP engedélyezési lista: válassza a kompromisszumot

A távoli asztali hozzáférés egy hónapig működött, aztán az engedélyezési lista minden látható ok nélkül abbahagyta az egyezést. A gazdagép nem mozdult el, és a tűzfalban semmit nem szerkesztettek. A Windows továbbra is véletlenszerű interfész-azonosítókkal rendelkező ideiglenes IPv6-címeket képez és von vissza, így a kiszolgáló által egy adott napon látott forráscím lehet olyan, amelyet senki nem írt be a szabályba. Ennek a viselkedésnek a kikapcsolása helyrehozza az egyezést, és egyben hosszú életű azonosítóvá teszi a gazdagépet. Mérlegelje a lehetőségeket, mielőtt elfogadja a második felét.

Miért hagyta abba a szabály az egyezést

Az RFC 4941 az ideiglenes címeket írja le: a gazdagép további címeket hoz létre véletlenszerűsített azonosítókkal, és visszavonja azokat, ami megakadályozza, hogy egy megfigyelő egy gazdagépet látogatások között összekapcsoljon. A Windows ezt a viselkedést valósítja meg, így a tegnapi forráscím nem feltétlenül a mai. Az előre jelezhető cím továbbra is létezik az interfészen; egyszerűen nem az, amelyet egy kimenő kapcsolat előnyben részesít.

Ezért tűnik a hiba szakaszosnak és nem teljesnek. A szabály egy ideig egyezik a cím létrehozása után, megszűnik egyezni, amikor visszavonják, és újra egyezni kezd, miután valaki szerkeszti. A forráscím szerint csoportosított megfigyelés és a gazdagép-címhez kötött licencellenőrzések ugyanazon ütemterv szerint törnek el. Az a szabály, amely közvetlenül a szerkesztés után működik, és három héttel később meghibásodik, általában ez, nem a tűzfal újratöltése.

Első lehetőség: egy stabil cím, kevesebb adatvédelem

A szokásos javítás kikapcsolja mindkét forgó mechanizmust a gazdagépen: netsh interface ipv6 set privacy state=disabled store=persistent és netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Adja hozzá a store=active parancsot, ha azt szeretné, hogy a változás újraindítás nélkül életbe lépjen, és fogadja el, hogy most előre jelezhetővé tette az azonosítót a hálózatok között.

Pontosan ezt az előrejelezhetőséget hivatottak megakadályozni a bővítmények. Az a cím, amely a gazdagépet a kávézóból az irodába, majd haza követi, kényelmes szűrőkulcs és ugyanolyan kényelmes nyomkövetési kulcs, és a második tulajdonság túléli azt a jegyet, amely az elsőt kérte.

Második lehetőség: engedjen meg egy előtagot vagy egy nevet

Ha a /64-et engedélyezi a teljes cím helyett, a forgás sértetlen marad, és megfelel egy gyengébb, de gyakran őszinte állításnak: ez a gép az otthoni hálózatomon van. Ez akkor szűnik meg elegendő lenni, amikor az az előtag olyan gazdagépeket tartalmaz, amelyeket nem engedne be, ami fogyasztói kapcsolatnál általában kisebb halmaz annál, mint amit az emberek feltételeznek. A dinamikus DNS-en keresztül közzétett név könnyebben üzemeltethető, mert a rekord követi a gazdagépet, és a szabályzat identitásként olvasható, nem pedig olyan tartományként, amely minden hozzáadott eszköznél növekszik.

Mindkét lehetőséghez olyan feloldó kell, amelyben a kiszolgáló megbízhat, és olyan név, amely nem hamisítható triviálisan, ezért kezelje őket az identitásról szóló szakpolitikai döntésként, nem pedig a szabály kozmetikai módosításaként. Jegyezze fel, melyik feloldó válaszol arra a névre, mert a szabály csak annyira megbízható, mint az mögötte lévő rekord.

Harmadik lehetőség: az alagút ossza ki a címet

Ha a kapcsolat olyan VPN-en halad át, amelyet Ön irányít, a kiszolgáló a saját készletéből adhatja a címet, és az engedélyezési lista ekkor olyan értékre hivatkozik, amelyet a kiszolgáló választ, nem pedig olyanra, amelyet az ügyfél előnyben részesít. Ez jól működik kezelt ügyfeleknél, és rosszul minden olyannál, amit az ügyfél felül tud írni, ezért ellenőrizze, melyik fél nyer valójában az üzembe helyezésében.

A döntést teljesen elmozdítani a címről, egy ügyféltanúsítványra vagy egy hitelesített átjáróra, az a lehetőség, amely skálázódik, mert megszűnik egy olyan értéktől függeni, amelyet az operációs rendszer jogosult megváltoztatni.

A nyomkövetési költséget szem előtt tartva válasszon

Írja fel a négy lehetőséget a tényleges követelménnyel szemben, és egyet válasszon ahelyett, hogy kombinálná őket. Ha mégis kikapcsolja az adatvédelmet, korlátozza arra a gazdagépre, amelynek szüksége van rá, dokumentálja az okot a szabály mellett, és fontolja meg az RFC 7217 szerinti stabil-adatvédelmi címzést ott, ahol a platform támogatja, mivel előtagonként tart meg egy azonosítót anélkül, hogy felfedné a hardverből származtatottat. Ha az engedélyezési listát lecserélik, kapcsolja vissza a bővítményeket.

Rögzítse a változtatást azon szabály mellett, amelyet támogat. E feljegyzés nélkül a következő rendszergazda egy gazdagépet talál kikapcsolt adatvédelmi bővítményekkel és magyarázat nélkül, és egy takarítás során visszakapcsolja őket.