Seis aplicacións VPN para Mac aparecen nunha páxina de descarga e ningunha di cal aceptará a pasarela da súa empresa. Non é un oco na tenda; é un oco na entrega. Unha VPN SSL é unha familia de produtos, non un protocolo, así que dúas pasarelas con pantallas de acceso idénticas poden esixir clientes distintos. Esta é a orde que sigo cando alguén me entrega un Mac e un enderezo de servidor: establecer que fala a pasarela, escoller o cliente que encaixa e despois verificar rutas e DNS antes de confiarlle traballo ao túnel.

Empece pola pasarela, non pola tenda de aplicacións

A aplicación execútase no seu Mac, pero outra cousa debe aceptar a conexión e conceder acceso: unha pasarela con operador, enderezo, axustes compatibles e unha forma de autorizalo. Un cliente gratuíto pode ser bo software e non achegar nada diso. O acceso laboral, unha pasarela doméstica e unha saída comercial a internet son tres puntos de partida distintos que casualmente comparten unha páxina de descarga.

Antes de instalar ou substituír algo, obteña catro respostas de quen opera o servizo:

  • Modo de acceso: portal no navegador, acceso a aplicacións seleccionadas ou túnel de rede completo. Iso decide se necesita un cliente.

  • Familia da pasarela e versión admitida: o produto, o servizo habilitado e unha versión de cliente que aínda admita a súa compilación de macOS e o seu hardware Mac.

  • Autenticación: contrasinal máis MFA, inicio de sesión no navegador, certificado de dispositivo ou unha comprobación de postura. Un cliente sen o fluxo aprobado conectará e despois será rexeitado.

  • Propiedade: a fonte de descarga ou xestión de confianza, o perfil previsto e quen o mantén cando falla.

A propiedade é o punto que a xente salta. Nun Mac xestionado o perfil adoita chegar polo sistema de xestión da organización, e unha configuración feita a man pode ser substituída na seguinte comprobación. Pregunte se se espera que instale algo vostede mesmo antes de buscar unha aplicación de terceiros.

VPN SSL é unha etiqueta de familia, non un protocolo

TLS pode protexer unha conexión mentres un intercambio específico do produto dentro dela xestiona o inicio de sesión, a asignación de sesións e o tráfico do túnel. Ese intercambio interno é o que un cliente debe implementar. Un navegador que chega á páxina de acceso HTTPS da pasarela demostra a cadea de certificados e o servidor web; non demostra que unha aplicación VPN allea poida construír un túnel cara á mesma máquina.

OpenConnect é o exemplo máis claro que coñezo. A súa documentación do proxecto enumera modos de protocolo separados para distintas familias de pasarelas e separa a interoperabilidade do soporte oficial do fabricante. Se todas as VPN SSL falasen un só protocolo, eses modos serían innecesarios.

Un perfil OpenVPN ten a mesma limitación ao revés: é un formato de importación para un despregamento compatible con OpenVPN. Compartir TLS como bloque de construción non o converte nun ficheiro de configuración para unha pasarela corporativa calquera. Por iso un inicio de sesión no navegador que funciona é un falso positivo: o acceso ao portal pode ter éxito mentres non existe túnel, e un túnel levantado pode ser rexeitado despois por unha comprobación de postura.

Axuste o cliente ao que fala a pasarela

Unha vez coñecida a familia, a elección estreitase rápido. Esta é a correspondencia que reviso primeiro, e a última columna importa máis que calquera valoración de aplicación.

Familia da pasarelaCliente en macOSQue vixiar
IKEv2/IPsec, neutro de fabricanteCliente integrado de macOS cun perfil .mobileconfigIdentidade do servidor e un perfil que pode ser xestionado
OpenVPN 2.xTunnelblick ou a liña de comandos openvpn.ovpn máis credenciais; o cliente non achega ningún servizo
WireGuardCliente oficial de WireGuard ou wireguard-toolsConfiguración de par; a visibilidade de wg show varía segundo o cliente
VPN SSL de fabricante (AnyConnect, Pulse, GlobalProtect, F5, Fortinet)Cliente do fabricante ou OpenConnect cun --protocol explícitoCombinacións non admitidas, MFA e comprobacións de postura
Só portal no navegadorSen clienteO acceso a aplicacións non é un túnel de rede

Dúas filas merecen un aviso. O cliente integrado de macOS é unha implementación real de IKEv2, non un cliente SSL VPN xenérico: un servizo deseñado para el necesita o perfil correcto, a identidade de servidor esperada e credenciais, e nunha máquina xestionada ese perfil pode estar bloqueado. OpenConnect cobre varios protocolos de fabricante cun só binario, pero o seu propio proxecto non reclama soporte do fabricante; a exploración de host, as regras de túnel dividido enviadas pola pasarela ou un fluxo SSO concreto poden existir só no cliente do fabricante.

WireGuard ten a mesma forma. O servizo achega pares, o cliente achega o túnel e un perfil OpenVPN non é un substituto. Un detalle de macOS: o cliente da App Store garda os seus túneles dentro dunha extensión de rede, así que wg show desde as ferramentas de Homebrew pode non informar nada mentres a interface está activa. Verifique con rutas e tráfico.

Configure e despois verifique nunha orde fixa

Instale un cliente e un perfil, e anote que cambiou. Antes de conectar, capture unha liña base para saber que altera o túnel:

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

Conéctese co perfil entregado e repita os mesmos comandos. Nun túnel completo a ruta predeterminada debe apuntar a unha interface utun; con túnel dividido só deben encamiñarse os prefixos internos e a súa saída pública debe verse igual. O DNS é a metade que adoita quedar rota: scutil --dns lista os resolutores na orde en que o sistema os usará, e un resolutor interno baixo un público enviará os nomes internos ao servidor equivocado.

Para un servizo OpenVPN, Tunnelblick é un cliente razoable sen custo, e a súa propia guía é directa sobre a metade que falta: non achega ningún servizo VPN. Faga dobre clic no .ovpn que lle deron, deixe que Tunnelblick o instale e comprobe a versión fronte á súa versión de macOS antes de confiar nela.

Para unha pasarela de fabricante a miúdo probo con OpenConnect desde a liña de comandos:

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

A ferramenta imprime o certificado que recibiu e espera antes de confiar nunha cadea descoñecida; ese aviso é unha función, e fixar con --servercert pin-sha256:... é mellor que aceptar unha advertencia que non leu. Ctrl-C derruba o túnel, porque un openconnect en primeiro plano non ten nin interruptor de emerxencia nin lóxica de reconexión. Iso está ben para unha sesión de diagnóstico e é un mal valor por defecto para o traballo diario.

Cando non hai pasarela coa que axustar

Algunhas persoas chegan co problema contrario: sen operador, sen enderezo, sen servizo. Unha aplicación gratuíta para Mac non pode crear accesibilidade entrante nun router doméstico. Se quere a súa propia rede desde un hotel, alguén debe operar unha pasarela na casa, mantela actualizada, publicar ou resolver o seu enderezo e decidir que dispositivos son accesibles.

Se quere unha saída a internet distinta en lugar de acceso a unha rede privada, elixa o servizo antes que o cliente. Unha lista de perfís baleira nun cliente autónomo a miúdo non é unha subscrición gratuíta rota; pode que non haxa subscrición nin servidor asociado. Manteña tamén os custos separados: unha licenza de cliente, un plan de servizo e unha pasarela autoxestionada son tres compras distintas.

Un Mac de traballo engade unha capa de política. Unha aplicación gratuíta pode ser incorrecta mesmo cando conecta, porque o cliente aprobado pode impoñer comprobacións do dispositivo ou un fluxo de autenticación que a alternativa non ten. Pida unha alternativa aprobada en lugar de copiar credenciais entre aplicacións non relacionadas, e non trate desactivar as proteccións da plataforma como unha solución de compatibilidade.

Un visor de escritorio remoto tamén é outro produto. Móstralle unha sesión noutro ordenador; non dá ás aplicacións locais do seu Mac a ruta de rede que achega un túnel.

Unha lista de comprobación breve antes da primeira sesión real

Nomee por escrito a familia da pasarela e o modo de acceso, instale só o cliente que encaixe con eles e rexistre o perfil que usou. Despois confirme tres cousas con tráfico real: as rutas que instalou o túnel, a orde dos resolutores e unha aplicación interna acadada polo nome e non polo IP.

Se algo falla, cambie unha variable cada vez: cliente, perfil, fluxo de autenticación. Un portal que carga mentres o túnel se nega a arrincar separa un problema de servidor web dun de compatibilidade do cliente. Cando o servizo laboral responde e a ruta pública se comporta como se esperaba, ten un arranxo nomeado e soportado en lugar dunha morea de conxecturas.

Artigos relacionados