OpenVPN TAP a macOS: comproveu el client abans de començar a depurar

Un perfil antic arriba a un Mac actual, el client l’importa sense cap queixa i la connexió cau o no hi passa mai trànsit. Abans de passar una tarda sencera amb certificats, llegiu la línia de dispositiu del perfil. Si hi diu dev tap, esteu demanant al client una interfície d’estil Ethernet i, a macOS, és en aquesta petició on acaben la majoria d’aquestes sessions.

Pas 1: confirmeu que el perfil realment demana TAP

Els perfils es reanomenen, s’emboliquen i es tornen a exportar, així que reviseu el fitxer que heu importat de veritat. Busqueu la directiva de dispositiu i qualsevol include que la pugui substituir. Dues línies de sortida resolen la pregunta en la majoria de casos. Quan hi apareixen tant dev com dev-type, guanya la directiva posterior, i aquest és exactament el tipus de detall que amaga un perfil copiat.

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

Si el fitxer conté dev tap o dev tap0, el client ha d’implementar una interfície TAP. Si conté dev tun, la resta d’aquest article no s’aplica i la fallada és en un altre lloc.

Anoteu el nom i la versió del client, la versió de macOS i d’on prové el perfil. Aquests tres fets decideixen quin dels dos camins següents és possible, si és que ho és.

Pas 2: sapigueu què canvia realment el mode de dispositiu

Una interfície TUN transporta paquets IP. El client llegeix i escriu paquets adreçats a un par IP, i el sistema operatiu els encamina com qualsevol altra interfície.

Una interfície TAP transporta trames Ethernet, incloses la difusió i l’ARP. Això és el que permet que un servidor pont reparteixi adreces per DHCP i que un client descobreixi dispositius cridant, i per això alguns dissenys antics hi depenen.

El cost és que TAP necessita un controlador que presenti al sistema una interfície Ethernet. Apple ha retirat el model d’extensió del nucli en què es basaven els controladors TAP antics per a Mac, i la seva API substituta no apareix per art de màgia dins de clients que mai no s’han actualitzat per fer-la servir. Una capacitat de plataforma i un producte ja lliurat són coses diferents.

Pas 3: trieu entre un client compatible i una migració

Hi ha dos camins honestos. El primer és un client el fabricant del qual declara, per a la vostra versió de macOS i el vostre maquinari, que admet la disposició TAP que necessiteu. No una publicació de fòrum de fa quatre anys ni un instal·lador arxivat: una declaració actual més una connexió de prova.

El segon és moure el servei a TUN, cosa que és un canvi de servidor tant com un de client. Cal una topologia encaminada, un pool d’adreces, rutes empenyudes per a les xarxes remotes i un camí de tornada des d’aquestes xarxes fins al pool.

El que no funciona és editar tap a tun a la vostra còpia local i esperar que surti bé. El servidor encara fa pont, el client ara parla IP i res no concorda.

Pas 4: reuniu els fets abans de canviar un servei que funciona

Deixeu intacte el perfil original i feu-ne una còpia per als experiments. Un fitxer que podeu restaurar en un minut val més que una carpeta endreçada. Quan el substitut funcioni, esborreu la còpia expressament en lloc de deixar dos perfils que semblen idèntics en una llista. Aquest sol hàbit evita la major part de la confusió que segueix una migració fallida. Enregistreu el comportament actual per poder demostrar què ha canviat: s’aixeca el túnel, rep una adreça, podeu arribar a un amfitrió conegut i funciona la resolució de noms.

Pregunteu al propietari de la passarel·la tres coses. El servidor funciona amb una topologia de pont o encaminada? Quins prefixos remots haurien de ser accessibles? I hi ha una finestra de manteniment per canviar la configuració, o s’espera que funcioni sense tocar el servidor?

Les respostes a això determinen si aquesta tarda resoleu un problema de client o si planifiqueu un canvi de xarxa la setmana que ve.

Pas 5: verifiqueu la migració des de tots dos extrems

Quan el servidor tingui una configuració encaminada i tingueu un perfil que hi encaixi, proveu-ho en aquest ordre: s’estableix el túnel, el client rep una adreça del pool nou, un amfitrió del costat remot respon i un nom es resol mitjançant la configuració DNS empenyuda.

Després proveu allò que abans depenia del comportament Ethernet. Si una aplicació descobria dispositius per difusió, no els trobarà per un túnel encaminat i cap configuració de client no ho recupera. Aquesta aplicació necessita una adreça coneguda, un amfitrió auxiliar local o un altre mètode de descoberta.

Acabeu reconnectant i reiniciant un cop, perquè un perfil que només funciona al primer intent normalment vol dir que les rutes empenyudes o la configuració DNS no s’apliquen en reconnectar.

Quan encara falla, llegiu el primer error

Un client que no pot crear la interfície ho diu al seu registre, normalment dins de les primeres línies. Un client que la crea i després no aconsegueix autenticar-se ja ha passat de llarg la qüestió del dispositiu, i continuar perseguint TAP malbarata la sessió.

Conserveu el perfil original i la configuració que funciona fins que el substitut estigui provat. Desfer un canvi de client és ràpid; reconstruir una xarxa pont que algú ha desmuntat per un pressentiment no ho és.