Микротик. Как настроить проброс до веб сервера?

Question

[Мария Гросс]

Суть проблемы...
Настроен проброс портов с 77.77.77.1, 77.77.77.2 на 66.66.66.66.
За ним стоит веб сервер 10.10.10.10.

Сетевое оборудование mikrotik cloud core 1036-12G-4S.

Так вот. При обращении клиентов на 66.66.66.66 - веб сервер видит внешние ip адреса клиентов, а при обращении через 77.77.77.1, 77.77.77.2 - веб сервер показывает ip 77.77.77.1, 77.77.77.2.

Каким образом реализовать проброс портов так, чтобы веб сервер видел ip адреса клиентов идущих через 77.77.77.1, 77.77.77.2?

ip 66.66.66.66 клиенты не должны видеть. прячусь от ддос.
Графическая схема упрощена.

Answer 1

[lega]

Если на фронте стояли бы веб-сервера (например nginx), то можно было ip клиента запихивать в http заголовок (при проксировании это есть).

Comments

[Мария Гросс]

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

Answer 2

[АртемЪ]

Как настроить проброс до веб сервера?

Поднять тоннель между 77.77.77.1, 77.77.77.2 и 66.66.66.66 после чего настроить проброс портов, так же как вы делали на 66.66.66.66.

А вообще это довольно кривая защита от ddos. Для этих целей есть CDN.

Comments

[Мария Гросс]

Кривая не кривая, а работает. Потоком трафика с нескольких адресов легче управлять. Раньше с одним ip меня ложили на лопатки сразу. Теперь трафик фильтруется еще до 66.66.66.66. Жить намного легче. С тоннелем Ваша идея ясна. Данная схема реализовывалась, но почему-то сервера начинали показывать внутренний ip тоннеля от 77.77.77.1, 77.77.77.2... Чувствую, что дело в кривых руках. Правда где-то рядом.

Answer 3

[Валерий Рябошапко]

Если под пробросом портов с 77.77.77.[12] на 66.66.66.66 Вы имеете ввиду NAT, то 66.66.66.66 уже должен получать правильный IP отправителя, так как NAT подменяет только получателя. Соответственно, второй NAT на 66.66.66.66 ещё раз подменит получателя и на 10.10.10.10 придёт правильный отправитель.

Но может возникнуть проблема. Если маршрут от 77.77.77.[12] лежит через сторонний маршрутизатор (например, между разными
ДЦ), то он почти наверняка дропнет эти пакеты, потому что поймёт, что отправитель у них поддельный. Нужно или иметь договорённость с владельцем этого маршрутизатора, или не иметь этого маршрутизатора, например, хоститься в одном ДЦ или поднимать VPN или любой другой тоннель.

Кстати, в случае VPN хост 66.66.66.66 лишний, достаточно поднять VPN от 10.10.10.10 до 77.77.77.1 и 77.77.77.2. Правда, я не знаю, умеет ли Mikrotik поднимать VPN.

Comments

[playnet]

"Правда, я не знаю, умеет ли Mikrotik поднимать VPN."
PPTP, L2TP, SSTP, IPSEC. Ограниченно openvpn.

Но вообще самое правильное - точки входа должны быть с nginx, и делать предварительную фильтрацию, лимитирование по коннектам, пакетам, сайтам итд, фильтровать АЦЛями совсем левые сети, ... Плюс добавлять хидеры с адресами. А еще лучше обратиться к тем, кто это умеет делать, если сайт коммерческий - ddosprotector, qrator, у них куча точек входа, все с фильтрацией ещё на входе.
Ну и частный случай - CDN, если нагрузка по статике, а не настоящий ддос по заказу.

[Валерий Рябошапко]

playnet: ух ты, оказывается Mikrotik куда круче, чем я думал.

Про nginx и CDN — это всё правильно, но всё же вопрос был про проброс и видимость IP.

Answer 4

[Иван]

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