OpenVPN: uruchomienie pliku .ovpn w systemie Linux i zrozumienie błędu

Otrzymałeś plik .ovpn, uruchamiasz OpenVPN na maszynie wirtualnej Debian lub Ubuntu, a terminal pokazuje błąd lub utknął przed połączeniem. Plik może być ważny, wskazując na brakujący certyfikat, filtr portów lub trasę, która przerywa twoją sesję SSH. Sprawdź profil, zanotuj pierwszy błąd, a następnie zweryfikuj trasę i wewnętrzną usługę po połączeniu.

Przeczytaj plik .ovpn przed uruchomieniem OpenVPN

Zachowaj lokalny terminal, terminal dostawcy, iDRAC/IPMI lub już zweryfikowaną oddzielną sieć zarządzania. Rozpocznij test z tego niezależnego dostępu. redirect-gateway może być zapisane w pliku lub przesyłane przez serwer po połączeniu. Trasa domyślna może wtedy przechodzić przez tunel. Druga sesja SSH korzystająca z tej samej trasy nie jest dostępem awaryjnym.

Jeśli jesteś połączony przez SSH przed testem, wyświetl i zanotuj adres klienta. Z terminala kontrolnego używanego po połączeniu, przedefiniuj ten adres przed sprawdzeniem trasy. Terminal odzyskiwania umożliwia powrót na serwer, nie gwarantuje jednak, że twoja sesja SSH pozostanie otwarta.

# W sesji SSH przed uruchomieniem:
printf '%sn' "$SSH_CLIENT"
# W terminalu kontrolnym po połączeniu:
SSH_CLIENT_IP='198.51.100.42' # zamień na zanotowany adres klienta
ip route get "$SSH_CLIENT_IP"

Umieść plik w katalogu zarezerwowanym dla twojego konta i ogranicz jego prawa, jeśli klucze są wbudowane. Nie umieszczaj ani identyfikatora, ani hasła w pliku demonstracyjnym czy w repozytorium Git.

mkdir -p ~/vpn-test
install -m 600 /ścieżka/otrzymanego/client.ovpn ~/vpn-test/client.ovpn
cd ~/vpn-test
grep -nE '^[[:space:]]*(remote|proto|port|ca|cert|key|pkcs12|tls-auth|tls-crypt|tls-verify|auth-user-pass|auth-user-pass-verify|redirect-gateway|redirect-private|route|route-ipv6|route-gateway|route-table|route-noexec|route-nopull|pull-filter|config|plugin|script-security|up|down|route-up|route-pre-down|ipchange|dns-updown|management|daemon|log|log-append|syslog|status|writepid|askpass|cd|chroot|user|group|learn-address|client-connect|client-disconnect)' client.ovpn

To odczytanie pokazuje zdalnego hosta, protokół, pliki certyfikatów i sposób uwierzytelniania bez wyświetlania ich treści. Jeśli config ładuje inny plik, przeczytaj go z katalogu profilu, powtórz ten filtr i śledź każdy config aż do ostatniego pliku. Cały łańcuch musi być zrozumiany przed uruchomieniem. up, down, route-up, route-pre-down, ipchange i tls-verify uruchamiają polecenia zewnętrzne. plugin ładuje bibliotekę w procesie OpenVPN. management otwiera interfejs kontrolny, który nie może być narażony. Profil klienta, który zawiera learn-address, client-connect, client-disconnect lub auth-user-pass-verify jest odrzucany w tym diagnozowaniu. Zatrzymaj się również, jeśli którąkolwiek inną trasę jest nieznana. Zewnętrzne skrypty wymagają wartości script-security równej 2 lub 3, wartość którą profil może ustalić sam. Sprawdź również auth-user-pass: bez argumentu OpenVPN poprosi o dane logowania na prompt; z ścieżką, odczyta ten plik i przekaże jego treść do serwera profilu. Uruchamianie z sudo pozostaje normalne dla tworzenia interfejsu i tras, ale żaden plik referencyjny nie powinien być nieznany.

# Dla każdej trasy znalezionej po „config”, z ~/vpn-test:
sed -n '1,220p' znaleziona-ścieżka.conf

Plik, którego pochodzenie lub dyrektywy są nieznane, nigdy nie powinien być uruchamiany na serwerze produkcyjnym ani na maszynie, która ma dostęp do SSH. Pierwsza próba odbywa się w jednorazowej maszynie wirtualnej z niezależnym terminalem. To odczytanie zmniejsza ryzyko, nie przekształca jednak dowolnego profilu w bezpieczny. Odrzuć również daemon, log, log-append i syslog w tej diagnozie: przenoszą one komunikaty poza terminal i mogą pozostawić proces w tle.

Jeśli profil odnosi się do ścieżek względnych, nie przenoś tylko client.ovpn. Zachowaj otrzymany katalog w kontrolowanej lokalizacji lub skopiuj każdą zależność przeczytaną ze swoją strukturą i z ograniczonymi prawami. Na przykład profil, który cytuje ca ca.crt musi znaleźć ca.crt w ~/vpn-test.

install -m 600 /ścieżka/otrzymanego/ca.crt ~/vpn-test/ca.crt

Brakująca lub nieczytelna zależność jest niepowodzeniem profilu, różniącym się od błędu TLS po teście sieciowym. Plik .ovpn może również zawierać certyfikaty między znacznikami, w takim przypadku ta kontrola nie wyświetli żadnej zewnętrznej ścieżki.

find ~/vpn-test -maxdepth 1 -type f -printf '%f %mn'
# Dla proto udp4/tcp4:
getent ahostsv4 vpn.przyklad.net
# Dla proto udp6/tcp6:
getent ahostsv6 vpn.przyklad.net
ip -brief link show > ~/vpn-test/links-before.txt

Zamień hosta i rodzinę na wartości z remote i proto. Profil może zawierać wiele linii remote. Jeśli rodzina pozostaje otwarta, sprawdź oba wyjścia, a następnie zachowaj adres rzeczywiście ogłoszony przez OpenVPN w dzienniku. Połączenie OpenVPN samo w sobie pozostaje użytecznym testem protokołu i portu, niezależnie czy jest to UDP lub TCP.

Uruchom klienta w trybie interaktywnym i zachowaj dziennik

Uruchom klienta w trybie interaktywnym. Terminal powinien wtedy pokazać adres kontaktowany i pierwszy wykorzystany błąd. Zainstaluj pakiet, jeśli openvpn jest nieobecny:

command -v openvpn || { sudo apt update && sudo apt install openvpn; }
sudo openvpn --config ~/vpn-test/client.ovpn --verb 3

Z --verb 3, zachowaj pierwszy wyraźny błąd, adres serwera i fazę, w której klient się zatrzymuje.

• Błąd opcji lub plik nieznaleziony wskazują na ścieżkę, dyrektywę lub certyfikat do skorygowania przed kolejną próbą.
• Błąd TLS po próbie połączenia wymaga sprawdzenia serwera, portu, protokołu UDP/TCP, filtrowania sieci, tls-auth lub tls-crypt, certyfikatów, czasu systemowego i ustawień kryptograficznych profilu.
• Prośba o dane logowania może pochodzić z auth-user-pass. Wpisz je na prompt lub użyj mechanizmu przewidzianego przez twojego dostawcę, nie dodając sekretu do client.ovpn.
• Komunikat Initialization Sequence Completed potwierdza, że klient zakończył swoją inicjalizację. Nie dowodzi to jeszcze, że oczekiwana zasób wewnętrzny jest osiągalny.

Zachowaj polecenie otwarte podczas następnej kontroli. Zakończ je za pomocą Ctrl+C dopiero po sprawdzeniu interfejsu, tras i usługi wewnętrznej.

Sprawdź interfejs i trasę po połączeniu

Zarejestruj interfejsy przed połączeniem, a następnie porównaj je po. tun transportuje pakiety IP, tap emuluje interfejs Ethernet. Dyrektywa dev może również narzucić nazwę. Używaj tylko faktycznie utworzonej nazwy. ip route get pokazuje urządzenie, które Linux by wybrał, bez wysyłania pakietu.

# Po „Initialization Sequence Completed”:
ip -brief link show | diff -u ~/vpn-test/links-before.txt -
VPN_IF='nazwa-utworzonego-interfejsu'
ip -brief address show dev "$VPN_IF"
ip route get 10.8.0.10
ip route get 1.1.1.1
ip route get "$SSH_CLIENT_IP"

Zamień 10.8.0.10 na wewnętrzny cel dokumentowany przez zespół dostarczający VPN. Jego trasa powinna wspominać o interfejsie tunelu, jeśli ta sieć przebiega przez OpenVPN. Ponownie przestań kilka minut w kierunku SSH_CLIENT_IP, jeśli miałeś zdalną sesję przed testem.

Trasa nie dowodzi, że usługa wewnętrzna odpowiada. Następnie przetestuj oczekiwaną usługę z adresem i portem dokumentowanymi przez twój zespół. Dla usługi HTTPS, która udostępnia stronę zdrowia, na przykład:

getent hosts intranet.przyklad.lan
curl --fail --silent --show-error --connect-timeout 5 --max-time 10 --output /dev/null --write-out '%{http_code}n' https://intranet.przyklad.lan:443/health

Zamień tę nazwę, port i ścieżkę na te rzeczywiste usługi. Pierwsze polecenie powinno zwrócić adres wewnętrzny. Drugie powinno wyświetlić oczekiwany kod przez tę usługę, na przykład 200 lub 204. curl sprawdza również certyfikat TLS: zainstaluj wewnętrzną CA lub użyj dokumentacji usługi, jeśli jest to konieczne, nie dodawaj --insecure. Dla wewnętrznego DNS, zapytaj raczej o nazwę i resolver dokumentowane przez twój zespół.

Wybrałbym to jednorazowe uruchomienie przed usługą openvpn-client@... na serwerze, ponieważ diagnostyka pozostaje oddzielona od uruchomienia. Po Ctrl+C, sprawdź, czy interfejs zniknął, że trasa do wewnętrznego celu już nie korzysta z tunelu, a trasa do zanotowanego adresu SSH wraca do oczekiwanego urządzenia. Profil z zewnętrznymi skryptami down lub route-pre-down nakłada tę kontrolę, nie pozwalając przypuszczać, że czyszczenie powiodło się.

ip link show "$VPN_IF"
ip route get 10.8.0.10
ip route get "$SSH_CLIENT_IP"

Pierwsze polecenie powinno zgłosić, że interfejs już nie istnieje. Porównaj obie trasy z ich wynikami zarejestrowanymi przed i w trakcie tunelu. Trasa nadal związana z usuniętym interfejsem lub błąd skryptu czyszczącego wymaga weryfikacji przed kolejną próbą.