OpenVPN brīdinājums par vairākiem --up skriptiem: darbojas tikai viens

Brīdinājums par vairākiem skriptiem izklausās kā plānošanas sūdzība, tāpēc acīmredzamais labojums ir pārkārtot rindas, līdz tas pazūd. Taču tā nav plānošanas sūdzība. Vēlāka --up definīcija aizstāj komandu, kas jau saglabāta šim posmam, un parsētājs to pasaka, kas nozīmē, ka no jūsu diviem skriptiem kādreiz ir darbojies tieši viens. Otrs negaida rindā aiz tā; tas ir pazudis.

Tāpēc brīdinājums ir pelnījis uzmanību, lai gan nav nāvējošs: tas paredz DNS atjauninājumu vai maršruta izmaiņas, kas klusi pārstājušas notikt.

Brīdinājums nav par secību

OpenVPN glabā vienu lietotāja skripta komandu up posmam. Kad parsētājs sastop citu definīciju, no profila, iekļauta faila vai komandrindas, tas aizstāj to, ko jau turēja, un izdod brīdinājumu. Nekas netiek savienots, nekas netiek izpildīts divreiz, un secības jautājums nepastāv. Izdzīvo tā komanda, kuru parsētājs redzēja pēdējo, tāpēc rindas pārvietošana var mainīt uzvarētāju, kamēr otrs skripts paliek miris.

Tas pats modelis attiecas uz pārējiem skriptu posmiem: viena komanda katram. Ja diviem darbiem jānotiek abiem, tiem vajag vienu ieejas punktu, nevis divas direktīvas, kas atgādina sarakstu.

Atrodiet abas definīcijas īstajā palaišanā

Sāciet ar to, ko dēmons faktiski saņēma, nevis ar profilu, kuru rediģējāt. ps -ef un vienības ExecStart parāda komandrindu, kurā konteinera ieejas punkts vai ietvars var pievienot --up; distribūcijas init fails var darīt to pašu. systemctl cat openvpn-server@server atklāj, ko pievieno pats pakalpojums, un rekursīvs grep konfigurācijas mapē atrod failu līmeņa definīcijas. Dublikāti parasti nāk no dažādiem slāņiem, un tieši tāpēc viena faila rediģēšana neko nemaina.

Skripta kopēšana citā mapē vai pārdēvēšana arī nenoņem direktīvu. Parsētājs skaita definīcijas, nevis failus.

Lai viens hook pārvalda darbu

Ilgtspējīgais risinājums ir viens izsūtītājs, kas izpilda abas darbības pārdomātā secībā. Īss shell skripts ar set -eu, kas izsauc nepieciešamo integrāciju un pēc tam vietējo darbību un nodod "$@", lai argumentu robežas saglabātos, tur uzvedību vienā pārbaudāmā vietā. Argumentu nodošana tos tikai saglabā; tā nepierāda, ka abi palīgi sagaida vienu un to pašu saskarni, tāpēc izlasiet katra līgumu. Izlemiet, kas jādara kļūdai un vai daļējas izmaiņas jāatceļ.

Ja palaidējs piedāvā atbalstītu paplašinājuma hook, dodiet tam priekšroku salīdzinājumā ar ar rokām veidotu ķēdi. Konteinera attēlam vai piegādātāja pakotnei bieži ir dokumentēta vieta papildu darbam, un tā izmantošana neļauj atjauninājumam pārrakstīt jūsu izsūtītāju.

Tīrīšana pieder atbilstošajam down posmam. Up darbība, kas pārraksta DNS vai pievieno maršrutus, prasa dokumentētu atcelšanu, un izsūtītājs, kas rūpējas tikai par palaišanu, ir puse dizaina.

Apstipriniet integrāciju, ne tikai klusumu

Atbrīvoties no dublētā brīdinājuma ir vieglā daļa; integrācijai joprojām jādarbojas. Pēc savienojuma pārbaudiet atrisinātāja stāvokli ar resolvectl status vai nolasot /etc/resolv.conf, un apstipriniet maršrutus ar ip route. Pēc tam atvienojieties un pievienojieties vēlreiz, jo steigā savienots hook mēdz atstāt kaut ko no iepriekšējās sesijas. journalctl -u openvpn-server@server -b parāda, vai jūsu izsūtītājs darbojās un ko tas izdrukāja.

Turiet hook privilēģijas tur, kur tām jābūt. script-security paaugstināšana vai dēmona palaišana ar lielākām tiesībām nav aizstāta hook labojums; tas paplašina, ko var darīt katrs nākamais skripts, tostarp tāds, kuru nosauks uzbrucējs.

Pazīme, ka labojums ir īsts, nav klusums žurnālā. Tie ir DNS atbilde, maršruta ieraksts un tīrīšana, kas visas darbojas pēc divām atkārtotām pievienošanām.