Większość ludzi zakłada, że plik .ovpn konfiguruje VPN. Tak nie jest: konfiguruje jednego klienta, a wszystko, czego wymaga, musi już istnieć po drugiej stronie. Zmiana wiersza w pliku może zmienić to, czego próbuje twoja maszyna, nigdy to, co oferuje serwer. Ta różnica wyjaśnia większość zamieszania wokół profili, których nie można zaimportować ani połączyć.

Czytaj plik jak listę żądań adresowanych do twojego klienta, a większość jego wierszy stanie się oczywista.

Plik opisuje twojego klienta, a nie serwer

Profil łączy punkt końcowy remote, transport, typ interfejsu, materiał tożsamości i dowolne zachowanie po stronie klienta, którego chce operator. Każdy wiersz jest wykonywany przez klienta przy starcie. Żaden z nich nie dociera do serwera jako zmiana konfiguracji i żaden nie może utworzyć nasłuchu, który już nie działa. Profil, który podaje TCP 443 wobec serwera nasłuchującego tylko na UDP 1194 zawodzi już przy pierwszym pakiecie.

Dlatego ten sam plik zachowuje się różnie na dwóch klientach: plik prosi, a klient decyduje, jaką część żądania może spełnić.

Wiersze transportu muszą odpowiadać nasłuchowi, który już istnieje

proto i remote muszą zgadzać się z tym, co serwer faktycznie wiąże. UDP to zwykły wybór, bo utracony datagram nie zatrzymuje tunelu, podczas gdy TCP może przetrwać restrykcyjne sieci kosztem blokowania nagłówka kolejki wewnątrz tunelu. Przełączenie profilu z UDP na TCP nie sprawia, że serwer przyjmie TCP; sprawia tylko, że klient wysyła do portu, którego nikt nie czyta.

Port 443 jest popularny, bo przechodzi przez sieci, które nie pozwalają prawie na nic innego, i pozostaje sesją OpenVPN, a nie żądaniem HTTPS. Jeśli operator publikuje kilka remote wierszy, klient próbuje ich po kolei, co jest listą przełączania awaryjnego, a nie decyzją o równoważeniu obciążenia. Zachowaj kombinacje dostarczone przez operatora zamiast mieszać host z jednego wpisu z portem z innego.

Wbudowane klucze zmieniają sposób obchodzenia się z plikiem

Certyfikaty i klucze mogą być wbudowane między znacznikami <ca>, <cert> i <key>, albo wskazane jako osobne pliki. Wbudowany materiał czyni profil samowystarczalnym i jednocześnie czyni go tajemnicą, bo prywatny klucz klienta podróżuje w jego wnętrzu. Certyfikat CA jest publicznym materiałem zaufania i można go bezpiecznie udostępniać; klucz prywatny nie, nawet gdy wygląda jak nieczytelny blok tekstu.

Hasło chroniące klucz jest osobną tajemnicą od hasła konta, a ich pomylenie daje błąd uwierzytelniania, który wygląda jak nieprawidłowe dane logowania.

Trasy i DNS mogą wcale nie pochodzić z pliku

Routing może być wypychany przez serwer, ustawiany przez profil poleceniem redirect-gateway, albo pozostawiony własnym domyślnym wartościom klienta. Pobrany plik nie określa więc w pełni, dokąd pójdzie ruch po podniesieniu tunelu. Gdy nazwy wewnętrzne się rozwiązują, a publiczne witryny nie, polityka tunelu dzielonego robi to, do czego została zaprojektowana, a nie zawodzi.

DNS działa według tego samego wzorca: wypchnięty dhcp-option DNS może zostać zastosowany przez klienta, zignorowany albo nadpisany przez lokalnego menedżera resolvera. Sprawdź stan resolvera po połączeniu, zamiast czytać profil ponownie.

Nieobsługiwane opcje to kwestia wersji klienta

Ostrzeżenia przy imporcie zwykle oznaczają, że klient nie implementuje danej dyrektywy, a nie że plik jest uszkodzony. Klienci desktopowi mogą uruchamiać skrypty i wtyczki w ramach udokumentowanych kontroli, natomiast klienci mobilni akceptują węższy zestaw i mogą po cichu odrzucać wiersze, których nie rozumieją. Ustawienie szyfru lub TLS, którego starszy klient odmawia, to problem wersji do rozwiązania z operatorem. Włączanie nieznanych uprawnień, by wymusić import, wymienia ostrzeżenie na szerszą powierzchnię ataku.

Zachowaj oryginalny plik do porównania, zapisz w prośbie dokładną nieobsługiwaną dyrektywę i poproś o profil zbudowany dla klienta, którego naprawdę używasz.

Po każdej wymianie sprawdź, którego wpisu profilu używa aplikacja, bo import nowego pliku nie zawsze nadpisuje stary.

Powiązane artykuły