Strony się ładują, ale wysyłanie plików zrywa w VPN: która przyczyna wygrywa
Zawieszenie zależne od rozmiaru pasuje do usterki MTU ścieżki, a także do DNS, limitu aplikacji lub niestabilnego tunelu. Cztery obserwacje decydują, która.
Strony się ładują, VPN zgłasza połączenie, a wysyłanie pliku za każdym razem zamiera w tym samym miejscu. Do tego opisu pasują cztery wyjaśnienia: problem z rozmiarem pakietu, problem z rozwiązywaniem nazw, limit aplikacji i tunel, który ciągle się resetuje. Każde z nich można potwierdzić lub wykluczyć inną obserwacją, więc decyzja polega na wyborze właściwego testu, a nie na zgadywaniu przyczyny.
Cztery kandydatury i jeden kształt
Zacznij od kształtu awarii, bo eliminuje on większość listy, zanim otworzysz jakiekolwiek narzędzie. Zawieszenie występujące przy stałym rozmiarze jest problemem rozmiaru, dopóki nie zostanie dowiedzione inaczej. Zawieszenie w losowych miejscach jest problemem strat lub stabilności. Awaria przed otwarciem połączenia jest problemem nazw.
Czwartym kandydatem jest aplikacja. Limity wysyłania, limity czasu żądań i górne limity rozmiaru ciała w proxy powodują awarie, które z przeglądarki wyglądają jak usterki sieci, i zwykle przychodzą jako odrzucenie, a nie jako zawieszenie.
Zapisz zaobserwowany kształt, zanim cokolwiek przetestujesz. „Zatrzymuje się przy mniej więcej tej samej liczbie bajtów, za każdym razem, przy podniesionym tunelu” to znacznie mocniejszy punkt wyjścia niż „wysyłanie nie działa”.
Potem utrzymuj ścieżkę bez zmian podczas testów. Zmiana wyjścia, protokołu i serwera naraz daje wynik, którego nie możesz przypisać żadnemu z nich. Jedna zmienna na przebieg, i zapisz ją.
Podziel rozmiar na pół, zanim dotkniesz polityki
Najtańszym rozróżnieniem jest próba zmieniająca jedną liczbę. Wyślij do celu pingi o rosnącym rozmiarze z zakazem fragmentacji, wyślij plik, który kontrolujesz, do tej samej usługi, a potem porównaj, gdzie zatrzymuje się każdy z nich.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadPierwsze polecenie mówi, czy pakiet pełnego rozmiaru w ogóle przechodzi przez ścieżkę. Przy MTU 1500 bajtów największy nie fragmentowany ładunek ICMP to 1472 bajty, a tunel zabiera z tego budżetu więcej, zanim zacznie się pakiet wewnętrzny. Drugie daje rozmiar i czas trwania transferu na poziomie aplikacji, i to jest liczba, która naprawdę się liczy.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Czytaj oba razem. Próby, które zawodzą powyżej progu, i wysyłanie, które zatrzymuje się blisko tego samego progu, to spójna historia. Próby, które wszystkie się udają, podczas gdy wysyłanie zawiesza się przy liczbie bajtów wyraźnie przenoszonej przez ścieżkę, wskazują na aplikację lub serwer, i żadna praca nad MTU tego nie zmieni. Ten negatywny wynik jest wart tyle samo co pozytywny. Usuwa najdroższą gałąź dochodzenia.
Potem sprawdź stabilność podczas transferu, bo tunel, który odnawia klucz w środku dużego wysyłania, powoduje awarię wyglądającą na zależną od rozmiaru, choć taką nie jest. Odczyt czasu działania to najtańszy sposób, by to potwierdzić.
Wybierz między naprawą a obejściem
Jeśli dowody wskazują na rozmiar, są dwie uczciwe odpowiedzi i jedna nieuczciwa. Uczciwe to przywrócenie wykrywania MTU ścieżki przez dopuszczenie potrzebnej informacji zwrotnej ICMP albo ograniczenie ogłaszanego rozmiaru segmentu, aby partnerzy wysyłali mniejsze segmenty. Nieuczciwa to obniżenie MTU interfejsu do wartości skopiowanej z forum i nigdy niesprawdzenie, co zmieniła.
Wybór zależy od tego, co kontrolujesz. W sieci, którą prowadzisz, dopuszczenie komunikatów ICMP jest czystszym rozwiązaniem, bo utrzymuje mechanizm działający dla każdego protokołu. Na ścieżce, której nie kontrolujesz, ograniczanie jest praktyczną opcją, i należy je stosować wąsko, a nie na całym serwerze.
Jeśli dowody wskazują na aplikację, napraw aplikację lub jej konfigurację proxy. Odpowiedź 413 i zawieszone połączenie to różne awarie, a druga jest zwykle przekroczeniem limitu czasu gdzieś w łańcuchu zawierającym proxy z własnymi limitami.
Tak czy inaczej, zachowaj pierwotne wartości i przetestuj ponownie po wycofaniu. Zmiana, która zbiega się z udanym transferem, nie jest dowodem, że go spowodowała, a możliwość wycofania jest tym, co oddziela diagnozę od przypadku.
Zapisz decyzję, aby przetrwała następny incydent
Wystarczą cztery fakty: zaobserwowany kształt awarii, wyniki prób, wprowadzona zmiana i wynik ponownego testu. Dzięki nim następna osoba może powiedzieć, czy problem jest ten sam, czy to nowy z tym samym objawem.
Zanotuj też kontekst ścieżki, bo ustalenie dotyczące MTU jest właściwe dla konkretnego łącza. Laptop, który działa w domu i zawodzi w hotelu, ma dwie ścieżki, a poprawka zastosowana do jednej nic nie mówi o drugiej.
Na koniec oprzyj się podsumowaniu, że „VPN zepsuł wysyłanie”. Tunel był obecny zarówno w przypadku działającym, jak i zawodzącym; zmienił się rozmiar pakietu, który ścieżka musiała przenieść, albo miejsce, w którym transfer został zatrzymany. To nazwanie rzeczywistego mechanizmu czyni notatkę użyteczną.