Adrese de confidențialitate IPv6 sau o listă de permisiuni RDP: alegeți compromisul

Accesul la desktop la distanță a funcționat o lună, apoi lista de permisiuni a încetat să se potrivească fără niciun motiv vizibil. Gazda nu se mutase și nimic din firewall nu fusese editat. Windows continuă să formeze adrese temporare IPv6 cu identificatori de interfață aleatori și să le retragă, așa că adresa sursă pe care o vede serverul într-o zi oarecare poate fi una pe care nimeni nu a scris-o în regulă. Dezactivarea acestui comportament repară potrivirea și, în același timp, transformă gazda într-un identificator de lungă durată. Cântăriți alternativele înainte de a accepta a doua jumătate.

De ce regula a încetat să se potrivească

RFC 4941 descrie adresele temporare: gazda creează adrese suplimentare cu identificatori randomizați și le retrage, ceea ce împiedică un observator să coreleze o gazdă între vizite. Windows implementează acest comportament, deci adresa sursă de ieri nu este neapărat cea de azi. Adresa previzibilă există în continuare pe interfață; pur și simplu nu este cea pe care o preferă o conexiune de ieșire.

De aceea defecțiunea pare intermitentă, nu totală. Regula se potrivește o vreme după crearea adresei, încetează să se potrivească atunci când aceasta este retrasă și începe din nou să se potrivească după ce cineva o editează. Monitorizarea grupată după adresa sursă și verificările de licență legate de o adresă de gazdă se strică după același calendar. O regulă care funcționează imediat după editare și eșuează trei săptămâni mai târziu este de obicei aceasta, nu o reîncărcare a firewall-ului.

Opțiunea unu: o singură adresă stabilă, mai puțină confidențialitate

Reparația obișnuită dezactivează ambele mecanisme de rotație pe gazdă: netsh interface ipv6 set privacy state=disabled store=persistent și netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Adăugați store=active dacă vreți ca schimbarea să intre în vigoare fără a aștepta o repornire, și acceptați că ați făcut identificatorul previzibil între rețele.

Exact această previzibilitate au fost create extensiile să o împiedice. O adresă care urmează gazda de la cafenea la birou și acasă este o cheie de filtrare comodă și o cheie de urmărire la fel de comodă, iar a doua proprietate supraviețuiește biletului care a cerut-o pe prima.

Opțiunea doi: permiteți un prefix sau un nume

Permiterea /64 în locul adresei complete păstrează rotația intactă și se potrivește cu o afirmație mai slabă, dar adesea onestă: această mașină este în rețeaua mea de acasă. Devine insuficientă în momentul în care acel prefix conține gazde pe care nu le-ați admite, ceea ce într-o conexiune de consum este de obicei o mulțime mai mică decât presupun oamenii. Un nume publicat prin DNS dinamic este mai ușor de operat, pentru că înregistrarea urmează gazda, iar politica se citește ca o identitate, nu ca un interval care crește de fiecare dată când se adaugă un dispozitiv.

Ambele opțiuni au nevoie de un resolver în care serverul poate avea încredere și de un nume care nu poate fi falsificat trivial, așa că tratați-le ca o decizie de politică privind identitatea, nu ca o schimbare cosmetică a regulii. Notați care resolver răspunde acelui nume, pentru că regula este doar atât de de încredere pe cât este înregistrarea din spatele ei.

Opțiunea trei: lăsați tunelul să atribuie adresa

Dacă conexiunea trece printr-un VPN pe care îl controlați, serverul poate distribui adresa din propriul pool, iar lista de permisiuni face referire atunci la o valoare pe care o alege serverul, nu la una pe care o preferă clientul. Asta funcționează bine pentru clienții administrați și prost pentru orice poate clientul să suprascrie, așa că verificați care parte câștigă de fapt în implementarea voastră.

Mutarea deciziei complet în afara adresei, către un certificat de client sau o poartă autentificată, este opțiunea care scalează, pentru că încetează să depindă de o valoare pe care sistemul de operare are dreptul să o schimbe.

Alegeți cu costul urmăririi în vedere

Scrieți cele patru opțiuni față de cerința reală și alegeți una în loc să le combinați. Dacă totuși dezactivați confidențialitatea, limitați-o la gazda care are nevoie de ea, documentați motivul lângă regulă și luați în calcul adresarea stabil-privată din RFC 7217 acolo unde platforma o acceptă, pentru că păstrează un identificator pe prefix fără a-l expune pe cel derivat din hardware. Reactivați extensiile când lista de permisiuni este înlocuită.

Înregistrați schimbarea lângă regula pe care o susține. Fără acea notă, următorul administrator găsește o gazdă cu extensiile de confidențialitate oprite și fără explicație, și le pornește din nou în timpul unei curățenii.