SonicWall VPN en Mac: ĉu SSL-kliento aŭ denaska L2TP?

Komencu ĉe la Mac, poste iru eksteren, ĉar la decidon pri la kliento faras la fajroŝirmilo kaj ĝi nur speguliĝas sur la labortablo. Malfermu la Sistemajn agordojn, rigardu, kiu VPN-agordo jam ekzistas, kaj demandu la administranton unu demandon antaŭ ol tajpi pasvorton. La respondo estas la ŝaltita fora alira servo, ne la aparata modelo sur la ensaluta paĝo. Du klientoj povas sidi sur unu tekokomputilo, kaj neniu el ili estas la ĝusta.

Demandu la enirejon, kiu servo estas ŝaltita

Du foraj aliraj servoj aperas sub la sama produktnomo kaj kondutas tute malsame. Unu estas SSL VPN atingebla per kliento de la vendisto, la alia estas IPsec aŭ L2TP, kiun la denaska macOS-kliento povas voki. Ili malsamas laŭ pordoj, aŭtentigo kaj adresatribuo, do profilo de unu senutilas kontraŭ la alia. Elekti nur de la Mac-flanko estas konjekto vestita kiel agordo.

Petu tri aferojn samtempe: la servon, kiu estas licencita kaj ŝaltita, la klienton kaj version, kiujn tiu servo subtenas en macOS, kaj la aŭtentigan fluon, kiun ĝi atendas. Io malpli lasas vin konjekti ĉe la sekva malsukceso.

Iru la vojon de denaska L2TP

Denaska konekto ekzistas en la Mac ĉiam, kiam profilo estis aldonita, kaj la agorda panelo montras ĝin apud Wi-Fi kaj Ethernet. Se la listo estas malplena, la maŝino tute ne havas VPN-agordon kaj la problemo estas en provizado, ne en konektebleco. La jena komando printas, kion la sistemo efektive tenas, inkluzive agordojn, kiujn la fasado eble kaŝas.

Legu la eligon antaŭ ol aldoni ion, ĉar malnova profilo kun konata nomo estas ofta kialo, ke nova agordo ŝajnas esti ignorata. Poste komparu la servilan adreson kun la adreso, kiun la administranto donis al vi, ne kun tiu en malnova bileto. Ambaŭ kontroloj daŭras minuton kaj forigas du el la kutimaj sakstratoj.

scutil --nc list
networksetup -listallnetworkservices

Denaska L2TP-enskribo bezonas ankaŭ la komunan sekreton, uzantnomon kaj pasvorton, kaj enirejon, kiu proponas tiun servon ĉe la atendataj pordoj. Kiam mankas io el tio, la Mac raportas aŭtentigan eraron aŭ eraron, ke la servilo ne respondas, kaj neniu mesaĝo distingas malĝustan sekreton de servo, kiu neniam estis ŝaltita. Tenu ĉiujn tri valorojn kune, kiam vi komparas notojn kun la administranto.

Iru la vojon de SSL-kliento

SSL VPN-kliento konektiĝas per TLS al portalo, poste funkciigas sian propran tunelon kaj sian propran adrespolitikon. Ĝi bezonas la portaladreson, konton kaj tiun duan faktoron, kiun la deplojo postulas, kaj ĝi kutime instalas retan etendaĵon la unuan fojon. Profilo eksportita por unu kliento malofte enportiĝas en alian, eĉ kiam ambaŭ parolas IPsec sube. Nenio el tio aperas en la VPN-listo de Sistemaj agordoj, ĝis la etendaĵo estos aprobita.

Du SSL-klientoj instalitaj unu apud la alia povas konkuri pri la sama reta etendaĵo, kaj tiu, kiu ŝargiĝis unue, kutime venkas. Forigu la neuzatan klienton antaŭ ol instali la aprobitan, poste restartigu, por ke la etendaĵa listo estu rekonstruita.

Kontrolu la macOS-version kontraŭ la nuna subtena deklaro de la vendisto antaŭ la instalado, kaj atendu, ke la instalilo petos aprobon en Privateco kaj sekureco. Blokita etendaĵo aspektas precize kiel konekto, kiu neniam komenciĝas.

Legu la rebrandigan avizon ĝuste

Klientnomoj moviĝas, kaj renomigo ne estas protokola ŝanĝo. La avizo de la vendisto, ke Mobile Connect fariĝas NetExtender, priskribas markadon, do malnova deklaro pri subteno de labortablaj platformoj ne transdoneblas al ĉiu aplikaĵo kun la nova nomo.

Identigu la klienton, kiun vi efektive instalís, per paka identigilo kaj versio, ne per la etikedo sur la ikono. Tiu distingo decidas, kiu subtena matrico validas por via Mac.

Se la ŝaltita servo kaj la subtenata Mac-kliento ne interkovras, la honestaj ebloj estas aprobita alternativa servo aŭ planita enireja ŝanĝo. Reskribi komunan politikon por kontentigi unu tekokomputilon, aŭ aĉeti aplikaĵon ĉar forumrespondo menciis ĝin, lasas la demandon pri kongrueco precize tie, kie ĝi komenciĝis.