Ustawienia OpenVPN na routerze wracają po restarcie: napraw generator

Firmware routera konsumenckiego lub NAS często przy każdym starcie odbudowuje konfigurację OpenVPN, więc dodana dyrektywa przetrwa dokładnie do następnego uruchomienia. To samo dotyczy kluczy wpisanych w formularz sieciowy, gdzie zapisana wartość może wrócić zniekształcona po zapisaniu. Żaden z tych objawów nie oznacza, że zmiana została odrzucona. Oznacza, że edycja trafiła do pliku, który firmware traktuje jako wyjście, a trwałe miejsce znajduje się o krok wcześniej w sekwencji startowej.

Dlaczego edytowany plik jest generowany od nowa

Skrypt startowy składa konfigurację serwera z szablonu, a następnie uruchamia demona, co czyni wyrenderowany plik artefaktem kompilacji, a nie źródłem. Wszystko dodane po starcie jest niewidoczne dla następnego uruchomienia tego skryptu. Drugi wzorzec jest subtelniejszy: pola klucza i certyfikatu w interfejsie sieciowym są zapisywane w formie z escapowaniem, a zapisanie formularza może wepchnąć tenzescapowany tekst do pliku, który czyta demon. W obu przypadkach wyrenderowana konfiguracja to złe miejsce na trwałą zmianę.

Spójrz, co zapisuje sekwencja startowa i kiedy. Odpowiedzią jest prawie zawsze skrypt w katalogu init lub autostartu firmware.

Wstaw dyrektywę tam, gdzie skrypt buduje plik

Urządzenia QTS regenerują konfigurację serwera OpenVPN wewnątrz skryptu init, który uruchamia demona, więc edycja musi nastąpić tam. Dodaj dopisanie bezpośrednio przed poleceniem startu, zamiast edytować wygenerowany plik.

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

Zakotwicz wstawienie na poleceniu, które się nie przesunie, ponieważ numery linii zmieniają się między kompilacjami. Ponieważ sam skrypt init jest podmieniany podczas startu, zmianę trzeba ponownie wydać z haka autostartu przy każdym uruchomieniu systemu. Po jednym restarcie policz wystąpienia w wygenerowanym pliku: jedna linia oznacza, że poprawka zadziałała, a dwie oznaczają, że hak działa więcej niż raz. Zbadaj podwójne uruchomienie osobno, bo to nie jest ta sama usterka co znikająca zmiana.

Napraw formularz, który zapisał zakodowane klucze

Na stronach w stylu Asus pola certyfikatu i klucza pokazują tekst z escapowaniem, a zapis po niepowiązanej korekcie może zapisać te encje z powrotem na dysk. Pracuj na zdekodowanej kopii i zapisuj tylko raz, gdy wszystkie zmiany będą gotowe.

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

Przy podmianie nowego zestawu parametrów wklej tylko ładunek base64, jeśli etykieta prosi o treść klucza, a linie zbroi zachowaj tylko wtedy, gdy pole oczekuje pełnego bloku PEM. Odzyskanie strony zapisanej już w formie z escapowaniem zwykle oznacza wyczyszczenie dotkniętych pól i zastosowanie, co pozwala firmware odbudować je ponownie. Generuj wszystko powyżej 2048 bitów na stacji roboczej, bo zapas entropii routera czyni operację wolną i czasem zawodną. Przechowuj plik parametrów w miejscu, do którego dotrzesz po resecie fabrycznym.

Sprawdź ponownie po aktualizacjach

Aktualizacje firmware podmieniają skrypty init i mogą wyczyścić katalog autostartu, więc poprawkę trzeba ponownie zainstalować i przetestować. Porównaj ponownie wygenerowany plik z zachowaną kopią i potwierdź, że dyrektywa występuje dokładnie raz. Wartość widoczna w interfejsie sieciowym nie jest dowodem, że demon ją otrzymał, bo strona czyta zapisane pola. Zapisz polecenie poprawki i wersję firmware w notatkach serwisowych, aby następna aktualizacja je przeniosła.

Następnie podłącz klienta i przeczytaj w dzienniku serwera informację o przekazanej opcji. Ustawienie, które kiedykolwiek istniało tylko w formularzu, jest ustawieniem, którego nikt nie przetestował.