Trasa urządzenia OpenVPN: właściciel konfiguracji czy skrypt startowy?
Trasa oddziału, która przetrwa jedno ponowne uruchomienie, nadal może zniknąć po zapisie w GUI lub aktualizacji firmware. Porównaj obsługiwanego właściciela konfiguracji ze skryptem łatającym.
Dodajesz trasę oddziału, działa, a potem aktualizacja firmware lub zapis z interfejsu web usuwa ją. Dwie poprawki wyglądają w tym momencie równie rozsądnie: umieścić trasę w obsługiwanym źródle konfiguracji urządzenia albo dopisać ją do wygenerowanego pliku ze skryptu startowego. Zachowują się tak samo przez tydzień i rozchodzą się przy drugiej aktualizacji. Ten artykuł porównuje, czym każda z nich naprawdę zarządza.
Dwaj kandydaci zarządzają różnymi rzeczami
Obsługiwane źródło konfiguracji to wszystko, co urządzenie traktuje jako wejście: pole GUI, zaimportowany profil, udokumentowany katalog dla klienta, baza ustawień, którą czyta pakiet zarządzający. Wygenerowany server.conf to wyjście. Edycja wyjścia działa, dopóki generator nie uruchomi się ponownie, a to dzieje się przy zapisie, przy ponownym uruchomieniu i przy aktualizacji.
Podejście ze skryptem łata to wyjście po zakończeniu generatora. To legalna technika dla laboratorium i zły domyślny wybór dla oddziału, ponieważ uzależnia trasę od dopasowania tekstu, a nie od udokumentowanego pola.
| Question | Supported config source | Post-generation script |
|---|---|---|
| Survives a GUI save | Yes | Only if the save does not regenerate the file |
| Survives a package upgrade | Usually, when the field is documented | No guarantee; the wrapper can be replaced |
| Supportable by the vendor | Yes | No |
| Obvious to the next admin | Yes, it is in the UI | No, it lives in a wrapper |
Co urządzenie generuje ponownie i kiedy
Pakiety zarządzające zwykle trzymają ustawienia w bazie danych lub zestawie szablonów i renderują konfigurację demona przy starcie. Zapis z interfejsu web często przepisuje cały plik zamiast łatać jedną linię. Jeśli twoja zmiana żyła w tym pliku, teraz jej nie ma, i nic nie zapisuje ostrzeżenia, bo z punktu widzenia urządzenia nic nie zostało utracone.
Nakładki startowe mają drugi tryb awarii. grep dla dyrektywy z określonym odstępem przestaje pasować po zmianie szablonu, a skrypt po cichu nic nie robi. Gorzej, aktualizacja firmware może zastąpić nakładkę nową wersją i zabrać ze sobą łatkę. Wtedy masz trasę, która istniała rok i zniknęła podczas konserwacji, której nikt nie powiązał z routingiem.
Co musi wyrazić obsługiwany właściciel
Prefiks oddziału wymaga trzech stwierdzeń, nie jednego. Klient musi nauczyć się trasy, serwer musi wiedzieć, który uwierzytelniony klient jest właścicielem prefiksu, a strona oddziału musi zwracać ruch na przydzielony jej adres tunelu. W terminach OpenVPN oznacza to wypchnięty route, pasujący iroute powiązany z klientem i drogę powrotną po drugiej stronie.
Tu interfejsy urządzeń wprowadzają w błąd. Pole wyboru z etykietą „zezwól klientom na dostęp do sieci LAN serwera” opisuje ruch w stronę własnej sieci serwera. Twój oddział to przeciwny kierunek: sieć za jednym klientem, osiągalna od strony serwera. Ta sama etykieta nie oznacza wsparcia dla tego, a prawidłowa dyrektywa w pliku nie jest obietnicą, że pakiet ją zachowa.
Gdy nie ma obsługiwanego sterowania
Czasami zainstalowane wydanie naprawdę nie potrafi wyrazić trasy specyficznej dla peera. Wtedy uczciwe opcje to inna brama, którą kontrolujesz, albo obsługiwany tryb lokacja-lokacja po obu stronach. Oba końce muszą go mówić. Strona produktu, która mówi lokacja-lokacja, nie czyni dowolnego profilu OpenVPN wymiennym z tunelem innego protokołu, a wymuszanie tej pary zwykle daje na wpół połączony tunel, który dobrze wygląda na stronie statusu.
Wybierz opcję, którą potrafisz opisać jednym zdaniem temu, kto odziedziczy sieć. Jeśli odpowiedź wymaga wspomnienia ścieżki skryptu i wzorca tekstu, projekt jest już kruchy.
Uczyń intencję audytowalną
Zapisz kontrakt poza urządzeniem: efektywna tożsamość klienta, prefiks, brama powrotna i obsługiwane pole, które każde z nich zapewnia. Eksportuj konfigurację obsługiwanym mechanizmem, aby przebudowa miała odniesienie, i weryfikuj usługę po ponownym połączeniu, restarcie i aktualizacji, a nie tylko po zmianie.
Gdy coś się psuje, porównaj wygenerowany wynik z tym zapisem, zamiast przywracać niewyjaśnioną linię i mieć nadzieję.dokumentacja OpenVPN 2.6 to miejsce, w którym potwierdzisz, jak route i iroute na siebie oddziałują, zanim zaczniesz spierać się z interfejsem.
Lista kontrolna do następnej zmiany: nazwij właściciela, podaj trójdzielny kontrakt, wyeksportuj intencję i przetestuj ponownie po własnych zdarzeniach cyklu życia urządzenia, a nie po swojej edycji.