Dos comptes d'inici de sessió del Mac no separen el trànsit VPN

Dos comptes d'inici de sessió al mateix Mac semblen dos mons separats fins que arriba la xarxa. Un túnel iniciat en una sessió encara pot canviar el que experimenta l'altra sessió, segons quin client el posseeix i quina política hi va associada. Descriu la separació que necessites abans de triar un mecanisme per fer-la complir. L'ordre importa, perquè un mecanisme triat primer tendeix a redefinir el requisit al seu voltant.

Tres preguntes fan la major part de la feina: quines aplicacions de qui necessiten quins recursos privats, si les dues sessions han d'estar actives alhora i què poden fer aquestes aplicacions quan el seu túnel no està disponible.

Comença pel trànsit, no per la llista de comptes

Canviar de compte és una frontera d'identitat, no una frontera d'encaminament. El macOS carrega una configuració VPN per al compte que la posseeix, però la interfície, les seves rutes i qualsevol política de tot el sistema que instal·li pertanyen a la màquina. Si el requisit és que només les aplicacions d'una persona entrin a la xarxa corporativa, el disseny ho ha de dir en termes d'aplicacions i destinacions, no de qui ha iniciat sessió. Altrament, el segon compte hereta el que el client del primer ha deixat.

Escriu el comportament requerit en una frase: el correu i l'accés a fitxers d'un usuari segueixen el túnel gestionat, la navegació de l'altre usuari es queda a la connexió de casa i cap dels dos camins hereta la ruta predeterminada de l'altre. Aquesta frase és comprovable; una història de canvi d'inici de sessió normalment no ho és.

El canal del perfil i l'abast del trànsit són coses diferents

Apple admet disposicions VPN gestionades lliurades per usuari o per dispositiu, i una guia de desplegament descriu aquests models juntament amb la integració dependent del proveïdor. El canal de lliurament diu qui rep la configuració i qui la posseeix. No defineix per si mateix quin trànsit es captura, perquè la implementació del client i la política configurada encara ho decideixen.

On un mode documentat que té en compte l'usuari o l'aplicació pot expressar el requisit, aquest és el camí més curt. Després verifica les aplicacions i identitats reals en lloc de confiar en els noms: dues còpies de la mateixa aplicació no són dos camins de xarxa diferents, i un perfil que llista una aplicació no garanteix que els seus processos auxiliars quedin coberts.

Un sistema convidat és una frontera real amb límits reals

Una màquina virtual et dona un sistema operatiu separat amb la seva pròpia pila de xarxa, així que un convidat pot executar el seu propi túnel i les seves pròpies aplicacions sense tocar les rutes de l'amfitrió. És una separació més forta que un segon compte d'inici de sessió, i també és més feina de mantenir. Decideix si aquest cost compra una frontera que realment necessites abans de proposar-lo.

El mode de xarxa virtual encara s'ha de revisar. Si el convidat està pontat, darrere de NAT o aïllat determina què pot assolir i què el pot assolir, i les aplicacions de l'amfitrió no es converteixen en aplicacions del convidat pel fet que el convidat estigui connectat. Comprova també la política de bloqueig, o un túnel de convidat caigut tornarà al camí de l'amfitrió d'una manera que ningú no volia.

Un proxy és més estret que un compte d'usuari

Una aplicació de l'amfitrió pot arribar a un servei de proxy real que s'executa en un convidat o contenidor aprovat, i això cobreix el trànsit que l'aplicació envia realment pel protocol admès. No cobreix tots els processos propietat d'aquest compte del Mac ni el trànsit que l'aplicació envia fora del protocol del proxy.

Una altra precaució en màquines compartides: un oient TCP lligat al loopback de l'amfitrió no és una comprovació de nom d'usuari. Restringir un proxy a la màquina local el manté fora de la xarxa, però no autoritza un usuari local per sobre d'un altre que ja ha iniciat sessió. Mantén explícita l'autenticació del servei si aquesta distinció importa.

Demostra la frontera amb dues proves

Executa tots dos camins i observa'ls per separat. Amb el compte previst, obre l'aplicació que necessita el recurs privat i confirma que arriba al servei gestionat; amb l'altre compte, confirma que la navegació ordinària manté el camí de casa. Després trenca el túnel expressament i comprova el comportament de reserva de cada costat, perquè és aquí on la majoria de dissenys fallen en silenci. Fes les comprovacions dins de la mateixa hora, perquè una xarxa canviada no contamini la comparació.

Si un contenidor o convidat executa el túnel, afegeix una tercera comprovació: confirma que una aplicació nativa del Mac fora d'ell encara es comporta com estava dissenyada. Tria la disposició més simple l'abast de la qual puguis demostrar, i no etiquetis les màquines virtuals com a universalment necessàries ni el canvi de compte com a universalment suficient abans de fer aquestes proves.