OpenVPN TAP en macOS: comprobe o cliente antes de depurar

Un perfil antigo chega a un Mac actual, o cliente impórtao sen queixa e a conexión cae ou nunca pasa tráfico. Antes de pasar unha tarde cos certificados, lea a liña de dispositivo do perfil. Se di dev tap, está a pedir ao cliente unha interface de tipo Ethernet e, en macOS, é nesa petición onde rematan a maioría destas sesións.

Paso 1: confirme que o perfil realmente pide TAP

Os perfís renómbranse, envólvense e volven exportarse, así que revise o ficheiro que importou de verdade. Busque a directiva de dispositivo e calquera include que poida anulala. Dúas liñas de saída resolven a pregunta na maioría dos casos. Cando aparecen tanto dev como dev-type, gaña a directiva posterior, e ese é xusto o tipo de detalle que agocha un perfil copiado.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Se o ficheiro contén dev tap ou dev tap0, o cliente debe implementar unha interface TAP. Se contén dev tun, o resto deste artigo non se aplica e o fallo está noutro sitio.

Anote o nome e a versión do cliente, a versión de macOS e de onde saíu o perfil. Eses tres feitos deciden cal dos dous camiños seguintes é sequera posible.

Paso 2: saiba que cambia realmente o modo de dispositivo

Unha interface TUN transporta paquetes IP. O cliente le e escribe paquetes dirixidos a un par IP, e o sistema operativo encamíñaos como calquera outra interface.

Unha interface TAP transporta tramas Ethernet, incluíndo a difusión e ARP. Iso é o que permite que un servidor ponte reparta enderezos por DHCP e que un cliente descobra dispositivos a berros, e por iso algúns deseños antigos dependen diso.

O custo é que TAP necesita un controlador que presente ao sistema unha interface Ethernet. Apple retirou o modelo de extensión do núcleo no que se baseaban os controladores TAP antigos para Mac, e a súa API substituta non aparece por arte de maxia dentro de clientes que nunca se actualizaron para usala. Unha capacidade de plataforma e un produto xa entregado son cousas distintas.

Paso 3: escolla entre un cliente compatible e unha migración

Hai dous camiños honestos. O primeiro é un cliente cuxo editor declara, para a súa versión de macOS e o seu hardware, que admite a disposición TAP que precisa. Non unha publicación de foro de hai catro anos nin un instalador arquivado: unha declaración actual máis unha conexión de proba.

O segundo é trasladar o servizo a TUN, o que é un cambio de servidor tanto como de cliente. Require unha topoloxía encamiñada, un grupo de enderezos, rutas empurradas para as redes remotas e un camiño de volta desde esas redes ao grupo.

O que non funciona é editar tap a tun na súa copia local e esperar. O servidor segue facendo ponte, o cliente agora fala IP e nada concorda.

Paso 4: reúna os feitos antes de cambiar un servizo que funciona

Deixe intacto o perfil orixinal e faga unha copia para experimentos. Un ficheiro que pode restaurar nun minuto vale máis que un cartafol ordenado. Cando o substituto funcione, borre a copia a propósito en lugar de deixar dous perfís que parezan idénticos nunha lista. Ese único hábito evita a maior parte da confusión que segue a unha migración fallida. Rexistre o comportamento actual para poder demostrar que cambiou: sobe o túnel, obtén un enderezo, pode chegar a un host coñecido e funciona a resolución de nomes.

Faga tres preguntas ao propietario da pasarela. O servidor funciona cunha topoloxía de ponte ou encamiñada? Que prefixos remotos deberían ser accesibles? E hai unha xanela de mantemento para cambiar a configuración, ou espérase que funcione sen tocar o servidor?

As respostas determinan se esta tarde resolve un problema de cliente ou se a próxima semana planifica un cambio de rede.

Paso 5: verifique a migración desde ambos os extremos

Cando o servidor teña unha configuración encamiñada e vostede teña un perfil que encaixe, probe nesta orde: establécese o túnel, o cliente recibe un enderezo do novo grupo, un host do lado remoto responde e un nome resólvese mediante o axuste DNS empurrado.

Despois probe o que antes dependía do comportamento Ethernet. Se unha aplicación descubría dispositivos por difusión, non os atopará por un túnel encamiñado, e ningunha configuración de cliente o recupera. Esa aplicación necesita un enderezo coñecido, un host auxiliar local ou un método de descuberta distinto.

Remate reconectando e reiniciando unha vez, porque un perfil que só funciona ao primeiro intento adoita significar que as rutas empurradas ou o axuste DNS non se aplican ao reconectar.

Cando segue fallando, lea o primeiro erro

Un cliente que non pode crear a interface diuno no seu rexistro, normalmente nas primeiras liñas. Un cliente que a crea e despois non consegue autenticarse xa pasou de longo a cuestión do dispositivo, e seguir perseguindo TAP malgasta a sesión.

Conserve o perfil orixinal e a configuración que funciona ata que o substituto estea probado. Desfacer un cambio de cliente é rápido; reconstruír unha rede ponte que alguén desmontou por un presentimento non o é.