OpenVPN TAP pe macOS: verificați clientul înainte de a depana

Un profil vechi ajunge pe un Mac actual, clientul îl importă fără nicio obiecție, iar conexiunea cade sau nu trece niciodată trafic. Înainte să petreci o după-amiază întreagă cu certificate, citește linia dispozitivului din profil. Dacă acolo scrie dev tap, ceri clientului o interfață de tip Ethernet, iar pe macOS exact la această cerere se termină majoritatea acestor sesiuni.

Pasul 1: confirmă că profilul cere într-adevăr TAP

Profilele sunt redenumite, împachetate și reexportate, așa că verifică fișierul pe care l-ai importat de fapt. Caută directiva dispozitivului și orice include care ar putea să o suprascrie. În majoritatea cazurilor, două linii de ieșire lămuresc întrebarea. Când apar atât dev, cât și dev-type, câștigă directiva ulterioară, și exact un astfel de detaliu ascunde un profil copiat.

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

Dacă fișierul conține dev tap sau dev tap0, clientul trebuie să implementeze o interfață TAP. Dacă conține dev tun, restul articolului nu se aplică, iar defectul este în altă parte.

Notează numele și versiunea clientului, versiunea macOS și de unde provine profilul. Aceste trei fapte decid care dintre cele două căi de mai jos este măcar posibilă.

Pasul 2: află ce schimbă de fapt modul dispozitivului

O interfață TUN transportă pachete IP. Clientul citește și scrie pachete adresate unui partener IP, iar sistemul de operare le rutează ca pe orice altă interfață.

O interfață TAP transportă cadre Ethernet, inclusiv broadcast și ARP. Aceasta permite unui server punte să distribuie adrese prin DHCP și unui client să descopere dispozitive strigând, și de aceea unele proiecte vechi depind de ea.

Costul este că TAP are nevoie de un driver care prezintă sistemului o interfață Ethernet. Apple a renunțat la modelul de extensie a nucleului pe care se bazau driverele TAP mai vechi pentru Mac, iar API-ul său de înlocuire nu apare ca prin magie în clienți care nu au fost niciodată actualizați să îl folosească. O capacitate a platformei și un produs livrat sunt două lucruri diferite.

Pasul 3: alege între un client compatibil și o migrare

Există două căi oneste. Prima este un client al cărui editor declară, pentru versiunea ta de macOS și hardware-ul tău, că acceptă aranjamentul TAP de care ai nevoie. Nu o postare pe forum de acum patru ani și nu un instalator arhivat: o declarație actuală plus o conexiune de test.

A doua este mutarea serviciului pe TUN, ceea ce este tot atât o schimbare de server, cât și de client. Necesită o topologie rutată, un pool de adrese, rute trimise pentru rețelele îndepărtate și o cale de întoarcere de la acele rețele la pool.

Ce nu funcționează este să schimbi tap în tun în copia locală și să speri. Serverul încă face punte, clientul vorbește acum IP, și nimic nu se potrivește.

Pasul 4: adună faptele înainte de a schimba un serviciu care funcționează

Lasă profilul original neatinse și fă o copie pentru experimente. Un fișier pe care îl poți restaura într-un minut valorează mai mult decât un dosar ordonat. Când înlocuitorul funcționează, șterge copia intenționat, în loc să lași două profile care arată identic într-o listă. Acel singur obicei previne cea mai mare parte a confuziei care urmează unei migrări eșuate. Notează comportamentul actual ca să poți demonstra ce s-a schimbat: urcă tunelul, primește o adresă, ajungi la un host cunoscut și funcționează rezolvarea numelor.

Pune proprietarului gateway-ului trei întrebări. Serverul rulează o topologie punte sau rutată? Ce prefixe îndepărtate ar trebui să fie accesibile? Și există o fereastră de mentenanță pentru schimbarea configurației, sau se așteaptă să funcționeze fără să atingi serverul?

Răspunsurile la acestea decid dacă rezolvi o problemă de client după-amiaza asta sau planifici o schimbare de rețea săptămâna viitoare.

Pasul 5: verifică migrarea de la ambele capete

Când serverul are o configurație rutată și tu ai un profil potrivit, testează în această ordine: tunelul se stabilește, clientul primește o adresă din noul pool, un host din partea îndepărtată răspunde și un nume se rezolvă prin setarea DNS trimisă.

Apoi testează ce depindea înainte de comportamentul Ethernet. Dacă o aplicație descoperea dispozitive prin broadcast, nu le va găsi printr-un tunel rutat, și nicio configurație de client nu readuce asta. Acea aplicație are nevoie de o adresă cunoscută, de un host ajutător local sau de o altă metodă de descoperire.

Încheie cu o reconectare și o repornire, pentru că un profil care funcționează doar la prima încercare înseamnă de obicei că rutele trimise sau setarea DNS nu se aplică la reconectare.

Când tot eșuează, citește prima eroare

Un client care nu poate crea interfața spune asta în jurnal, de obicei în primele rânduri. Un client care o creează și apoi nu reușește autentificarea a trecut demult de întrebarea dispozitivului, iar continuarea urmăririi TAP irosește sesiunea.

Păstrează profilul original și configurația funcțională până când înlocuitorul este dovedit. Revenirea asupra unei modificări de client este rapidă; reconstruirea unei rețele punte pe care cineva a demontat-o din presupuneri nu este.