OpenVPN TAP op macOS: controleer de client voordat je gaat debuggen

Een oud profiel belandt op een moderne Mac, de client importeert het zonder klagen, en de verbinding valt weg of laat nooit verkeer door. Voordat je een middag aan certificaten besteedt, lees je de apparaatregel in het profiel. Als daar dev tap staat, vraag je de client om een Ethernet-achtige interface, en op macOS eindigen de meeste van dit soort sessies precies bij dat verzoek.

Stap 1: bevestig dat het profiel echt om TAP vraagt

Profielen worden hernoemd, ingepakt en opnieuw geëxporteerd, dus controleer het bestand dat je echt hebt geïmporteerd. Zoek naar de apparaatrichtlijn en naar elke include die die kan overschrijven. Twee regels uitvoer beslechten de vraag in de meeste gevallen. Als zowel dev als dev-type voorkomen, wint de latere richtlijn, en dat is precies het detail dat een gekopieerd profiel verbergt.

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

Bevat het bestand dev tap of dev tap0, dan moet de client een TAP-interface implementeren. Bevat het dev tun, dan geldt de rest van dit artikel niet en zit de fout elders.

Noteer de naam en versie van de client, de macOS-versie en waar het profiel vandaan komt. Die drie feiten bepalen welk van de twee onderstaande wegen überhaupt mogelijk is.

Stap 2: weet wat de apparaatmodus werkelijk verandert

Een TUN-interface draagt IP-pakketten. De client leest en schrijft pakketten die aan een IP-peer zijn geadresseerd, en het besturingssysteem routeert ze als elke andere interface.

Een TAP-interface draagt Ethernet-frames, inclusief broadcast en ARP. Dat stelt een overbrugde server in staat adressen via DHCP uit te delen en een client om apparaten door te roepen te ontdekken, en daarom vertrouwen sommige oude ontwerpen erop.

De prijs is dat TAP een stuurprogramma nodig heeft dat een Ethernet-interface aan het systeem presenteert. Apple heeft het kerneluitbreidingsmodel afgeschaft waarop oudere TAP-stuurprogramma’s voor de Mac leunden, en de vervangende API verschijnt niet magisch in clients die nooit zijn bijgewerkt om die te gebruiken. Een platformmogelijkheid en een geleverd product zijn twee verschillende dingen.

Stap 3: kies tussen een compatibele client en een migratie

Er zijn twee eerlijke wegen. De eerste is een client waarvan de uitgever voor jouw macOS-versie en hardware verklaart dat die de TAP-opstelling ondersteunt die je nodig hebt. Niet een forumbericht van vier jaar geleden, en niet een gearchiveerde installer: een actuele verklaring plus een testverbinding.

De tweede is de dienst naar TUN verplaatsen, wat net zo goed een serverwijziging als een clientwijziging is. Dat vraagt een gerouteerde topologie, een adrespool, gepushte routes voor de externe netwerken en een terugweg van die netwerken naar de pool.

Wat niet werkt, is tap in tun veranderen in je lokale kopie en hopen. De server overbrugt nog steeds, de client spreekt nu IP, en niets stemt overeen.

Stap 4: verzamel de feiten voordat je een werkende dienst wijzigt

Laat het originele profiel ongemoeid en maak een kopie voor experimenten. Een bestand dat je binnen een minuut kunt herstellen, is meer waard dan een nette map. Zodra de vervanging werkt, verwijder je de kopie bewust in plaats van twee profielen achter te laten die in een lijst identiek lijken. Die ene gewoonte voorkomt het grootste deel van de verwarring na een mislukte migratie. Leg het huidige gedrag vast zodat je kunt bewijzen wat er is veranderd: komt de tunnel op, krijgt die een adres, bereik je één bekende host, en werkt naamresolutie.

Stel de gateway-eigenaar drie vragen. Draait de server een overbrugde of gerouteerde topologie? Welke externe prefixen moeten bereikbaar zijn? En is er een onderhoudsvenster voor een configuratiewijziging, of wordt verwacht dat dit werkt zonder de server aan te raken?

De antwoorden daarop bepalen of je vanmiddag een clientprobleem oplost of volgende week een netwerkwijziging plant.

Stap 5: verifieer de migratie vanaf beide kanten

Zodra de server een gerouteerde configuratie heeft en jij een passend profiel hebt, test je in deze volgorde: de tunnel komt tot stand, de client krijgt een adres uit de nieuwe pool, een host aan de externe kant antwoordt, en een naam wordt opgelost via de gepushte DNS-instelling.

Test daarna wat voorheen van Ethernet-gedrag afhing. Als een toepassing apparaten via broadcast ontdekte, vindt die ze niet over een gerouteerde tunnel, en geen enkele clientconfiguratie brengt dat terug. Die toepassing heeft een bekend adres, een lokale hulphost of een andere ontdekkingsmethode nodig.

Sluit af met één keer opnieuw verbinden en één keer opnieuw opstarten, want een profiel dat alleen bij de eerste poging werkt, betekent meestal dat de gepushte routes of de DNS-instelling bij het opnieuw verbinden niet worden toegepast.

Als het nog steeds mislukt, lees de eerste fout

Een client die de interface niet kan aanmaken, zegt dat in zijn log, meestal in de eerste paar regels. Een client die hem aanmaakt en daarna niet authenticeert, is de apparaatvraag allang voorbij, en doorgaan met jagen op TAP verspilt de sessie.

Bewaar het originele profiel en de werkende configuratie tot de vervanging bewezen is. Een clientwijziging terugdraaien is snel; een overbrugd netwerk herbouwen dat iemand op een vermoeden heeft gesloopt, niet.