Żądanie dociera, serwer je zapisuje, a klient nadal zgłasza przekroczenie czasu. Taka kombinacja oznacza, że odpowiedź nie znalazła drogi powrotnej, i jest to jedna z niewielu awarii, które możesz potwierdzić z obu stron naraz. Wykonuj kontrole po kolei i zatrzymaj się, gdy któraś z nich zawiedzie.

Zacznij od tego, gdzie dotarło żądanie

Zanim zaczniesz sprawdzać cokolwiek innego, potwierdź, że pakiet dotarł do usługi. Wpis w logu po stronie serwera, licznik połączeń albo dozwolone przechwycenie na dalekim końcu odpowiadają na to samo pytanie, a ich brak odsyła cię do tunelu, a nie dalej do odpowiedzi. To kontrola, która oddziela problem przekazywania od problemu drogi powrotnej.

Jeśli żądanie nigdy nie dotarło, zatrzymaj się tutaj. Tematem jest tunel, routing do prywatnego prefiksu lub reguła dostępu, a droga odpowiedzi nie jest jeszcze istotna. Zanotuj też adres źródłowy, który widział serwer. To albo adres z puli przydzielony klientowi, albo adres przetłumaczony, i ta różnica decyduje, która z późniejszych kontroli ma zastosowanie.

Odpowiedź potrzebuje trasy do puli

Klient dostępu zdalnego zwykle otrzymuje adres z puli, a sieć prywatna potrzebuje trasy powrotnej do tej puli. Serwer, którego trasa domyślna wskazuje na jego własną bramę, oddaje pakiet tej bramie, a ona nie ma pojęcia, gdzie znajduje się pula, więc odpowiedź tam ginie. Klient widzi przekroczenie czasu, bo nic nie wróciło, i tego nie da się odróżnić od żądania, które nigdy nie wyszło.

Sprawdź trasę, którą serwer wybiera dla adresu klienta, a nie trasę, której używa dla własnej podsieci. Te dwa wyszukiwania mogą dać różne odpowiedzi, a tutaj liczy się to drugie. Tłumaczenie to alternatywna konstrukcja i zmienia to, co widzi serwer. Może uprościć drogę powrotną, a także usuwa pierwotny adres klienta z logów serwera, co wpływa na każdą regułę lub raport zbudowany na tym polu.

Porównaj przechwycenie na serwerze z przechwyceniem na bramie

Porównaj to, co opuszcza serwer, z tym, co dociera do bramy. Przechwycenie na interfejsie wyjściowym serwera i przechwycenie na bramie tunelu odpowiadają na różne połowy pytania, a luka między nimi lokalizuje utratę.

ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0
Where the reply stopsWhat it proves
Request in the server log, nothing on its outbound captureThe server picked a gateway that cannot reach the pool
Reply leaves the server but never shows up at the gatewayLoss on the LAN path, not on the tunnel
Reply reaches the gateway but not the clientReturn translation or tunnel policy, not the server route

Żądanie wygenerowane przez samą bramę jest słabym zamiennikiem testu z klienta, bo pochodzi z innego adresu i trafia na inne reguły. Dlatego udany ping z bramy i nieudane żądanie od klienta mogą być prawdziwe jednocześnie.

Gdy na drodze stoi kilka routerów, sprawdź każdy, który potrzebuje trasy do puli. Konstrukcja lokacja-lokacja często wymaga, aby zdalny prefiks był znany na więcej niż jednym urządzeniu, a sama brama musi przekazywać między tunelem a siecią lokalną; notatki strongSwan o przekazywaniu omawiają stronę sysctl i zapory ogniowej tego zagadnienia.

Zapisz pulę, prefiks i osobę odpowiedzialną

Do notatki należą cztery fakty: pula, którą otrzymał klient, prywatny prefiks, którego potrzebował, router odpowiedzialny za odpowiedź oraz reguła tłumaczenia, jeśli istnieje. Z nimi późniejsza zmiana bramy jest porównaniem, a nie śledztwem.

Potem przetestuj ponownie ze zwykłym klientem i prawdziwym kontem aplikacji. Rozszerzenie uprawnień aplikacji nie naprawi drogi powrotnej pakietu, a zmiana konta podczas tej diagnostyki pomiesza następne porównanie. Jeśli konstrukcja opiera się na tłumaczeniu, udokumentuj je tam, gdzie czyta się logi serwera. Ktoś, kto w śladzie audytu widzi nieznany adres źródłowy, nie powinien odkrywać mapowania od nowa ze zgłoszenia.

Powiązane artykuły