OpenVPN-inställningar på routern återställs efter omstart: reparera generatorn

Firmware på en konsumentrouter eller NAS bygger ofta om OpenVPN-konfigurationen vid varje start, så ett direktiv du lägger till överlever exakt till nästa start. Samma sak gäller nycklar som skrivs in i ett webbformulär, där det sparade värdet kan komma tillbaka skadat efter en sparning. Inget av dessa symtom betyder att ändringen avvisades. Det betyder att ändringen hamnade i en fil som firmware behandlar som utdata, och att den varaktiga platsen ligger ett steg tidigare i startsekvensen.

Varför den redigerade filen genereras på nytt

Ett startskript sätter ihop serverkonfigurationen från en mall och startar sedan daemonen, vilket gör den renderade filen till en byggartefakt i stället för en källa. Allt som läggs till efter starten är osynligt för nästa körning av det skriptet. Det andra mönstret är subtilare: nyckel- och certifikatinmatning i webbgränssnittet lagras i escapad form, och en sparning av formuläret kan trycka in den escapade texten i filen som daemonen läser. Hur som helst är den renderade konfigurationen fel plats för en varaktig ändring.

Titta på vad startsekvensen skriver och när. Svaret är nästan alltid ett skript i firmwarens init- eller autorun-katalog.

Infoga direktivet där skriptet bygger filen

QTS-enheter återgenererar OpenVPN-serverkonfigurationen inne i init-skriptet som startar daemonen, så ändringen måste ske där. Lägg till tillägget direkt före startkommandot i stället för att redigera den genererade filen.

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

Förankra infogningen på ett kommando som inte flyttar sig, eftersom radnummer ändras mellan byggen. Eftersom init-skriptet självt ersätts vid starten måste ändringen utfärdas igen från firmwarens autorun-krok varje gång systemet startar. Efter en omstart räknar du förekomsterna i den genererade filen: en rad betyder att patchen fungerade, medan två betyder att kroken körs mer än en gång. Undersök dubbelkörningen separat, för det är inte samma fel som en ändring som försvann.

Reparera ett formulär som sparade escapade nycklar

På sidor i Asus-stil visar certifikat- och nyckelfälten escapad text, och en sparning efter en orelaterad justering kan skriva tillbaka dessa entiteter till disken. Arbeta från en avkodad kopia och spara bara en gång, när alla ändringar är klara.

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

När du byter in en ny parameteruppsättning klistrar du bara in base64-nyttolasten om fältet ber om nyckelns kropp, och behåller armor-raderna bara när fältet förväntar sig ett fullständigt PEM-block. Att rädda en sida som redan sparats i escapad form innebär vanligtvis att tömma de berörda fälten och tillämpa, vilket låter firmware bygga dem igen. Generera allt över 2048 bitar på en arbetsstation, eftersom routerns entropitillförsel gör operationen långsam och ibland opålitlig. Förvara parameterfilen på en plats du kan nå efter en fabriksåterställning.

Kontrollera igen efter uppgraderingar

Firmwareuppdateringar ersätter init-skript och kan radera autorun-katalogen, så patchen måste installeras och testas igen. Jämför den återgenererade filen med kopian du behöll och bekräfta att direktivet finns exakt en gång. Ett värde som syns i webbgränssnittet är inte bevis för att daemonen fick det, eftersom sidan läser sparade fält. Skriv patchkommandot och firmwareversionen i underhållsanteckningarna så att nästa uppdatering tar dem vidare.

Anslut sedan en klient och läs serverloggen för det pushade alternativet. En inställning som bara någonsin funnits i ett formulär är en inställning som ingen har testat.