Trei condiții decid ce identificator ar trebui să folosească o rezervare: ce sistem distribuie adresa, dacă acel sistem vede vreodată un cadru de nivel 2 și ce folosește ca cheie de client. Un router de acasă cu DHCP, un VPN punte și un tunel rutat răspund diferit la aceste întrebări. Alegerea identificatorului este mai durabilă decât încercarea de a îngheța fiecare adresă MAC raportată de un adaptor, deoarece identificatorul este ceea ce citește de fapt alocatorul.

Începe de la alocator și lucrează invers; identificatorul din partea clientului este ceea ce acceptă acel sistem.

Întreabă mai întâi alocatorul

Un server DHCP alocă dintr-un pool și potrivește rezervările cu un identificator pe care îl recunoaște, care poate fi adresa hardware, un șir de identificator de client sau un DUID în funcție de versiunea protocolului. Un server VPN alocă din propriul pool și potrivește cu ceea ce expune modelul său de configurare, adesea Common Name autentificat. O rețea punte poate preda aceeași problemă serverului DHCP care deservește deja LAN-ul. Fiecare este o căutare diferită, iar o rezervare validă într-unul este invizibilă pentru celelalte.

Confirmă ce vede de fapt serverul înainte de a configura orice. O rezervare care numește identificatorul greșit eșuează în tăcere: clientul primește pur și simplu o adresă din pool, iar eroarea arată ca o problemă a clientului.

Unde o adresă MAC încă înseamnă ceva

Pe o legătură Ethernet sau Wi-Fi fizică, adresa hardware identifică o interfață din acel segment. Funcțiile de confidențialitate o rotesc, adaptoarele virtuale creează altele noi, iar un laptop poate prezenta valori diferite pe Wi-Fi și într-un dock. Un tunel TUN rutat transportă pachete IP și nu transmite identitatea wireless originală unui server DHCP aflat la distanță, așa că o rezervare bazată pe MAC pe acea cale nu are cu ce să se potrivească. TAP este diferit: transportă cadre Ethernet și se poate alătura unui domeniu punte unde identificatorii de nivel 2 încă contează.

Chiar și acolo, adresa relevantă este cea folosită în acel domeniu, nu automat cea a legăturii fizice superioare.

Adresele tunelurilor și cheile partenerilor au propriul spațiu

Un deployment OpenVPN rutat atribuie adrese prin propriul model: configurare per client cu cheie după un nume autentificat, sau un pool explicit. Schimbarea rezervării DHCP a unui router LAN nu creează acea atribuire, iar adăugarea unei rezervări de tunel nu influențează LAN-ul. WireGuard merge mai departe, pentru că un partener este identificat prin cheia sa publică și adresele permise, nu printr-un identificator hardware. Nicio rezervare Ethernet generică nu înlocuiește acolo configurația partenerului.

Ține un inventar care separă patru obiecte: acreditarea dispozitivului, adaptorul virtual, identificatorul alocatorului și adresa atribuită. O singură mașină fizică poate avea mai multe adaptoare, adrese și sesiuni.

O adresă stabilă nu este o identitate

O adresă previzibilă este comodă operațional și nu este o acreditare de autentificare. Regulile de acces care se bazează pe o adresă încetează să mai fie verificări de identitate în momentul în care aceasta este realocată, partajată sau falsificată. Dacă o regulă depinde de adresă, coordonează realocarea și revocarea cu cel care deține identitatea și păstrează decizia reală de autentificare în altă parte. Astfel o comoditate nu devine singura dovadă a dispozitivului care s-a conectat.

Înregistrează împreună alocatorul, identificatorul și adresa atribuită. Când unul se schimbă, celelalte două sunt ceea ce verifici.

Dacă două sisteme susțin amândouă că alocă pentru aceeași subrețea, decide care o deține înainte de a adăuga rezervări la oricare dintre ele.

Articole similare