OpenVPN-asetukset palaavat reitittimessä uudelleenkäynnistyksen jälkeen: korjaa generaattori

Kuluttajareitittimen tai NAS-laitteen laiteohjelmisto rakentaa OpenVPN-määrityksensä usein uudelleen joka käynnistyksellä, joten lisäämäsi direktiivi säilyy täsmälleen seuraavaan käynnistykseen asti. Sama koskee verkkolomakkeeseen kirjoitettuja avaimia, joissa tallennettu arvo voi palata sotkeutuneena tallennuksen jälkeen. Kumpikaan oire ei tarkoita, että muutos hylättiin. Se tarkoittaa, että muokkaus päätyi tiedostoon, jota laiteohjelmisto kohtelee tulosteena, ja pysyvä paikka on yksi askel aiemmin käynnistysjärjestyksessä.

Miksi muokattu tiedosto luodaan uudelleen

Käynnistysskripti kokoaa palvelimen määrityksen mallipohjasta ja käynnistää sitten daemonin, mikä tekee renderöidystä tiedostosta koontiversion artefaktin eikä lähteen. Kaikki käynnistyksen jälkeen lisätty on näkymätöntä kyseisen skriptin seuraavalle ajolle. Toinen kuvio on hienovaraisempi: verkkoliittymän avain- ja varmennesyötteet tallennetaan escaped-muodossa, ja lomakkeen tallentaminen voi työntää tuon escaped-tekstin tiedostoon, jonka daemon lukee. Kummassakin tapauksessa renderöity määritys on väärä paikka pysyvälle muutokselle.

Katso, mitä käynnistysjärjestys kirjoittaa ja milloin. Vastaus on lähes aina skripti laiteohjelmiston init- tai autostart-hakemistossa.

Lisää direktiivi sinne, missä skripti rakentaa tiedoston

QTS-laitteet luovat OpenVPN-palvelimen määrityksen uudelleen init-skriptissä, joka käynnistää daemonin, joten muokkauksen on tapahduttava siellä. Lisää liitos välittömästi ennen käynnistyskomentoa sen sijaan, että muokkaisit luotua tiedostoa.

sed -i '/daemon_mgr/i echo client-config-dir clientconfig >>/etc/openvpn/server.conf' /etc/init.d/vpn_openvpn.sh
grep -c client-config-dir /etc/openvpn/server.conf

Ankkuroi lisäys komentoon, joka ei siirry, koska rivinumerot vaihtelevat koontiversioiden välillä. Koska init-skripti itsessään korvataan käynnistyksen aikana, muutos on julkaistava uudelleen laiteohjelmiston autostart-koukusta joka kerta, kun järjestelmä käynnistyy. Yhden uudelleenkäynnistyksen jälkeen laske esiintymät luodusta tiedostosta: yksi rivi tarkoittaa, että paikkaus toimi, kun taas kaksi tarkoittaa, että koukku ajetaan useammin kuin kerran. Tutki kaksoisajo erikseen, sillä se ei ole sama vika kuin kadonnut muutos.

Korjaa lomake, joka tallensi escaped-avaimet

Asus-tyylisillä sivuilla varmenne- ja avainkentät näyttävät escaped-tekstiä, ja tallennus asiaankuulumattoman säädön jälkeen voi kirjoittaa ne entiteetit takaisin levylle. Työskentele dekoodatusta kopiosta ja tallenna vain kerran, kun kaikki muokkaukset ovat valmiita.

openssl dhparam -out dh2048.pem 2048
grep -n "BEGIN DH PARAMETERS" dh2048.pem

Kun vaihdat uuden parametrijoukon, liitä vain base64-hyötykuorma, jos kenttä pyytää avaimen rungon, ja pidä armor-rivit vain silloin, kun kenttä odottaa täyttä PEM-lohkoa. Jo escaped-muotoon tallennetun sivun palauttaminen tarkoittaa yleensä kyseisten syötteiden tyhjentämistä ja soveltamista, mikä antaa laiteohjelmiston rakentaa ne uudelleen. Luo kaikki yli 2048 bitin asiat työasemalla, koska reitittimen entropiansyöttö tekee toimenpiteestä hitaan ja joskus epäluotettavan. Säilytä parametritiedosto paikassa, johon pääset tehdasasetusten palautuksen jälkeen.

Tarkista uudelleen päivitysten jälkeen

Laiteohjelmistopäivitykset korvaavat init-skriptit ja voivat pyyhkiä autostart-hakemiston, joten paikkaus on asennettava ja testattava uudelleen. Vertaa uudelleen luotua tiedostoa säilyttämääsi kopioon ja varmista, että direktiivi on täsmälleen kerran. Verkkoliittymässä näkyvä arvo ei ole todiste siitä, että daemon sai sen, koska sivu lukee tallennettuja kenttiä. Kirjoita paikkauskomento ja laiteohjelmistoversio ylläpitomuistiinpanoihin, jotta seuraava päivitys kuljettaa ne mukanaan.

Yhdistä sitten asiakas ja lue palvelimen lokista työnnetty asetus. Asetus, joka on koskaan ollut vain lomakkeessa, on asetus, jota kukaan ei ole testannut.