[XuHT]

Заголовок банальный, но не очевидный. Расскажу

Суть заключается в том, что есть два провайдера, подключенные к разным интерфейсам. Есть большая локалка со станциями и серверами. Активно используется NAT. А теперь немного в деталях и схематично (под рукой только дюдя).

 

ISP1 - дает несколько IP адресов, пусть будут 1.1.1.1, 1.1.2.1

ISP2 - тоже несколько IP адресов, пусть будет 2.2.2.2, 2.2.1.2

Локальная сеть - 192.168.200.0/24

WEB1 сервер - 192.168.200.100

WEB2 сервер - 192.168.200.101

MAIL сервер - 192.168.200.103

FTP сервер - 192.168.200.104

Ну и остальные рабочие станции. Их много

 

WEB1 должен быть доступен по 1.1.1.1, 2.2.2.2

WEB2 должен быть доступен по 1.1.2.1, 2.2.1.2

MAIL по 1.1.1.1, 2.2.2.2

FTP по 1.1.2.1, 2.2.1.2 - выходить должен под 1.1.2.1

Рабочие станции должны выходить под 1.1.1.1

 

Как правильно настроить NAT? Если с DST все понятно, то не ясно как настраивать общий маскарад и src-nat по отдельности. Как правильно настроить ip-route? И что работал hairpin nat.

 

Немножко предисловия, которое должно было быть в начале. Рутер настроен, был подключен только один провайдер. Теперь подключили второй, и его нужно сделать основным. Ну и оставить первый для бекапа, хотя бы для локальной сети.

Сейчас там 40 правил файрвола, 100 правил ната, 80 манглов. Черт ногу сломит.

[nkusnetsov]

XuHT, вопрос с доступностью серверов в 2-х интерфейсов решается через маркировку трафика(соединений), плюс чётко сформулировать критерии "проброса порта". Хорошая статья по DualWan здесь

[myth]

а нормальный pbr оно не умеет?

[Saab95]

WEB1 должен быть доступен по 1.1.1.1, 2.2.2.2

WEB2 должен быть доступен по 1.1.2.1, 2.2.1.2

MAIL по 1.1.1.1, 2.2.2.2

FTP по 1.1.2.1, 2.2.1.2 - выходить должен под 1.1.2.1

Рабочие станции должны выходить под 1.1.1.1

 

Как правильно настроить NAT? Если с DST все понятно, то не ясно как настраивать общий маскарад и src-nat по отдельности. Как правильно настроить ip-route? И что работал hairpin nat.

 

Вам надо не NAT настраивать, а сделать нормальную схему сети. Т.к. в тех условиях, что сейчас у вас, нормально задачу не решить.

 

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

Кроме всего есть такая штука, как OSPF, и, скорее всего, все ваши сервера имеют его поддержку.

И даже если центральную железку не трогать, можно проанонсировать нужные IP на каких-то других микротиках, которые подключить в локалку, и уже они будут делать пробросы портов.

При этом большинство правил ната и маркировок можно будет отключить.

[rmika]

Может так?

/ip firewall nat

add action=src-nat chain=srcnat comment=WEB1 src-address=192.168.200.100 to-addresses="1.1.1.1,2.2.2.2"

add action=src-nat chain=srcnat comment=WEB2 src-address=192.168.200.101 to-addresses="1.1.2.1,2.2.1.2"

[ShyLion]

Еще вариант, если серваки под линуксом и есть вторые сетевые адаптеры, то с помощью ip rule можно развести соединения по разным шлюзам. Линуху все равно, а на роутерах меньше нестандартных настроек и PBR.

[Saab95]

Может так?

/ip firewall nat

add action=src-nat chain=srcnat comment=WEB1 src-address=192.168.200.100 to-addresses="1.1.1.1,2.2.2.2"

add action=src-nat chain=srcnat comment=WEB2 src-address=192.168.200.101 to-addresses="1.1.2.1,2.2.1.2"

 

Ага, как представляется логика работы? При запросе на адрес 192.168.200.100 подключиться сразу к двум серверам? Или один пакет отправлять на один, а второй на другой=) Тут нужен несколько иной подход. Например через маркировку соединений.

 

Еще вариант, если серваки под линуксом и есть вторые сетевые адаптеры, то с помощью ip rule можно развести соединения по разным шлюзам. Линуху все равно, а на роутерах меньше нестандартных настроек и PBR.

 

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

[XuHT]

Немного "забил" на вопрос, но решил вернуться.

 

Помимо NAT`а, мне еще нужно оставить доступным поднятые сервисы на самом микротике. Пусть это будет VPN.

В манглах создал по два правила на провайдера

Первое правило маркирует входящие пакеты на том интерфейсе, куда подключен провайдер,

Второе правило маркирует пакеты для маршрутизации:

add action=mark-connection chain=input comment="MARK INPUT ISP1" in-interface=ether1 new-connection-mark=ISP1_input
add action=mark-routing chain=output comment="MARK OUTPUT ISP1" connection-mark=ISP1_input new-routing-mark=ISP1_route passthrough=no

add action=mark-connection chain=input comment="MARK INPUT ISP2" in-interface=ether2 new-connection-mark=ISP2_input
add action=mark-routing chain=output comment="MARK OUTPUT ISP2" connection-mark=ISP2_input new-routing-mark=ISP2_route passthrough=no

 

В роуте создал по маршруту на каждого провайдера

 

add comment="MARKED ROUTE ISP1" distance=1 gateway=1.1.1.254 routing-mark=ISP1_route
add comment="MARKED ROUTE ISP2" distance=1 gateway=2.2.2.254 routing-mark=ISP2_route
add comment="DEFAULT ROUTE ISP1" distance=2 gateway=1.1.1.254

 

 

Эта кухня работает только для трафика, предназначенного самому рутеру.

 

 

Но проходящий (для NAT) трафик у меня не получается таких образом организовать.

Я, так понял, нужно помечать цепочкой forward, а для маршрутизации цепочкой prerouting.

Но по сниферу видно, что пакет пришел на один интерфейс и пытается уйти со второго - на котором поднят дефолтный маршрут с метрикой 2

 

Уверен, что если отключить

add comment="DEFAULT ROUTE ISP1" distance=2 gateway=1.1.1.254

то ничего не поменяется

[nkusnetsov]

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

1)Маркировка с целью выбора произвольного маршрута делается в mangle-prerouting.

2)Исходящий собственный (локально порожденный webfig,winbox,vpn-server) трафик маршрутизатора маркируется в mangle-output.

 

Обычная логика: 1) помечаем новое соединение, на основании src+dst IP (и протокола/порта, если необходимо); 2) пакетам принадлежащим помеченному соединению, делаем "mark-routing". Маркируем именно по соединению, т.к. при этом сразу выбираются и входящие и исходящие пакеты, в т.ч. транзитные.

 

 

IMHO маркировать соединения лучше с критерием "connection-state=new". Входящие извне выбирать, не только по критерию in-interface, но и по dst-ip.

Изменено 2 мая, 2017 пользователем nkusnetsov

[Andrei]

В 14.02.2017 в 09:19, ShyLion сказал:

Еще вариант, если серваки под линуксом и есть вторые сетевые адаптеры, то с помощью ip rule можно развести соединения по разным шлюзам. Линуху все равно, а на роутерах меньше нестандартных настроек и PBR.

А если на том же Линух-сервере еще и BGP, то кто будет приоритетней в плане маршрутизации: BGP или ip rule?

BGP ведь по факту как раз ip rule и перетасовывает во время своей работы.

[pppoetest]

ip rule - это инструмент для правил по которым определяется таблица маршрутизации, согласно которой пакет и улетает на нужный интерфейс. К бгп это не имеет никакого отношения.

[Andrei]

Так bgp по факту и формирует таблицу маршрутизации путем добавления маршрутов с помощью ip rule.

[aleks_lebedev]

На тиках ip rule без mangle >prerouting  пробывали ?

 

->ip->route->Rules

[Andrei]

6 минут назад, aleks_lebedev сказал:

На тиках

Я выше написал "на том же Линух-сервере", не на тике.

[pppoetest]

 

15 минут назад, Andrei сказал:

Так bgp по факту и формирует таблицу маршрутизации путем добавления маршрутов с помощью ip rule.

Чего? Маршруты отдельно, ip rule отдельно, это две независимые субстанции.

[Andrei]

Ну ОК, я просто уточнил. Т.е. можно прописать вручную в  /etc/network/interfaces отдельные роуты, которые будут работать независимо от BGP. Это устраивает.

[pppoetest]

Ок, ip rule это инструмент управления правилами, к самим маршрутам он не имеет отношения.

[Andrei]

Мне собственно надо, чтобы с адресов из определенной подсетки пакеты бегали в конкретный аплинк независимо от того, что по этому поводу думает bgp

[pppoetest]

Чтобы пакеты с подсети 1.1.1.0/24 бегали через шлюз 2.2.2.2 достаточно:

ip rule add from 1.1.1.0/24 table 400
ip route add default via 2.2.2.2 table 400

 

[Andrei]

Это понятно. Вот меня и брали сомнения, что это будет конфликтовать с BGP.

Я планировал просто в /etc/network/interfaces (у меня debian) добавить в описание интерфейса что-то типа

up route add -net 1.1.1.0 netmask 255.255.255.0 gw 2.2.2.2

down route del -net 1.1.1.0 netmask 255.255.255.0 gw 2.2.2.2

[pppoetest]

Как раз таки и непонятно. Я вам за pbr на основе src ip, вы мне просто за маршрут в дефолтную таблицу. Это разные вещи. И да.

up route add -net 1.1.1.0 netmask 255.255.255.0 gw 2.2.2.2
down route del -net 1.1.1.0 netmask 255.255.255.0 gw 2.2.2.2 

Это точно будет конфликтовать с бгп, например если в rib есть префикс с более длинной маской.

[Andrei]

Не понимаю разницы. В обоих примерах пакеты из сетки 1.1.1.0 netmask 255.255.255.0 бегают через gw 2.2.2.2. Разве нет?

[pppoetest]

Нет, в первом случае - пакеты ИЗ сети, во-втором - пакеты В сеть.

[Andrei]

Понятно. ip rule так же можно прописывать в /etc/network/interfaces , чтобы они создавались при включении интерфейса?

[pppoetest]

Можно, почитайте уже чтоли про пбр на линуксе https://habr.com/ru/post/108690/