NM OpenVPN: zapisany profil to nie twój plik .ovpn
Import tłumaczy opcje na zapisane połączenie. Odczytaj ponownie vpn.data, sprawdź ta i ta-dir i zaktualizuj jeden wpis zamiast zastępować słownik.
Ten sam .ovpn plik łączy się z powłoki i kończy się przekroczeniem limitu czasu po imporcie do NetworkManagera. Naturalny wniosek jest taki, że VPN jest zepsuty. Bardziej prawdopodobne wyjaśnienie jest mniejsze: NetworkManager nie zachował pliku, zaimportował jego część do zapisanego połączenia, a działający tunel używa zamiast tego tych zapisanych danych. To, co plik mówi teraz, nie ma znaczenia dla tego, co zawiera profil.
Plik to nie profil
Import to tłumaczenie, a nie montowanie. Opcje, które rozumie wtyczka, stają się kluczami w vpn.data słowniku połączenia; opcje, których nie rozumie, są odrzucane lub zapisywane gdzie indziej, a pierwotna ścieżka jest tylko odwołaniem. Późniejsza edycja pliku źródłowego niczego nie zmienia w już zapisanym połączeniu.
Ta luka wyjaśnia całą rodzinę zgłoszeń: klucz współdzielony został obrócony, plik zaktualizowano, a tunel nadal zawodzi. Zapisany profil nadal wskazuje starą ścieżkę lub starą wartość, a wiersz poleceń nadal działa, bo czyta plik, który edytowałeś. Dwaj klienci, dwa źródła prawdy i tylko jedno z nich zostało zaktualizowane.
Czytaj zapisany profil, nie okno dialogowe
nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn
Użyj UUID, gdy dwa profile dzielą nazwę, i potwierdź, że typ usługi to oczekiwana OpenVPN wtyczka, a nie inny typ VPN, który przypadkiem jest zainstalowany. Następnie porównaj punkt końcowy, transport i odwołania do certyfikatów z działającym wywołaniem.
Wartość widoczna w edytorze graficznym nie jest dowodem, że została zapisana. Zapisz, otwórz ponownie i odczytaj ją przez wiersz poleceń; historyczne błędy zapisu są powodem, by sprawdzić zapisane dane, a nie dowodem, że każde bieżące wydanie ma ten sam błąd. Sprawdzenie kosztuje jedno polecenie.
Dwa klucze i kierunek, który ma znaczenie
Dla połączenia korzystającego z uwierzytelniania TLS wtyczka zapisuje ścieżkę klucza współdzielonego w ta i kierunek w ta-dir, gdy wdrożenie go używa. Oba mieszkają w słowniku danych profilu i oba muszą odpowiadać temu, czego oczekuje serwer.
Kierunek to decyzja po stronie serwera wyrażona na kliencie. Wybranie jednego, bo ma go sąsiedni profil, to sposób, w jaki działający klucz zaczyna zawodzić podczas uścisku dłoni. Jeśli konfiguracja serwera nie ma kierunku, klient nie powinien wymyślać kierunku.
Sam plik klucza musi być czytelny dla wtyczki w kontekście, w którym faktycznie działa. Ograniczony pakiet ma inny widok systemu plików niż zwykła instalacja desktopowa, więc ścieżka istniejąca w twojej powłoce może być niewidoczna dla usługi.
Zaktualizuj jeden wpis, a nie słownik
nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'
Wiodący plus aktualizuje poszczególne wpisy słownika. Przypisywanie vpn.data bez niego zastępuje cały słownik i tak jeden brakujący klucz zamienia się w pięć zepsutych ustawień. Odczytaj profil po zmianie i potwierdź, że pozostałe wpisy przetrwały. Słownik, który stracił zdalny punkt końcowy i certyfikaty, to znacznie dłuższe popołudnie niż to, które zacząłeś.
Połącz się ponownie przez normalne elementy sterujące i obserwuj etap, który zawodzi. Jeśli brama klucza współdzielonego teraz przechodzi, a klient zgłasza błąd certyfikatu lub uwierzytelniania użytkownika, posunąłeś się naprzód, a następne śledztwo jest inne.
Nie mieszaj trybów kanału sterowania
tls-auth, tls-crypt, i tls-crypt-v2 to różne układy. Podobnie wyglądający plik klucza nie czyni ich wymiennymi, a wypełnianie pól TLS-Auth, ponieważ inny profil zawiera sformatowany klucz, daje profil, który zawodzi w sposób przypominający zły klucz.
Użyj mapowania wtyczki zgodnego z trybem w konfiguracji serwera. Gdy tryb jest niejasny, zapytaj właściciela serwera, zamiast zgadywać z pierwszego wiersza pliku.
Zachowaj ścieżkę odzyskiwania, gdy tunel przenosi twoją sesję zarządzania. Zapisana zmiana niekoniecznie jest zastosowaną zmianą, a udany import nie dowodzi, że każda opcja źródłowa była obsługiwana. Obie te luki warto znać, zanim ponownie połączysz łącze, przez które pracujesz.