Două conturi de autentificare Mac nu separă traficul VPN

Două conturi de autentificare pe același Mac par două lumi separate până când sosește rețeaua. Un tunel pornit într-o sesiune poate schimba totuși ceea ce trăiește cealaltă sesiune, în funcție de ce client îl deține și ce politică vine cu el. Descrieți separarea de care aveți nevoie înainte de a alege un mecanism pentru a o impune. Ordinea contează, pentru că un mecanism ales primul tinde să redefinească cerința în jurul său.

Trei întrebări fac cea mai mare parte a muncii: ce aplicații ale cui au nevoie de ce resurse private, dacă ambele sesiuni trebuie să fie active simultan și ce li se permite acelor aplicații să facă atunci când tunelul lor nu este disponibil.

Începeți cu traficul, nu cu lista de conturi

Schimbarea contului este o graniță de identitate, nu o graniță de rutare. macOS încarcă o configurație VPN pentru contul care o deține, dar interfața, rutele ei și orice politică la nivel de sistem pe care o instalează aparțin mașinii. Dacă cerința este ca doar aplicațiile unei persoane să intre în rețeaua corporate, proiectarea trebuie să spună asta în termeni de aplicații și destinații, nu în termeni de cine este autentificat. Altfel, al doilea cont moștenește ce a lăsat clientul primului.

Scrieți comportamentul cerut într-o propoziție: poșta și accesul la fișiere ale unui utilizator urmează tunelul administrat, navigarea celuilalt utilizator rămâne pe conexiunea de acasă, iar niciuna dintre căi nu moștenește ruta implicită a celeilalte. Acea propoziție este testabilă; o poveste despre schimbarea autentificării de obicei nu este.

Canalul profilului și amploarea traficului sunt lucruri diferite

Apple acceptă aranjamente VPN administrate livrate per utilizator sau per dispozitiv, iar un ghid de implementare descrie acele modele împreună cu integrarea dependentă de furnizor. Canalul de livrare spune cine primește configurația și o deține. Nu definește de la sine ce trafic este capturat, pentru că implementarea clientului și politica configurată încă decid asta.

Acolo unde un mod documentat conștient de utilizator sau de aplicație poate exprima cerința, aceea este cea mai scurtă cale. Apoi verificați aplicațiile și identitățile reale în loc să vă bazați pe nume: două copii ale aceleiași aplicații nu sunt două căi de rețea diferite, iar un profil care listează o aplicație nu garantează că procesele ei ajutătoare sunt acoperite.

Un sistem invitat este o graniță reală cu limite reale

O mașină virtuală vă oferă un sistem de operare separat cu propriul stivă de rețea, astfel încât un invitat poate rula propriul tunel și propriile aplicații fără să atingă rutele gazdei. Este o separare mai puternică decât un al doilea cont de autentificare și este și mai multă muncă de întreținere. Decideți dacă acel cost cumpără o graniță de care aveți nevoie cu adevărat înainte de a o propune.

Modul de rețea virtuală necesită încă o revizuire. Dacă invitatul este în punte, în spatele NAT sau izolat determină ce poate atinge și ce poate ajunge la el, iar aplicațiile gazdei nu devin aplicații ale invitatului pentru că invitatul este conectat din întâmplare. Verificați și politica de blocare, altfel un tunel de invitat căzut va reveni pe calea gazdei într-un mod pe care nimeni nu l-a intenționat.

Un proxy este mai îngust decât un cont de utilizator

O aplicație a gazdei poate atinge un serviciu proxy real care rulează într-un invitat sau container aprobat, iar asta acoperă traficul pe care aplicația îl trimite efectiv prin protocolul acceptat. Nu acoperă fiecare proces deținut de acel cont Mac și nu acoperă traficul pe care aplicația îl trimite în afara protocolului proxy.

Încă o precauție pe mașini partajate: un ascultător TCP legat de loopback-ul gazdei nu este o verificare a numelui de utilizator. Restrângerea unui proxy la mașina locală îl ține departe de rețea, dar nu autorizează un utilizator local în fața altuia care este deja autentificat. Păstrați autentificarea serviciului explicită dacă această distincție contează.

Demonstrați granița cu două teste

Rulați ambele căi și observați-le separat. Sub contul dorit, deschideți aplicația care are nevoie de resursa privată și confirmați că ajunge la serviciul administrat; sub celălalt cont, confirmați că navigarea obișnuită păstrează calea de acasă. Apoi rupeți tunelul intenționat și verificați comportamentul de rezervă pe fiecare parte, pentru că acolo eșuează în tăcere majoritatea proiectelor. Faceți verificările și în aceeași oră, ca o rețea schimbată să nu contamineze comparația.

Dacă un container sau un invitat rulează tunelul, adăugați o a treia verificare: confirmați că o aplicație Mac nativă din afara lui se comportă în continuare conform proiectării. Alegeți cea mai simplă aranjare al cărei scop îl puteți demonstra și nu etichetați mașinile virtuale ca universal necesare sau schimbarea contului ca universal suficientă înainte de a rula acele teste.