OpenConnect sa macOS: package, release archive o git clone

Tatlong landas ang nagbibigay sa iyo ng OpenConnect client sa isang Mac, at magkaiba ang iniiwan nila sa disk. Ang Homebrew formula ay nag-iinstall ng naka-compile na binary at ang network script na nagse-set ng mga ruta at DNS. Ang release archive ay nagbibigay ng source code na may nabuong build system. Ang git checkout ay nagbibigay ng source code na wala nito. Ang pagpili ng mali ang dahilan kung bakit ang mga tao ay nakakaharap ng kulang na configure ilang minuto pagkatapos magsimula ng tutorial.

Dalawang magkaibang makina sa ilalim ng iisang pangalan

Ang landas ng package ay isang utos lang, at ito ang tamang default para sa sinumang ang trabaho ay kumonekta sa halip na mag-develop.

brew install openconnect

Ang inilalagay nito ay mas mahalaga kaysa sa utos. Nakukuha mo ang binary ng client, at nakukuha mo rin ang vpnc-script na tinatawag ng client para i-program ang interface, ang mga ruta at ang resolver. Magkatuwang silang gumagana: tinatapos ng binary ang TLS session at ibinibigay ang nagawang interface sa script, at ang script ang bahaging nakakaalam kung paano gustong baguhin ng operating system na ito ang network nito.

Ipinapaliwanag ng paghahating iyon ang isang buong uri ng nakakalitong ulat. Ang client na kumokonekta, nag-uulat ng tagumpay at pagkatapos ay nagpapadala ng trapiko sa maling daan ay kadalasang problema sa script, hindi sa tunnel, at ang muling pag-install ng formula ay nag-aayos lamang dahil ang script ay muling nai-install din. Suriin ang kasalukuyang suporta ng formula para sa macOS at sa arkitektura ng CPU bago magplano sa paligid nito; ang Mac na perpektong nagpapatakbo ng shell ay maaaring wala pang kasalukuyang package na binuo para rito.

Ano talaga ang ginagawa ng landas ng source

Ang release archive ay dumarating na may nabuong build system, kaya ang pamilyar na ./configure ay naroon mula sa simula. Ang git checkout ay wala, dahil ang mga nabuong file ay produkto ng build at hindi mga bagay na inimbak ng proyekto. Iyon ang buong dahilan kung bakit lumilitaw ang ./autogen.sh sa mga tagubilin para sa mga checkout at hindi para sa mga release archive.

./autogen.sh
./configure
make
make install

Bawat linya ay may tiyak na ginagawa, at ang pag-alam kung alin ang nabigo ay nakakatipid ng maraming hula. Ang hakbang na autogen ay nagpapatakbo ng autotools para makabuo ng configure. Ang hakbang na configure ay sinusuri ang compiler, mga library at header na kailangan ng client, pagkatapos ay isinusulat ang mga makefile na sumasalamin sa natagpuan. Ang hakbang na make ay nagko-compile. Ang hakbang na install ay kinokopya ang mga resulta sa isang lugar sa iyong path.

Sa huling linyang iyon madalas napupunta sa mali ang payo. Ang pag-install ay hindi patunay na gumana ang build, at ang pagpapatakbo nito sa anumang download folder na may mataas na pribilehiyo ay isang magandang paraan upang magkalat ng mga file na hindi mo maaalala mamaya. Kung nabigo ang configure dahil sa kulang na library, ang kapaki-pakinabang na output ay ang unang error na inilimbag nito, hindi ang huling dalawampung linya ng log.

Hiwalay ang session at ang configuration ng network

Ang pagkakaibang ito ang nagpapasya kung ang koneksyon ay talagang nagdadala ng trapiko. Ang pagtatatag ng TLS session ay nagbibigay sa iyo ng interface sa panig ng client. Ang paglalapat ng mga ruta, address at DNS resolver ay ikalawang hakbang na ginagawa sa pamamagitan ng network script, at ang build na gumawa ng binary na walang script ay may kalahating client.

Ipinapaliwanag ng parehong paghahati kung bakit magkaiba ang kilos ng dalawang makina na may magkatulad na client: ang script ay sumasangguni sa network configuration ng system, at kasama sa configuration na iyon ang lahat ng iba pang nag-angkin ng ruta. Kapag ang split tunnel ay nagpadala ng trapiko sa hindi inaasahang lugar, ginagawa ng tunnel ang trabaho nito at ang desisyon sa routing ang dapat suriin.

Kaya kapag nagde-debug ka, itanong kung aling layer ang nabigo. Ang session na hindi kailanman naitatag ay protocol, certificate o credentials. Ang session na naitatag at walang ipinapasa ay ang interface at ang script. Ang naka-install na client na gumagana mula sa isang network at hindi sa iba ay reachability, at walang dami ng rebuild ang makakabago niyon.

Alamin kung aling binary ang pinapatakbo mo

Ang build na in-install sa kamay at ang naka-package na binary ay maaaring mabuhay nang payapa nang magkasama, at kung alin ang tumatakbo ay nakadepende sa iyong path at hindi sa iyong intensyon. Alamin ito bago mo iulat ang isang version number sa kahit kanino.

which -a openconnect
openconnect --version
brew list --versions openconnect

Ang unang utos ay naglilista ng bawat kopya na nakikita ng shell mo, sa ayos na susubukan nito. Sinasabi ng pangalawa kung alin ang sumagot. Kapag hindi iyon tugma sa inaasahan mo, pinapatakbo mo ang isang build mula sa lumang eksperimento, at walang pagbabago sa configuration ang makakagalaw niyon.

Ang pag-install ng client ay hindi pag-apruba ng gateway

Ang gumaganang binary ay hindi ginagawang compatible ang isang deployment. Kumpirmahin ang protocol ng gateway, ang daloy ng authentication nito at anumang kinakailangan sa managed device sa mga taong nagmamay-ari nito, dahil mga katotohanan iyon sa patakaran at layer ng application na hindi maibibigay ng build.

Ang mga tagubilin sa build ng proyekto ay mas detalyadong sumasaklaw sa autotools sequence at sa kinakailangan ng network script, at iyon ang dapat sundin at hindi isang blog post na mas luma pa sa iyong bersyon ng macOS. Kung ang layunin ay kumonekta lang, kunin ang package, panatilihin ang script, at iwanan ang compiler sa labas.