Маркировка исходящих соединений.

Обсуждение общих вопросов, не касающихся настройки оборудования и ОС
Ответить
KARaS'b
Сообщения: 848
Зарегистрирован: 29 сен 2011, 09:16

26 дек 2018, 10:55

Многоуважаемые, а помогите моему мозгу остыть, пока он не перегрелся и не вытек)
Есть тоннель тик-тик, используется что бы видеть то, что по мнению ркн видеть низя. :hi_hi_hi:
Есть удаленный CHR, у него есть только внешний адрес и всего один интерфейс. Поднимаем до него тоннель и получаем тоннельные адреса, допустим 192.168.YYY.1 у CHR и 192.168.YYY.2 с нашей стороны, при этом основная адресация на нашей стороне отлична от тоннельной 192.168.XXX.0/24

На стороне "клиента" берем мангл и делаем раз

Код: Выделить всё

/ip firewall mangle
add action=mark-routing chain=prerouting dst-address-list=freeVPN new-routing-mark=freeVPN passthrough=no
Дальше берем маршрутизацию и делаем два

Код: Выделить всё

add distance=1 gateway=chr routing-mark=freeVPN
И на стороне CHR добавляем маршрут что бы он знал кто это такие к нему обращаются

Код: Выделить всё

add distance=1 dst-address=192.168.XXX.0/24 gateway=192.168.YYY.2
На этом этапе какбэ все, все кто находится в ХХХ.0/24 начинают спокойно ходить туда, куда им ходить низя)

Но тут появляется желание попробовать натификяшки от роутера через телегу и поскольку она заблочена, то мы понимаем что работать это не будет, пока мы не завернем трафик самого роутера до телеграма в тоннель.
На этом этапе у меня начались сомнения в том, правильно ли я делаю, но сделал еще вот так

Код: Выделить всё

/ip firewall mangle
add action=mark-routing chain=output dst-address-list=freeVPN new-routing-mark=freeVPN passthrough=no
И нифига, ресурсы телграм по прежнему недоступны, при этом счетчик мангла по правилу output накручивается. Трассировка показывает что трафик почему-то стучит на внешний IP CHR, что вообще будоражит сознание! Но стоит только начать маскарадить трафик уходящий в тоннель, сразу все начинает работать. До этого пользовался бесплатным vpn и там конечно же выходящий в тоннель трафик тоже натился, там то это было необходимо, но в случае со своим CHR и настроенной на нем маршрутизацией, думал, что это лишнее, тем более когда трафик генерирует сам маршрутизатор, который какбэ априори имеет адрес известный CHR, а оказалось что нет.

Как выкрутиться я конечно нашел, но больше хотелось бы понять, почему оно так (почему не работает без маскарада всего что уходит от меня в тоннель) и где я сделал не правильно. :-(


vqd
Модератор
Сообщения: 3586
Зарегистрирован: 26 сен 2013, 14:20
Откуда: НСК
Контактная информация:

26 дек 2018, 18:48

оу, ну тут надо смотреть конфиги, где то похоже мелочь какую то пропустили

Вообще в таких случаях очень помогает анализ соединений. Там как бы все видно, ну вообще в непонятных ситуациях создаем кучу логирующих правил и изучаемссс долго и мучительно


Есть интересная задача и бюджет? http://mikrotik.site
KARaS'b
Сообщения: 848
Зарегистрирован: 29 сен 2011, 09:16

27 дек 2018, 23:24

Буду честен, пока еще не пытался воспользоваться советом и помониторить соединения, но только что в голову пришла мысль-догадка про то, что маршрутизатор понимая, что адреса назначения живут где-то в интернетах, смотрит свою таблицу маршрутизации main и подставляет в src адрес пакета, адрес наиболее подходящий для дефолтного маршрута, ака внешний с ван интерфейса, а уже потом трафик уходит в тоннель, отсюда и стуки на внешний интерфейс CHR, который еще к тому же и ответить пытается, скорее всего, с внешнего интерфейса, отсюда и сплошные таймауты на первом же хопе.


vqd
Модератор
Сообщения: 3586
Зарегистрирован: 26 сен 2013, 14:20
Откуда: НСК
Контактная информация:

28 дек 2018, 07:14

ну вот анализ соединений это и покажет, а дальше уже предпринимать шаги-действия

А ну и вот еще. Для того что бы микротик работал через определенную таблицу маршрутизации и не пытался перекинуть в main маркированный трафик, следует об этом ему сказать в ip - route - rules


Есть интересная задача и бюджет? http://mikrotik.site
Ответить