Comments 13
> Ну и вот как понять, в чем был затык то? почему трафик себя так вел? почему через socks с того же самого интерфейса соединения проходили? как вообще делать траблшутинг при таком?
Похоже, что затык был с MTU, и вам помогло включение вот этой настройки:
> Change TCP MSS=yes
Причина этому - у вас в LAN скорее всего стоит стандартный MTU=1500, который в туннель PPPoE с MTU=1492 не пролезает.
Короткие пакеты проходят, длинные нет - отсюда и вся причудливость глюков. Дополнительный бонус к причудливости - некоторые большие пакеты могут пройти, если у них не стоит бит DF (то есть разрешена фрагментация - роутер сам порежет большой пакет на два), а некоторые большие пакеты не пройдут (если стоит бит DF).
Если включено Change TCP MSS - микрот на этапе установки TCP соединения вмешивается в заголовки TCP и меняет там значение MSS для обоих сторон так, чтобы итоговый MTU не превышал MTU на интерфейсе в который будет отправлен пакет, тем самым устраняет эту проблему (так как несмотря на MTU=1500 на конечных устройствах они из-за ограничения MSS не будут генерировать настолько длинные пакеты для TCP соединений).
А вот для UDP будет дейстововать всё тот же MTU=1500, и соответственно там сейчас творится всё такая же вакханалия. По хорошему вам надо выставить MTU=1492 на оконечных устройствах, чтобы избежать проблем с UDP и прочим не-TCP трафиком.
> почему через socks с того же самого интерфейса соединения проходили?
Потому что в этом случае трафик с MTU=1500 терминируется на самом микроте, а дальше уже микрот генерирует новые пакеты с MTU=1492 и шлёт их уже в PPPoE туннель, и разумеется эти новые пакеты пролезают туда нормально.
> как вообще делать траблшутинг при таком?
Определить реальный MTU (например с помощью ping с включенным DF битом и указанием размера пакета: ping -M do <ipaddr> -s <SIZE>, где SIZE это размер данных с учётом IP и ICMP заголовков (то есть, для MTU=1500 SIZE будет 1500-28==1472).
Подробнее тут: https://www.opennet.ru/base/net/pppoe_mtu.txt.html
Вообще, если в сети где-то есть туннель - всегда надо задуматься об MTU, так как заголовки туннеля отбирают какое-то количество байт от MTU (причём разные туннели отбирают разное количество MTU).
> Ну и вот как понять, в чем был затык то? почему трафик себя так вел? почему через socks с того же самого интерфейса соединения проходили? как вообще делать траблшутинг при таком?
Похоже, что затык был с MTU, и вам помогло включение вот этой настройки:
> Change TCP MSS=yes
Причина этому - у вас в LAN скорее всего стоит стандартный MTU=1500, который в туннель PPPoE с MTU=1492 не пролезает.
Короткие пакеты проходят, длинные нет - отсюда и вся причудливость глюков. Дополнительный бонус к причудливости - некоторые большие пакеты могут пройти, если у них не стоит бит DF (то есть разрешена фрагментация - роутер сам порежет большой пакет на два), а некоторые большие пакеты не пройдут (если стоит бит DF).
Если включено Change TCP MSS - микрот на этапе установки TCP соединения вмешивается в заголовки TCP и меняет там значение MSS для обоих сторон так, чтобы итоговый MTU не превышал MTU на интерфейсе в который будет отправлен пакет, тем самым устраняет эту проблему (так как несмотря на MTU=1500 на конечных устройствах они из-за ограничения MSS не будут генерировать настолько длинные пакеты для TCP соединений).
А вот для UDP будет дейстововать всё тот же MTU=1500, и соответственно там сейчас творится всё такая же вакханалия. По хорошему вам надо выставить MTU=1492 на оконечных устройствах, чтобы избежать проблем с UDP и прочим не-TCP трафиком.
> почему через socks с того же самого интерфейса соединения проходили?
Потому что в этом случае трафик с MTU=1500 терминируется на самом микроте, а дальше уже микрот генерирует новые пакеты с MTU=1492 и шлёт их уже в PPPoE туннель, и разумеется эти новые пакеты пролезают туда нормально.
> как вообще делать траблшутинг при таком?
Определить реальный MTU (например с помощью ping с включенным DF битом и указанием размера пакета: ping -M do <ipaddr> -s <SIZE>, где SIZE это размер данных с учётом IP и ICMP заголовков (то есть, для MTU=1500 SIZE будет 1500-28==1472).
Подробнее тут: https://www.opennet.ru/base/net/pppoe_mtu.txt.html
Вообще, если в сети где-то есть туннель - всегда надо задуматься об MTU, так как заголовки туннеля отбирают какое-то количество байт от MTU (причём разные туннели отбирают разное количество MTU).
Есть же хороший специализированный форум. Форуммикротик, лучше вопросы задавать там. А по проблематике S-trace все верно понял и правильно написал, 99.9 что проблема в mtu.
По хорошему вам надо выставить MTU=1492 на оконечных устройствах
Ни в коем случае. За это отвечает механизм Path MTU Discovery. Роутер, видя, что не может отправить в интерфейс пакет с флагом DF из-за превышающего размера, должен этот пакет отбросить и сгенерировать клиенту ICMP Type 3 Code 4 с указанием MTU. На основе этого сообщения, клиент формирует новый пакет, не превышающий указанный размер.
Возможно, в данном случае, автор выключил этот механизм на роутере, или зафильтровал данное сообщение.
Вот, думаю, достаточное освещение данной темы от самих микротиков
https://mum.mikrotik.com/presentations/RU18M/presentation_5659_1538438877.pdf
Некоторые "заботливые" провайдеры блокируют трафик ICMP. Тогда PMTU discovery не поможет.
Да, к сожалению, такие до сих пор встречаются. Но надеюсь, все меньше и меньше )))
Но если с таким сталкиваешься, то спасает просто выставить на интерфейсе, смотрящего в провайдера, выставить MTU в ту цифру, которую нашли опытным путем (mturoute.exe или tracepath). Ваш-то роутер позволит нормально отработать PMTUD для клиентов. Но согласись, выставлять руками на всех своих клиентах MTU - это как минимум контрпродуктивно )
Тоже сталкивался с похожей проблемой при поднятии тунеля EoIP. Часть сайтов открывается, часть - нет. Проблема плавающая, суть понять было трудно, причем по всей сети (до и после тунеля).
Подсказали настроить правило которое будет менять MSS пакета. Сильно тогда не вникал, но все заработало и проблемы исчезли.
Причем поведение микрота при похожей проблеме очень странное - он просто теряет пакетв
Определить макс. размер пакета:
ping -f -l <размер-пакета-в-байтах> <ip-адрес>
mtu mss туда копай и будет тебе счастье
Мне что-то не понравилась 7.10. Обновил домашний после 7.9. Незначительные моменты не понравились (правило нетвотча улетело, одно правило Mangle включилось, хотя я его отключил в 7.9). Накатил 7.10.1 уже на 7.10, что-то тоже какие-то траблы (по крайней мере, потерял удалённый доступ).
Проблемы с трафиком из локальной сети. Mikrotik RouterOS, PPPoE