Laptop în roaming: nume stabil sau adresă fixă de birou?

Deschideți consola de administrare de acasă, căutați laptopul după nume și primiți o adresă care a încetat să fie validă când a părăsit biroul. Instinctul este să mutați adresa biroului pe adaptorul VPN ca totul să funcționeze în continuare. Acea corectare strică de obicei altceva, pentru că găsirea unui dispozitiv, permiterea traficului său și menținerea unei sesiuni în viață sunt trei probleme diferite. Separați-le înainte de a alege un design al adreselor.

Separați cele trei cerințe

Scrieți care dintre cele trei eșuează de fapt. O persoană sau un instrument nu găsește serviciul; un server refuză cererile pentru că adresa sursă nu este pe o listă; sau o aplicație cade când se schimbă interfața. Într-un tabel arată la fel și necesită corecturi diferite.

Majoritatea reclamațiilor de roaming ajung în primul coș și se rezolvă în DNS. A numi o identitate stabilă este ieftin și acoperă primul caz. Păstrarea adresei este scumpă și ajută al doilea caz doar dacă politica este rescrisă oricum.

Faceți numele lucrul stabil

Dați laptopului un nume care se rezolvă la orice adresă accesibilă apelantului. În acest exemplu adresa biroului este 192.168.50.42, bazinul de acces de la distanță distribuie 10.90.0.42, iar laptop17.corp.example urmează conexiunea. Nimic nu cere ca ultimul octet să coincidă, iar proiectarea în jurul acelei coincidențe creează muncă fără beneficiu. Înregistrarea ar trebui să indice adresa pe care apelantul o poate folosi cu adevărat, nu fiecare interfață pe care a avut-o laptopul vreodată.

dig +short laptop17.corp.example

Resolverele stochează răspunsurile în cache, așa că schimbarea nu este instantanee pentru toți. TTL-urile scurte ajută, iar logica de reconectare a aplicației ajută mai mult.

Când lista de surse permise este constrângerea reală

O listă de surse permise vede adresa pe care o primește serviciul protejat, după orice traducere. Este adesea o adresă de gateway sau NAT și nu cea a laptopului, de aceea editarea înregistrărilor DNS nu repară niciodată o cerere respinsă. Actualizați politica pentru adresa care ajunge de fapt, sau înlocuiți lista cu o identitate autentificată.

Capturați o cerere acceptată pe server și citiți câmpul sursă, apoi repetați din calea de la distanță. Dacă cele două adrese diferă, politica are nevoie de două intrări sau de alt mecanism. Notați ambele adrese împreună cu intrarea de politică, ca următoarea persoană să vadă de ce sunt două. Reutilizarea unei adrese deja active pe aceeași legătură este o problemă separată de conflict, cu propriile reguli de detectare.

Ce cere de fapt continuitatea

Continuitatea conexiunii este cea mai dificilă cerință și cea mai des interpretată greșit. O conexiune TCP este identificată de ambele adrese și ambele porturi, așa că o adresă locală nouă este altă conexiune, indiferent ce spune DNS. Aplicațiile care contează trebuie să se reconecteze, ceea ce înseamnă un strat de sesiune sau un client care reîncearcă, nu un truc de rețea. Observați o sesiune în timpul mutării și căderea este imediată, nu graduală.

ss -tnp state established '( dport = :443 )'

Clonarea unei adrese MAC nici nu rezolvă asta. Identitatea de leasing DHCP poate folosi un identificator de client explicit, iar două interfețe care împart o identitate au tot nevoie de rute coordonate. Tratați mobilitatea ca un design de aplicație și de alocare și mențineți identitatea dispozitivului stabilă în timp ce adresa lui urmează rețeaua.