Чудес не бывает. Пристально смотрите на операторский канал без IPSec, пинг не показатель. Возможно возникают потери при утилизации полосы, возможно потери фрагментов или у них странно настроенный DPI присутствует или еще что. Банально соседний клиент включает торрент и оборудование провайдера не успевает обрабатывать пакеты, а ICMP проходит без задержек из за большего приоритета.
Поддержу за DPI, после влетания одного сервера в списки РКН из нетбайнета, например, начали рваться ssh-соединения на этот сервер при отсутствии постоянной активности. Только -o ServerAliveInterval=1 кое-как помогает (именно 1, даже на 5 секундах тоже рвётся). По симптомам - не долетает часть пакетов.
Провайдеры, особенно местячковые, на многое способны. Вплоть до отбрасывания n-ных фрагментов на портах доступа из-за кривых настроек или глючного Д-Линка. Я бы составил с юристом претензию, на которую провайдер официальной бумажкой ответит "проблемы на вашей стороне", потом взял бы в аренду поверенное тестовое оборудование или заказал работы по тестированию таким оборудованием, запротоколировал проблему и выкатил повторную претензию вместе со счетом на компенсацию затрат, но это подразумевает изначально грамотный договор с провайдером, а не то, что обычно клиенты подписывают не глядя.
MTU физического окончания менять нет смыла и/или возможности. MTU туннеля понизить могло бы помочь от одной из причин, но крайне маловероятно, что у вас эта причина, так как проблемы были бы не эпизодически, а постоянно и выражались бы не в задержках, а в потерях.
Так что этот совет из серии "протереть стёкла, попинать по колёсам".
Ну, с каналом-то мы ничего сделать не можем, в нашей власти только окончания. Или виртуальные/туннельные интерфейсы (если вы их используете), которые заворачиваются в IPSEC. А для начала можно попросту посмотреть, как пролезают большие пакеты через сеть провайдера. Особенно в моменты возникновения проблем с IPSEC. Пинг-то по умолчанию короткий, а вот если где-то в оборудовании провайдера притаилась фрагментация/дефрагментация, то вмомент конда она начинается, задержка может скачком увеличиться. А кстати, посмотрите, не приходит ipsec вам фрагментированным, для начала.
Dlink DFL-260E с одной стороны и DFL-860E с другой.
Пакетом по 1400, без фрагментации, и туда, и туда. Между концами может и до 80мс иногда подниматься, но в среднем - 30мс. Задержки в туннеле не всегда увязаны по времени с задержками между концами - может быть 600-700 в IPSec`е и 40-50 между WAN`ами. А может быть 70-80 снаружи и 80-90 внутри. Бред какой-то.
"Маршрутизация статическая" - в смысле, без OSPF и BGP, но вполне автоматизировано. Мониторинг маршрута каждую минуту шлёт в этот маршрут ping, если нет ответа или latency слишком высокий - маршрут помечается как failed. Но к вопросу это отношения не имеет.
Ну, для диагностики я бы начал с записи sflow (netflow) на нешифрованном канале и в шифрованном (там, где ipsec). По таймингам пакетов можно будет понять, оборудование это или нет. (Для обоих концов, причём надо проверять оба направления, итого, 4 раздельных проверки).
Когда будет видно, что процесс шифрования не создаёт пиков в latency, следующая цель - лаборатория, состоящая и генератора ipsec пакетов (можно тупо сделать replay для записанного трафика с помощью scapy) и отвечателя на них (например, icmp unreachable с помощью iptables на получателе, плюс локальная запись в лог на получателе). Лог этой записи плюс описание лабы позволит ткнуть провайдера в проблему "я шлю пакет, а получатель его видит через 800000 us вместо обычных 4000 us".
Хотя я подозреваю, что проблема просто в пересогласовании ключей между отправителем и получателем. Пока они не передоговорятся, трафик-то не шлётся (или дропается?).
Comments 27
Reply
Reply
Reply
Reply
Reply
Reply
Так что этот совет из серии "протереть стёкла, попинать по колёсам".
Reply
Reply
Reply
Пакетом по 1400, без фрагментации, и туда, и туда. Между концами может и до 80мс иногда подниматься, но в среднем - 30мс. Задержки в туннеле не всегда увязаны по времени с задержками между концами - может быть 600-700 в IPSec`е и 40-50 между WAN`ами. А может быть 70-80 снаружи и 80-90 внутри. Бред какой-то.
"Маршрутизация статическая" - в смысле, без OSPF и BGP, но вполне автоматизировано.
Мониторинг маршрута каждую минуту шлёт в этот маршрут ping, если нет ответа или latency слишком высокий - маршрут помечается как failed. Но к вопросу это отношения не имеет.
Попробую сравнить PCAP`ы.
Reply
Когда будет видно, что процесс шифрования не создаёт пиков в latency, следующая цель - лаборатория, состоящая и генератора ipsec пакетов (можно тупо сделать replay для записанного трафика с помощью scapy) и отвечателя на них (например, icmp unreachable с помощью iptables на получателе, плюс локальная запись в лог на получателе). Лог этой записи плюс описание лабы позволит ткнуть провайдера в проблему "я шлю пакет, а получатель его видит через 800000 us вместо обычных 4000 us".
Хотя я подозреваю, что проблема просто в пересогласовании ключей между отправителем и получателем. Пока они не передоговорятся, трафик-то не шлётся (или дропается?).
Reply
Leave a comment