Почему не работает интернет без change-mss?

Question

[Шамиль]

Есть микротик, к которому подключены 2 провайдера:

• pptp; mtu-1436
  
• pppoe;mtu-1480
  

почему-то оба подключения требуют изменения change-mss в mangle, иначе большая часть сайтов практически не открывается (прошелся утилитой mtupath, нашел значения для установки в TCP MSS);

Пытался выяснить у провайдеров, первый отшил словами что у меня неправильный микротик, второй - пока не ответил, но говорят что кроме меня никто не обращался с подобной проблемой.

Почему я вообще решил обратиться за помощью, и не обращать внимание - потому что телефония 3CX перестала работать, оператор (пчелайн) сказал что мое оборудование отбрасывало пакеты., в результате пришлось перенести телефонию в другой офис, но как-только пропадает там интернет - колл центр начинает возмущаться

Comments

[Валентин]

Вот с телефонией вообще не понятно. Она через интернет работает чтоли? Да и странно как-то держать сип-транк в месте, далеком от основных потребителей услуги.

[Шамиль]

Валентин, IP телефония, крутится на виртуалке.
держать в основном офисе не получилось - роутер пакеты не принимал

Answer 1

[Wexter]

Потому что у вас локальная сеть MTU 1500, а pptp/pppoe меньше, добавьте правило

/ip firewall mangle add chain=postrouting action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface=all-ppp log=no

, тогда микротик сам будет дробить пакеты правильно

Comments

[Saenara]

<зануда моде он>
Я бы только исправил на "локальная сеть с MTU как минимум 1500", вдруг у него гигабит с поддержкой jumbo frames дома :-)
<зануда моде офф>

[Wexter]

Saenara, ну jumbo frames на гигабите дома это уже изврат непонятный. Да и люди использующие его скорее всего знают почему часть сайтов не работает через pptp/pppoe :)

[Шамиль]

Wexter, а кто сказал что я использую его дома ?
это на работе.
мне дома 2 провайдера с 2мя белыми IP не нужны

[Wexter]

Шамиль, проблему то решили?

[Шамиль]

Wexter, пока еще нет. вернее буду пробовать вечером.

[Шамиль]

Wexter, ваш скрипт работает, сайты открывает..
касательно MTU - в бридже микротика следующее

interface bridge print 
     name="bridge" mtu=auto <b>actual-mtu=1408</b> <b>l2mtu=1598 </b>arp=proxy-arp arp-timeout=auto 
     protocol-mode=rstp fast-forward=no igmp-snooping=no auto-mac=no 
     ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15
     transmit-hold-count=6 vlan-filtering=no

какая-то большая разница получается между actual-mtu & l2mtu.
поглядел как в других офисах - l2mtu - в среднем 1520

[Шамиль]

и вариант с построутингом встретил только у вас

[Wexter]

Шамиль, mtu в бридже равен минимальному mtu портов в нём, видимо у вас в бридже какой-то eoip туннель с mtu 1408 (вероятнее всего поднят поверх какого-нибудь pptp/l2tp/ppp/pppoe)

Answer 2

[Denis Michurin]

Странное дело у вас, конечно. Могу предложить поиграть с прошивками RouterOS. Может есть какой то баг

Comments

[Dmitry Tallmange]

Чего же тут странного? Какое-то вышестощее оборудование не хочет фрагментировать пакеты, вы упираетесь в ограничение MTU.

[Шамиль]

бага в прошивках нет.
тянется беда много лет, раньше просто правило автоматически создавалось в манглах (при создании pptp), начиная с версии 6.39 перестало.

Answer 3

[Дмитрий Скоромнов]

Рекомендую выложить конфигурацию целиком.

Comments

[Шамиль]

https://pastebin.com/uHF0EUK6

[Дмитрий Скоромнов]

Шамиль, к сожалению, сейчас загрузка увеличилась и внимательно проверить не успеваю. Прежде всего благодарю, что конфигурацию вставили отформатированную. Это заметно облегчает чтение.

То, что обнаружили опишу ниже. Не факт, что это поможет с Вашей проблемой, но тем не менее может оказаться полезным.

1. В Файерволе у Вас жесткий бардак. В цепочке Forward, если не считать правила блокирующего invalid трафик у Вас правила пустышки. Вообще советую внимательно прочесть всю статью.

2. Возможно торопился, но не понял назначение этого правила "add action=masquerade chain=srcnat out-interface=ether1"

3. Рекомендую указать исходящий интерфейс в этом правиле "add action=masquerade chain=srcnat comment="vpn_clients NAT rule" src-address=192.168.192.0/24"

4. Кажется у Вас есть проблемы с маршрутизацией. Есть отсылки к маркированным маршрутам "wan2_route" и "wan1_route". При этом самих маршрутов нет. Есть и другие подозрительные моменты.

Рекомендации:
Выполняйте именно в том порядке, как они будут идти.
1. Сделайте полную резервную копию.
2. Оставьте только одного Интернет-провайдера. Любого.
3. Отключите все, что касается маркировки маршрутов в /ip route, /ip route rule и /ip firewall mangle
4. Сбросьте все соединения в Connection Tracker и проверьте работу.
5. Разберитесь с правилами NAT. Больше всего меня смущает это правило "add action=masquerade chain=srcnat out-interface=ether1"
6. Сбросьте все соединения в Connection Tracker и проверьте работу.

Если помогло, то напишите на каком шаге.

[Grims]

По моему субъективному мнению в вашем ответе есть некоторые противоречия...
"у Вас правила пустышки"
Официальное, а не фейковое wiki рекомендует все-таки прописывать BOGON, если нет более жестких ограничений в INPUT.
Firewall Customer protection
Basic universal firewall script
BOGON Address List
Из статьи про пустышки:
1) "BOGON — это IP-адреса, которые не должны встречаться в таблицах маршрутизации в Интернет." - то что они там не должны быть это не значит что их там нет, это как с сусликом.
Если не доверяете мне посмотрите список от Hurricane Electric о том что Bogon сети в Интернете все же есть. Также ничто не мешает провайдеру завернуть bogon в вашу сторону и ломиться к вам на оборудование без всякого Интернета.
2) По поводу "Здесь я люблю задавать вопрос. Почему Вы решили заблокировать сеть 192.0.2.0/24, но при этом не стали блокировать 192.0.3.0/24 или 192.0.4.0/24 или 192.0.5.0/24?"
Есть RFC который регламентирует что такое BOGON и есть RFC который регламентирует что такое Private Address Space - сложить 1+1 для специалистов не составит труда.
Мораль такова, что не нужно слушать советы в Интернет, читайте только официальный сайт производителя оборудования и официальные документы IEEE, остальное все пустое.

[Дмитрий Скоромнов]

Grims,
1. Какие сети BOGON, которые могут инициировать обращение из-вне, не окажутся заблокированными правилом, которое блокирует invalid-трафик? Ответ: никакие. Вывод: блокировка BOGON смысла не имеет, если уже имеется правило, которое блокирует invalid-трафик. А наличие этого правила является правилом хорошего тона.
2. То, что RFC регламентирует, что такое BOGON не дает ответ на поставленный вопрос. Так же напоминаю, что часть сетей не являются постоянными и могут динамически изменятся со временем.
3. Аргумент про то, что надо надо читать официальную документацию очень хороший. Но еще лучше аргумент про то, что надо не просто слепо следовать рекомендациям, но и понимать, что и зачем делается. К сожалению, на официальной англоязычной Wiki не на 100% все гладко. Я сам несколько раз находил неточности на ней. К счастью, вендор обсуждает такие вопросы и при необходимости вносит правки.