Komunikat „File exists” OpenVPN na trasie nie jest problemem pliku

Zacznij tam, gdzie pojawia się komunikat. Klient się łączy, tunel wstaje, a potem dziennik zgłasza, że polecenie dodania trasy w Linuksie nie powiodło się z File exists. Nic w tym zdaniu nie odnosi się do certyfikatu, klucza ani pliku konfiguracyjnego, choć słowa to sugerują. Jądro opisuje swoją tablicę tras, a prefiks, który kazano zainstalować, ma już wpis.

Podążaj za własną kolejnością klienta: o co poprosił, co tablica już zawierała, kto umieścił tam ten wpis, i dopiero potem co zmienić. Każdy krok usuwa jednego możliwego właściciela.

O co klient naprawdę prosił

Przed błędem klient zapisuje trasę, którą zamierza dodać, zwykle jako cel, maskę sieci, bramę i czasem jako metrykę lub tablicę. Ta linia jest żądaniem. Błąd, który następuje, jest odpowiedzią jądra, i oba należy czytać obok siebie.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

Niezerowy kod wyjścia pomocnika tras jest mniej informacyjny niż tekst pod nim, ponieważ różne odpowiedzi jądra dają niezerowy stan. Zachowaj dokładny komunikat; rozróżnienie między istniejącym wpisem a nieosiągalną bramą decyduje, która z kolejnych sekcji obowiązuje.

Czytaj istniejącą trasę, nie tylko adres

Szukanie w tablicy tego samego kropkowanego czworaka nie wystarczy. Obiekt trasy jest identyfikowany przez rodzinę adresów, tablicę, prefiks celu, metrykę, protokół i urządzenie wyjściowe, a wpisy dzielące prefiks mogą legalnie współistnieć, gdy te atrybuty się różnią. Zderza się cały obiekt, nie tekst.

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

Ostatnie polecenie odpowiada na inne pytanie niż dwa pierwsze: nie co istnieje, ale który wpis jądro wybrałoby dla tego celu teraz. Oba widoki są przydatne i wystarczająco często się różnią, by warto je porównać przed wyciągnięciem wniosków. Rozbieżność między nimi to ciekawy przypadek, a nie błąd zaokrąglenia.

Zapisz prefiks, tablicę, metrykę i urządzenie obok nieudanego żądania. Jeśli istniejący wpis ma te same atrybuty i ten sam następny skok, masz zduplikowaną instrukcję, a nie problem z routingiem.

Czterech właścicieli, których może mieć prefiks

Trasy połączone pochodzą z przypisanego adresu i system odtwarza je za każdym razem, gdy ten adres istnieje. Klient DHCP lub menedżer połączeń instaluje trasy jako część własnego cyklu życia. Inny klient VPN może już nieść ten sam prefiks. A lokalny hook lub skrypt może dodać taki, o którym nic innego nie wie.

Każdy właściciel wymaga innej korekty. Trasa połączona nie jest do usunięcia przez ciebie; jej usunięcie może przerwać dostęp lokalny, zanim tunel będzie użyteczny, a jądro ją przywróci. Trasę należącą do menedżera należy zmieniać przez ten menedżer, a nie ręcznym ip route del, które następne ponowne połączenie cofa.

Zachowany interfejs ułatwia to samo zamieszanie. Gdy urządzenie tunelu przetrwa ponowne połączenie, trasy zainstalowane przez własny kod konfiguracji mogą nadal istnieć przy drugim uruchomieniu, więc skrypt zakładający czysty stan zawodzi za drugim razem, a działa za pierwszym. Albo świadomie wyczyść nieaktualny wpis, albo uczyń kod konfiguracji idempotentnym.

block-local odpowiada na inne pytanie

Gdy profil wysyła cały ruch przez tunel, klient musi zdecydować, co dzieje się z siecią lokalną. Flaga block-local zmienia tę decyzję, kierując lokalny LAN przez tunel i zachowując udokumentowany wyjątek dla bramy LAN; to wybór polityki ruchu z widocznymi konsekwencjami dla osiągalności.

To nie wyjaśnia, dlaczego dodanie trasy zwróciło błąd istniejącego wpisu, a przyjęcie tego jako uniwersalnej naprawy ukrywa rzeczywisty konflikt za zmianą polityki. Jeśli twoje lokalne zasoby przestaną być osiągalne po edycji profilu, ta flaga jest jedną z pierwszych rzeczy do sprawdzenia; jeśli dodanie trasy zawodzi, to nie jest odpowiedź.

Traktuj ją jako decyzję o tym, które cele pozostają lokalne, podjętą świadomie i zapisaną. To nie przełącznik do wypróbowania, gdy dziennik wygląda alarmująco.

Zamknij pętlę: usuń duplikat u jego źródła

Gdy wiesz, który właściciel trzyma wpis, usuń zduplikowaną instrukcję tam, gdzie jest zdefiniowana. Może to być wiersz route w profilu, push z serwera lub hook, którego nie trzeba już uruchamiać.

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

Następnie połącz się ponownie i potwierdź trzy rzeczy: tunel wstaje, zamierzony cel rozwiązuje się na żądaną ścieżkę, a błąd znika bez pojawienia się nowego w jego miejscu. Czysty dziennik z błędnie wybraną ścieżką nie jest naprawą.

Jeśli prefiks oznacza lokalny LAN po jednej stronie, a sieć zdalną po drugiej, problemem jest nakładanie się adresów, a nie duplikat, i żadne usuwanie nie sprawi, że oba znaczenia będą prawdziwe jednocześnie. Ten przypadek wymaga innego planu dla jednej z dwóch sieci. Zdecyduj, która strona zostanie przenumerowana, zanim dotkniesz którejkolwiek.