OpenVPN TAP macOS sisteman: egiaztatu bezeroa arazketari ekin aurretik

Profil zahar bat Mac moderno batera iristen da, bezeroak kexarik gabe inportatzen du, eta konexioa erortzen da edo ez da inoiz trafikorik pasatzen. Ziurtagiriekin arratsalde oso bat eman aurretik, irakurri profileko gailu-lerroa. Bertan dev tap badago, Ethernet motako interfaze bat eskatzen ari zara bezeroari, eta macOS-en saio horietako gehienak eskaera horretan amaitzen dira.

1. urratsa: egiaztatu profileak benetan TAP eskatzen duela

Profilak berrizendatzen, biltzen eta berriro esportatzen dira, beraz, egiaztatu benetan inportatu duzun fitxategia. Bilatu gailuaren direktiba eta hura gainidatz dezakeen edozein include. Irteerako bi lerrok galdera erabakitzen dute kasu gehienetan. dev eta dev-type biak agertzen direnean, geroagoko direktibak irabazten du, eta hori da, hain zuzen, kopiatutako profil batek ezkutatzen duen xehetasuna.

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

Fitxategiak dev tap edo dev tap0 baditu, bezeroak TAP interfazea inplementatu behar du. dev tun badu, artikulu honen gainerakoa ez da aplikatzen eta hutsegitea beste nonbait dago.

Idatzi bezeroaren izena eta bertsioa, macOS bertsioa eta profila nondik datorren. Hiru datu horiek erabakitzen dute beheko bi bideetatik zein den posible.

2. urratsa: jakin zer aldatzen duen gailu-moduak benetan

TUN interfazeak IP paketeak garraiatzen ditu. Bezeroak IP pare bati zuzendutako paketeak irakurtzen eta idazten ditu, eta sistema eragileak beste edozein interfazeren gisa bideratzen ditu.

TAP interfazeak Ethernet markoak garraiatzen ditu, difusioa eta ARP barne. Horrek ahalbidetzen dio zubidun zerbitzari bati DHCP bidez helbideak banatzen eta bezero bati gailuak oihukatuz aurkitzen, eta horregatik diseinu zahar batzuek horren mende daude.

Kostua da TAPek Ethernet interfaze bat sistemari aurkezten dion kontrolatzaile bat behar duela. Appled bertan behera utzi zuen Macerako TAP kontrolatzaile zaharrek oinarritzat zuten kernel luzapenaren eredua, eta haren ordezko APIa ez da magikoki agertzen inoiz erabiltzeko eguneratu ez ziren bezeroen barruan. Plataformaren gaitasun bat eta entregatutako produktu bat bi gauza desberdinak dira.

3. urratsa: aukeratu bezero bateragarri baten eta migrazio baten artean

Bi bide zintzo daude. Lehena bezero bat da, zeinaren argitaletxeak zure macOS bertsiorako eta hardwarearako behar duzun TAP antolaketa onartzen duela adierazten duen. Ez duela lau urteko foro-mezu bat, ez eta artxibatutako instalatzaile bat: uneko adierazpena gehi probako konexioa.

Bigarrena zerbitzua TUNera lekualdatzea da, eta hori bezeroaren aldaketa adina da zerbitzariaren aldaketa. Bideratutako topologia, helbide multzo bat, urruneko sareetarako bultzatutako bideak eta sare horietatik multzorako itzulera-bidea behar dira.

Funtzionatzen ez duena zure tokiko kopian tap tun bihurtu eta espero izatea da. Zerbitzariak oraindik zubi egiten du, bezeroak orain IP hitz egiten du, eta ezer ez dator bat.

4. urratsa: bildu datuak funtzionatzen duen zerbitzu bat aldatu aurretik

Utzi jatorrizko profila ukitu gabe eta egin kopia bat esperimentuetarako. Minutu batean leheneratu dezakezun fitxategi bat karpeta txukun bat baino baliotsuagoa da. Ordezkoak funtzionatzen duenean, ezabatu kopia nahita, zerrendan berdinak diruditen bi profil ez uzteko. Ohitura bakar horrek migrazio huts baten ondorengo nahasmenaren zatirik handiena eragozten du. Erregistratu uneko portaera, zer aldatu den frogatu ahal izateko: tunela altxatzen da, helbidea hartzen du, host ezagun batera iristen zara eta izenen ebazpena funtzionatzen du.

Egin hiru galdera atebidearen jabearen. Zerbitzaria zubidun ala bideratutako topologian ari da? Zein urruneko aurrizki izan beharko lirateke irisgarri? Eta mantentze-leiho bat badago konfigurazioa aldatzeko, edo zerbitzaria ukitu gabe funtzionatzea espero da?

Horien erantzunek erabakitzen dute gaur arratsaldean bezero baten arazoa konpontzen ari zaren ala datorren astean sare-aldaketa bat planifikatzen ari zaren.

5. urratsa: egiaztatu migrazioa bi muturretatik

Zerbitzariak konfigurazio bideratua eta zuk profil egokia dituzunean, probatu ordena honetan: tunela ezartzen da, bezeroak helbide bat hartzen du multzo berritik, urruneko aldeko host batek erantzuten du, eta izen bat ebazten da bultzatutako DNS ezarpenaren bidez.

Ondoren probatu lehen Ethernet portaeraren mende zegoena. Aplikazio batek gailuak difusioz aurkitzen bazituen, ez ditu tunel bideratu batetik aurkituko, eta bezeroaren konfigurazioak ez du hori itzultzen. Aplikazio horrek helbide ezagun bat, tokiko host lagungarri bat edo aurkitzeko metodo desberdin bat behar du.

Amaitzeko, berriz konektatu eta berrabiarazi behin, lehen saiakeran soilik funtzionatzen duen profil batek esan nahi baitu, normalean, bultzatutako bideak edo DNS ezarpena ez direla berriz konektatzean aplikatzen.

Oraindik huts egiten duenean, irakurri lehen errorea

Interfazea sortu ezin duen bezeroak bere erregistroan esaten du, normalean lehen lerroetan. Interfazea sortu eta gero autentifikazioan huts egiten duen bezeroa gailuaren galderatik haratago dago aspaldi, eta TAPen atzetik ibiltzeak saioa alferrik galtzen du.

Mantendu jatorrizko profila eta funtzionatzen duen konfigurazioa ordezkoa frogatu arte. Bezeroaren aldaketa bat atzera botatzea azkarra da; norbaitek susmo baten ondorioz desmuntatutako sare zubidun bat berreraikitzea ez da hain azkarra.