Пинг кроз VPN ради, али сајт се замрзава: проверите величину

Одговори еха стижу, удаљена радна површина ради, а прегледач стоји на празној страници док не одустане. Овом обрасцу одговарају два објашњења и она нису варијанте једног проблема: политика која никада није дозволила услугу, или пакети који престају да се уклапају када пренос порасте. Одговор еха не искључује ниједно од њих.

Идите од најмањег питања ка највећем и запишите шта је сваки корак заиста доказао.

Одговор еха одговара на много мање питање

Одговор еха каже да је IP стек одредишта одговорио на ICMP захтев са вашег извора. Он не каже ништа о томе да ли на порту који вам треба постоји TCP слушалац, да ли политика дозвољава тај порт, или да ли одредишни домаћин филтрира саобраћај независно од мрежног пролаза. Пролаз који дозвољава једну услугу може одбацити другу, док обоје циљева одговарају на ping. Читајте одговор као једну чињеницу о једном пакету и једном смеру.

Потврдите одредиште и порт услуге пре него што било шта друго протумачите. Адреса коју сте тестирали и адреса коју апликација користи понекад су различити записи, а име које се разрешава на две адресе то чини вероватним.

Откријте да ли је веза почела

Веза која се одмах одбија је одговор слушаоца или политике: нешто је одговорило и рекло не. Веза која се отвори па застане када подаци почну да се крећу указује на величину. Веза која уопште не заврши руковање обично је ствар политике или усмеравања и изгледа као истек времена, а не као одбијање.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Запишите који од та три случаја сте приметили пре него што дотакнете подешавања MTU. Промена величине тунела да бисте поправили одбијену везу траћи ту промену и извесно време крије прави узрок.

Измерите величину наведеним бројем

Када се застој појави под оптерећењем, тестирајте једну величину пакета са постављеним битом забране фрагментације и наведите аритметику да резултат нешто значи. На Linux-у са iputils, корисни терет од 1392 бајта плус ICMP заглавље од 8 бајтова и IPv4 заглавље од 20 бајтова даје унутрашњи пакет од тачно 1420 бајтова. Наведите ту аритметику у тикету, јер голи ping који стигне до пролаза не доказује ништа о апликацији.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Обе пробе су мерне тачке, а не препоруке за величину тунела. Ако се ICMP филтрира било где на путу, истек времена не говори ништа о величини, јер филтрирање и превелики пакет изгледају исто са стране клијента. Успех такође не говори ништа о супротном смеру или о другом одредишту.

Узмите у обзир спољни пут

Инкапсулација додаје своја заглавља, па је пакет на жици већи од пакета који сте измерили унутар тунела. Управо разлика између њих омогућава истовремено постојање малог захтева који ради и великог који не успева.

Откривање MTU пута у IPv4 зависи од повратних информација о пакетима који не могу да се проследе без фрагментације, а IPv6 користи поруке Packet Too Big. Спецификација IPv4 описује тај механизам. Филтрирање повратних информација квари способност пошиљаоца да учи и оставља га да поново шаље пакете који никада неће стати. Зато мали захтев који ради и велики који не успева тако удобно коегзистирају.

Промените један број и поново тестирајте апликацију

Снизите MTU тунела или ограничите највећу величину сегмента за TCP, па поновите изворни тест апликације уместо пробе. Проба која успе после промене и апликација која још виси јесу различит проблем сличног облика, и само тест апликације их разликује.

Чувајте аритметику у запису о промени: измерену величину, претпостављени додатни трошак и вредност коју сте поставили. Свако ко то касније прегледа може да провери претпоставку уместо да је изнова изводи са снимка екрана ping-а.

Ако апликација ради при свакој величини коју сте пробали, престаните да подешавате бројеве и погледајте политику која одваја услугу која ради од оне која не успева.