Test odzyskiwania serwera VPN po ponownym uruchomieniu: co sprawdzić najpierw

Uruchom ponownie serwer, gdy nikt nie jest zalogowany, a następnie połącz się z sieci, której nie kontrolujesz. Ten jeden test odpowiada, czy odzyskiwanie jest prawdziwe, ponieważ tunel, który działa dopiero po ręcznym uruchomieniu polecenia przez kogoś, nie jest odzyskiwaniem, lecz naprawą. Większość kontroli kończy się zbyt wcześnie: usługa wygląda na aktywną, interfejs się podnosi, a strona nadal się nie ładuje. Luka prawie zawsze dotyczy trwałości elementów wokół tunelu, nie samego polecenia tunelu.

Cztery podmioty, cztery różne testy

Przed ponownym uruchomieniem nazwij, co ma przywrócić tunel. Test, który wykonujesz, i poprawka, którą stosujesz, zależą od tej odpowiedzi, a istnieją cztery typowe podmioty: jednostka systemd dla usługi VPN, jednostka instancji wg-quick dla interfejsu WireGuard, środowisko uruchomieniowe kontenerów lub profil menedżera sieci. Jeśli nie potrafisz nazwać podmiotu, zatrzymaj się i znajdź go, ponieważ test ponownego uruchomienia bez oczekiwanej ścieżki startu mówi tylko, że coś się stało.

Każdy podmiot trzyma konfigurację w innym miejscu. Serwer OpenVPN zarządzany przez systemd czyta konfigurację przy starcie, więc to, co jest w pliku podczas rozruchu, jest tym, co działa. Interfejs wg-quick czerpie adresy, trasy i DNS z tego samego pliku, co oznacza, że interfejs podniesiony ręcznie z powłoki i nigdy nie włączony jako jednostka nie wróci. Kontener przywraca swój punkt wejścia, ale nie zmiany zapory hosta, chyba że te znajdują się poza kontenerem.

Najpierw stan bazowy, inaczej wynik nic nie znaczy

Zapisz stan działający, dopóki działa: adresy na tunelu, trasy do podsieci klientów, reguły NAT lub przekazywania, gniazdo nasłuchujące i sysctl przekazywania. ip addr show wg0, ip route, nft list ruleset lub iptables-save, ss -lunp i sysctl net.ipv4.ip_forward wystarczą na większości hostów.

Zapisz, jak usługa jest skonfigurowana do startu, nie tylko że działa. systemctl is-enabled wg-quick@wg0 i systemctl is-active wg-quick@wg0 odpowiadają na różne pytania, a przy rozruchu liczy się stan włączony, jak opisano w systemctl(1). W przypadku OpenVPN sprawdź, jakiego szablonu używa host, ponieważ openvpn@server i openvpn-server@server to różne jednostki z różnymi wartościami domyślnymi.

Wykonaj ponowny start i odczytaj pierwszy błąd

Uruchom ponownie celowo, w wybranym przez siebie oknie, z otwartą konsolą lub ścieżką poza pasmem. Obserwuj kolejność zdarzeń, a nie stan końcowy: host osiągalny, jednostka aktywowana, interfejs obecny, trasy zainstalowane, reguły zapory obecne, nasłuchujący związany, klient zaakceptowany. Pierwszy krok, który nie następuje, jest ustaleniem; wszystko po nim to szum.

Usługa może być aktywna, gdy tunel jest bezużyteczny, i to jest najczęstsze fałszywe przejście. Start może zakończyć się zanim sieć będzie online, jeśli jednostka czeka tylko na network.target zamiast network-online.target. Pliki, do których się odwołuje — certyfikaty, klucze lub CRL — mogą być wtedy nieczytelne, ponieważ montowanie lub ścieżka sekretów nie jest jeszcze gotowa. Żaden z tych problemów nie pojawia się w systemctl status, dopóki nie przeczytasz dziennika jednostki.

Testuj spoza hosta. Klient w tej samej sieci LAN może odnieść sukces trasą, której żaden klient zdalny nigdy by nie użył, a sesja SSH do maszyny niczego nie dowodzi o tunelu. Połącz się, rozwiąż nazwę wewnętrzną, dotrzyj do zasobu prywatnego, a następnie połącz się jeszcze raz, aby potwierdzić, że stan unieważnienia i klucze nadal obowiązują.

Trzy warunki, które decydują o twojej poprawce

Jeśli tunel wraca, ale klienci do niczego nie docierają, błąd leży w routingu lub trwałości NAT. Jeśli klienci nie mogą nawet dokończyć uścisku dłoni, błąd leży w interfejsie lub materiale uwierzytelniającym. Jeśli usługa nigdy nie startuje, błąd leży w pliku jednostki lub jej zależnościach. Te trzy gałęzie prowadzą do różnych poprawek, dlatego ślepy restart bez stanu bazowego kosztuje więcej czasu, niż oszczędza.

Wprowadź poprawkę tam, gdzie ustawienie jest własnością. Umieść przekazywanie w sysctl drop-in, umieść reguły NAT w zestawie reguł ładowanym przy rozruchu, włącz jednostkę zamiast ją uruchamiać i trzymaj sekrety na ścieżce, która istnieje przed startem jednostki. Dodanie uśpienia do jednostki ukrywa zależność zamiast ją zadeklarować.

Zapisz wynik w runbooku

Zapisz, co wróciło samo, co musiałeś uruchomić i jak długo trwała luka. Uwzględnij dokładne polecenia, których użyłeś do weryfikacji, aby następna osoba powtórzyła test, a nie wymyślała nowy. Jeśli któryś krok wymagał polecenia ręcznego, to polecenie należy do konfiguracji, a nie do runbooka jako stały krok.

Następnie zaplanuj kolejny test po następnej zmianie stosu sieciowego hosta, a nie na datę kalendarzową za sześć miesięcy. Tryb awarii, przed którym się bronisz, to tymczasowe polecenie, które wydawało się trwałe, i pojawiają się one dokładnie wtedy, gdy ktoś edytuje reguły zapory lub przenosi usługę do nowej jednostki.