Страниците се зареждат, но качванията на VPN зациклят: кой причинител печели
Забавяне, зависещо от размера, подхожда на дефект в MTU на пътя, а също и на DNS, на ограничение в приложението или на нестабилен тунел. Четири наблюдения решават кое е то.
Страниците се зареждат, VPN съобщава, че е свързан, а качването на файл замръзва на едно и също място всеки път. Четири обяснения пасват на това описание: проблем с размера на пакета, проблем с разрешаването на имена, ограничение в приложението и тунел, който постоянно се преустановява. Всяко от тях може да бъде потвърдено или изключено с различно наблюдение, затова решението е въпрос на избор на правилния тест, а не на гадаене за причината.
Четири кандидата и една форма
Започнете с формата на отказа, защото тя изключва по-голямата част от списъка, преди още да е отворен какъвто и да е инструмент. Забавяне, което се случва при постоянен размер, е проблем с размера, докато не се докаже обратното. Забавяне в случайни точки е проблем със загуби или стабилност. Отказ преди отварянето на връзката е проблем с имената.
Четвъртият кандидат е приложението. Ограниченията за качване, таймаутите на заявките и лимитите за размер на тялото при проксито създават откази, които изглеждат на браузъра като мрежови дефекти, и обикновено идват като отхвърляне, а не като забиване.
Запишете наблюдаваната форма, преди да тествате каквото и да е. „Спира при приблизително еднакъв брой байтове, всеки път, при вдигнат тунел“ е много по-силна отправна точка от „качванията не работят“.
След това дръжте пътя фиксиран, докато тествате. Промяната на изхода, протокола и сървъра едновременно дава резултат, който не можете да припишете на нито едно от тях. Една променлива на пускане и я запишете.
Разделете размера, преди да пипате политиката
Най-евтиният различител е проба, която променя едно число. Изпратете ping-ове със забрана за фрагментиране с нарастващ размер към дестинацията, качете файл, който контролирате, към същата услуга и после сравнете къде спира всяко от двете.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadПървата команда съобщава дали пакет с пълен размер изобщо преживява пътя. При MTU от 1500 байта най-големият ICMP полезен товар, който не се фрагментира, е 1472 байта, а тунелът взема още повече от този бюджет, преди вътрешният пакет да започне. Втората ви дава размер и продължителност за трансфер на ниво приложение, а това е числото, което наистина има значение.
| 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 |
Четете двойката заедно. Проби, които се провалят над праг, и качване, което спира близо до същия праг, са последователна история. Проби, които всички успяват, докато качването забива при брой байтове, който пътят очевидно носи, сочат към приложението или сървъра и никаква работа по MTU няма да го промени. Този отрицателен резултат струва колкото положителен. Той премахва най-скъпия клон на разследването.
След това проверете стабилността по време на трансфера, защото тунел, който преподписва ключ по средата на голямо качване, създава отказ, който изглежда зависим от размера, без да е такъв. Показанието за време на работа е най-евтиният начин да го потвърдите.
Изберете между поправка и заобиколно решение
Ако доказателствата сочат към размера, има два честни отговора и един нечестен. Честните са да възстановите откриването на MTU на пътя, като разрешите необходимата ICMP обратна връзка, или да ограничите обявения размер на сегмента, така че партньорите да изпращат по-малки сегменти. Нечестният е да намалите MTU на интерфейса до стойност, копирана от форум, и никога да не проверите какво е променила.
Изборът зависи от това какво контролирате. В мрежа, която управлявате, разрешаването на ICMP съобщенията е по-чистата поправка, защото запазва механизма работещ за всеки протокол. На път, който не контролирате, ограничаването е практичният вариант и трябва да се прилага тясно, а не за целия сървър.
Ако доказателствата сочат към приложението, поправете приложението или конфигурацията на проксито му. Отговор 413 и забила връзка са различни откази, а вторият обикновено е таймаут някъде във верига, която включва прокси със собствени лимити.
Във всеки случай запазете първоначалните стойности и тествайте отново след връщане назад. Промяна, която съвпада с работещ трансфер, не е доказателство, че тя го е причинила, и възможността да я отмените е това, което отделя диагнозата от случайността.
Запишете решението, за да преживее следващия инцидент
Четири факта са достатъчни: наблюдаваната форма на отказа, резултатите от пробите, промяната, която направихте, и резултатът от повторния тест. С тях следващият човек може да каже дали проблемът е същият или е нов със същия симптом.
Отбележете и контекста на пътя, защото констатация за MTU е специфична за конкретна връзка. Лаптоп, който работи вкъщи и се проваля в хотел, има два пътя и поправка, приложена към единия, не казва нищо за другия.
Накрая, устоявайте на обобщението „VPN счупи качванията“. Тунелът присъстваше и в работещия, и в проваления случай; това, което се промени, беше размерът на пакета, който пътят трябваше да носи, или мястото, където трансферът беше спрян. Именно назоваването на действителния механизъм прави бележката полезна.