Kailangan ng VPN client ang pribilehiyadong tulong para muling i-configure ang network, at masyadong malawak na inilalapat ang katotohanang iyon sa lahat ng nakapaligid dito. Ang script na nag-mount ng file share ay hindi kailangan ng root, dahil ang share ay pag-aari ng session ng naka-sign in na user at ng mga kredensyal ng user na iyon. Ang pag-alis ng mount mula sa pribilehiyadong landas ay nag-aalis ng pangangailangan sa mga sudo rule, root hook at pag-edit sa mga bundled na application. Ang natitira ay isang maliit na applet na nananatiling bukas, nagmamatyag sa isang profile at gumagawa ng isang pagtatangka.

Bakit ito kabilang sa user session

Ang naka-mount na volume ay katangian ng session na nag-mount nito. Hindi ito nakikita ng session ng ibang user, at ang mount na pag-aari ng root ay kumikilos nang iba kaysa sa ginawa ng Finder. Ang pagpapanatili ng mount sa user session ay nagpapanatili ng semantikang iyon.

Umiiral ang mga pribilehiyadong katulong para sa mga bahaging talagang nangangailangan ng mga ito: paglikha ng tunnel interface, pagbabago ng ruta, pag-update ng resolver. Ang pag-mount ng SMB share ay hindi isa sa mga bahaging iyon. Ang pagtrato dito na parang isa ay nagpipilit ng pagpili sa pagitan ng sudo na walang password at root script na tumatakbo nang walang taong naroroon. Pareho silang mas malaking panganib kaysa sa katwiran ng problema, at iniiwasan ng diskarte sa user session ang pagpili nang lubusan.

Ang sariling connection hook ng Tunnelblick ay hindi kapalit dito, dahil tumatakbo ang mga ito sa labas ng desktop session at hindi tinukoy ang pagkakasunod-sunod nila kaugnay ng mga script ng client. Ang pagtatanong ng estado mula sa user applet ay mas maliit na mekanismo na may mas kaunting palagay.

Patunayan muna nang manu-mano na gumagana ang share

Hindi makapagbibigay ang automation ng ruta, pahintulot o account na wala. Ikonekta ang VPN nang manu-mano at buksan ang share sa Finder bago magsulat ng anumang script. Kung mabibigo iyon, mabibigo ang script sa mas nakakalitong paraan.

Itala ang tatlong halaga na gagamitin ng script: ang pangalan ng profile nang eksakto ayon sa listahan ng Tunnelblick, ang URL ng share at ang pangalan ng volume na ipinapakita ng Finder pagkatapos ng mount. Mahalaga ang pangalan ng volume dahil ginagamit ito ng pagsusuri sa umiiral na mount, at ang pagsusuring nakabatay lamang sa pangalan ay pananggalang sa kaginhawahan, hindi patunay ng pagkakakilanlan ng server. Gumamit ng pangalang natatangi sa makina. Pagkatapos ay kumpirmahin na sumasagot man lang ang server.

smbutil view //files.corp.example
osascript -e 'tell application "Tunnelblick" to get state of first configuration whose name is "Office"'
mount | grep -i smbfs

Pinatutunayan ng unang utos na sumasagot ang server, ng pangalawa na nagreresolba ang pangalan ng profile, at ipinapakita ng pangatlo kung ano ang hitsura ng matagumpay na mount. Itala ang tatlo bago i-automate ang anuman.

Basahin ang estado ng profile mula sa Tunnelblick

Inilalantad ng Tunnelblick ang mga configuration nito at ang kanilang estado sa pamamagitan ng AppleScript, at iyon ang tanging hook na kailangan ng disenyong ito. Ang estadong mahalaga ay ang string na iniuulat para sa partikular na profile, hindi ang presensya ng application.

May mga kahihinatnan ang pagtatanong na dapat banggitin. Ang muling pagkonekta na mas maikli kaysa sa agwat ay maaaring lumipas nang hindi napapansin, at hindi talaga nakikita ng applet ang pagbabago. Katanggap-tanggap iyon para sa pananggalang ng mount at hindi katanggap-tanggap para sa anumang kailangang tumugon sa bawat kaganapan. Kung kailangan mo ng katapatan sa kaganapan, maling mekanismo ito, hindi mekanismong nangangailangan ng mas maikling timer. Piliin ang agwat na isinasaalang-alang ang kompromisong iyon.

property attempted : false

on idle
    set profileName to "Office"
    set shareURL to "smb://files.corp.example/OfficeTeam"
    set volName to "OfficeTeam"
    tell application "Tunnelblick" to set vpnState to state of first configuration whose name is profileName
    if vpnState is not "CONNECTED" then
        set attempted to false
        return 20
    end if
    tell application "Finder" to set mounted to (exists disk volName)
    if (not mounted) and (not attempted) then
        set attempted to true
        try
            mount volume shareURL
        end try
    end if
    return 20
end idle

I-export ito bilang application na may opsyong manatiling bukas, pagkatapos ay ilunsad sa naka-sign in na session kaysa sa pamamagitan ng sudo.

Mag-mount nang isang beses, pagkatapos ay tumigil sa pagsubok

Ang flag na sinubukan ay ang pumipigil dito na maging loop na humuhula ng kredensyal. Kapag nasubukan na ng applet, hinihintay nitong magbago ang estado ng koneksyon bago muling subukan.

Sinasadya ang pag-uugaling iyon. Ang share na tumatanggi sa mount ay karaniwang tumatanggi dahil sa dahilang hindi kayang ayusin ng muling pagsubok, at ang paulit-ulit na pagtatangka ay ginagawang agos ng mga hiling ang isang hiling. Nire-reset ang flag kapag umalis ang profile sa konektadong estado, kaya ang tunay na muling pagkonekta ay gumagawa ng eksaktong isang bagong pagtatangka. Nire-reset din ito ng paglabas at muling paglunsad ng applet, at iyon ang manu-manong override. Wala sa dalawang landas ang nagtatago ng pagpalya; iniiwan ng dalawa itong nakikita sa Finder.

Walang dalang password ang script, at dapat manatiling ganoon. Hayaang magtanong ang pag-mount, at hayaang gawin ng keychain ang sinusuportahan ng organisasyon. Ang paglalagay ng kredensyal sa URL ay ginagawang lihim ang isang script na pangkaginhawahan, at kailangan itong paikutin.

Ano ang hindi kayang gawin ng katulong

Tatlong hangganan ang dapat isulat sa tabi ng applet. Hindi nito kayang ilabas ang abalang volume pagkatapos ng pagpalya ng network, hindi nito kayang siguraduhing handa ang DNS at server kapag sinabi ng estadong konektado, at hindi ito tumutugon sa bawat muling pagkonekta.

Ang unang hangganan ang pinakamahalaga sa pagsasanay. Ang share na nawawala ang server ay nag-iiwan ng volume na mukhang naka-mount at humaharang sa pag-access, at ang magalang na pagwawasto ay tapusin ang mga operasyon ng file at ilabas ito bago ang planadong pagdiskonekta. Ipinapaliwanag ng pangalawa ang karamihan sa mga bigong unang pagtatangka: nakaangat ang tunnel habang hindi pa nakakahabol ang resolver, kaya maghintay at pagkatapos ay mag-mount nang manu-mano nang isang beses upang kumpirmahin. Ang pangatlo ay ang kompromiso sa pagtatanong kanina, hindi isang bug na dapat ayusin.

Para sa makina na walang nagbabantay o pinamamahalaang fleet, maling hugis ang disenyong ito. Gumamit ng patakaran sa pag-mount na pag-aari ng administrator kaysa palawakin ang desktop applet tungo sa pribilehiyadong serbisyo.

Kaugnay na mga artikulo