Publiczna konfiguracja VPN przestała działać? Przeczytaj etap awarii

Profil działał we wtorek, a w piątek klient kręci się przez trzydzieści sekund i poddaje. Na twoim komputerze nic się nie zmieniło. Właśnie o to chodzi: pobrana konfiguracja opisuje jeden host w jednej chwili, a operator po drugiej stronie nie ma obowiązku utrzymywać tego opisu w prawdzie. Pokusa jest taka, żeby zacząć zmieniać ustawienia bezpieczeństwa, aż tunel wróci. Właśnie ten odruch sprawia, że ludzie kończą z profilem i wyłączoną weryfikacją certyfikatów, co jest gorsze niż brak jakiegokolwiek tunelu.

Plik opisuje chwilę, nie umowę

Plik konfiguracji to zbiór założeń: ta nazwa hosta nasłuchuje na tym porcie z tym protokołem, przedstawia certyfikat pasujący do tej nazwy i akceptuje te dane logowania. Gdy którekolwiek z nich przestaje być prawdziwe, plik jest nieaktualny, a naprawa należy do strony operatora za granicą, nie do twoich ustawień.

Publiczne listy węzłów czynią to oczywistym ze swojej natury. Węzły prowadzą wolontariusze, pojawiają się i znikają, adresy są recyklingowane, a porty blokuje sieć, za którą się znajdują. Lista jest migawką, która jest generowana na nowo, a kopia na twoim dysku to fotografia starszej migawki.

Usługi komercyjne zmieniają się wolniej, ale nie nigdy. Urzędy certyfikacji rotują, nasłuchujący przenosi się ze współdzielonego adresu na dedykowany, stary protokół jest wycofywany i pojawia się nowa lista szyfrów. Każda z tych zmian jest niewidoczna, dopóki twój klient nie spróbuje się połączyć i nie dostanie innej odpowiedzi niż oczekuje plik.

Przeczytaj etap awarii, zanim dotkniesz ustawienia

Komunikat błędu mówi, które założenie się rozsypało, a każde założenie ma zupełnie inną naprawę. Edytowanie szyfrów, gdy nazwa hosta już się nie rozwiązuje, marnuje popołudnie i nikogo niczego nie uczy.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Środkowa linia oddziela zablokowaną ścieżkę od zepsutego uzgadniania, a trzecia pokazuje wystawcę i daty ważności certyfikatu, który jest faktycznie przedstawiany. Jeśli ten wystawca nie jest tym, który przypiął profil, certyfikat się zmienił i żadna opcja po stronie klienta nie sprawi, że stare przypięcie znów będzie poprawne.

Zmiany certyfikatu i tożsamości są tymi cichymi

Większość awarii sama się ogłasza. Zmiany tożsamości nie, bo klient przypinający nazwę certyfikatu odrzuci całkiem dobry nowy certyfikat z komunikatem, który wielu czyta jako błąd oprogramowania. Tunel jest w porządku. Przypięcie jest nieaktualne.

Zanim cokolwiek wywnioskujesz, poszukaj opcji tożsamości:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Jeśli profil zawiera wbudowane CA, a operator przeszedł na nowy urząd, stary plik nie może zweryfikować nowego serwera. Zastąpienie bloku CA tym opublikowanym przez operatora to uzasadniona naprawa. Usunięcie dyrektywy weryfikacji już nie, i to te same naciśnięcia klawiszy z zupełnie innym skutkiem.

Aktualizacja klienta może wywołać ten sam objaw bez żadnej zmiany u operatora. Opcje, które były po cichu tolerowane, są teraz odrzucane, albo przestarzały protokół jest usuwany. To granica zgodności w twoim oprogramowaniu i warto sprawdzić drugi profil na tym samym kliencie, zanim obwinisz serwer.

Tylko operator może opublikować ważne zastępstwo

Gdy węzeł znika, zastępstwo musi pochodzić z tego samego źródła, które opublikowało oryginał. Profil, który przychodzi w wiadomości bezpośredniej, bo „używa tej samej nazwy serwera”, jest niezweryfikowaną konfiguracją od nieznanej strony, a jego import daje tej stronie kontrolę nad twoim trasowaniem.

Sprawdzenie jest tanie. Pobierz aktualny plik z opublikowanej lokalizacji, porównaj punkt końcowy i protokół z listą, i potwierdź odcisk materiału CA, zamiast ufać nazwie pliku:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Jeśli dwa skróty różnią się tylko białymi znakami, masz zmianę formatowania. Jeśli różnią się punktami końcowymi, operator coś przeniósł i opublikowany plik jest autorytetem. Jeśli opublikowany plik jest starszy od twojego, prawdopodobnie patrzysz w pamięć podręczną, a nieaktualna odpowiedź wyśle cię w złym kierunku.

Wycofaj stary wpis i zapisz, co się stało

Po zweryfikowaniu działającego zastępstwa usuń stary profil, zamiast trzymać go jako rezerwę. Nieaktualny wpis, który łączy się połowicznie, to pułapka: zostanie wybrany podczas awarii, będzie zawodził powoli, a osoba diagnozująca spędzi pierwsze dziesięć minut na złym pliku.

Prowadź krótką notatkę poza konfiguracją: datę, stary punkt końcowy, etap awarii i co go zastąpiło. Publiczne węzły się zmieniają, a sześć tygodni później to samo pytanie wraca z inną osobą. Jedna linia w pliku notatek odpowiada na nie w kilka sekund.

Jeśli z jednej sieci każdy węzeł zawodzi w ten sam sposób a z innej żaden, przestań edytować profile i spójrz na lokalną ścieżkę. Portal przechwytujący, filtrowany zakres portów lub przechwytujące proxy dadzą identyczne błędy u niepowiązanych dostawców, i właśnie ten wzorzec jest jedynym sygnałem, że problemem nigdy nie był plik.