klink0v (klink0v) wrote,
klink0v
klink0v

Category:

Внезапно торкнуло

Меня внезапно торкнуло.

Вот есть механизм Path MTU Discovery. Типичный случай.

Клиент устанавливает HTTPS-соединение. Сервер начинает слать ему payload с флагом DF (Don't Fragment). Роутер где-то по дороге понимает, что пакет не протиснется через очередное звено маршрута, а фрагментировать пакет низззя потому что DF. Тогда он шлёт серверу ICMP-сообщение "Fragmentation needed" и говорит, мол, "кромсай на пакетики помельче". После чего всё благополучно бегает. Это если совсем на пальцах. И к слову о том, почему не стоит из соображений "безопасности" фильтровать ICMP.

Но тут я внезапно вспомнил, что сейчас уже почти на всех современных сетевых картах есть поддержка TCP Segmentation Offloading (TSO). И в ядре она практически всегда включена по умолчанию.

То есть, если вы натравите какой-нибудь tcpdump / wireshark и иже с ними на сетевой интерфейс и будете изучать исходящий трафик, то "без палева" внезапно увидите там пакетики длиной килобайта по четыре и шосукахарактерно с неправильной контрольной суммой. Это вот как раз оно и есть. Покромсает потом уже сама сетевая карта. И если хочется узреть "настоящую" длину кадра и контрольную сумму, то надо либо отключать offloading в драйвере интерфейса, либо снимать пакет с порта коммутатора. Кому интересно, подробнее есть вот здесь.

Но теперь я задумался: класть бороду под одеяло или на одеяло как TSO уживается совместно с Path MTU Discovery? То есть по идее, сетевая плата не сможет обработать входящее ICMP-сообщение "Fragmentation needed", она для этого недостаточно умная. Ядро его, конечно, получит и примет к сведению... но на что это повлияет, когда на кадры режет-то всё равно сетевуха? Этот вопрос отныне не будет давать мне спать ночами.

А задался я им вот почему. Тут шаловливые мои ручки решили "пооптимизировать" один IPSEC-тоннель и выставить на нем MTU=1446, дабы шифрованный туннелированный пакет вместе с оверхедом по-прежнему бы умещался в один кадр на сети провайдера. Но при этом отвалились HTTPS-ресурсы по одну из сторон тоннеля. И как прикажете понимать, это я вляпался в очередной баг ждунипера, или же просто Path MTU Discovery не работает одновременно с TSO?

Посидел бы со снифферами, но на боевой среде отлаживать это достаточно тяжело. Слишком много всякого говна трафика летает.

Tags: it, juniper, наброс, сети, ссылки
Subscribe

  • И снова PostgreSQL

    ... Есть у нас один "проблемный" сервис, который очень сильно нагружает БД PostgreSQL. Вытащили его из общего кластера на отдельную…

  • Вдогонку про IPSec

    Вдогонку к предыдущему посту. Я разобрался в чём косяк. В IKEv2 появилась новая фича: так называемый "childless IKE_SA" (RFC6023). Это…

  • Очередные грабли с IPSec (StrongSWAN + Juniper + IKEv2)

    Во время строительства очередного IPSec-а опять традиционно походил по граблям. Потерял кучу времени и замудохал саппорт одного хостинг-провайдера.…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 4 comments