Не срабатывает маршрутизация при маркировке. Как исправить?

Такая штука происходит, когда отключаю маршрут, т.е. остается

Код:

/ip route
add distance=1 gateway=192.168.0.1 routing-mark=test

При этом если

Код:

ping routing-table=test 8.8.8.8

то всё хорошо
Гоняю это на hap lite.
в Torch с использованием одного маршрута ничего не попадает.
Но само-собой ловятся пакеты которые идут с ПК на 8.8.8.8

P.S. Может я что то упустил? Например должно быть не одно output правило?

 

Есть ли решение с использованием mangle? Или единственное правильное решение останется только с правильной расстановкой маршрутов main (по дистанции)?
Большое спасибо! Схему сегодня уже смотрел, но не верно ее разложил и понял.

 

Всё равно не догоняю как настроить...

 

Теперь ясно.
Для срабатывания mangle в output обязательно должен быть маршрут main(даже пусть и не верный), тогда всё начинает работать. Этакий подводный камень...
Большое спасибо!

 

Протестировал, Black Hole и Prohibited варианты не срабатывают, пакеты отбрасываются раньше чем доходят до output'а.
Единственный правильный вариант, использовать один реальный/неверный маршрут.

 

Здравствуйте. А подскажите как для маркированного маршрута настроить доступ к внешнему IP изнутри. Т.е. сам на себя.
Сам порт открывать получается. А вот стукнуть на него изнутри нет.
Без mangle все работает.
На всякий случай уточню. Основной интернет у меня работает на pppoe и не маркирован, правила для порта 123 работают, он открыт снаружи и доступен изнутри для определенного локального статик адреса, либо всей локальной сети. Нужно настроить доступ к такому же порту, но на другом статик IP в этой же сети, но уже с выделенного IP на 3G модеме.
Спасибо!

 

ну я как понимаю dual WAN нужно настроить. Т.е маркировать весь трафик WAN1 и WAN2

 

Что-то я не продумал такой вариант.
Попробую, спасибо.

 

Коллеги, очень прошу помощи! Тоже столкнулся с разновидностью неработоспособности маркирования роутинга. Задача стоит простая - заворачивать обращения к хостам Телеграма в PPTP-тоннель. Казалось бы, что проще, но нет. Что делаю:

Список узлов, которые заворачиваем:

Код:

/ip firewall address-list

add address=91.108.4.0/22 list=Telegram
add address=91.108.8.0/22 list=Telegram
add address=91.108.12.0/22 list=Telegram
add address=91.108.16.0/22 list=Telegram
add address=91.108.56.0/22 list=Telegram
add address=149.154.160.0/22 list=Telegram
add address=149.154.164.0/22 list=Telegram
add address=149.154.168.0/22 list=Telegram
add address=149.154.172.0/22 list=Telegram
add address=149.154.167.220 list=Telegram

Манглы:

Код:

 0    ;;; Mark Telegram
      chain=output action=mark-routing new-routing-mark=mark_telegram passthrough=no dst-address-type="" dst-address-list=Telegram log=no log-prefix=""

1    chain=prerouting action=mark-routing new-routing-mark=mark_telegram passthrough=yes dst-address-list=Telegram log=no log-prefix="" 

Тоннель:

Код:

/interface pptp-client add comment="Telegram VPN" connect-to=PL226.vpnbook.com disabled=no name=TelegramVPN user=vpnbook password=5bhea6u

Маршрут для трафика Телеги (с меткой):

Код:

/ip route add comment="Telegram to TelegramVPN" distance=1 gateway=TelegramVPN routing-mark=mark_telegram

Но, увы и ах, не работает. Ниже даю больше деталей:

- Доступ к Телеге для LAN-клиентов не нужен, нужен только для собственных пакетов микрота (поэтому у меня нет соотв. правила на маскарадинг). Доступ делается для Микротик-скрипта.
- Пакеты для 149.154.167.220 должным образом маркируются, что видно по счетчику пакетов в Mangle. Любой ping до 149.154.167.220 дает непрерывный рост счетчика, так что тут все ок.
- VPN-тоннель PPTP активен и подключен, и в нем появляются TX-пакеты, когда я делаю /tool fetch url="http://api.telegram.org/"

Конкретно что не так - обращения к узлам Телеги идут через ненужный мне интерфейс LAN5-WAN (вместо VPN-интерфейса TelegramVPN). До того момента, пока в маршруте TelegramVPN я не уберу routing_mark. Это я узнаю так:

Код:

[Mikrot] > /ip route check 149.154.167.220
     status: ok
  interface: LAN5-WAN
    nexthop: 89.xxx.xxx.x

Таблица маршрутизации:

Код:

 0 A S  0.0.0.0/0          192.168.2.1     TelegramVPN               1
1 A S  0.0.0.0/0                          89.xxx.xxx.x              2
2 ADC  89.xxx.xxx.0/21    89.xxx.xxx.xx   LAN5-WAN                  0
3 ADC  172.16.36.1/32     172.16.36.xxx    TelegramVPN               0
4 ADC  192.168.2.0/24     192.168.2.1     LAN-Bridge                0

Где 192.168.2.1 - собственный адрес Микротика в LAN.

routing_mark убрать в маршруте навсегда не могу, так как маршрута 0.0.0.0/0 у меня два, и маршрут 0.0.0.0/0 для MikrotikVPN начинает главенствовать над 0.0.0.0/0 89.xxx.xxx.x, который является дефолтным (выход в интернет).

Очень прошу помочь, так как чувствую, что я рядом, но не хватает какой-то мелочи.

 

Коллеги,

Вот полный конфиг устройства.

Сейчас веду переписку с Васильевым Кириллом, но пока не ясно WTF

 

Мне кажется, что проблема где-то здесь.

Код:

[mikroroot@Mikrot] > ip route check 149.154.167.220
     status: ok
  interface: LAN5-WAN
    nexthop: 89.xxx.xxx.xxx

В Торче в SRC и DST видна какая-то чушь - узел Телеграмма виден как SRC, а сетка с VPN - как DST.

 

Проблему решил!
И дело не в каких-то подвоных камнях схемы роутинга Микротика, или маркирования другого роутинга (main), и так далее, а в куда более простых вещах. В чем конкретно был затык - не скажу, но последовательное тестирование механизма обхода блокировки Телеги, позволило найти все причины.

1. С ростом версии ROS немного поменялась концепция обработки символа комментария, #. Теперь # в начале пустой строки при вставке в консоль соединяется со строкой, идущей вслед за решеткой. Даже если был перевод строки после решетки.
У меня в скрпите был такой фрагмент:

Код:

#
# Some comment
#

И в процессе апгрейдов 6.xx этот кусок скрипта перестал нормально обрабатываться.

2. VPN-сервис VPN99 (платный, но дешевый), на который я решил перейти с vpnbook, по какой-то причине прекрасно дает делать fetch url до узла api.telegram.org по протоколу http (правильный ответ 301 или 302), но не дает делать то же самое по протоколу https (а именно он нам и нужен). При использовании VPN99 и https выдается или таймаут или fail, точно не помню. Тупо при замене VPN на другого поставщика, проблема уходит.
В примере выше показан vpnbook, но я для теста также уходил на VPN99. В какой-то момент играя с fetch url и сравнивая запросы и ответы с обычным бразуером, подключенным через другой VPN, я нашел вышеуказанную проблему с SSL. Чем она вызвана - не имею представлений.

3. Вот здесь у меня была написана чушь:

Код:

add address=149.154.164.0/22 list=Telegram
add address=149.154.168.0/22 list=Telegram
add address=149.154.172.0/22 list=Telegram
add address=149.154.167.220 list=Telegram

Так как 149.154.167.220 входит в 149.154.164.0/22. Не знаю, могло ли это что-то рушить.

4. В некоторых гайдах по настройке обхода Телеги создается только mangle-правило на маркирование роутинге в звене prerouting. И при этом ни слова не сказано о том, что это будет работать только для LAN-клиентов, но не для самого роутера (и его скриптов). Для роутера и его скриптов нужна цепочка output и только она. Цепочка prerouting нафиг не нужна.
Не могу сказать что причиной была цепочка, так как я пробовал обе цепочки попеременно, а также 2 одновременно. От безысходности.

5. Даже несмотря на то, что доступ к Телеге нужен только самому роутеру (клиентам в LAN он не нужен!), все равно нужен маскарадинг на VPN-интерфейсе! Я уж не знаю зачем, но без него не работает. При этом в правиле на маскарад нельзя указать IP-адрес вашего роутера в LAN как src-адрес . Так как там почему-то фигурируют совершенно другие IP-адреса из другой сети, и если вы укажете там LAN-адрес роутера или всю LAN-сеть, то ничего не заработает.
Но данную настройку нельзя отнести к единственной причине неработоспособности моего сетапа, так как я добавлял и удалял src-адрес 100500 раз (метод ненаучного тыка).

Готовый рабочий конфиг в пару кликов (copy/paste) в Terminal:

Код:

/ip firewall address-list
add address=91.108.4.0/22 list=Telegram
add address=91.108.8.0/22 list=Telegram
add address=91.108.12.0/22 list=Telegram
add address=91.108.16.0/22 list=Telegram
add address=91.108.56.0/22 list=Telegram
add address=149.154.160.0/22 list=Telegram
add address=149.154.164.0/22 list=Telegram
add address=149.154.168.0/22 list=Telegram
add address=149.154.172.0/22 list=Telegram
/ip firewall mangle
add action=mark-routing chain=output comment="Mark Telegram" dst-address-list=Telegram new-routing-mark=mark_telegram passthrough=no
/interface pptp-client
add comment="Telegram VPN" connect-to=your_vpn_server disabled=no name=TelegramVPN password=vpnpass user=vpnuser
/ip firewall nat
add action=masquerade chain=srcnat out-interface=TelegramVPN
/ip route
/ip route
add comment="Telegram to TelegramVPN" distance=1 gateway=TelegramVPN routing-mark=mark_telegram

 

vpn99.net тоже работает, mtu надо уменьшить.

 

Да, я тоже дошел в итоге до MTU. Решение описано здесь: http://aptem.ru/all/pptp-tonnel-i-nedostupnost-saytov-cherez-ssl-https/