Du Mac-ensalutaj kontoj ne dividas VPN-trafikon
La posedanto de profilo kaj ĝia trafika amplekso estas malsamaj demandoj. Sur komuna Mac, elektu limon laŭ aplikaĵo, gasto aŭ prokuro, kaj pruvu, ke ambaŭ vojoj funkcias.
Du ensalutaj kontoj sur la sama Mac aspektas kiel du apartaj mondoj ĝis la reto alvenas. Tunelo komencita en unu sesio ankoraŭ povas ŝanĝi tion, kion la alia sesio spertas, depende de tio, kiu kliento posedas ĝin kaj kiu politiko venas kun ĝi. Priskribu la disigon, kiun vi bezonas, antaŭ ol elekti mekanismon por ĝin devigi. La ordo gravas, ĉar mekanismo elektita unue emas re-difini la postulon ĉirkaŭ si.
Tri demandoj faras la plej grandan parton de la laboro: kies aplikaĵoj bezonas kiujn privatajn resursojn, ĉu ambaŭ sesioj devas esti aktivaj samtempe, kaj kion tiuj aplikaĵoj rajtas fari, kiam ilia tunelo ne disponeblas.
Komencu de la trafiko, ne de la konto-listo
Konto-ŝanĝado estas identeca limo, ne enkursiga limo. macOS ŝargas VPN-agordon por la konto, kiu posedas ĝin, sed la interfaco, ĝiaj enkursigoj kaj ajna sistem-nivela politiko, kiun ĝi instalas, apartenas al la maŝino. Se la postulo estas, ke nur la aplikaĵoj de unu persono eniru la korporacian reton, la dezajno devas diri tion laŭ aplikaĵoj kaj celoj, ne laŭ tio, kiu estas ensalutinta. Alie la dua konto heredas tion, kion la kliento de la unua lasis.
Skribu la postulatan konduton en unu frazo: la retpoŝto kaj dosier-aliro de unu uzanto sekvas la administritan tunelon, la retumado de la alia uzanto restas sur la hejma konekto, kaj neniu vojo heredas la defaŭltan enkursigon de la alia. Tiu frazo estas testebla; rakonto pri ensalut-ŝanĝado kutime ne estas.
Profila kanalo kaj trafika amplekso estas malsamaj aferoj
Apple subtenas administritajn VPN-aranĝojn liveratajn laŭ uzanto aŭ laŭ aparato, kaj deploja gvidilo priskribas tiujn modelojn kune kun provizanto-dependa integriĝo. La livera kanalo diras, kiu ricevas la agordon kaj posedas ĝin. Ĝi ne difinas per si mem, kiu trafiko estas kaptata, ĉar la klienta efektivigo kaj la agordita politiko ankoraŭ decidas pri tio.
Kie dokumentita uzanto-konscia aŭ aplikaĵo-konscia reĝimo povas esprimi la postulon, tio estas la plej mallonga vojo. Poste kontrolu la efektivajn aplikaĵojn kaj identecojn anstataŭ fidi nomojn: du kopioj de la sama aplikaĵo ne estas du malsamaj retaj vojoj, kaj profilo, kiu listigas aplikaĵon, ne garantias, ke ĝiaj helpaj procesoj estas kovritaj.
Gasta sistemo estas reala limo kun realaj limigoj
Virtuala maŝino donas al vi apartan operaciumon kun propra reta stako, do gasto povas funkciigi sian propran tunelon kaj siajn proprajn aplikaĵojn sen tuŝi la enkursigojn de la gastiganto. Tio estas pli forta disigo ol dua ensaluta konto, kaj ankaŭ pli da prizorga laboro. Decidu, ĉu tiu kosto aĉetas limon, kiun vi efektive bezonas, antaŭ ol proponi ĝin.
La reĝimo de virtuala reto ankoraŭ bezonas revizion. Ĉu la gasto estas pontita, malantaŭ NAT aŭ izolita, determinas kion ĝi povas atingi kaj kio povas atingi ĝin, kaj gastigantaj aplikaĵoj ne fariĝas gastaj aplikaĵoj nur ĉar la gasto hazarde estas konektita. Kontrolu ankaŭ la blokan politikon, alie falinta gasta tunelo reiros al la vojo de la gastiganto tiel, kiel neniu intencis.
Prokuro estas pli mallarĝa ol uzanta konto
Unu gastiganta aplikaĵo povas atingi realan prokuran servon, kiu funkcias en aprobita gasto aŭ ujo, kaj tio kovras la trafikon, kiun la aplikaĵo efektive sendas per la subtenata protokolo. Ĝi ne kovras ĉiun proceson posedatan de tiu Mac-konto, kaj ĝi ne kovras trafikon, kiun la aplikaĵo sendas ekster la prokura protokolo.
Ankoraŭ unu singardo sur komunaj maŝinoj: TCP-aŭskultanto ligita al la loka loopback de la gastiganto ne estas uzantnoma kontrolo. Limigi prokuron al la loka maŝino tenas ĝin for de la reto, sed ĝi ne rajtigas unu lokan uzanton super alia, kiu jam ensalutis. Tenu la aŭtentikigon de la servo eksplicita, se tiu distingo gravas.
Pruvu la limon per du testoj
Rulu ambaŭ vojojn kaj observu ilin aparte. Sub la celata konto malfermu la aplikaĵon, kiu bezonas la privatan resurson, kaj konfirmu, ke ĝi atingas la administritan servon; sub la alia konto konfirmu, ke ordinara retumado konservas la hejman vojon. Poste intence rompu la tunelon kaj kontrolu la fallback-konduton por ĉiu flanko, ĉar tie la plej multaj dezajnoj silente malsukcesas. Faru la kontrolojn ankaŭ en la sama horo, por ke ŝanĝita reto ne poluu la komparon.
Se ujo aŭ gasto rulas la tunelon, aldonu trian kontrolon: konfirmu, ke indiĝena Mac-aplikaĵo ekster ĝi ankoraŭ kondutas kiel planite. Elektu la plej simplan aranĝon, kies amplekson vi povas pruvi, kaj ne nomu virtualajn maŝinojn universale necesaj aŭ konto-ŝanĝadon universale sufiĉa antaŭ ol fari tiujn testojn.