Slik velger du en Mac VPN-klient for gatewayen du allerede har

Seks Mac VPN-apper dukker opp på en nedlastingsside, og ingen av dem sier hvilken arbeidsgiverens gateway vil godta. Det er ikke et hull i butikken; det er et hull i overleveringen. En SSL VPN er en produktfamilie, ikke en protokoll, så to gatewayer med identisk påloggingsskjerm kan kreve ulike klienter. Dette er rekkefølgen jeg bruker når noen gir meg en Mac og en serveradresse: finn ut hva gatewayen snakker, velg klienten som passer til det, og verifiser deretter ruter og DNS før du overlater arbeid til tunnelen.

Start med gatewayen, ikke med appbutikken

Appen kjører på Macen din, men noe annet må godta tilkoblingen og gi tilgang: en gateway med en operatør, en adresse, kompatible innstillinger og en måte å autorisere deg på. En gratis klient kan være god programvare og likevel ikke gi noe av dette. Arbeidstilgang, en hjemmegateway og en kommersiell internettutgang er tre ulike startpunkter som tilfeldigvis deler én nedlastingsside.

Før du installerer eller erstatter noe, få fire svar fra den som drifter tjenesten:

• Tilgangsmodus: nettleserportal, tilgang til valgt applikasjon eller en full nettverkstunnel. Dette avgjør om du trenger en klient i det hele tatt.

• Gatewayfamilie og støttet utgave: produktet, den aktiverte tjenesten og en klientversjon som fortsatt støtter macOS-versjonen og Mac-maskinvaren din.

• Autentisering: passord med MFA, pålogging i nettleser, enhetssertifikat eller en tilstandskontroll. En klient uten den godkjente flyten kobler til og blir deretter avvist.

• Eierskap: den pålitelige nedlastings- eller administrasjonskilden, den tiltenkte profilen og hvem som støtter den når den ryker.

Eierskap er punktet folk hopper over. På en administrert Mac kommer profilen ofte gjennom organisasjonens administrasjonssystem, og en håndlaget konfigurasjon kan bli erstattet ved neste innsjekk. Spør om det forventes at du installerer noe selv, før du leter etter en tredjepartsapp.

SSL VPN er en familiebetegnelse, ikke en protokoll

TLS kan beskytte en tilkobling mens den produktspesifikke utvekslingen inni håndterer pålogging, sesjonstildeling og tunnelrafikk. Det er den indre utvekslingen klienten må implementere. En nettleser som når gatewayens HTTPS-påloggingsside, beviser sertifikatkjeden og webserveren; den beviser ikke at en urelatert VPN-app kan bygge en tunnel til samme maskin.

OpenConnect er det tydeligste eksempelet jeg kjenner. Det oppstrøms dokumentasjonen lister separate protokollmoduser for ulike gatewayfamilier og skiller interoperabilitet fra offisiell leverandørstøtte. Hvis hver SSL VPN snakket én protokoll, ville disse modusene være unødvendige.

En OpenVPN-profil har den samme begrensningen den andre veien: det er et importformat for en OpenVPN-kompatibel utrulling. Å dele TLS som byggekloss gjør den ikke til en konfigurasjonsfil for en vilkårlig bedriftsgateway. Derfor er en fungerende nettleserpålogging en falsk positiv: portaltilgang kan lykkes mens ingen tunnel finnes, og en tunnel som kommer opp, kan fortsatt avvises av en tilstandskontroll senere.

Tilpass klienten til det gatewayen snakker

Når familien er kjent, snevres valget raskt inn. Dette er tabellen jeg sjekker først, og den siste kolonnen betyr mer enn noen appvurdering.

To rader fortjener en advarsel. Den innebygde macOS-klienten er en ekte IKEv2-implementasjon, ikke en generisk SSL VPN-klient: en tjeneste laget for den trenger riktig profil, forventet serveridentitet og legitimasjon, og på en administrert maskin kan den profilen være låst. OpenConnect dekker flere leverandørprotokoller fra én binærfil, men prosjektet selv hevder ikke leverandørstøtte; skanning av vert, regler for delt tunnel som gatewayen pusher, eller en bestemt SSO-flyt kan bare finnes i leverandørklienten.

WireGuard har samme form. Tjenesten leverer Peers, klienten leverer tunnelen, og en OpenVPN-profil er ingen erstatning. En macOS-krøll: App Store-klienten holder tunnelene sine inne i en nettverksutvidelse, så wg show fra Homebrew-verktøyene kan rapportere ingenting mens grensesnittet er oppe. Verifiser med ruter og trafikk i stedet.

Konfigurer, og verifiser deretter i fast rekkefølge

Installer én klient og én profil, og noter hva du endret. Ta en basislinje før du kobler til, slik at du kan si hva tunnelen endrer:

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

Koble til med profilen du fikk, og gjenta de samme kommandoene. For en full tunnel skal standardruten peke på et utun-grensesnitt; med delt tunnel skal bare de interne prefiksene rutes, og den offentlige utgangen din skal se uendret ut. DNS er den halvdelen som vanligvis blir ødelagt: scutil --dns lister opp resolverne i den rekkefølgen systemet vil bruke dem, og en intern resolver under en offentlig en vil sende interne navn til feil server.

For en OpenVPN-tjeneste er Tunnelblick en rimelig gratisklient, og veiledningen deres er tydelig på den manglende halvdelen: den leverer ingen VPN-tjeneste. Dobbeltklikk .ovpn-filen du fikk, la Tunnelblick installere den, og sjekk utgivelsen mot macOS-versjonen din før du stoler på den.

For en leverandørgateway tester jeg ofte med OpenConnect fra 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å en ukjent kjede; den forespørselen er en funksjon, og å feste med --servercert pin-sha256:... er bedre enn å godta en advarsel du ikke leste. Ctrl-C river ned tunnelen, fordi en openconnect i forgrunnen ikke har kill switch og ingen gjentilkoblingslogikk. Det er greit for en diagnostiskøkt og en dårlig standard for daglig arbeid.

Når det ikke finnes noen gateway å matche

Noen kommer med det motsatte problemet: ingen operatør, ingen adresse, ingen tjeneste. En gratis Mac-app kan ikke skape innkommende tilgjengelighet på en hjemmeruter. Hvis du vil ha ditt eget nettverk fra et hotell, må noen drifte en gateway hjemme, lappe den, publisere eller slå opp adressen og bestemme hvilke enheter som er tilgjengelige.

Hvis du vil ha en annen internettutgang i stedet for tilgang til et privat nettverk, velg tjenesten før klienten. En tom profilliste i en frittstående klient er ofte ikke et ødelagt gratisabonnement; det kan hende det ikke finnes noe abonnement og ingen server tilkoblet. Hold kostnadene fra hverandre også: en klientlisens, en tjenesteplan og en egenoperert gateway er tre forskjellige kjøp.

En arbeids-Mac legger til et policy-lag. En gratiskapp kan være feil selv når den kobler til, fordi den godkjente klienten kan håndheve enhetskontroller eller en autentiseringsflyt alternativet mangler. Be om et godkjent alternativ i stedet for å kopiere legitimasjon mellom urelaterte apper, og ikke behandle det å slå av plattformbeskyttelse som en kompatibilitetsfiks.

En fjernskrivebordsvisning er også et annet produkt. Den viser deg en økt på en annen datamaskin; den gir ikke de lokale appene på Macen din nettverksveien en tunnel gir.

En kort sjekkliste før den første ekte økten

Navngi gatewayfamilien og tilgangsmodusen skriftlig, installer bare klienten som passer, og noter profilen du brukte. Bekreft deretter tre ting med ekte trafikk: rutene tunnelen installerte, rekkefølgen på resolverne og én intern applikasjon nådd med navn i stedet for IP.

Hvis noe feiler, endre én variabel om gangen: klient, profil, autentiseringsflyt. En portal som laster mens tunnelen nekter å starte, skiller et webserverproblem fra et klientkompatibilitetsproblem. Når arbeidstjenesten svarer og den offentlige veien oppfører seg som forventet, har du en navngitt, støttet ordning i stedet for en haug med gjetninger.