Странице се учитавају, али отпремања на VPN-у застају: који узрок побеђује
Застој који зависи од величине одговара квару MTU путање, а одговара и DNS-у, ограничењу апликације или нестабилном тунелу. Четири запажања одлучују које.
Странице се учитавају, VPN пријављује везу, а отпремање датотеке се сваки пут заледи на истом месту. Четири објашњења одговарају том опису: проблем величине пакета, проблем разрешавања имена, ограничење апликације и тунел који се стално ресетује. Свако од њих може се потврдити или искључити другачијим запажањем, па је одлука питање избора правог теста, а не нагађања узрока.
Четири кандидата и један облик
Почните од облика квара, јер он уклања већину списка пре него што се отвори било који алат. Застој који се јавља при сталној величини је проблем величине док се не докаже супротно. Застој на случајним местима је проблем губитка или стабилности. Квар пре отварања везе је проблем имена.
Четврти кандидат је апликација. Ограничења отпремања, рокови захтева и горње границе величине тела на проксију стварају кварове који у прегледачу изгледају као мрежни кварови, а обично стижу као одбијање, а не као застој.
Запишите запажени облик пре било каквог тестирања. „Зауставља се на приближно истом броју бајтова, сваки пут, са подигнутим тунелом“ много је јаче полазиште од „отпремања не раде“.
Затим држите путању непромењеном док тестирате. Мењање излаза, протокола и сервера истовремено даје резултат који не можете приписати ниједном од њих. Једна променљива по покретању, и запишите је.
Поделите величину пре него што дирнете политику
Најјефтинији разликовач је проба која мења један број. Пошаљите пинг без фрагментације растуће величине ка одредишту, отпремите датотеку коју контролишете на исту услугу, па упоредите где се сваки зауставља.
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 покварио отпремања“. Тунел је био присутан и у радном и у неуспелом случају; променила се величина пакета који је путања морала носити, или место где је пренос заустављен. Именовање стварног механизма чини белешку корисном.