Страниците се вчитуваат, но прикачувањата на 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 ги расипа прикачувањата“. Тунелот беше присутен и во работниот и во неуспешниот случај; она што се смени беше големината на пакетот што патеката мораше да го носи, или местото каде преносот беше запрен. Именувањето на вистинскиот механизам е она што ја прави белешката корисна.