У меня есть маршрутизатор Mikrotik RB2011, работающий под управлением RouterOS, который подключается к Интернету через статический IP-адрес. В моей локальной сети у меня есть два разных сервера, один с IP 192.168.89.11, а другой с 192.168.89.12.
Мой DNS (на cloudflare) разрешает myfirstserver.com и mysecondserver.com на статический IP-адрес моего маршрутизатора.
Теперь я хочу как-то разделить трафик, чтобы весь трафик для myfirstserver.com шел на 192.168.89.11, а трафик для mysecondserver.com - на 192.168.89.12 (и оба на порт 80. Я знаю, что могу просто изменить порты но если это общедоступные серверы, ни один пользователь не установит порт, отличный от 80)
То, что я пробовал до сих пор, - это как-то пометить пакеты через mangle, а затем использовать эту метку в NAT для правильной пересылки dst-nat.
Я пытаюсь маркировать пакеты с помощью регулярного выражения содержимого или протокола уровня 7 (они работают правильно, если действие записано в журнал. Я вижу, что они правильно регистрируются).
Дело в том, что после того, как я их помечаю, кажется, что NAT просто игнорирует их и перенаправляет соединение на сервер, который принимает немаркированные пакеты.
Думаю, я как-то перепутал порядок фильтрации и цепочки.
Может ли кто-нибудь дать некоторые указатели / помощь о том, как это сделать?
Спасибо!
РЕДАКТИРОВАТЬ: Мой вопрос очень конкретный, о маркировке пакетов в RouterOS на маршрутизаторе Mikrotik и проверке отметки в NAT. Дело не в том, нужен ли мне обратный прокси или что-то еще. Спасибо
РЕДАКТИРОВАТЬ 2: @ Cha0s спросил мой /ip firewall export
так вот оно:
/ip firewall layer7-protocol
add name=haf1a regexp=haf1a
/ip firewall address-list
add address=192.168.89.0/24 list=local
add address=192.168.88.0/24 list=local
add address=www.xxx.yyy.zzz list=local
add address=192.168.87.0/24 list=local
/ip firewall filter
add chain=input comment="default configuration" protocol=icmp
add chain=input comment="default configuration" connection-state=established
add chain=input comment="default configuration" connection-state=related
add action=drop chain=virus comment="Drop 80 DoS attack" src-address-list=spammer
add action=add-src-to-address-list address-list=spammer address-list-timeout=1d chain=input connection-limit=10,32 dst-address-list=!local dst-port=53 protocol=udp
add action=drop chain=input dst-port=53 protocol=udp src-address-list=!local
add action=add-src-to-address-list address-list=spammer address-list-timeout=1d chain=input connection-limit=30,32 protocol=tcp
/ip firewall mangle
add action=change-mss chain=forward new-mss=1422 out-interface=all-ppp protocol=tcp tcp-flags=syn tcp-mss=1423-65535
/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" out-interface=ether1-gateway
add action=masquerade chain=srcnat out-interface=pppoe-out1
add action=dst-nat chain=dstnat comment="No HAF mark" dst-address=www.xxx.yyy.zzz dst-port=80 packet-mark=!haf1 port="" protocol=tcp src-port="" to-addresses=192.168.89.41 to-ports=80
add action=dst-nat chain=dstnat comment="HAF mark" dst-address=www.xxx.yyy.zzz dst-port=80 packet-mark=haf1 port="" protocol=tcp src-port="" to-addresses=192.168.89.31 to-ports=80
где www.xxx.yyy.zzz
мой внешний ip (статический) и 192.168.89.31
и 192.168.89.41
мои два сервера в моей локальной сети
Моя цель - перенаправить любые соединения с haf1a
в них (например, haf1a.lala.com
) на соответствующий сервер (192.168.89.31)
Спасибо за экспорт.
Оказывается, либо эта конфигурация не поддерживается MikroTik, либо есть ошибка.
Согласно диаграмме потока пакетов, если я правильно понимаю, dst-nat
должен иметь возможность обнаруживать метки пакетов / соединений, поскольку mangle prerouting
раньше dst-nat
. Но после некоторых собственных тестов я застрял так же, как и вы.
В то время как mangle / filter может соответствовать отмеченным пакетам (или даже без маркировки, но напрямую используя фильтр L7 в правилах) в nat, он просто не соответствует ни одному пакету.
На форумах MikroTik также есть различные темы, которые, похоже, не нашли решения.
http://forum.mikrotik.com/viewtopic.php?f=2&t=83129
http://forum.mikrotik.com/viewtopic.php?f=2&t=73856
http://forum.mikrotik.com/viewtopic.php?f=13&t=62152
Один парень упоминает решение с использованием веб-прокси MikroTik, которое я лично не стал бы использовать, поскольку он изменит исходный IP-адрес на IP-адрес MikroTik, и, таким образом, веб-серверы будут регистрировать все запросы с одним и тем же IP-адресом вместо реальных посетителей. IP-адреса.
Я могу придумать два других решения, но они не так просты.
Решение 1: Если вы используете MikroTik версии 5.x, существует ISO-образ, который исправит MikroTik и добавит минимальный дистрибутив Debian поверх (или ниже). Что затем вы можете использовать для установки HAproxy или любого другого обратного прокси-сервера, который вам нравится, для правильного выполнения того, что вам нужно (HAproxy или любой другой обратный прокси-сервер - правильный способ сделать это, как уже упоминалось другими)
Решение 2: Другой подход - создать метаршрутизатор (если вы запускаете MikroTik на маршрутизаторе, у вас достаточно свободной оперативной памяти, и вы не используете nstreme) и загрузите на него изображение openwrt. На котором вы затем можете установить обратный прокси-сервер по своему вкусу для выполнения задачи.
Скорее всего не решение: Конечно, вы также можете отправить запрос в службу поддержки MikroTik, чтобы подтвердить или (что наиболее вероятно) опровергнуть наличие ошибки в NAT с маркировкой пакетов L7. Но я бы не ожидал многого от их поддержки. В большинстве случаев вам не поможет. Их стратегия по умолчанию заключается в том, что все глупы, и проблема всегда в конфигурации пользователей, а не в самом MikroTik ...
Было бы неплохо иметь возможность справиться с этой задачей на самом роутере. Это подходит для сред с ограничениями, где нельзя использовать еще одну машину для работы обратного прокси. Хотя я бы не стал использовать этот метод (даже если бы он работал) в производственной среде. Фильтр уровня 7 довольно медленный и тяжелый для маршрутизатора.
Обновить: Я только что увидел, что вы используете RB2011, поэтому решение ISO / debian вам не подойдет (только для x86). Если вы не используете nstreme (я думаю, что нет), тогда ваша единственная ставка - использовать метаршрутизатор с openwrt, чтобы сделать за вас обратный прокси.
Для HTTP обратный прокси может обрабатывать разделение трафика. Это работает, потому что современные браузеры отправляют заголовок Host, указывающий, какой сайт им нужен. Это не работает для большинства других протоколов - вы можете видеть только запрошенный IP-адрес.
Если вы хотите, чтобы другие протоколы передавались на отдельные серверы, вам нужно будет запросить второй общедоступный IP-адрес у вашего интернет-провайдера.