Stránky se načítají, ale nahrávání přes VPN zamrzá: která příčina vyhrává
Zaseknutí závislé na velikosti odpovídá závadě MTU cesty a také DNS, limitu aplikace nebo nestabilnímu tunelu. Která z nich to je, rozhodují čtyři pozorování.
Stránky se načítají, VPN hlásí připojení a nahrávání souboru pokaždé zamrzne ve stejném bodě. Tomu popisu odpovídají čtyři vysvětlení: problém s velikostí paketu, problém s překladem jmen, limit aplikace a tunel, který se neustále obnovuje. Každé z nich lze potvrdit nebo vyloučit jiným pozorováním, takže rozhodnutí spočívá ve volbě správného testu, nikoli v hádání příčiny.
Čtyři kandidáti a jeden tvar
Začněte tvarem poruchy, protože ten vyřadí většinu seznamu dřív, než otevřete jakýkoli nástroj. Zaseknutí, k němuž dochází při stálé velikosti, je problém velikosti, dokud se neprokáže opak. Zaseknutí v náhodných bodech je problém ztrát nebo stability. Selhání před otevřením spojení je problém jmen.
Čtvrtým kandidátem je aplikace. Limity nahrávání, časové limity požadavků a stropy velikosti těla na proxy vytvářejí selhání, která z prohlížeče vypadají jako síťové závady, a obvykle přicházejí jako odmítnutí, ne jako zamrznutí.
Zapište pozorovaný tvar, než cokoli otestujete. „Zastaví se přibližně na stejném počtu bajtů, pokaždé, když je tunel nahoře“ je mnohem silnější výchozí bod než „nahrávání nefunguje“.
Potom během testování držte cestu neměnnou. Změna výstupu, protokolu a serveru zároveň dává výsledek, který nemůžete připsat žádnému z nich. Jedna proměnná na běh, a zapište ji.
Rozdělte velikost dřív, než sáhnete na politiku
Nejlevnější rozlišovač je sonda, která mění jedno číslo. Posílejte pingy bez fragmentace rostoucí velikosti na cíl, nahrajte soubor, který ovládáte, na stejnou službu a pak porovnejte, kde se každý zastaví.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadPrvní příkaz hlásí, zda paket plné velikosti vůbec projde cestou. Při MTU 1500 bajtů je největší ICMP užitečné zatížení, které se nefragmentuje, 1472 bajtů, a tunel si z tohoto rozpočtu vezme ještě víc, než vnitřní paket začne. Druhý vám dá velikost a dobu trvání přenosu na úrovni aplikace, což je číslo, na kterém skutečně záleží.
| 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 |
Čtěte obojí společně. Sondy, které selhávají nad prahem, a nahrávání, které se zastaví poblíž stejného prahu, tvoří souvislý příběh. Sondy, které všechny uspějí, zatímco nahrávání zamrzá na počtu bajtů, který cesta zjevně přenáší, ukazují na aplikaci nebo server a žádná práce s MTU to nezmění. Takový negativní výsledek má stejnou cenu jako pozitivní. Odstraňuje nejdražší větev vyšetřování.
Potom zkontrolujte stabilitu během přenosu, protože tunel, který uprostřed velkého nahrávání obnoví klíč, vytváří selhání, které vypadá závislé na velikosti, aniž by takové bylo. Odečet doby běhu je nejlevnější způsob, jak to potvrdit.
Rozhodněte se mezi opravou a obejitím
Pokud důkazy ukazují na velikost, existují dvě poctivé odpovědi a jedna nepoctivá. Poctivé jsou obnovit objevování MTU cesty povolením potřebné zpětné vazby ICMP, nebo omezit oznámenou velikost segmentu, aby partneři posílali menší segmenty. Nepoctivá je snížit MTU rozhraní na hodnotu opsanou z fóra a nikdy neověřit, co změnila.
Volba závisí na tom, co ovládáte. V síti, kterou provozujete, je povolení ICMP zpráv čistší opravou, protože udržuje mechanismus funkční pro každý protokol. Na cestě, kterou neovládáte, je omezení praktickou volbou a mělo by se použít úzce, ne na celém serveru.
Pokud důkazy ukazují na aplikaci, opravte aplikaci nebo její konfiguraci proxy. Odpověď 413 a zamrzlé spojení jsou různé poruchy a druhá je obvykle časový limit někde v řetězci, který zahrnuje proxy s vlastními limity.
V každém případě si ponechte původní hodnoty a po vrácení změny znovu otestujte. Změna, která se kryje s funkčním přenosem, není důkazem, že jej způsobila, a možnost vrátit ji zpět je to, co odděluje diagnózu od náhody.
Zaznamenejte rozhodnutí, aby přežilo další incident
Stačí čtyři fakta: pozorovaný tvar poruchy, výsledky sond, změna, kterou jste provedli, a výsledek opakovaného testu. S nimi další člověk pozná, zda jde o stejný problém, nebo o nový se stejným příznakem.
Zaznamenejte i kontext cesty, protože zjištění o MTU je specifické pro konkrétní spoj. Notebook, který doma funguje a v hotelu selhává, má dvě cesty a oprava použitá na jedné z nich nic neříká o druhé.
Nakonec odolejte shrnutí, že „VPN rozbila nahrávání“. Tunel byl přítomný v obou případech, funkčním i nefunkčním; změnila se velikost paketu, který cesta musela přenést, nebo místo, kde byl přenos zastaven. Pojmenování skutečného mechanismu je to, co dělá poznámku užitečnou.