Sådan vælger du en Mac VPN-klient til den gateway, du allerede har

Seks Mac VPN-apps dukker op på en downloadside, og ingen af dem siger, hvilken din arbejdsgivers gateway accepterer. Det er ikke et hul i butikken; det er et hul i overdragelsen. En SSL VPN er en produktfamilie, ikke en protokol, så to gateways med identiske login-skærme kan kræve forskellige klienter. Her er den rækkefølge, jeg bruger, når nogen giver mig en Mac og en serveradresse: fastslå, hvad gatewayen taler, vælg den klient, der passer til det, og verificér så ruter og DNS, før du betror tunnelen arbejde.

Start med gatewayen, ikke med app-butikken

Appen kører på din Mac, men noget andet skal acceptere forbindelsen og give adgang: en gateway med en operatør, en adresse, kompatible indstillinger og en måde at autorisere dig på. En gratis klient kan være god software og alligevel ikke levere noget af det. Arbejdsadgang, en hjemmegateway og en kommerciel internetudgang er tre forskellige udgangspunkter, der tilfældigvis deler en downloadside.

Før du installerer eller erstatter noget, så få fire svar fra den, der driver tjenesten:

• Adgangstilstand: browserportal, adgang til udvalgte applikationer eller en fuld netværkstunnel. Det afgør, om du overhovedet har brug for en klient.

• Gateway-familie og understøttet udgivelse: produktet, den aktive tjeneste og en klientversion, der stadig understøtter dit macOS-build og din Mac-hardware.

• Godkendelse: adgangskode plus MFA, login i browseren, enhedscertifikat eller et posture-check. En klient uden det godkendte flow vil forbinde og derefter blive afvist.

• Ejerskab: den betroede download- eller administrationskilde, den tilsigtede profil og hvem der supporterer den, når den går i stykker.

Ejerskab er det punkt, folk springer over. På en administreret Mac kommer profilen ofte via organisationens administrationssystem, og en håndbygget konfiguration kan blive erstattet ved næste check-in. Spørg, om du forventes selv at installere noget, før du leder efter en tredjepartsapp.

SSL VPN er et familie-label, ikke en protokol

TLS kan beskytte en forbindelse, mens en produktspecifik udveksling indeni håndterer login, sessionstildeling og tunneltrafik. Det er den indre udveksling, en klient skal implementere. En browser, der når gatewayens HTTPS-loginside, beviser certifikatkæden og webserveren; den beviser ikke, at en ubeslægtet VPN-app kan bygge en tunnel til samme maskine.

OpenConnect er det tydeligste eksempel, jeg kender. Dens dokumentation hos projektet lister særskilte protokottilstande til forskellige gateway-familier og adskiller interoperabilitet fra officiel leverandørsupport. Hvis hver SSL VPN talte én protokol, ville de tilstande være unødvendige.

En OpenVPN-profil har samme begrænsning den anden vej: det er et importformat til en OpenVPN-kompatibel udrulning. Delt TLS som byggeklods gør den ikke til en konfigurationsfil til en vilkårlig enterprise-gateway. Derfor er et fungerende browserlogin en falsk positiv: portaladgang kan lykkes, mens der ingen tunnel er, og en tunnel, der kommer op, kan senere afvises af et posture-check.

Match klienten til det, gatewayen taler

Når familien er kendt, indsnævres valget hurtigt. Det er den mapping, jeg tjekker først, og den sidste kolonne betyder mere end enhver app-vurdering.

To rækker fortjener en advarsel. Den indbyggede macOS-klient er en rigtig IKEv2-implementering, ikke en generisk SSL VPN-klient: en tjeneste designet til den kræver den korrekte profil, den forventede serveridentitet og legitimationsoplysninger, og på en administreret maskine kan den profil være låst. OpenConnect dækker flere leverandørprotokoller fra én binær fil, men projektet selv påstår ikke leverandørsupport; hostscanning, gateway-skubbede regler for split tunnel eller et bestemt SSO-flow findes måske kun i leverandørens klient.

WireGuard har samme form. Tjenesten leverer peers, klienten leverer tunnelen, og en OpenVPN-profil er ikke en erstatning. En macOS-finesse: App Store-klienten holder sine tunneler inde i en netværksudvidelse, så wg show fra Homebrew-værktøjerne kan intet vise, mens grænsefladen er oppe. Verificér i stedet med ruter og trafik.

Konfigurér, og verificér så i en fast rækkefølge

Installér én klient og én profil, og notér, hvad du ændrede. Før du forbinder, optag en baseline, så du kan se, hvad tunnelen ændrer:

scutil --nc list
networksetup -listallnetworkservices
netstat -rn | grep -E "^default|utun"
scutil --dns

Forbind med den leverede profil og gentag de samme kommandoer. Ved en fuld tunnel skal standardruten pege på en utun-grænseflade; ved split tunneling skal kun de interne præfikser routes, og din offentlige udgang bør se uændret ud. DNS er den halvdel, der ofte forbliver brudt: scutil --dns lister resolvere i den rækkefølge, systemet bruger dem, og en intern resolver under en offentlig sender interne navne til den forkerte server.

Til en OpenVPN-tjeneste er Tunnelblick en rimelig gratis klient, og dens egen guide er direkte om den manglende halvdel: den leverer ingen VPN-tjeneste. Dobbeltklik på den .ovpn, du fik, lad Tunnelblick installere den, og tjek udgivelsen mod din macOS-version, før du stoler på den.

Til en leverandørgateway tester jeg ofte med OpenConnect fra kommandolinjen:

brew install openconnect
sudo openconnect --protocol=anyconnect --user=you vpn.example.com

Værktøjet udskriver det certifikat, det modtog, og venter, før det stoler på en ukendt kæde; den prompt er en funktion, og pinning med --servercert pin-sha256:... er bedre end at acceptere en advarsel, du ikke har læst. Ctrl-C river tunnelen ned, fordi en openconnect i forgrunden hverken har kill switch eller genopkoblingslogik. Det er fint til en diagnostisk session og et dårligt standardvalg til dagligt arbejde.

Når der ikke er nogen gateway at matche

Nogle kommer med det modsatte problem: ingen operatør, ingen adresse, ingen tjeneste. En gratis Mac-app kan ikke skabe indgående tilgængelighed på en hjemmerouter. Hvis du vil have dit eget netværk fra et hotel, skal nogen drive en gateway derhjemme, holde den opdateret, offentliggøre eller opløse dens adresse og beslutte, hvilke enheder der kan nås.

Hvis du vil have en anden internetudgang i stedet for adgang til et privat netværk, så vælg tjenesten før klienten. En tom profilliste i en selvstændig klient er ofte ikke et brudt gratis abonnement; der er måske hverken abonnement eller server tilknyttet. Hold også omkostningerne adskilt: en klientlicens, en serviceplan og en selvdriftet gateway er tre forskellige køb.

En arbejds-Mac tilføjer et politilag. En gratis app kan være forkert, selv når den forbinder, fordi den godkendte klient kan kræve enhedstjek eller et godkendelsesflow, som alternativet mangler. Bed om et godkendt alternativ i stedet for at kopiere legitimationsoplysninger mellem ubeslægtede apps, og behandl ikke deaktivering af platformsbeskyttelse som en kompatibilitetsrettelse.

En fjernskrivebordsfremviser er også et andet produkt. Den viser dig en session på en anden computer; den giver ikke dine lokale apps på Macen den netværksvej, en tunnel giver.

En kort tjekliste før den første rigtige session

Navngiv gateway-familien og adgangstilstanden på skrift, installér kun den klient, der matcher dem, og notér den profil, du brugte. Bekræft derefter tre ting med rigtig trafik: de ruter, tunnelen installerede, resolver-rækkefølgen og én intern applikation, der nås ved navn i stedet for ved IP.

Hvis noget fejler, så ændr én variabel ad gangen: klient, profil, godkendelsesflow. En portal, der indlæses, mens tunnelen nægter at starte, adskiller et webserverproblem fra et klientkompatibilitetsproblem. Når arbejdstjenesten svarer, og den offentlige vej opfører sig som forventet, har du en navngiven, understøttet løsning i stedet for en bunke gætterier.