Dlaczego trasy o równym koszcie utrudniają zauważenie awarii VPN
Gdy kilka tuneli dzieli ten sam koszt, każdy przepływ może wybrać inny. Udany ping nic nie mówi o ścieżce, której naprawdę używa Twoja aplikacja.
Użytkownik zgłasza, że aplikacja wewnętrzna działa z jednej maszyny, a z innej zawodzi, podczas gdy ping uruchomiony z bramy udaje się w obu przypadkach. Przy kilku tunelach o równym koszcie nie jest to sprzeczność. Każdy przepływ jest umieszczany na własnym następnym skoku, więc Twoje sprawdzenie i sesja użytkownika mogą po prostu korzystać z różnych ścieżek. Poniższy opis odtwarza ten wybór, zanim cokolwiek zostanie zmienione.
Jeden ping, kilka możliwych ścieżek
Gdy trasa ma więcej niż jeden następny skok o tym samym koszcie, router musi wybrać jeden na pakiet. Większość implementacji haszuje pola pakietu, zwykle adresy źródłowy i docelowy wraz z protokołem i portami, aby odpowiedzi pozostawały na tej samej ścieżce. Różne aplikacje, a nawet różne połączenia jednej aplikacji, dają różne skróty.
Dlatego diagnostyka z bramy dowodzi tak niewiele. Własne sprawdzenie bramy ma własne adresy i porty, a więc własny skrót. Może trafić na zdrowy tunel, podczas gdy użytkownik wciąż trafia na uszkodzony.
Jak platforma wybiera następny skok
Odtwórz wybór, zamiast go zgadywać. Zapytaj jądro, której trasy użyłoby dla tego samego źródła i celu co zawodna sesja. To wyszukiwanie obejmuje pola, które zwykłe wyszukiwanie po celu ignoruje. Uruchom je także z działającego klienta i porównaj obie odpowiedzi:
ip route get 10.20.5.7 from 10.20.0.14Nowsze wydania iproute2 akceptują także protokół i port docelowy, co ma znaczenie, gdy skrót je obejmuje. Porównaj ten wynik z tym samym wyszukiwaniem z działającego klienta, a różnica jest dowodem, którego brakowało.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Śledź zawodny przepływ, nie tablicę tras
Tablica tras wymienia oba tunele i z definicji wygląda poprawnie. Pytanie brzmi, co każdy tunel robi z pakietem po wybraniu. Sprawdź, czy oba niosą te same chronione prefiksy, to samo pozwolenie na przekazywanie i ścieżkę powrotną docierającą do tego samego klienta.
Zwróć uwagę na urządzenia stanowe pośrodku. Jeśli żądanie wychodzi jednym tunelem, a odpowiedź wraca drugim, zapora lub NAT, które nigdy nie widziały pierwotnego przepływu, odrzucą ją. Oba tunele poprawnie przekazują ruch, a połączenie nadal zawodzi.
Sprawdź też MTU na każdej ścieżce. Ścieżka z dodatkową enkapsulacją zmniejsza użyteczny rozmiar, a transfer, który udaje się jednym tunelem, zatrzymuje się na drugim dokładnie przy rozmiarze, przy którym mniejszy się łamie.
Porównuj jedną ścieżkę na raz
Tam, gdzie projekt pozwala na konserwację, wyłącz jeden tunel z eksploatacji i powtórz zadanie użytkownika. Jeśli awaria zniknie, problem należy do usuniętej ścieżki, a następnym krokiem jest porównanie jej konfiguracji z sąsiednią, a nie ponowne badanie tablicy routingu.
Porównuj rzeczywistą aplikację, a nie powtarzane pingi. Zanotuj, czy awaria podąża za konkretnym następnym skokiem, rozmiarem pakietu czy przejściem po ponownym połączeniu, bo te trzy wzorce wskazują na różne naprawy.
Na koniec zapisz, dlaczego ścieżki są uważane za równoważne i jak awaria powinna wyłączyć jedną z nich z eksploatacji. Wielościeżkowość jest bezpieczna tylko wtedy, gdy ścieżki naprawdę są wymienne, a to twierdzenie projektowe, które warto sprawdzić, a nie założyć.