Hvordan velge en Mac VPN-klient for gatewayen du allerede har

Seks Mac VPN-apper vises på ein nedlastingsside, og ingen av dei seier hvilken din arbeidsgiver-gateway vil godta. Det er ikkje eit hull i butikken; det er eit gap i overleveringen. En SSL VPN er ein produktfamilie, ikkje ein protokoll, så to gatewayer med identiske påloggingsskjermer kan kreve forskjellige klienter. Her er rekkefølgen jeg brukar når nokon gir meg ein Mac og ein serveradresse: finn ut kva gatewayen snakker, velg klienten som samsvarer med den, kontroller deretter ruter og DNS før du stoler på tunnelen med arbeid.

Start med gatewayen, ikkje appbutikken

Appen kjører på din Mac, men noko annet må godta tilkoblingen og gi tilgang: ein gateway med ein operatør, ein adresse, kompatible innstillinger og ein måte å autorisere deg på. En gratis klient kan vere god programvare og framleis ikkje levere nokon av desse tingene. Arbeidstilgang, ein hjemmegateway og ein kommersiell internettutgang er tre forskjellige utgangspunkt som tilfeldigvis deler ein nedlastingsside.

Før du installerer eller erstatter noko, få fire svar frå den som driver tjenesten:

• Tilgangsmodus: nettleserportal, valgt applikasjonstilgang eller ein full nettverkstunnel. Dette avgjør om du treng ein klient i det hele tatt.

• Gateway-familie og støttet utgivelse: produktet, den aktiverte tjenesten og ein klientversjon som framleis støtter macOS build og Mac-maskinvare.

• Autentisering: passord pluss MFA, nettleserpålogging, enhetssertifikat eller ein kroppskontroll. En klient som mangler den godkjente flyten vil koble seg til og deretter bli avvist.

• Eie: den pålitelige nedlastings- eller administrasjonskilden, den tiltenkte profilen og hvem som støtter den når den går i stykker.

Eierskap er elementet folk hopper over. På ein administrert Mac kommer profilen ofte gjennom organisasjonens styringssystem, og ein håndbygd konfigurasjon kan erstattes ved neste innsjekking. Spør om du forventes å installere noko sjølv før du leter etter ein tredjepartsapp.

SSL VPN er ein familieetikett, ikkje ein protokoll

TLS kan beskytte ein forbindelse mens ein produktspesifikk sentral inne i den håndterer pålogging, økttildeling og tunneltrafikk. Den indre utvekslingen er det ein klient må implementere. En nettleser som når gatewayen HTTPS påloggingssiden beviser sertifikatkjeden og webserveren; det beviser ikkje at ein urelatert VPN app kan bygge ein tunnel til samme maskin.

OpenConnect er den klareste illustrasjonen jeg veit. Dens oppstrøms dokumentasjon viser separate protokollmoduser for forskjellige gatewayfamilier og skiller interoperabilitet frå offisiell leverandørstøtte. Viss hver SSL VPN snakket én protokoll, ville desse modusene vere unødvendige.

En OpenVPN-profil har samme begrensning omvendt: det er eit importformat for ein OpenVPN-kompatibel distribusjon. Deling av TLS som ein byggeblokk gjer den ikkje til ein konfigurasjonsfil for ein vilkårlig bedriftsgateway. Det er grunnen til at ein fungerende nettleserpålogging er ein falsk positiv: portaltilgang kan lykkes mens ingen tunnel eksisterer, og ein tunnel som kommer opp kan framleis nektes ved ein kroppskontroll senere.

Match klienten med det gatewayen snakker

Når familien er kjent, smalner valget raskt. Dette er kartleggingen jeg sjekkar først, og den siste kolonnen betyr mer enn nokon appvurdering.

To rader fortjener ein advarsel. Den innebygde macOS-klienten er ein ekte IKEv2-implementering, ikkje ein generisk SSL VPN-klient: ein tjeneste designet for den treng riktig profil, forventet serveridentitet og legitimasjon, og på ein administrert maskin kan profilen vere låst. OpenConnect dekker flere leverandørprotokoller frå én binær, men dets eget prosjekt krever ikkje leverandørstøtte; vertsskanning, gateway-pushte delt-tunnel-regler eller ein bestemt SSO-flyt kan berre eksistere i leverandørklienten.

WireGuard har samme form. Tjenesten leverer likemenn, klienten leverer tunnelen, og ein OpenVPN-profil er ikkje ein erstatning. En macOS rynke: App Store klienten holder tunnelene sine inne ein Network Extension, så wg show frå Homebrew-verktøyene kan ikkje rapportere noko mens grensesnittet er oppe. Verifiser med ruter og trafikk i stedet.

Konfigurer, og bekreft deretter i ein fast rekkefølge

Installer én klient og én profil, og noter kva du har endret. Før du kobler til, ta ein grunnlinje slik at du kan se kva tunnelen endrer:

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

Koble til den medfølgende profilen og gjenta dei samme kommandoene. For ein full tunnel bør standardruten peke på eit utun grensesnitt; med delt tunnelering skal berre dei interne prefiksene rutes og den offentlige utgangen din skal se uendret ut. DNS er halvparten som vanligvis forblir ødelagt: scutil --dns lister oppløsere i rekkefølgen systemet vil bruke dei, og ein intern løser som sitter under ein offentlig vil sende interne navn til feil server.

For ein OpenVPN-tjeneste er Tunnelblick ein rimelig, gratis klient, og dens egen guide er direkte om den manglende halvdelen: den leverer ikkje ein VPN-tjeneste. Dobbeltklikk .ovpn du fikk, la Tunnelblick installere den, og sjekk utgivelsen mot macOS-versjonen din før du stoler på den.

For ein leverandørgateway tester jeg ofte med OpenConnect frå kommandolinjen:

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

Verktøyet skriver ut sertifikatet det mottok og venter før det stoler på ein ukjent kjede; den ledeteksten er ein funksjon, og å feste med --servercert pin-sha256:... er bedre enn å godta ein advarsel du ikkje har lest. Ctrl-C river tunnelen ned, fordi ein openconnect i forgrunnen ikkje har nokon kill switch og ingen reconnect logikk. Det er greit for ein diagnoseøkt og ein dårlig standard for daglig arbeid.

Når det ikkje er nokon gateway å matche

Noen kommer med det motsatte problemet: ingen operatør, ingen adresse, ingen tjeneste. En gratis Mac-app kan ikkje skape innkommende tilgjengelighet på ein hjemmeruter. Viss du vil ha ditt eget nettverk frå eit hotell, må nokon kjøre ein gateway hjemme, holde den oppdatert, publisere eller løse adressen og bestemme hvilke enheter som er tilgjengelige.

Viss du vil ha ein annen internettutgang i stedet for tilgang til eit privat nettverk, velger du tjenesten før klienten. En tom profilliste i ein frittstående klient er ofte ikkje eit ødelagt gratis abonnement; det kan ikkje vere noko abonnement og ingen server tilknyttet. Hold kostnadene frå hverandre òg: ein klientlisens, ein serviceplan og ein selvbetjent gateway er tre forskjellige kjøp.

En arbeids-Mac legger til eit policylag. En gratis app kan vere feil sjølv når den kobles til, fordi den godkjente klienten kan påtvinge enhetssjekker eller ein autentiseringsflyt alternativet mangler. Be om eit godkjent alternativ i stedet for å kopiere legitimasjon mellom urelaterte apper, og ikkje behandle deaktivering av plattformbeskyttelse som ein kompatibilitetsløsning.

En ekstern skrivebordsvisning er òg eit annet produkt. Den viser deg ein økt på ein annen datamaskin; det gir ikkje lokale Mac-applikasjoner nettverksbanen som ein tunnel gir.

En kort sjekkliste før første ordentlige økt

Navngi gatewayfamilien og tilgangsmodusen skriftlig, installer berre klienten som samsvarer med dei, og registrer profilen du brukte. Bekreft deretter tre ting med ekte trafikk: rutene tunnelen installerte, resolver-rekkefølgen og én intern applikasjon nådd med navn i stedet for IP.

Viss noko feiler, endre én variabel om gangen: klient, profil, godkjenningsflyt. En portal som lastes mens tunnelen nekter å starte, skiller eit webserverproblem frå eit klientkompatibilitetsproblem. Når arbeidstjenesten svarer og den offentlige banen oppfører seg som forventet, har du ein navngitt, støttet ordning i stedet for ein haug med gjetninger.