Etapy uzgadniania VPN: co dzieje się, zanim popłynie ruch

Naciśnięcie Połącz uruchamia cztery odrębne zadania, które udają się lub zawodzą niezależnie. Klient musi dotrzeć do nasłuchu, uzgodnić, kim jest partner, wyprowadzić klucze, a potem przekazać działający tunel resztę systemu. Większość nieudanych połączeń jest diagnozowana w niewłaściwym zadaniu. Dlatego pierwszy błąd liczy się bardziej niż trzecia próba.

Najpierw dotrzyj do nasłuchu

Zanim wymieniona zostanie jakakolwiek tożsamość, klient rozwiązuje nazwę, wybiera trasę i otwiera transport do portu. Portal przechwytujący, który odpowiada na wszystko, zamknięty port i błędna nazwa hosta zawodzą tutaj, i żaden z nich nie jest problemem uwierzytelniania. Zmiana hasła nie naprawi żadnego z trzech. Przeczytaj pierwszą linię błędu, zanim dotkniesz poświadczeń.

Przekroczenie limitu czasu, odrzucenie certyfikatu i odrzucone konto to trzy różne usterki z trzema różnymi sprawdzeniami. Właśnie ich wczesne rozdzielenie sprawia, że problem sieci nie jest debugowany jako problem poświadczeń.

Poświadcz partnera, potem wyprowadź klucze

Każdy protokół potrzebuje sposobu rozpoznania zamierzonego serwera, czy to przez skonfigurowany klucz publiczny, czy przez łańcuch certyfikatów. Logowanie użytkownika jest dodatkiem do tego sprawdzenia, a nie jego zamiennikiem. Serwer, który akceptuje twoje hasło, nie dowiódł niczego o własnej tożsamości. Dlatego wspólny sekret wpisany w kliencie nie zastępuje sprawdzenia, kto odpowiedział.

Wymiana wyprowadza następnie klucze ruchu z własnych danych wejściowych protokołu, a hasło logowania zwykle nie jest kluczem stemplowanym na każdej paczce. Długoterminowy materiał tożsamości i krótkotrwałe klucze sesji mają różne czasy życia i różne zadania. Właśnie o tej separacji mówi poufność forward.

Pozostaw weryfikację włączoną podczas rozwiązywania problemów, bo tunel, który łączy się po wyłączeniu sprawdzenia, nie dowiódł niczego poza tym, że sprawdzenie coś robiło. Zapisz, co zmieniłeś, i przywróć to przed następnym testem.

Trzy protokoły, trzy rozmowy

W OpenVPN opartym na TLS kanał sterujący negocjuje parametry bezpieczeństwa, a kanał danych przenosi ruch tunelu, więc opcja kanału danych i problem z certyfikatem mieszkają w różnych miejscach. IKEv2 uwierzytelnia obu uczestników, a następnie ustanawia asocjacje bezpieczeństwa IPsec z własnymi okresami ważności. WireGuard wyprowadza klucze przez swoją wymianę opartą na Noise i świadomie utrzymuje maszynę stanów małą. Wiedza, który z trzech uruchamiasz, decyduje, który dziennik warto czytać.

Podobnie wyglądający klienci nie oznaczają wymiennych komunikatów pod spodem, a pole konfiguracji istniejące w jednym produkcie może nie mieć odpowiednika w innym. Kopiowanie profilu między nimi jest domysłem, a nie migracją.

Czego uzgadnianie nie robi

Trasy, rozwiązywanie nazw i polityka miejsc docelowych pozostają wszystkie potem. Wewnętrzna witryna może pozostać nieosiągalna, bo brakuje trasy jej podsieci, nawet gdy partner został poprawnie uwierzytelniony, a tunel działa. Traktowanie tego jako słabego szyfrowania wysyła cię do szukania w niewłaściwej warstwie, i zwykle kończy się zmianą szyfru, która nic nie naprawia.

Odświeżanie kluczy i ponowne łączenie wyglądają podobnie w większości widoków stanu, a żadne z nich nie mówi, czy zwykły ruch był blokowany podczas przerwy. Tylko polityka awarii klienta odpowiada na to pytanie, więc czytaj politykę, a nie ikonę.

Przejdź etapy w powyższej kolejności i zatrzymaj się na pierwszym, który daje błąd. Każdy późniejszy etap dziedziczy stan wcześniejszych, więc błąd na trzecim etapie nic nie mówi o czwartym.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal