HTTPS w kontenerze zawiesza się w firmowym VPN? Przetestuj nogę DTLS
Logowanie w kontenerze działa, ale HTTPS się zawiesza, więc przetestuj kanał danych UDP. Wyłącz DTLS, porównaj oba strumienie, a potem sprawdź MTU, zanim zostawisz flagę.
W kontenerze za firmowym VPN DNS się rozwiązuje, strona logowania się ładuje, punkt kontroli stanu odpowiada, a potem żądanie HTTPS zawiesza się do upływu limitu czasu. Przebudowa obrazu i zmiana zmiennych proxy nic nie zmieniają, bo uszkodzona część nie jest w obrazie. Klient uwierzytelnia się przez jeden transport, a dane masowe przenosi przez inny, i tylko ten drugi jest zepsuty.
Dwa transporty, jeden mylący objaw
Klient firmowy oparty na TLS zwykle uwierzytelnia się przez zwykłe połączenie TLS, a następnie negocjuje drugi kanał danych oparty na UDP dla sesji. Gdy ta druga noga działa, przepustowość i opóźnienie się poprawiają. Gdy jest filtrowana albo nie mieści się w ścieżce, wszystko przed transferem masowym się udaje, a sam transfer staje, co jest dokładnie powyższym wzorcem.
Kontener nie zmienia tej negocjacji; zmienia ścieżkę, którą podróżują pakiety zewnętrzne. Host tłumaczy przepływ kontenera, więc datagramy UDP wychodzą z innego portu źródłowego niż lokalne gniazdo klienta i wracają przez wpis tłumaczenia, który wygasa na znacznie krótszym liczniku niż ustanowiony przepływ TCP. Jeśli tunel działa na hoście, a zawodzi w kontenerze, porównaj te dwa przepływy, zanim obwiniasz aplikację. To porównanie rozstrzyga więcej niż jakakolwiek przebudowa obrazu.
Decyduj eksperymentem, nie intuicją
Najtańszy eksperyment wyłącza kanał danych UDP i powtarza żądanie. Użyj klienta wiersza poleceń zamiast nakładki graficznej, żeby flaga naprawdę została zastosowana: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Jeśli żądanie, które się zawieszało, teraz się kończy, problemem była noga DTLS, a reszta to szum.
Potwierdź wynik w obu kierunkach z tego samego kontenera: jedno żądanie masowe z flagą i jedno bez niej. Zmiana zachowania, która podąża za flagą, jest dowodem; strona, która w końcu się ładuje, nie jest.
Jeśli flaga to naprawia, zdecyduj dlaczego
Trzy warunki dają ten sam objaw i wymagają różnych reakcji. Ścieżka może całkowicie filtrować UDP, co czyni flagę poprawną trwałą odpowiedzią dla tej sieci. Ścieżka może dopuszczać UDP, ale odrzucać duże datagramy, co wskazuje na MTU, a nie na filtrowanie. Albo ścieżka może być tak stratna, że noga UDP wypada gorzej niż TCP, co jest decyzją o przepustowości, a nie o osiągalności.
Odróżnij je, zanim udokumentujesz obejście. Filtrowanie przetrwa każdy rozmiar pakietu, problemy z MTU pojawiają się dopiero powyżej progu, a strata objawia się retransmisją i zmiennym opóźnieniem, a nie czystym zawieszeniem. Każdy test zawęża przyczynę bez zmiany konfiguracji klienta.
Sprawdź rozmiar pakietu, zanim zostawisz obejście
Jeśli przyczyną jest rozmiar, interfejs tunelu przyjmuje pakiety, których ścieżka nie uniesie, a problem wraca na każdym transporcie, gdy tylko ładunek rośnie. Porównaj interfejsy: ip link show tun0 na hoście, potem docker network inspect bridge, aby odczytać MTU zapisane w opcjach sieci. Mostek kontenera wciąż na 1500 bajtach pod tunelem, który niesie mniej, to zwykłe znalezisko.
Sondować w górę od znanego dobrego rozmiaru testem zakazu fragmentacji wewnątrz tunelu, potem obniż MTU sieci kontenera albo ogranicz TCP MSS na tunelu. Każda z tych poprawek często przywraca użyteczność ścieżki UDP i usuwa potrzebę flagi, co jest lepszym wynikiem, gdy przyczyną nie jest filtrowanie.
Zdecyduj, co jesteś gotów wymienić
Przy wyłączonym kanale danych tunel niesie ładunek w połączeniu TCP. Na czystej ścieżce to tylko wolniej; na stratnej jeden utracony segment opóźnia wszystko za nim, a zewnętrzna retransmisja konkuruje z wewnętrzną. Ten handel pasuje do rozwoju interaktywnego i małych wywołań API, a słabo pasuje do transferów masowych lub długich sesji przez łącza mobilne.
Niezależnie od wybranej opcji zapisz, którego transportu tunel ostatecznie użył i dlaczego. Kontener, który po cichu zależy od flagi dodanej przez kogoś miesiące temu, to następna awaria, a osoba, która będzie ją debugować, nie będzie wiedziała, czy flaga była obejściem dla filtrowania, czy pozostałością po eksperymencie z MTU.