Jak zweryfikować serwer profilu OpenVPN przed jego importem

Ktoś wysyła ci profil, importujesz go, a trzydzieści sekund później klient wybiera cel, którego nikt nie sprawdził. Najpierw przeczytaj plik w edytorze tekstu, bo wszystko, co istotne, mieści się w garści dyrektyw: remote, proto, port, ca, cert, tls-crypt i verify-x509-name. Wszystko inne to wartości domyślne i właśnie tam mieszkają niespodzianki.

Wypisz każdy punkt końcowy, którego plik może użyć

Zacznij od punktów końcowych, bo jeden profil może zawierać kilka. grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn wypisuje każdego kandydata w kolejności pliku, włącznie z tymi zagnieżdżonymi w blokach <connection>.

Gdy dyrektywa pomija port, klient wraca do wartości domyślnej nasłuchu, więc samo remote vpn.example.com oznacza port 1194 z dowolnym proto, który pojawi się później w pliku. Kilka zwykłych linii remote to alternatywy: klient próbuje ich po kolei, chyba że remote-random je przetasuje, i nigdy po cichu nie podmienia hosta innego operatora. Dwie linie remote w niepowiązanych domenach to miejsce, w którym zatrzymujesz się i pytasz, która była zamierzona.

Zwróć uwagę także na pisownię proto. tcp jest akceptowany jako synonim tcp-client po stronie klienta, ale tcp-server w profilu klienta to błąd konfiguracji, który zwykle zawiesza się zamiast czysto zawodzić.

Najpierw potwierdź nazwę, potem port

dig +short vpn.example.com mówi ci, czy nazwa istnieje i jakie adresy zwraca, a punkt końcowy z wieloma adresami lub za proxy może legalnie zwrócić kilka. Rozwiązanie nazwy jest warunkiem wstępnym, nie dowodem własności; każdy może wskazać nazwę na adres, a jeden adres może odpowiadać za wiele nazw.

Następnie sprawdź nasłuch na znalezionym porcie, zgodnie z warstwą transportową. Po TCP openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com wypisuje łańcuch przedstawiany przez serwer. Po UDP potrzebujesz DTLS: openssl s_client -dtls1_2 -connect vpn.example.com:1194 wykonuje to samo uzgadnianie przez datagramy. Ukończone uzgadnianie dowodzi, że coś nasłuchuje i ma certyfikat, co jest więcej niż pokazuje ping i mniej niż wymagają własne ustawienia zaufania profilu.

Gdy uzgadnianie zawodzi, a host odpowiada na ping, port jest prawdopodobnie zły lub filtrowany. Potraktuj to jako powód, by poprosić o właściwy port, a nie zaproszenie do przeszukania sąsiednich. nc -vzu również zgłasza sukces na niektórych stosach, gdy nic nie nasłuchuje, więc goła próba UDP nic nie znaczy bez uzgadniania za nią.

Czytaj pinezki zaufania osobno od adresu

Adres decyduje, dokąd idzie klient; blok zaufania decyduje, komu wierzy po przybyciu. verify-x509-name "vpn.example.com" name przypina nazwę pospolitą podmiotu, a remote-cert-tls server wymaga rozszerzonego użycia klucza do uwierzytelniania serwera. Profil przekazany przez operatora powinien mieć oba.

Szukaj ca, wbudowanego bloku <ca> oraz tls-crypt albo tls-auth. Profil używający tls-auth wymaga key-direction 1 na kliencie, gdy strona serwera używa kierunku 0, a niezgodność wywala uzgadnianie błędem TLS, który czyta się jak usterka certyfikatu. Wbudowany CA, który nie należy do operatora, którego nazwę właśnie rozwiązałeś, oznacza, że plik złożono z dwóch źródeł, i to jest przypadek wart kategorycznego odrzucenia.

verify-x509-name przyjmuje tryby name, name-prefix lub subject, a ostatni oczekuje pełnej nazwy wyróżniającej w dokładnie takiej kolejności, w jakiej drukuje ją serwer. Wybierz tryb pasujący do kształtu wartości, bo klient odrzuca każde połączenie zamiast ostrzegać o niemal trafieniu. Dla pliku, którego nie napisałeś, name z prostą nazwą hosta to najmniej zaskakujący wybór.

Sprawdź opcje, które zawodzą po cichu

OpenVPN 2.6 negocjuje szyfry przez data-ciphers, a profil zawierający tylko stary wiersz cipher AES-256-CBC może ukończyć kanał sterujący, a potem zaciąć się na danych. Odczytanie tej wartości mówi ci, czy plik jest starszy od serwera, do którego dołączasz; strona podręcznika wersji 2.6 wymienia kolejność negocjacji, jeśli musisz ją zacytować operatorowi.

auth-user-pass bez nazwy pliku oznacza, że klient zapyta, więc profil wyglądający na samowystarczalny nadal potrzebuje danych logowania. auth-user-pass credentials.txt oznacza, że oczekuje pliku, którego prawdopodobnie ci nie wysłano. nobind i resolv-retry infinite są zwyczajne i nieszkodliwe, natomiast explicit-exit-notify jest tylko dla UDP i bezsensowny przez TCP.

Żadna z tych rzeczy nie zmienia, dokąd łączy się profil, ale każda zmienia, czy w ogóle się połączy, i żadna nie jest widoczna w oknie importu klienta.

Zdecyduj, a potem zapisz, co zdecydowałeś

Po tym czytaniu są trzy wyniki i tylko jeden to import. Gdy punkt końcowy i pinezki zgadzają się z instrukcjami otrzymanymi innym kanałem, zaimportuj go. Gdy punkt końcowy wygląda dobrze, ale pinezki lub CA się nie zgadzają, poproś o poprawiony plik. Gdy plik miesza punkty końcowe lub materiał CA z różnych źródeł, usuń go i poproś o świeżą kopię.

Zapisz hash, który przejrzałeś, aby następna osoba wiedziała, czy plik się zmienił: sha256sum profile.ovpn, wklejony obok punktu końcowego w twoich notatkach. Profil to cały układ, nie lista adresów, więc nigdy nie wstawiaj działającego remote do cudzego bloku zaufania, zachowując jego dane logowania.

Trzymaj klucze prywatne i hasła poza zrzutami ekranu i wątkami czatu, gdy porównujesz notatki. Punkt końcowy i opcje niebędące sekretami wystarczą, by zadać precyzyjne pytanie, a reszta należy do pliku.

Jeśli jednak go zaimportujesz i pierwsza próba zawiedzie, uruchom klienta z --verb 3 i przeczytaj pierwszych dziesięć wierszy: rozwiązany adres remote, wynegocjowany proto i błąd TLS pojawiają się w tej kolejności, co mówi ci, które z powyższych sprawdzeń pominąłeś.