Отказ на DNS или проблем с MTU? Къде всъщност спира заявката

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

Два отказа на различни слоеве

Резолвването превръща име в адрес и нищо друго във връзката не може да започне, докато то не успее. Проблемите с MTU на пътя се случват по-късно, когато пакет, по-голям от лимита на някаква връзка, бъде изхвърлен и изпращачът така и не бъде уведомен. Едното е търсене; другото е отказ при доставяне, който се появява само над определен размер.

Симптомите се различават по начин, който можете да наблюдавате без никакви инструменти. Отказът на DNS е мгновен и постоянен: браузърът казва, че сървърът не може да бъде намерен. Отказът по MTU е частичен: страницата започва, някои ресурси пристигат, а голям отговор или качване забива.

Ако симптомът ви е частичен, спрете да гледате DNS.

Етап 1: резолвва ли се името изобщо

Използвайте инструментите за търсене на платформата с точното име на хоста, което приложението използва. Частно име в офиса може да изисква вътрешен резолвер, а собственият защитен DNS на браузъра може да се държи различно от резолвера на операционната система, така че двата могат да не са съгласни за едно и също име.

Попитайте резолвера, който операционната система би използвала, след което сравнете:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

Ако резолвването се провали, проблемът е в тази политика и достъпността ѝ. Не изпращайте частни имена до произволни публични резолвери само за да получите сравнение, защото самото сравнение издава имената, които сте искали да останат вътрешни.

Етап 2: къде спира трансферът

Ако името се резолвне и връзката започне, запишете къде спира операцията. Страница, която се изобразява и след това забива на един ресурс, качване, което умира в постоянна точка, или голямо изтегляне, което никога не завършва, докато малките заявки работят, всички са симптоми с форма на размер. Отговор, който изобщо не започва, има друга форма.

Държте крайната точка и дестинацията на приложението фиксирани, докато сравнявате, иначе измервате две променливи наведнъж. На този етап остават възможни и други причини: грешки в услугата, загуба, поведение на филтъра и повторни свързвания на тунела всички създават забиване.

Едно повтарящо се забиване струва повече от десет анекдотични.

Защо MTU вреди само след ръкостискането

Ръкостискането по TCP използва малки пакети, затова успява по път, който не може да пренесе сегмент с пълен размер. Отказът се появява, когато изпращачът пусне голям пакет с бит за забрана на фрагментация, връзка го изхвърли, а ICMP съобщението, което би докладвало лимита, така и не пристига, защото филтър го е изял. След това изпращачът опитва същия размер и трансферът забива.

Затова симптомът зависи от размера и се повтаря, а не е случаен. Това също обяснява защо пингването на хоста нищо не доказва, защото малко ICMP ехо може да премине по път, който няма да пренесе полезен товар с пълен размер. Проверете размера от двата края на пътя, ако можете. Лимит, който се появява само в една посока, е асиметрия в маршрутизацията, а не MTU на тунела.

Проверете размера изрично, вместо да го извеждате:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Сменете един слой, после го докажете

За имена сменете политиката на резолвера и пуснете отново същото търсене. За размер използвайте процедурата за MTU със записани оригинални стойности и готовност за връщане назад, защото ограничаването на MSS без знание какво е реалното MTU на тунела разменя едно забиване за друго.

Страница, която се зареди веднъж след промяна на няколко настройки, не показва кое е поправката. Сменете едно нещо, пуснете отново същия тест и запазете резултата до първия записан неуспешен етап.

Този запис е това, което пречи DNS, размерът на пакета и удостоверяването да се превърнат в купища постоянни заобикалявания, които никой не може да обясни. Тестването чрез суров IP е добър пример за преки път, който променя идентичността на TLS, а изключването на проверката на сертификата, за да успее сравнение, не е диагноза.