Czy można przekonwertować konfigurację WireGuard na OpenVPN?

Masz plik wg0.conf i klienta, który przyjmuje tylko .ovpn, więc ktoś sugeruje konwersję pliku. Zmiana nazwy daje profil, którego OpenVPN nie potrafi sparsować, a staranne tłumaczenie pole po polu daje taki, który się parsuje, a potem zawodzi przy uzgadnianiu połączenia. Przyczyną nie jest format pliku. WireGuard i OpenVPN to różne protokoły z różnymi uzgodnieniami, różnymi modelami uwierzytelniania i różnym wyobrażeniem o tym, czym jest peer. Konwersja działa tylko w tym sensie, że można poprosić o profil OpenVPN tego, kto obsługuje drugą stronę.

Plik, który masz, opisuje peera, a nie profil połączenia

Konfiguracja WireGuard jest krótka, bo taki jest protokół: interfejs z kluczem prywatnym i adresami, potem jeden lub więcej peerów z kluczem publicznym, punktem końcowym i listą AllowedIPs. Nie ma warstwy negocjacji do skonfigurowania ani zestawu szyfrów do wyboru.

Profil OpenVPN to klient kanału sterującego opartego na TLS, dlatego zawiera odwołania do certyfikatów lub danych logowania oraz dyrektywy opisujące sposób uwierzytelniania.

Dlaczego przetłumaczony plik nadal zawodzi przy uzgadnianiu

WireGuard zaczyna od uzgadniania opartego na Noise, powiązanego ze statycznymi kluczami peerów, i milczy, dopóki klucz publiczny peera nie jest już znany. OpenVPN otwiera sesję TLS, weryfikuje certyfikat serwera lub klucz statyczny, a następnie uwierzytelnia użytkownika certyfikatami, nazwą użytkownika i hasłem albo jednym i drugim. Nic w pliku WireGuard tego nie opisuje. Przetłumaczony plik miałby właściwy punkt końcowy i wszystko inne błędne.

Ponowne użycie adresu i portu też nie pomoże, bo druga strona nasłuchuje innego pakietu.

O co zapytać dostawcę

Jeśli dostawca dał plik WireGuard, zapytaj, czy to samo konto ma dostęp do OpenVPN, i poproś o ten profil. Wielu ma, a przychodzi on z własnymi danymi logowania, a nie jako zmodyfikowana kopia pierwszego.

Jeśli odpowiedź brzmi nie, ograniczeniem jest subskrypcja, a nie plik, i żaden konwerter tego nie zmieni.

Jeśli router lub klient mówi tylko OpenVPN

Gdy urządzenie, które ma się połączyć, obsługuje tylko OpenVPN, sprawdź udokumentowane wsparcie protokołów drugiej strony, zanim zaczniesz szukać innego rozszerzenia. Routera, który kończy OpenVPN, nie da się przekonać do WireGuard przez import pliku. Realne opcje to punkt końcowy OpenVPN po stronie serwera albo inne urządzenie mówiące WireGuard.

Wybieraj według tego, kto administruje drugą stroną, a nie według tego, jaki plik masz.

Jeśli sam prowadzisz serwer, dodaj protokół

Obsługa drugiego protokołu oznacza uruchomienie drugiej usługi. Na serwerze Linux to instancja OpenVPN z własnym CA, certyfikatem serwera, certyfikatami klientów oraz dyrektywami server i push, wraz z regułą firewalla dla jej portu. Istniejący wpis peera WireGuard nie opisuje żadnego z tych obiektów. Zaplanuj pulę adresów i wypychane trasy osobno od AllowedIPs WireGuarda, bo to nie ten sam mechanizm pod dwiema nazwami.

Potem sprawdź z klienta: profil się ładuje, sesja TLS kończy się, wypychana trasa się pojawia, a ruch dociera do hosta osiągalnego tylko przez tunel.

Gdzie pomysł z konwerterem jest bezpieczny

Ręczne przepisywanie wartości do notatek jest w porządku i często przydatne, bo punkt końcowy, adresy i klucz publiczny peera to po prostu fakty o wdrożeniu. Wysyłanie klucza prywatnego na stronę, która obiecuje konwersję, nie jest w porządku, bo ten klucz to dane logowania, a usługa nie ma protokołu, na który miałaby go przekonwertować. Jeśli potrzebujesz tego samego dostępu z klienta OpenVPN, poproś o dane logowania OpenVPN.

Trzymaj obie konfiguracje obok siebie i traktuj je jako osobne ścieżki dostępu, bo nimi są.