OpenVPN TAP på macOS: sjekk klienten før du feilsøker

En gammel profil lander på en aktuell Mac, klienten importerer den uten klager, og forbindelsen faller eller slipper aldri trafikk gjennom. Før du bruker en ettermiddag på sertifikater, les enhetslinjen i profilen. Hvis det står dev tap, ber du klienten om et Ethernet-lignende grensesnitt, og på macOS er det nettopp denne forespørselen de fleste slike økter ender på.

Trinn 1: bekreft at profilen virkelig ber om TAP

Profiler blir omdøpt, pakket inn og eksportert på nytt, så sjekk filen du faktisk importerte. Se etter enhetsdirektivet og enhver include som kan overstyre det. To linjer med utdata avgjør spørsmålet i de fleste tilfeller. Når både dev og dev-type dukker opp, vinner det senere direktivet, og det er nettopp slike detaljer en kopiert profil skjuler.

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

Hvis filen inneholder dev tap eller dev tap0, må klienten implementere et TAP-grensesnitt. Hvis den inneholder dev tun, gjelder ikke resten av denne artikkelen, og feilen ligger et annet sted.

Skriv ned klientens navn og versjon, macOS-versjonen og hvor profilen kom fra. Disse tre fakta avgjør hvilken av de to veiene nedenfor som i det hele tatt er mulig.

Trinn 2: vit hva enhetsmodusen faktisk endrer

Et TUN-grensesnitt bærer IP-pakker. Klienten leser og skriver pakker adressert til en IP-motpart, og operativsystemet ruter dem som et hvilket som helst annet grensesnitt.

Et TAP-grensesnitt bærer Ethernet-rammer, inkludert broadcast og ARP. Det er dette som lar en broet server dele ut adresser via DHCP og en klient oppdage enheter ved å rope, og derfor er noen eldre design avhengige av det.

Prisen er at TAP trenger en driver som presenterer et Ethernet-grensesnitt for systemet. Apple har avviklet kjernemodellen som eldre TAP-drivere for Mac bygget på, og erstatnings-API-et dukker ikke opp magisk i klienter som aldri er oppdatert for å bruke det. En plattformevne og et levert produkt er to forskjellige ting.

Trinn 3: velg mellom en kompatibel klient og en migrering

Det finnes to ærlige veier. Den første er en klient hvis utgiver for din macOS-versjon og maskinvare erklærer at den støtter TAP-oppsettet du trenger. Ikke et foruminnlegg fra for fire år siden, og ikke en arkivert installasjonspakke: en gjeldende erklæring pluss en testforbindelse.

Den andre er å flytte tjenesten til TUN, som er en serverendring like mye som en klientendring. Det krever en rutet topologi, en adressepool, pusha ruter for fjernnetverkene og en returvei fra disse nettene tilbake til poolen.

Det som ikke fungerer, er å endre tap til tun i den lokale kopien og håpe. Serveren broer fortsatt, klienten snakker nå IP, og ingenting stemmer.

Trinn 4: samle fakta før du endrer en tjeneste som virker

La den opprinnelige profilen være urørt og lag en kopi til eksperimenter. En fil du kan gjenopprette på et minutt, er mer verdt enn en ryddig mappe. Når erstatningen virker, slett kopien med vilje i stedet for å etterlate to profiler som ser identiske ut i en liste. Den ene vanen forebygger det meste av forvirringen som følger en mislykket migrering. Noter dagens oppførsel slik at du kan bevise hva som endret seg: kommer tunnelen opp, får den en adresse, når du en kjent vert, og virker navneoppslag.

Still gateway-eieren tre spørsmål. Kjører serveren en broet eller rutet topologi? Hvilke fjernprefikser skal være tilgjengelige? Og finnes det et vedlikeholdsvindu for en konfigurasjonsendring, eller forventes det å virke uten å røre serveren?

Svarene på det avgjør om du løser et klientproblem i ettermiddag eller planlegger en nettverksendring neste uke.

Trinn 5: verifiser migreringen fra begge ender

Når serveren har en rutet konfigurasjon og du har en passende profil, test i denne rekkefølgen: tunnelen etableres, klienten mottar en adresse fra den nye poolen, en vert på fjernsiden svarer, og et navn løses opp via den pusha DNS-innstillingen.

Test deretter det som før var avhengig av Ethernet-atferd. Hvis en applikasjon oppdaget enheter via broadcast, vil den ikke finne dem over en rutet tunnel, og ingen mengde klientkonfigurasjon bringer det tilbake. Den applikasjonen trenger en kjent adresse, en lokal hjelpevert eller en annen oppdagelsesmetode.

Avslutt med å koble til på nytt og starte på nytt én gang, fordi en profil som bare virker ved første forsøk vanligvis betyr at de pusha rutene eller DNS-innstillingen ikke brukes ved gjenoppkobling.

Når det fortsatt feiler, les den første feilen

En klient som ikke kan opprette grensesnittet, sier det i loggen sin, vanligvis innen de første linjene. En klient som oppretter det og deretter ikke autentiserer, er for lengst forbi enhetsspørsmålet, og å fortsette å jage TAP sløser bort økten.

Behold den opprinnelige profilen og den fungerende konfigurasjonen til erstatningen er bevist. Å rulle tilbake en klientendring er raskt; å gjenoppbygge et broet nettverk som noen demonterte på en innskytelse, er det ikke.