+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

DST-NAT через два шлюза

DST-NAT через два шлюза, RouterOS

tete

Guest

30.12.2008 11:42:00

Привет всем, у меня есть MKT, подключенный к двум xDSL соединениям… Не хочу балансировку нагрузки, но мне нужен доступ к одному TS-серверу в локальной сети. Я могу получить доступ к маршрутизатору через оба соединения с помощью правила маршрутизации, и это нормально. У меня есть dst-nat через шлюз по умолчанию, чтобы получить доступ к TS, и это работает нормально. Проблемы начинаются, когда я пытаюсь сделать dst-nat через интерфейс другого шлюза (не по умолчанию) — правило не срабатывает. Я прослушивал трафик на MKT и заметил, что пакет приходит через Не стандартный шлюз, переводится на LAN-сервер, но отправляется через шлюз по умолчанию, а не через интерфейс, на который пришел пакет. Я сделал правило mangle, которое помечает новые соединения с этим сервером, а затем другое правила, которое помечает маршрутизацию на основе этой метки соединения. Я создал маршрутную политику, чтобы применить эту метку маршрутизации, но это по-прежнему не работает. Я проанализировал эту ситуацию, и пакет приходит на LAN-сервер, но не возвращается. Вот моя конфигурация:

add chain=prerouting action=mark-connection new-connection-mark=Conexion-WIFI passthrough=yes connection-state=new in-interface=WIFI dst-port=33392 protocol=tcp comment="" disabled=no
add chain=prerouting action=mark-routing new-routing-mark=100 passthrough=no connection-mark=Conexion-WIFI comment="" disabled=yes
add chain=dstnat action=dst-nat to-addresses=192.168.100.6 to-ports=3389 in-interface=WIFI dst-port=33392 protocol=tcp comment="ПАТ портов TS на SRVSQL1" disabled=no
add dst-address=0.0.0.0/0 gateway=XXX.XXX.XXX.XXX distance=1 scope=255 target-scope=10 routing-mark=100 comment="" disabled=no
add src-address=XXX.XXX.XXX.XXX/32 action=lookup table=100 comment="" disabled=no
add routing-mark=100 action=lookup table=100 comment="" disabled=no

У кого-нибудь есть предложения? Заранее спасибо, Тете.

Sob

Guest

31.03.2018 12:04:00

Проверьте http://wiki.mikrotik.com/wiki/Manual:PCC и проигнорируйте саму часть PCC. Короче говоря, вам нужно отметить входящие соединения исходя из их источника, а затем правильно отметить маршрутизацию для ответов, чтобы они возвращались тем же маршрутом. И, пожалуйста, не поднимайте старые темы девятилетней давности.

anav

Guest

31.03.2018 16:30:00

Как обычно, отсутствие ясности затрудняет понимание того, что именно спрашивается или объясняется. У автора сообщения две ADSL-связи (два WAN-порта). Балансировка нагрузки между двумя соединениями не требуется, так что более типичный вариант "используй WAN2 только если WAN1 выйдет из строя" будет вполне достаточно. На мой взгляд, это случай, когда нужно сделать ДВЕ маршрутизации и только одно правило маскировки:
1. wan1 0.0.0.0/0 с адресом шлюза провайдера ISP1, расстояние=1
2. wan2 0.0.0.0/0 с адресом шлюза провайдера ISP2, расстояние=2

В меню выбора интерфейса перейдите на вкладку "список интерфейсов" и убедитесь, что в списке WAN у вас есть ваши WAN-провайдеры ISP1 и ISP2. Основное правило SRCNAT, охватывающее весь трафик, покидающий маршрутизатор:
- Srcnat цепочка: out - interface list - WAN, действие: masquerade.

Следующий шаг - автор обсуждает необходимость виртуального сервера или переадресации портов через правило NAT dstnat: в -списке интерфейсов - WAN, цепочка - dstnat, необходимый протокол, предполагая TCP, порт 3389. Выберите dstnat в качестве действия и введите IP-адрес назначения, т.е. LANIP сервера TS - 192.168.100.2 (перевод портов не требуется).

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

ПРОБЛЕМА: При такой настройке маршрутизатор будет отслеживать, какой трафик поступает на какой интерфейс, и возвращать трафик через соответствующий интерфейс. То, что WAN2 используется только для резервирования, должно затрагивать только новые сессии, инициированные за маршрутизатором Microtik. Другими словами, MT заставит все новые исходящие сессии LAN проходить через ISP1. Я предполагаю, что люди используют динамические DNS-имена для доступа к вашим ISP1 и ISP2. Не должно быть проблем с одним IP-адресом TS, так как переадресация портов идет с разных WAN-интерфейсов. Надеюсь, это поможет, и если кто-то увидит в моих мыслях или знании правил какие-то пробелы, пожалуйста, дайте знать!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Далее автор заявил нечто, что для меня не имеет смысла, но я перенес эту часть в конец, так как она отвлекает. Я могу получить доступ к маршрутизатору через оба соединения с помощью маршрутизационного правила, и это нормально. Эм, я никогда не слышал о создании маршрутизационного правила для доступа к маршрутизатору из интернета??? Меня бесит, что возникают предположения:
a. он имеет в виду, что использует названия dydns для доступа к маршрутизатору через оба провайдера: dydns1 для isp1 и dydns2 для ISP2??
b. Что именно он получает, когда обращается к маршрутизатору?
i. имеет ли он в виду winbox для управления маршрутизатором?
ii. имеет ли он в виду сервер (и все, что с этим связано)?
iii. или он просто может пинговать маршрутизатор с удаленного сайта?
c. Неясно, говорит ли он о том, что делает эти вторжения с WAN-стороны из удаленного сайта или ОН ПЫТАЕТСЯ СДЕЛАТЬ ХЭРПИНДИНГ.

Следующее утверждение немного яснее, но все еще недостаточно описано. Он хочет получить доступ к серверу TS в своей локальной сети, но…
a. имеется ли в виду доступ от других пользователей в интернете?
b. имеет ли он в виду доступ из-за маршрутизатора Mikrotik?
i. в этом случае просто используйте LANIP сервера TS, ха-ха.
ii. или это еще один случай херпинга, что, по моему мнению, усложняет уже доступную простую прямую линию LAN в LAN.

Sob

Guest

31.03.2018 17:44:00

Забудьте об авторе поста, эта тема с 2009 года, но кто-то решил ее воскресить с похожей проблемой. И нет, все не так просто. Допустим, у вас есть два WAN, с адресами 1.2.3.4 и 2.3.4.5. Вы хотите, чтобы внутренний веб-сервер был доступен по обоим адресам. Для этого вы добавляете обычное правило dstnat и удостоверяетесь, что оно работает для обоих адресов. Можно использовать ваш список входящих интерфейсов, список адресов назначения с этими двумя адресами, добавить отдельное правило для каждого адреса — что угодно. Но вы обнаружите, что есть только один маршрут по умолчанию, допустим, он на WAN1. Если подключение идет оттуда, ответ уйдет туда же, и все будет работать. Но если соединение приходит с WAN2, ответ будет отправлен на WAN1 (потому что это маршрут по умолчанию), и это не сработает. И это не ошибка, потому что асимметричная маршрутизация может быть тем, что нужно пользователю (но не с такой настройкой с двумя разными провайдерами). Вот почему маршрутизатор нуждается в указании, куда должен идти трафик. Именно для этого служит маркировка соединений/маршрутов на странице PCC.

anav Guest	#5 0 02.04.2018 01:41:00 Спасибо, SOB, я узнал что-то новое! То есть, невозможно настроить переброску портов с использованием двух интернет-провайдеров в сценарии резервирования, но можно при балансировке нагрузки?

skuykend

Guest

02.04.2018 02:27:00

Вы определенно можете использовать dstnat с двумя WAN... вам просто нужно убедиться, что вы управляете/маркируете новые входящие соединения и используете помеченную таблицу маршрутизации, которая будет иметь маршрут по умолчанию к правильному WAN. Если вы используете fasttrack, убедитесь, что вы не применяете fasttrack к измененным соединениям.

sindy

Guest

02.04.2018 08:09:00

Чтобы немного развить ответ @skuykend: и резервирование, и балансировка нагрузки основываются на политической маршрутизации, где вы выбираете конкретную таблицу маршрутизации в зависимости от определенных критериев. Для соединений, приходящих со стороны WAN, ключевым моментом является то, что они должны получать отметку соединения при поступлении, и отметка соединения, сделанная правилами балансировки нагрузки, не должна это переопределять. Резервирование является своего рода побочным эффектом балансировки нагрузки, если вы включаете порт источника в **** хэш по классификации соединений (потому что, если соединение разрывается, новая попытка его установить использует другой порт источника, что увеличивает шансы получить другую отметку соединения). Если вы используете другой WAN как резервный маршрут для каждой отметки маршрутизации, как вы делаете в настройке «только резервирование», вы можете устанавливать новые исходящие соединения через «неправильный» WAN, пока «правильный» не работает, но в этом случае они обрываются в момент, когда правильный WAN восстанавливается. Так что трудно сказать, какое поведение более удобно для пользователя. Для соединений с dst-nat нет разницы, они всегда обрываются, как только WAN, через который они пришли, отключается.

tete Guest	#8 0 14.01.2009 09:19:00 Привет, спасибо всем за советы... Я собираюсь протестировать эти решения и сообщу, если сработает... Приветствую вас

zippel Guest	#9 0 31.03.2018 04:25:00 та же проблема, два шлюза работают, но порты NAT не работают одновременно на двух шлюзах

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры