Patakbuhin ang mga gawain pagkatapos ng VPN mula sa dispatcher, hindi mula sa if-up

Ang script na dapat tumakbo pagkatapos bumangon ang VPN ay nangangailangan ng kaganapan mula sa bahaging nagmamay-ari ng koneksyon. Ang file na inilagay sa lumang direktoryo ng mga hook ng network ay hindi callback para sa bawat VPN na maaaring gawin ng NetworkManager, pppd o ng isang hiwalay na proseso ng OpenVPN. Ang bawat isa sa mga may-ari ay nag-uulat ng ibang kaganapan na may ibang kapaligiran, kaya dapat munang matukoy ang may-ari bago piliin ang hook. Kung hindi, tama ang script at hindi lang talaga ito tumatakbo.

Para sa VPN na pinamamahalaan ng NetworkManager, ang dispatcher ang tamang lugar, at ang vpn-up ang tamang aksyon.

Gamitin ang vpn-up, hindi ang kaganapan ng interface

Nakikilala ng dispatcher ang up mula sa vpn-up. Ang una ay nag-uulat ng nakaaktibong interface; ang pangalawa ay nag-uulat ng nakaaktibong koneksyon ng VPN. Ang pagbangon ng Wi-Fi ay nangangahulugan lamang na umiiral ang pinagbabatayang link; maaaring nag-uusap pa ang tunel, o maaaring hindi ito kailanman ma-authenticate.

Natatanggap ng script ang interface at ang aksyon, habang ang mga detalye ng koneksyon ay dumarating sa pamamagitan ng kapaligiran, kasama ang UUID ng profile at ang IP interface ng VPN. Basahin ang mga variable na iyon sa halip na hulaan ang pagkakakilanlan mula sa mga pangalan ng device.

Limitahan ang pagtutugma sa isang koneksyon

Itugma sa UUID ng koneksyon, o sa ibang pagkakakilanlang ibinibigay ng dispatcher, sa halip na sa prefix na tun o ppp0. Hindi matatag ang mga pangalan ng interface, maaaring may higit sa isang tunel nang sabay, at dalawang profile ang maaaring may parehong pangalan sa display. Ang pagtutugma sa prefix na tun ay nangangahulugang sa huli ay tatakbo ang script para sa koneksyong walang sinumang nagbalak hawakan. Maaari rin itong tumakbo nang dalawang beses para sa isang profile kapag muling itinayo ng muling pagkonekta ang device.

Gawing idempotent ang gawain. Ang callback na nagdaragdag ng ruta sa bawat tawag ay sa huli ay pinupuno ang talahanayan ng mga duplicate, at ang pangalawang kopya ang sumisira sa routing.

Alamin kung ano ang hindi pinapatunayan ng activation

vpn-pre-up ay tumatakbo bago iulat ng NetworkManager na ganap nang aktibo ang VPN, at hinihintay ng manager ang mga script na iyon. Gumamit ng blocking na yugto lamang kapag talagang nabibilang doon ang gawain, dahil ang mabagal na pagsusuri ay nagpapabagal sa activation na hinihintay ng lahat ng iba pang bahagi.

Ang pagkakaroon ng mga ruta ay hindi nagpapatunay na may aplikasyong nakikinig, may pribadong pangalang nare-resolve, o may session ng user. Suriin ang mga iyon nang hiwalay na may limitadong oras, at iulat kung aling layer ang nabigo sa halip na subukan muli ang buong chain.

Igalang ang kontekstong pinapatakbuhan ng script

Ang mga script ng dispatcher ay tumatakbo bilang root, labas ng anumang session ng user. Huwag ipagpalagay na available ang kapaligiran ng naka-log in na user, ang graphical session nito, o ang nakabukas na keyring. Walang sinuman ang dapat tumugon sa kawalan ng konteksto ng desktop sa pamamagitan ng paggawang mababasa ng bawat proseso ang bawat kredensyal. Itago ang gawain ng session ng user sa isang serbisyo ng user o sa isang katulong ng session na maaaring senyasan ng callback nang hindi nagpapanggap na user.

Mahalaga rin ang pagmamay-ari at mga pahintulot sa script. Ang file na pinapatakbo bilang root at maaaring palitan ng sinumang user ay isang daan para sa pagtaas ng pribilehiyo, at ito ay isang natuklasang independiyente sa kung tama ang lohika ng VPN.

Magplano para sa paghihiwalay na hindi kailanman nangyayari

Itinatala ng NetworkManager na ang vpn-pre-down ay hindi inilalabas para sa mga sapilitang paghihiwalay tulad ng hindi inaasahang pagtatapos o pagkawala ng koneksyon. Kaya ang paglilinis na itinayo lamang sa paligid ng isang malumanay na pre-down ay hindi kumpleto sa konstruksyon. Anumang shared na estado na binabago ng script ay nangangailangan ng ibang may-ari na makapagpapanumbalik nito pagkatapos ng crash, at ang landas ng pagbawi ay dapat subukan sa halip na ipalagay.

Subukan ang hook sa normal na koneksyon, muling pagkonekta, sinadyang paghihiwalay at hinila na cable. Itala ang UUID, ang aksyon at ang interface na tumakbo, nang hindi nagtatala ng mga sikreto. Ang talaang iyon ang tanging mapagkakatiwalaang patunay na tumakbo ang hook para sa koneksyong nilayon mo, at iyon ang nagpapasiguro sa susunod na pagbabago.