OpenConnect vpnc-script: aling file ang tumatakbo?

Maaaring tapusin ng OpenConnect ang handshake ng tunnel at iwan ka pa ring walang ruta patungo sa pribadong subnet, dahil ang kliyente at ang katulong na nagbabago ng estado ng lokal na network ay dalawang magkaibang programa. Pinatutunayan ng pagpapatotoo na tinanggap ng gateway ang sesyon; wala itong pinatutunayang anuman tungkol sa kung aling interface, aling mga ruta o aling mga setting ng resolver ang na-install pagkatapos. Karamihan sa mga nakakalitong ulat ay nagmumula sa pagpapalit ng katulong ng kopya mula sa lumang sagot, na nagbabago sa pag-uugali ng bawat koneksyon sa makina. Hanapin ang katulong na talagang tinatawag ng tumatakbong kliyente bago baguhin ang anumang bahagi nito.

Dalawang programa, dalawang responsibilidad

Pagmamay-ari ng kliyente ang transportasyon, pagpapatotoo at aparato ng tunnel. Pagmamay-ari ng hiwalay na katulong ang nangyayari sa lokal na sistema kapag umiiral na ang tunnel: pag-address sa interface, mga ruta patungo sa mga subnet na inihayag ng gateway, at configuration ng resolver. Ang dokumentasyon ng katulong ng OpenConnect ay naglalarawan ng paghahating iyon at ng kapaligirang natatanggap ng katulong. Mahalaga ang pagkakaiba kapag may pagpalya, dahil ang tinanggihang password at ang nawawalang ruta ay hindi isang insidente kahit nagpapakita ang desktop ng isang dialog para sa dalawa.

Ang pagtanda sa paghahating ito ay nagpapaliwanag din kung bakit ang isang koneksyon ay makapag-uulat ng tagumpay habang ang mga pribadong pangalan ay hindi pa rin nareresolba. Nakatayo ang tunnel sa dalawang kaso, at ang yugto ng lokal na integrasyon lamang ang naiiba.

Hanapin ang katulong na ginagamit ng tumatakbong kliyente

Itinakda ang landas kapag binubuo ang pakete at maaaring i-override sa bawat pagtawag, kaya ang file na natatandaan mo mula sa ibang distribusyon ay maaaring walang kinalaman sa koneksyong ito. Itanong sa tumatakbong proseso, hindi sa dokumentasyong nakabukas nang nagkataon.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

Kung ang linya ng proseso ay may bitbit na --script argumento, ang file na iyon ang mananaig sa naka-compile na default. Ang mas lumang mga landas tulad ng /etc/vpnc/vpnc-script ay maaaring umiiral at manatiling hindi ginagamit, kaya walang binabago ang pagbura o pag-edit sa mga ito sa isang bagong build. Tingnan din ang petsa ng pagbabago, dahil ang katulong na walang nakahawak nang maraming taon ay malakas na senyales na ang naka-package na default ang gumagawa ng trabaho.

Ang integrasyon sa NetworkManager ay ikatlong may-ari, may sariling katulong at sariling mga setting ng profile. Ang pagpatong ng pangalawang script ng ruta o resolver sa integrasyong iyon ay nagdodoble ng mga ruta at nag-iiwan ng resolver na pinagsasabihan ng dalawang programa na sila ang namamahala. Pumili ng isang may-ari bawat koneksyon at patayin ang isa bago mag-test.

Basahin ang unang nabigong operasyon, hindi ang huling babala

Ang configuration ng interface, pag-install ng ruta, pagpili ng resolver at paglilinis ng lumang estado ay magkakahiwalay na hakbang, at ang huling nakalimbag na babala ay madalas reklamo sa paglilinis at hindi ang pagpalya na sinira ang koneksyon. Basahin pataas hanggang sa unang tiyak na operasyong nabigo. Ang error ng katulong na nagpapangalan ng file o address ay mas mahalaga kaysa sampung linyang ingay ng pagbuwag.

Ihambing ang inaasahang lokal na resulta sa naobserbahang resulta: mayroon ang aparato ng tunnel, dumadaan dito ang ruta patungo sa kilalang pribadong address, at sumasagot ang resolver para sa pribadong pangalan. Ang katulong na nagtagumpay sa unang dalawa at nabigo sa pangatlo ay tumuturo sa patakaran ng resolver at hindi sa routing. Ang katulong na hindi man lang naka-configure ng aparato ay malamang hindi kailanman naisakatuparan, at iyon ay usapin ng pahintulot, hindi ng network. Kumpirmahin ang bit na maipapatupad at ang service account bago muling isulat ang anumang lohika.

I-verify ang konekta, muling konekta at idiskonekta

Ang setup ay kalahati lamang ng kontrata, dahil dapat ibalik o tanggalin ng parehong katulong ang estadong pagmamay-ari nito kapag nagsara ang tunnel. Ang katulong na nagdaragdag ng ruta at hindi kailanman nag-aalis ay nag-iiwan sa makina ng lumang landas na mas matagal pa kaysa sesyon.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

Patakbuhin ang unang tatlo habang konektado, idiskonekta, pagkatapos patakbuhin muli at kumpirmahin na wala na ang ruta at ang entry ng resolver. Ipinapakita ng ikaapat na linya kung ang katulong ay tinawag man lang at kung aling maipapatupad na landas ang ginamit ng serbisyo. Itabi ang pares ng output na iyon sa ticket, dahil ang paghahambing bago at pagkatapos ang nagpapalinaw ng bug sa paglilinis.

Panatilihing naka-package ang katulong at maipapatupad ng service account, dahil ang script na tumatakbo sa shell mo ay maaari pa ring tanggihan sa ilalim ng limitadong patakaran ng serbisyo. Kapag talagang kailangan ang pag-customize, idokumento ang layunin at may-ari nito at ihambing ito sa naka-package na bersyon sa bawat pag-upgrade. Ang hindi maipaliwanag na fork ng isang katulong ay isa sa mga kaunting bagay na makapagpapabagsak sa isang gumaganang koneksyon makalipas ang isang taon.