Отговорите на ехо пристигат, отдалеченият работен плот работи, а браузърът стои на празна страница, докато не се откаже. Този модел се обяснява по два начина и те не са варианти на един проблем: политика, която никога не е разрешавала услугата, или пакети, които спират да се побират, щом трансферът нарасне. Отговорът на ехо не изключва нито едно от двете.

Вървете от най-малкия въпрос към най-големия и записвайте какво всъщност е доказала всяка стъпка.

Отговорът на ехо отговаря на много по-малък въпрос

Отговорът на ехо казва, че 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 байта плюс 8-байтова ICMP заглавка и 20-байтова IPv4 заглавка дава вътрешен пакет точно 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.

Ако приложението работи при всеки размер, който опитахте, спрете да настройвате числа и погледнете политиката, която разделя работещата услуга от провалящата се.

Подобни статии