Dlaczego strony OpenConnect zawieszają się, dopóki nie obniżysz MTU tunelu

Logowanie się udaje, strona główna portalu się rysuje, a potem widżet pulpitu lub raport zostaje na waiting for host, aż przeglądarka się podda. Publiczne witryny ładują się normalnie przez cały czas i żadne dane logowania się nie zmieniły. To, że małe odpowiedzi docierają, a duże się zatrzymują, jest sygnaturą pułapu rozmiaru pakietu, a nie reguły dostępu. Potwierdź tę interpretację, zanim zmienisz cokolwiek innego w profilu.

Oddziel problem rozmiaru od problemu polityki

Zacznij od wykluczenia odmowy. Gdyby brama cię odrzuciła, połączenie zawiodłoby od razu, zamiast wczytać stronę do połowy. Tunel, który wstaje i potem zatrzymuje się tylko przy większych transferach, mówi ci, że zewnętrzna ścieżka nie może nieść wewnętrznego pakietu.

Mechanizmem jest enkapsulacja. Każdy wewnętrzny pakiet zyskuje nagłówki tunelu, więc ładunek, który mieścił się w łączu fizycznym, staje się pakietem zewnętrznym, który już się nie mieści, a wszystko, co niesie bit do-not-fragment, jest odrzucane bez odpowiedzi, którą przeglądarka mogłaby zinterpretować.

Zmierz pułap sondami do-not-fragment

Zmierz pułap, zamiast go zgadywać. Wysyłaj sondy, które odrzucają fragmentację, i zmniejszaj ładunek krok po kroku, aż wróci odpowiedź, zaczynając od polecenia takiego jak ping -M do -s 1472 host. Odpowiedź skarżąca się, że potrzebna jest fragmentacja, gdy DF jest ustawiony, oznacza, że wartość jest wciąż za wysoka. Powtórz na 1462, potem 1452, i zatrzymaj się na pierwszym rozmiarze, który odpowie. Zapisz liczbę razem z hostem, który testowałeś, bo odpowiedź należy do tej ścieżki, a nie do protokołu w ogóle.

Testuj adres, na który tunel naprawdę wysyła ruch. Sonda zewnętrzna wobec publicznej nazwy bramy i sonda wewnętrzna wobec wewnętrznego serwera mierzą różne przeskoki, a filtrowanie ICMP na którejkolwiek z nich może sprawić, że zdrowa ścieżka wygląda na zepsutą.

Zastosuj wartość do urządzenia tunelu

Zastosuj wynik do interfejsu utworzonego przez klienta, a nie do adaptera Wi-Fi. W kliencie Linux to jest ip link set dev tun0 mtu 1300 a następnie ip link show tun0, aby potwierdzić, że wartość została przyjęta. Użyj tej nazwy urządzenia, którą zgłasza klient, bo różni się ona w zależności od implementacji i od tego, jak zbudowano tunel.

Obniżenie MTU tunelu zmniejsza ładunek niesiony przez każdy pakiet, więc przepustowość masowa nieco spada, i to jest cena za to, że duże odpowiedzi nie trafiają do czarnej dziury. Mniejsza liczba nie jest automatycznie bezpieczniejsza. Zmiana adaptera fizycznego zamiast tego rozkłada szkodę na każde połączenie na tym łączu, podczas gdy zbyt duże wewnętrzne pakiety pozostają równie duże.

Najpierw użyj własnych żądań MTU klienta

Gdy kontrolujesz wywołanie, klient może poprosić o rozmiar, zamiast być łatany po fakcie. --mtu prosi serwer o MTU tunelu, a --base-mtu deklaruje MTU ścieżki pod spodem, aby brama mogła wyprowadzić liczbę tunelu. Oba są żądaniami, a podręcznik klienta nie obiecuje, że brama spełni którekolwiek z nich.

Ta różnica wyznacza kolejność pracy. Najpierw wypróbuj żądanie i sprawdź interfejs, który ono tworzy, a potem wróć do lokalnego ustawienia urządzenia, jeśli wartość wybrana przez bramę nadal się zatrzymuje.

Zweryfikuj transferem, który zawiódł, a potem utrwal to

Lokalna zmiana ip link obowiązuje, dopóki klient nie odbuduje tunelu, co dzieje się przy następnym ponownym połączeniu lub wznowieniu. Umieść wartość tam, gdzie zaczyna się połączenie: opakowanie, które uruchamia klienta, a potem dostraja urządzenie, jednostka systemd z krokiem ExecStartPost, albo opcja klienta, gdy brama ją przyjmie. Trzymaj ją obok profilu w kontroli wersji, aby następna osoba widziała, dlaczego liczba tam jest.

Testuj żądaniem, które zawiodło, a nie stroną główną. Otwórz raport, pobierz załącznik albo uruchom pobieranie repozytorium, które się zawiesiło, i zapisz dokładnie, gdzie się zatrzymuje, jeśli nadal się zatrzymuje. Strona, która rysuje się po zmianie, niewiele dowodzi, bo rysowała się też wcześniej.

Jeśli ten sam transfer zatrzymuje się w tym samym miejscu, teoria MTU nie jest udowodniona. Przechwyć ruch na tunelu i sprawdź, która strona przestaje wysyłać, zanim znowu zmienisz liczbę, a poprzednią wartość trzymaj zapisaną, aby wycofanie pozostało jednym poleceniem.