Przenośność profilu OpenVPN: przenośne klucze kontra opcje platformy

Ten sam plik .ovpn otwiera tunel w jednym kliencie, a w innym nie startuje, i to certyfikat jest zwykle pierwszym podejrzanym. Częściej plik zawiera dyrektywę, którą implementuje tylko jeden silnik. Profil to umowa z konkretnym klientem, a nie przenośny skrypt.

Oddziel to, co podróżuje z tożsamością, od tego, co należy do platformy. Wtedy awaria zwykle nazywa się sama.

Jeden plik, dwie umowy

Profil łączy trzy rodzaje treści: materiał tożsamości, taki jak certyfikaty CA i klienta oraz klucz prywatny, fakty transportowe, takie jak zdalny punkt końcowy i protokół, oraz dyrektywy zachowania, takie jak obsługa DNS czy opcje urządzenia. Pierwsze dwa są szeroko przenośne między silnikami obsługującymi ten sam protokół. Trzeci to miejsce, w którym implementacje się rozchodzą. Traktowanie całego pliku jako jednej przenośnej jednostki właśnie tworzy mylące awarie.

Plik, który działa w GUI na jednej platformie, nie jest automatycznie ważny dla klienta wiersza poleceń na innej. Nawet gdy oba to OpenVPN, parsery i zestawy opcji się różnią. Dlatego udany import nie jest dowodem przenośnego profilu.

Materiał przenośny a dyrektywy platformy

Sekcje tożsamości i transportu to część, którą należy zachować. ca, cert, key i remote opisują, kto się łączy i dokąd, i znaczą to samo dla każdego zgodnego klienta.

Dyrektywy zachowania to część, którą trzeba porównać. block-outside-dns na przykład istnieje, aby zmienić zachowanie DNS w Windows. Klient Unix może jej w ogóle nie rozpoznać.

Czytaj listę opcji klienta odbierającego, a nie wysyłającego. Podręcznik referencyjny OpenVPN 2.6 dokumentuje opcje silnika, a okno importu w GUI nie jest tą listą.

Najpierw błąd parsera, potem certyfikat

Błąd wskazujący nierozpoznaną opcję to awaria parsera, nie awaria uwierzytelniania. Połączenie nigdy nie dotarło do TLS, więc zmiana certyfikatów nie pomoże. Przeczytaj pierwszy błąd rzeczywistego klienta i wersji, a następnie usuń lub zastąp tylko tę dyrektywę, której ten klient nie potrafi zaimplementować. Usuwanie sekcji certyfikatu lub tras, aby plik się wczytał, to droga, na której działający profil staje się niebezpieczny.

Jeśli błąd wspomina uścisk dłoni, certyfikat lub szyfr, profil został sparsowany i problem jest gdzie indziej.

Zachowaj oryginalny plik obok dostosowanego. Gdy dostosowany plik później zawiedzie, oryginał jest kontrolą, która mówi, czy zmieniła się zmiana, czy środowisko.

Uprawnienia to druga granica

Uprawnienia to druga granica: utworzenie urządzenia tunelowego, instalacja tras i odczyt klucza prywatnego zależą od lokalnych uprawnień. Plik klucza czytelny tylko dla roota to normalne wdrożenie, a nie wada profilu. Poprawka należy do własności lub uprawnień, nie do pliku.

Uruchomienie klienta przez sudo może rozwiązać lokalną odmowę uprawnień i nie może dodać dyrektywy, której binarka nie implementuje. Zmienia też to, czyj pęk kluczy, ścieżki konfiguracji i kontekst menedżera sieci obowiązują, więc wynik nie jest tym samym testem.

Dostosowuj świadomie

Gdy dostawca publikuje osobne profile, weź ten przeznaczony dla klienta odbierającego. Dostosowanie pliku innej platformy to ostateczność. Wymaga zapisu każdej zmienionej opcji i kopii oryginału.

Testuj tożsamość, routing i DNS jako trzy osobne wyniki. Profil, który uwierzytelnia i routuje, ale psuje rozwiązywanie nazw, jest częściowo dostosowanym profilem, a nie działającym.