Hur man väljer en Mac VPN-klient för den gateway du redan har

Sex Mac VPN-appar dyker upp på en nedladdningssida och ingen av dem säger vilken din arbetsgivargateway kommer att acceptera. Det är inte en lucka i butiken; det är en lucka i handoff. En SSL VPN är en produktfamilj, inte ett protokoll, så två gateways med identiska inloggningsskärmar kan kräva olika klienter. Här är ordningen jag använder när någon ger mig en Mac och en serveradress: fastställa vad gatewayen talar, välj den klient som matchar den, verifiera sedan rutter och DNS innan du litar på tunneln med arbete.

Börja med gatewayen, inte appbutiken

Appen körs på din Mac, men något annat måste acceptera anslutningen och ge åtkomst: en gateway med en operatör, en adress, kompatibla inställningar och ett sätt att auktorisera dig. En gratis klient kan vara bra programvara och fortfarande inte tillhandahålla någon av dessa saker. Arbetsåtkomst, en hemgateway och en kommersiell internetutgång är tre olika utgångspunkter som råkar dela en nedladdningssida.

Innan du installerar eller byter ut något, få fyra svar från den som kör tjänsten:

• Åtkomstläge: webbläsarportal, vald applikationsåtkomst eller en komplett nätverkstunnel. Detta avgör om du behöver en kund överhuvudtaget.

• Gateway-familj och version som stöds: produkten, den aktiverade tjänsten och en klientversion som fortfarande stöder din macOS build och Mac-hårdvara.

• Autentisering: lösenord plus MFA, webbläsarinloggning, enhetscertifikat eller en hållningskontroll. En klient som saknar det godkända flödet kommer att ansluta och sedan avvisas.

• Äganderätt: den betrodda nedladdnings- eller hanteringskällan, den avsedda profilen och vem som stöder den när den går sönder.

Ägande är föremålet folk hoppar över. På en hanterad Mac kommer profilen ofta via organisationens ledningssystem, och en handbyggd konfiguration kan bytas ut vid nästa incheckning. Fråga om du förväntas installera något själv innan du letar efter en tredjepartsapp.

SSL VPN är en familjeetikett, inte ett protokoll

TLS kan skydda en anslutning medan en produktspecifik växel inuti den hanterar inloggning, sessionstilldelning och tunneltrafik. Det inre utbytet är vad en klient måste implementera. En webbläsare som når gatewayen HTTPS inloggningssidan bevisar certifikatkedjan och webbservern; det bevisar inte att en orelaterade VPN app kan bygga en tunnel till samma maskin.

OpenConnect är den tydligaste illustration jag vet. Dess uppströms dokumentation listar separata protokolllägen för olika gatewayfamiljer och separerar interoperabilitet från officiellt leverantörsstöd. Om varje SSL VPN talade ett protokoll skulle dessa lägen vara onödiga.

En OpenVPN profil har samma begränsning tvärtom: det är ett importformat för en OpenVPN-kompatibel distribution. Att dela TLS som ett byggblock gör det inte till en konfigurationsfil för en godtycklig företagsgateway. Det är därför en fungerande webbläsarinloggning är ett falskt positivt: portalåtkomst kan lyckas medan ingen tunnel existerar, och en tunnel som kommer upp kan fortfarande nekas genom en hållningskontroll senare.

Matcha klienten med vad gatewayen talar om

När familjen väl är känd minskar valet snabbt. Det här är kartläggningen jag kollar först, och den sista kolumnen är viktigare än någon appbetyg.

Två rader förtjänar en varning. Den inbyggda macOS-klienten är en riktig IKEv2-implementering, inte en generisk SSL VPN-klient: en tjänst som är designad för den behöver rätt profil, förväntad serveridentitet och referenser, och på en hanterad maskin kan profilen vara låst. OpenConnect täcker flera leverantörsprotokoll från en binär, men dess eget projekt kräver inte leverantörsstöd; värdskanning, gateway-pushade regler för delad tunnel eller ett speciellt SSO-flöde kan endast existera i leverantörsklienten.

WireGuard har samma form. Tjänsten tillhandahåller peers, klienten tillhandahåller tunneln och en OpenVPN-profil är inte en ersättning. En macOS rynka: App Store klienten håller sina tunnlar inne ett Network Extension, så wg show från Homebrew-verktygen kan ingenting rapportera medan gränssnittet är uppe. Verifiera med rutter och trafik istället.

Konfigurera och verifiera sedan i en fast ordning

Installera en klient och en profil och notera vad du ändrade. Innan du ansluter, fånga en baslinje så att du kan se vad tunneln förändrar:

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

Anslut till den medföljande profilen och upprepa samma kommandon. För en hel tunnel bör standardrutten peka på ett utun-gränssnitt; med delad tunnel ska endast de interna prefixen dirigeras och din offentliga utgång ska se oförändrad ut. DNS är hälften som vanligtvis förblir trasig: scutil --dns listar resolvers i den ordning som systemet kommer att använda dem, och en intern resolver som sitter under en offentlig kommer att skicka interna namn till fel server.

För en OpenVPN-tjänst är Tunnelblick en rimlig, kostnadsfri kund, och dess egen guide är direkt om den saknade halvan: den tillhandahåller inte en VPN-tjänst. Dubbelklicka på .ovpn du fick, låt Tunnelblick installera det och kontrollera versionen mot din macOS-version innan du litar på den.

För en leverantörsgateway testar jag ofta med OpenConnect från kommandoraden:

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

Verktyget skriver ut certifikatet det tog emot och väntar innan det litar på en okänd kedja; den prompten är en funktion, och att fästa med --servercert pin-sha256:... är bättre än att acceptera en varning som du inte läste. Ctrl-C river tunneln, eftersom en openconnect i förgrunden inte har någon kill-switch och ingen återanslutningslogik. Det är bra för en diagnostisk session och en dålig standard för dagligt arbete.

När det inte finns någon gateway att matcha

Vissa människor kommer med det motsatta problemet: ingen operatör, ingen adress, ingen service. En gratis Mac-app kan inte skapa inkommande nåbarhet på en hemrouter. Om du vill ha ditt eget nätverk från ett hotell måste någon köra en gateway hemma, hålla den lappad, publicera eller lösa dess adress och bestämma vilka enheter som är tillgängliga.

Om du vill ha en annan internetutgång istället för tillgång till ett privat nätverk, välj tjänsten före klienten. En tom profillista i en fristående klient är ofta inte en trasig gratisprenumeration; det kanske inte finns något abonnemang och ingen server ansluten. Håll isär kostnaderna också: en kundlicens, en serviceplan och en självmanövrerad gateway är tre olika köp.

En arbets-Mac lägger till ett policylager. En kostnadsfri app kan ha fel även när den ansluter, eftersom den godkända klienten kan tvinga fram enhetskontroller eller ett autentiseringsflöde som alternativet saknar. Be om ett godkänt alternativ istället för att kopiera referenser mellan orelaterade appar, och behandla inte inaktivering av plattformsskydd som en kompatibilitetsfix.

En remote-desktop viewer är också en annan produkt. Den visar en session på en annan dator; det ger inte din Mac lokala applikationer den nätverksväg som en tunnel tillhandahåller.

En kort checklista inför första riktiga passet

Namnge gatewayfamiljen och åtkomstläget skriftligt, installera endast den klient som matchar dem och registrera profilen du använde. Bekräfta sedan tre saker med verklig trafik: rutterna som tunneln installerade, resolverordern och en intern applikation som nås med namn snarare än med IP.

Om något misslyckas, ändra en variabel åt gången: klient, profil, autentiseringsflöde. En portal som laddas medan tunneln vägrar att starta skiljer ett webbserverproblem från ett klientkompatibilitetsproblem. När väl arbetstjänsten svarar och den allmänna vägen beter sig som förväntat har man ett namngivet, understödt arrangemang istället för en hög med gissningar.