OpenVPN TAP sa macOS: suriin ang kliyente bago mag-debug

Dumarating ang lumang profile sa isang makabagong Mac, ini-import ito ng kliyente nang walang reklamo, at bumabagsak ang koneksyon o hindi kailanman dumadaan ang trapiko. Bago magpalipas ng isang hapon sa mga sertipiko, basahin ang linya ng device sa profile. Kung nakasulat doon ang dev tap, humihingi ka sa kliyente ng interface na parang Ethernet, at sa macOS doon nagtatapos ang karamihan ng ganitong sesyon.

Hakbang 1: kumpirmahin na talagang humihingi ng TAP ang profile

Pinapalitan ng pangalan, binabalot at muling ine-export ang mga profile, kaya suriin ang file na aktwal mong ini-import. Hanapin ang direktiba ng device at anumang include na maaaring pumalit dito. Sa karamihan ng kaso, dalawang linya ng output ang nagtatapos sa tanong. Kapag parehong lumitaw ang dev at dev-type, ang huling direktiba ang nananalo, at iyon mismo ang detalyeng itinatago ng kinopyang profile.

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

Kung ang file ay may dev tap o dev tap0, kailangang magpatupad ang kliyente ng TAP interface. Kung may dev tun, hindi naaangkop ang natitirang bahagi ng artikulong ito at nasa ibang lugar ang problema.

Isulat ang pangalan at bersyon ng kliyente, ang bersyon ng macOS, at kung saan galing ang profile. Ang tatlong faktong iyon ang magpapasya kung alin sa dalawang landas sa ibaba ang posible.

Hakbang 2: alamin kung ano talaga ang binabago ng device mode

Nagdadala ang TUN interface ng mga packet na IP. Nagbabasa at nagsusulat ang kliyente ng mga packet na naka-address sa kapares na IP, at rina-ruta ito ng operating system tulad ng anumang ibang interface.

Nagdadala ang TAP interface ng mga Ethernet frame, kasama ang broadcast at ARP. Ito ang nagpapahintulot sa naka-bridge na server na mamahagi ng address sa pamamagitan ng DHCP at sa kliyente na matuklasan ang mga device sa pagsigaw, kaya umaasa rito ang ilang lumang disenyo.

Ang halaga ay kailangan ng TAP ng driver na naglalahad ng Ethernet interface sa system. Inalis na ng Apple ang modelong kernel extension na pinag-aasahan ng lumang TAP driver para sa Mac, at ang kapalit nitong API ay hindi lumilitaw na parang mahika sa mga kliyenteng hindi kailanman na-update para gamitin ito. Magkaibang bagay ang kakayahan ng platform at ang naihatid na produkto.

Hakbang 3: pumili sa pagitan ng compatible na kliyente at migration

May dalawang tapat na landas. Ang una ay kliyenteng idinedeklara ng publisher, para sa iyong bersyon ng macOS at hardware, na sinusuportahan nito ang TAP setup na kailangan mo. Hindi forum post mula apat na taon ang nakalipas, at hindi archived na installer: kasalukuyang pahayag kasama ang test connection.

Ang pangalawa ay ilipat ang serbisyo sa TUN, na pagbabago ng server kasing dami ng pagbabago ng kliyente. Kailangan nito ng routed topology, pool ng address, pushed routes para sa malalayong network, at pabalik na ruta mula sa mga network na iyon patungo sa pool.

Ang hindi gumagana ay baguhin ang tap sa tun sa lokal na kopya at umasa. Nagbobridge pa rin ang server, nagsasalita na ng IP ang kliyente, at walang nagtutugma.

Hakbang 4: tipunin ang mga katotohanan bago baguhin ang gumaganang serbisyo

Iwanang hindi ginalaw ang orihinal na profile at gumawa ng kopya para sa mga eksperimento. Ang file na maibabalik mo sa isang minuto ay mas mahalaga kaysa maayos na folder. Kapag gumana na ang kapalit, sadyang burahin ang kopya sa halip na mag-iwan ng dalawang profile na magkamukha sa listahan. Ang nag-iisang ugali na iyon ay pumipigil sa karamihan ng pagkalito pagkatapos ng nabigong migration. Itala ang kasalukuyang gawi upang mapatunayan kung ano ang nagbago: umaangat ba ang tunnel, nakakakuha ba ito ng address, naaabot mo ba ang isang kilalang host, at gumagana ba ang paglutas ng pangalan.

Tanungin ang may-ari ng gateway ng tatlong bagay. Gumagana ba ang server sa naka-bridge o routed na topology? Aling malalayong prefix ang dapat maabot? At may maintenance window ba para sa pagbabago ng configuration, o inaasahang gagana ito nang hindi hinahawakan ang server?

Ang mga sagot sa mga iyon ang magpapasya kung nilulutas mo ngayong hapon ang problema ng kliyente o nagpaplano ka ng pagbabago sa network sa susunod na linggo.

Hakbang 5: i-verify ang migration mula sa dalawang dulo

Kapag may routed configuration na ang server at may tugmang profile ka, subukan sa ganitong pagkakasunod-sunod: nabubuo ang tunnel, tumatanggap ang kliyente ng address mula sa bagong pool, sumasagot ang host sa malayong panig, at nalulutas ang pangalan sa pamamagitan ng pushed DNS setting.

Pagkatapos subukan ang dating umaasa sa gawi ng Ethernet. Kung natuklasan ng isang app ang mga device sa broadcast, hindi niya ito makikita sa routed tunnel, at walang dami ng client configuration ang makakapagbalik niyon. Kailangan ng app na iyon ng kilalang address, lokal na helper host, o ibang paraan ng pagtuklas.

Tapusin sa isang muling pagkonekta at isang muling pag-boot, dahil ang profile na gumagana lamang sa unang pagtatangka ay karaniwang nangangahulugang hindi inilalapat ang pushed routes o DNS setting kapag muling kumonekta.

Kapag nabigo pa rin, basahin ang unang error

Ang kliyenteng hindi makagawa ng interface ay sinasabi ito sa log nito, kadalasan sa mga unang linya. Ang kliyenteng nakagawa nito at pagkatapos ay nabigo sa authentication ay matagal nang nalampasan ang tanong sa device, at ang patuloy na paghabol sa TAP ay sayang sa sesyon.

Itago ang orihinal na profile at ang gumaganang configuration hanggang mapatunayan ang kapalit. Mabilis ibalik ang pagbabago sa kliyente; hindi mabilis ang muling pagtatayo ng naka-bridge na network na giniba ng isang tao batay sa haka-haka.