Запускайце задачы пасля VPN з дыспетчара, а не праз if-up
Стары хук інтэрфейса не ўбачыць VPN-злучэнне. Супастаўляйце vpn-up з UUID профілю, рабіце задачу паўторнай і плануйце адключэнне, якое ніколі не спрацоўвае.
Скрыпту, які павінен працаваць пасля ўзняцця VPN, патрэбна падзея ад кампанента, які валодае злучэннем. Файл, пакладзены ў стары каталог сеткавага хука, не з’яўляецца зваротным выклікам для кожнага VPN, які могуць стварыць NetworkManager, pppd або асобны працэс OpenVPN. Кожны з гэтых уладальнікаў паведамляе пра іншую падзею з іншым асяроддзем, таму ўладальніка трэба вызначыць да выбару хука. Інакш скрыпт слушны і проста ніколі не спрацоўвае.
Для VPN, якім кіруе NetworkManager, дыспетчар — правільнае месца, а vpn-up — правільнае дзеянне.
Выкарыстоўвайце vpn-up, а не падзею інтэрфейса
Дыспетчар адрознівае up ад vpn-up. Першы паведамляе пра актываваны інтэрфейс; другі паведамляе пра актываванае VPN-злучэнне. Узняцце Wi-Fi азначае толькі тое, што базавае звяно існуе; тунель можа яшчэ весці перамовы або ўвогуле ніколі не аўтэнтыфікавацца.
Скрыпт атрымлівае інтэрфейс і дзеянне, а звесткі пра злучэнне прыходзяць праз асяроддзе, уключаючы UUID профілю і IP-інтэрфейс VPN. Чытайце гэтыя зменныя замест таго, каб выводзіць ідэнтычнасць з імёнаў прылад.
Абмяжуйце супадзенне адным злучэннем
Супастаўляйце па UUID злучэння або іншай ідэнтычнасці, якую падае дыспетчар, а не па прэфіксе tun ці ppp0. Імёны інтэрфейсаў не стабільныя, адначасова можа існаваць больш за адзін тунель, і два профілі могуць мець аднолькавае адлюстраванае імя. Супастаўленне па прэфіксе tun азначае, што скрыпт рана ці позна спрацуе для злучэння, якога ніхто не збіраўся закранаць. Ён таксама можа спрацаваць двойчы для аднаго профілю, калі перападлучэнне перабудоўвае прыладу.
Зрабіце задачу ідэмпатэнтнай. Зваротны выклік, які дадае маршрут пры кожным выкліку, у рэшце рэшт запоўніць табліцу дублікатамі, і менавіта другая копія ламае маршрутызацыю.
Ведайце, чаго не даказвае актывацыя
vpn-pre-up працуе да таго, як NetworkManager паведаміць пра поўную актывацыю VPN, і кіраўнік чакае гэтых скрыптоў. Выкарыстоўвайце блакуючую стадыю толькі тады, калі задача сапраўды належыць туды, бо павольная праверка затрымлівае актывацыю, якую чакаюць усе астатнія кампаненты.
Наяўнасць маршрутаў не даказвае, што праграма слухае, прыватнае імя вырашаецца або існуе сеанс карыстальніка. Правярайце гэта асобна з абмежаваным тайм-аўтам і паведамляйце, які ўзровень зламаўся, замест паўторнай спробы ўсяго ланцуга.
Паважайце кантэкст, у якім працуе скрыпт
Скрыпты дыспетчара працуюць ад імя root, па-за любым сеансам карыстальніка. Не мяркуйце, што асяроддзе ўвайшоўшага карыстальніка, графічны сеанс або незаблакаванае сховішча ключоў даступныя. Ніхто не павінен адказваць на адсутнасць кантэксту працоўнага стала тым, каб зрабіць кожныя ўліковыя дадзеныя чытэльнымі для кожнага працэсу. Трымайце працу сеансу карыстальніка ў службе карыстальніка або памочніку сеансу, якому зваротны выклік можа падаць сігнал без выдавання сябе за карыстальніка.
Валоданне і правы на скрыпт таксама маюць значэнне. Файл, што выконваецца ад імя root і які можа замяніць любы карыстальнік, — гэта шлях да павышэння прывілеяў, і гэта знаходка, незалежная ад таго, ці слушная логіка VPN.
Плануйце адключэнне, якое ніколі не спрацоўвае
NetworkManager дакументуе, што vpn-pre-down не выходзіць пры прымусовых адключэннях, такіх як нечаканае завяршэнне або страта злучэння. Таму ачыстка, пабудаваная толькі вакол спакойнага pre-down, па вызначэнні няпоўная. Любы агульны стан, які змяняе скрыпт, патрабуе іншага ўладальніка, здольнага аднавіць яго пасля збою, і гэты шлях аднаўлення трэба праверыць, а не меркаваць.
Праверце хук звычайным падключэннем, перападключэннем, наўмысным адключэннем і выцягнутым кабелем. Запішыце UUID, дзеянне і інтэрфейс, які спрацаваў, не журналюючы сакрэтаў. Гэты запіс — адзіны надзейны доказ таго, што хук працаваў для патрэбнага вам злучэння, і менавіта ён робіць наступную змену бяспечнай.