Потратил тут примерно пару дней, на диагностику какой-то плавающей неисправности:
все больше и больше ресурсов не открывалось из моей домашней сети.
гугл, ютуб продолжали работать как ни в чем ни бывало.
некоторый трафик на 80 порт тоже ходил
некоторый - connection timeout
https трафик так же на какое то количество ресурсов падал в timeout.
проверил на gosuslugi - тоже не работает
при этом icmp - окей, ответы есть, а curl говорит:curl https://www.gosuslugi.ru/curl: (35) Recv failure: Соединение разорвано другой стороной
Выставлял для проверки чтобы с одного из локальных хостов трафик шел через VPN - все отлично работало.
Выключал - переставало.
Так как я в эти дни много возился со своим MikroTik RouterOS, то понять в чем конкретно дело сразу не мог:
я настраивал входящие VPN с нескольких локаций
пробовал wireguard и sstp
соответственно какие то правила firewall для трафика из/в те сети настраивал
я настраивал скрипты мониторинга, и рассылки уведомлений о событиях
я настраивал скрипт пере-подключения pppoe, при условии серого ip (провайдер выдает как белые, так и серые адреса для pppoe интерфейса, это рандом - надо просто пере-подключиться, и может быть будет белый адрес)
на днях routeros обновился до версии 7.10
ну мало ли на что можно подумать...
И вот, последние дни я наблюдаю что какие то ресурсы по http/https недоступны. И я уже начинаю наблюдать проблемы с другими протоколами (в рамках TCP).
Вчера уже tcpdump запустил, но ничего так и не понял. пытался отсеять запросы в локальной сети, потом pcap файл смотреть в wireshurk, но вот как то не хватило меня на это.
Сегодня уже смотрю, у мня в telegram картинки грузятся слишком медленно
Пришла мысль проверить как оно будет работать если выставить mikrotik как socks5 proxy, и с него открыть ресурсы (для тестов было достаточно habr.com и opennet.ru).
А все работает окей, вообще без нареканий.
Тогда я начинаю думать в сторону всяких правил firewall, но в больших сомнениях - ну как бы там нет такого, чтобы какие то ресурсы были выделены, куда трафик шел бы так, а в другое место иначе.
прошерстил, повыключал всякие устаревшие/неактуальные nat-ы, почистил все что мог - не помогает.
Думаю, ну черт с ним, надо попробовать пере-подключить pppoe на серый адрес.
а, у меня ж скрипт для пере-подключения, при определении, что адрес "серый". а скрипт запускается при поднятии интерфейса, а сделать это можно только если добавить script на event on up в profile, который привязан к pppoe интерфейсу.
ну, чтобы скрипт не убирать из профиля, я просто профиль поменял на стандартный "default", пере-подключился, получил новый ip, но при этом, вдруг, так же не из "серой" сети - и у меня все заработало сразу.
Ок, ясно. Дело в профиле для pppoe. Но что с этим делать то? в чем отличие от стандартного? есть одно - стоит Use UPnP=yes.
Выключаю и проверяю еще раз - меняю профиль на "pppoe_isp" - то с чем проблемы были - проблемы есть.
Проверил с профилем default-encryption - все работает как и должно, проблема отсутствует.
Для теста выставляю на профиле pppoe_isp : Change TCP MSS=yes, Use Compression=yes, Use Encryption=yes, включаю с этим профилем - и вуаля, проблемы больше нет.
Ну и вот как понять, в чем был затык то? почему трафик себя так вел? почему через socks с того же самого интерфейса соединения проходили? как вообще делать траблшутинг при таком?
// Знаю что в таком ключе публикации не приветствуются, и я надеюсь, что в комментариях будет больше полезного чем в теле этого поста.
Комментарии (6)
S-trace
20.06.2023 07:58+12> Ну и вот как понять, в чем был затык то? почему трафик себя так вел? почему через 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).
typ6o0jiehb Автор
20.06.2023 07:58+1Спасибо, ради такого ответа я собственно и делал пост. Меня смутило, что в profile вообще не указывается MTU, оно в задается в интерфейсе, и там оно указано как 1492. а вот тот факт что Change TCP MSS отвечает за то чтобы изменить его - я не подумал.
Kostetyo
20.06.2023 07:58Есть же хороший специализированный форум. Форуммикротик, лучше вопросы задавать там. А по проблематике S-trace все верно понял и правильно написал, 99.9 что проблема в mtu.
Vigogne
20.06.2023 07:58По хорошему вам надо выставить MTU=1492 на оконечных устройствах
Ни в коем случае. За это отвечает механизм Path MTU Discovery. Роутер, видя, что не может отправить в интерфейс пакет с флагом DF из-за превышающего размера, должен этот пакет отбросить и сгенерировать клиенту ICMP Type 3 Code 4 с указанием MTU. На основе этого сообщения, клиент формирует новый пакет, не превышающий указанный размер.
Возможно, в данном случае, автор выключил этот механизм на роутере, или зафильтровал данное сообщение.
Вот, думаю, достаточное освещение данной темы от самих микротиков
https://mum.mikrotik.com/presentations/RU18M/presentation_5659_1538438877.pdf
vassav
20.06.2023 07:58Тоже сталкивался с похожей проблемой при поднятии тунеля EoIP. Часть сайтов открывается, часть - нет. Проблема плавающая, суть понять было трудно, причем по всей сети (до и после тунеля).
Подсказали настроить правило которое будет менять MSS пакета. Сильно тогда не вникал, но все заработало и проблемы исчезли.
Причем поведение микрота при похожей проблеме очень странное - он просто теряет пакетв
S-trace
> Ну и вот как понять, в чем был затык то? почему трафик себя так вел? почему через 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).