Ordinador de feina en una VPN personal: què hi passa realment
Un segon túnel en un ordinador de feina no és un pont, però el punt final encara pot retransmetre dades. Repasseu tres punts de travessa abans d'aprovar res.
Connectar un ordinador d'empresa a una VPN domèstica el situa en dos llocs alhora, i la pregunta interessant és més petita i més útil que la que fa por. Ningú no ha estès un cable Ethernet entre l'oficina i la casa, i cap ruta no converteix la xarxa domèstica en una extensió de la subxarxa corporativa. El que hi ha és un sol punt final amb accés a tots dos entorns, i tres mecanismes separats decideixen què es pot moure realment entre ells. Recórrer aquests tres des del punt final cap enfora dona una resposta sobre la qual un administrador pot actuar en lloc d'un debat sobre etiquetes.
Comença pel punt final, no pel diagrama de xarxa
El punt final és on es troben les dues connexions, així que és on comença la revisió: quins processos s'executen, què poden assolir i qui els controla. Un diagrama que mostra dos núvols connectats a un ordinador portàtil és exacte i inútil, perquè implica un enllaç que potser no existeix. Substitueix-lo per una llista de les aplicacions que poden parlar amb cada entorn i anota amb quin compte s'executa cadascuna. Aquest plantejament també manté la revisió proporcionada, ja que un ordinador amb dos túnels no és el mateix objecte que dues xarxes unides.
Aquesta llista és l'inventari a partir del qual treballa la resta de la revisió. Si conté un client de sincronització, un perfil de navegador amb sessió iniciada als dos entorns i un agent de compilació amb credencials, la revisió ja té els seus subjectes.
Tres punts de travessa, revisats per separat
L'accés d'aplicacions és el primer punt de travessa i no requereix cap reenviament. Una pestanya del navegador, un client de sincronització o un agent de compilació al punt final poden llegir d'un recurs d'un entorn i enviar dades a un recurs de l'altre. Aquesta capacitat existeix tant si el sistema operatiu reenvia paquets entre interfícies com si no, i és el mecanisme que la gent passa per alt quan conclou que sense pont no hi ha risc. Per tant, llegir la llista d'aplicacions és més informatiu que llegir la llista d'interfícies.
La identitat i les dades formen el segon punt de travessa. Les credencials corporatives, les galetes de sessió, els documents baixats i els drets d'administració viuen al punt final, i unir-se a una altra xarxa no els revela per si sol. El que canvia és el conjunt de parts que podrien influir en el punt final mentre aquest té les credencials, i això és una qüestió sobre la fiabilitat de la xarxa personal, no sobre l'encaminament. És un judici que el propietari del punt final no pot fer sol, i no el respon l'absència d'una regla de reenviament.
El reenviament de xarxa és el tercer, i l'únic que pot convertir l'ordinador en un dispositiu de trànsit. El reenviament d'IP, la compartició de connexió a Internet, un proxy o una funció de pont poden fer-ho, i cadascun és una configuració que o bé està activada o bé no. Inspecciona aquest estat directament en lloc d'inferir-lo de la presència d'un client VPN. En una màquina gestionada la resposta sol ser no, i verificar-ho converteix una suposició en un fet que val la pena enregistrar.
Demana un recurs, no dues xarxes
La majoria de requisits reals són més estrets del que semblen al principi: una consola, un recurs compartit, una aplicació web interna. Exposa el requisit així i deixa que el propietari del recurs decideixi si pertoca en aquest punt final. Una petició formulada com a unió de dues xarxes és difícil d'aprovar i fàcil de denegar; una petició per a un servei concret té resposta.
Si la resposta és sí, prefereix el camí admès més estret i mantén-lo dins dels controls existents de l'organització. Un segon perfil gestionat o una entrada d'aplicació d'abast limitat preserven la monitorització i la política; una configuració personal competidora les substitueix en silenci, i ningú no sap quina guanya després de la propera actualització.
Inclou els efectes de DNS i de rutes
La resolució de noms canvia en el moment en què un segon perfil és actiu. Un client personal pot imposar el seu propi resolutor, un navegador pot usar el seu DNS xifrat i una taula de política pot encaminar noms interns a un servidor diferent del que espera la configuració corporativa. Cap d'aquests casos no requereix reenviament, i qualsevol pot enviar un nom d'amfitrió intern al lloc equivocat.
Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0
Captura aquestes tres sortides abans i després que el segon perfil es connecti. La diferència entre elles és l'efecte que arriba realment a l'usuari, i sovint és més gran que el canvi d'encaminament que descriu el tiquet. Conserva les dues captures perquè un revisor posterior pugui veure què va canviar i no què es pretenia.
Verifica i mantén una sortida
Prova l'aplicació aprovada des del procés i el context d'usuari reals, no des d'una consola d'administrador a la mateixa màquina. Després confirma que les destinacions no relacionades continuen sent inabastables on el disseny ho exigeix: una frontera que ningú no ha provat és una frontera que ningú no pot reivindicar. Desconnectar el túnel personal hauria de restaurar l'estat anterior, i val la pena comprovar aquesta restauració mentre algú encara mira.
Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile
La guia del NIST sobre arquitectura de confiança zero és útil aquí perquè elimina la ubicació de xarxa com a font automàtica de confiança, que és exactament la suposició en qüestió. La pregunta no és si la xarxa domèstica és fiable per naturalesa; és qui pot arribar a quin recurs, des de quin punt final i a través de quin punt d'aplicació. Respon aquestes tres i guarda les proves amb la decisió.