Zmiana nazwy pliku .visz z Viscosity na .ovpn nie zmienia jego zawartości, ponieważ rozszerzenie nigdy nie opisywało protokołu. Istotne porównanie dotyczy pakietu z zależnościami i zwykłego profilu klienta bez żadnych. Ustal, który kontener naprawdę otrzymałeś, zanim poprosisz importer w systemie Linux o jego odczytanie.

Co zawiera każdy kontener

Dokumentacja eksportu Viscosity opisuje pakiet połączenia .visc oraz formę archiwum .visz, czyli skompresowane archiwum tar. Pakiet niesie konfigurację wraz z plikami certyfikatu, klucza i skryptów, od których zależy. Zwykły profil OpenVPN to jeden plik, a wszystko, do czego się odwołuje, musi istnieć osobno lub być osadzone wewnątrz.

Ta różnica to całe porównanie. Relacje pakietu są częścią artefaktu; relacje zwykłego profilu są założeniem. Przeniesienie pakietu do Linuksa bez zachowania tych relacji daje plik, który się otwiera, a następnie zawodzi przy pierwszym brakującym odwołaniu. Profil, który osadza swoje certyfikaty, unika tego błędu, przenosząc wszystko w jedno miejsce, co jest wygodne, dopóki ktoś nie musi wymienić jednego z nich.

Zewnętrzne rozszerzenie mówi, który kontener masz, a nie który klient może go użyć.

Gdzie konfiguracja naprawdę się zaczyna

Wewnątrz pakietu dostawca dokumentuje plik config.conf obok plików zależnych, a odwołania są rozwiązywane lokalnie. Ten plik jest punktem wyjścia, a nie nazwa archiwum i nie ten certyfikat, który przypadkiem znajduje się na górze listy katalogu.

W systemie Linux pakiet może pojawić się jako katalog, a nie jako jeden obiekt, ponieważ archiwum rozpakowuje się do plików, które oczekują wspólnej lokalizacji. Utrzymuj spójne ścieżki względne w obszarze roboczym, do którego rozpakowujesz, i nie zamieniaj ręcznie bezwzględnej ścieżki Windows na ścieżkę Linuksa. Brakujący plik zależny i błędna ścieżka wywołują tę samą skargę klienta.

Usunięcie opcji zaufania lub tożsamości, aby uciszyć tę skargę, nie jest poprawką.

Czego pakiet nie przenosi

Własne preferencje Viscosity nie są wszystkimi opcjami OpenVPN. Skrypty, zachowanie tras i ustawienia aplikacji mogą wymagać przedstawienia przez obsługiwaną integrację klienta Linuksa, zamiast kopiowania ich jako tekstu, który może wykonać inny program.

Traktuj każdy dołączony skrypt jak dane, dopóki go nie przeczytasz i nie zdecydujesz, że jest dozwolony. Uruchamianie go dlatego, że eksport go zawierał, odwraca przegląd, który powinieneś był przeprowadzić. Ta sama ostrożność dotyczy osadzonych danych logowania: pakiet może nieść materiał klucza prywatnego, więc kopia robocza należy do chronionego miejsca, a nie do folderu pobierania.

Oryginał pozostaje chroniony, dopóki migracja nie zostanie zaakceptowana.

Co musi zdecydować strona Linuksa

Zdecyduj, kto będzie właścicielem połączenia: samo Community OpenVPN, wtyczka NetworkManager czy inny obsługiwany klient. Każdy akceptuje inny zestaw opcji i każdy inaczej zarządza trasami, resolverami i sekretami. Plik, który pomyślnie otwiera się w jednym importerze, może zostać odrzucony przez inny, a powodzenie importu nie dowodzi zgodności z zamierzonym połączeniem. Zapytaj operatora, czy istnieje już profil zgodny z Linuksem, ponieważ rozpoczęcie od obsługiwanego artefaktu jest krótsze niż przetłumaczenie go.

Trzymaj zaufanie do serwera, tożsamość klienta i ochronę klucza prywatnego jako trzy osobne pytania.

Przegląd przed połączeniem

Sprawdź punkt końcowy i transport, metodę uwierzytelniania, każde odwołanie do pliku oraz zamierzoną politykę tras i DNS. Następnie zweryfikuj połączenie i wymaganą aplikację niezależnie, ponieważ tunel, który wstaje, nic nie mówi o tym, czy aplikacja dociera do tego, czego potrzebuje.

openvpn --config ./config.conf --verb 4

Porównaj wynegocjowany wynik z tym, co według operatora profil powinien robić, i zanotuj każdą opcję, którą klient Linuksa zignorował.

Gdy migracja zostanie zaakceptowana, wycofaj kopie transferowe przez zwykły proces postępowania z danymi logowania. Pakiet pozostawiony w udostępnionym folderze to dane logowania pozostawione w udostępnionym folderze.

Powiązane artykuły