Сделать прозрачное туннелирование трафика (с сохранением ip) в Linux?

Question

[Ajex]

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

Какими инструментами правильнее решить эту задачу?

Цель — фильтрация разного мусора на уровне iptables, возможно какая-то мелкая антиддос защита. Нагрузка будет небольшая.

Comments

[Yagoda123]

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

[Ajex]

Нет, подмена ип не планируются. Что пришло, то ушло.
Стандартно я бы решал эту задачу так:

/sbin/iptables -t nat -A PREROUTING -p tcp --dport 80 -d [src_ip] -j DNAT --to-destination [dst_ip]
/sbin/iptables -t nat -A POSTROUTING -p tcp --dport 80 -d [dst_ip] -j SNAT --to [src_ip]

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

WEBIVAN, трафик возможно будет не только на 80 порт. Так что нужно нечто универсальное по типу ipip.

[jcmvbkbc]

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

уберите второе правило и всё будет нормально.

Answer 1

[Ilya Evseev]

Bridge + iptables:
habrahabr.ru/qa/29447/#answer_117693

Comments

[Ajex]

В данной схеме, как я понимаю, присутсвует 2 eth интерфейса, у меня же он один на вход и на выход.

Answer 2

[WEBIVAN]

Если трафик на вебсайт — X-Forwarded-For:

Answer 3

[stavinsky]

Думаю, если я правильно понял, и машины будут физически рядом, или же это виртуалки, то:
1. Туннелирование здесь явно лишнее, думаю можно обойтись виртуальным бриджем на проксирующей машине. (Она будет стоять физически в разрез бекэнда и провайдера. )
2. В предложенном варианте вам не придется ничего перенастраивать на бекэнде, так как IP адреса останутся на нем.
3. фильтрация будет при этом полностью возможна средствами iptables. (хотя могу ошибаться, скорее еще понадобится ibtables, поправьте )
4. Решение универсально и поддержит любой тип IP трафика

Comments

[Ajex]

Нет, машины удалены по ДЦ, не виртуалки. Фронтэнд точно выделенный сервер (win 2008), тоннель — linux vps. Задача — базовая очистка трафика (возможно ограничения по коннектам, ipset списки… ), в целом стандартные задачи для iptables.По сути не важно что будет происходить с трафиком на фильтре. Важно чтобы пакет пришел на ип фильтра 1.1.1.1. и прозрачно транслировался на фронтэнд 2.2.2.2 (пройдя по цепочке iptables). При чем не фрондэнд ни клиент (условно) не должны догадываться о наличии фильтра. Для них он должен быть абсолютно прозрачным.

[stavinsky]

А простейший PPP не подойдет? Прямо на ppp интерфейсе бекэнда указать реальный IP. Я вроде так делал с cisco + linux. DHCP с реальными адресами был на Cisco

[Ajex]

Честно, не приходилось сталкиваться с этой задачей. Как-то пользовались сторонними услугами антиддоса, у нас был клиентский скрипт который поднимал ipip тоннель на фронтэнде, а внешний ип был антиддоса. Все ip адеса при фильтрации оставались.
Как я понимаю, мне нужно и копать в сторону ipip.

[stavinsky]

ppp или ipip — да! Хотя мне в целом такой подход не нравится. Лучше все же проксировать нормально

[Ajex]

stavinsky, а нормально это как (применительно к моим реалиям где 2 машины по одному интерфейсу на каждой)?

[stavinsky]

Проблема не в количестве интерфейсов а в том что вам нужен реальный IP на бекенде. Зачем если не секрет?

[Ajex]

На фронтэнде вы хотели сказать. Ну, если рассматривать задачу для простоты понимания, отбросив все хотелки. Допустим Win2008 машинка достаточно чувствительна ко входящему трафику и лишним нагрузкам. Вот хочется перед ней поставить какой-то фильтр с шаровым трафиком и нагрузками, который бы взял на себя основной удар, например отсеять по гео, количеству соединений, прочий мусорный трафик… чтобы на выходе получить чистый поток. Также тут дополнительный + с точки зрения безопасности. Ни кто не знает реального адреса фронтэнда. А айпишники нужны, для статистик, логов…

Answer 4

[mastini]

А почему никто не предложил HAProxy?
У меня работает так
Client -> iptables -> haproxy -> backend

В зависимости от Ваших нужд, можно настроить haproxy для работы от l3 до l7

Comments

[stavinsky]

Потому что человеку надо что бы реальный IP был на бекенде

[mastini]

И что мешает это сделать с haproxy?
читаем доки к haproxy ;)

Answer 5

[Yagoda123]

Фильтрующий сервер с одним интерфейсом. Переправляет трафик на обрабатывающий сервер без SNAT.
Клиент должен обратиться именно к фильтрующему серверу и ответ получить через него.
Т.е. для клиента, IP обрабатывающего сервера = IP фильтра. С соответствующими записями в DNS (если речь о веб-сервере).
Перенаправлять трафика от клиента на обработку — это просто DNAT. А вот чтобы ответ шел через фильтр, на обрабатывающем сервере должен быть основной маршрут на фильтр. Значит, фильтр и сам сервер должны быть в одной подсети.
Вероятно, удобнее всего делать VPN от фронтэнда к фильтру (или наоборот, смотря что проще) и настраивать маршруты на обоих сторонах.
Ну и для защиты блокировать лишнее (почти все) на обычном интерфейсе обрабатывающего сервера.

Если предполагается только веб-трафик, то nginx + X-Forwarded-For. Заодно и фильтрацию любую в nginx можно сделать. А можно и Squid(ом) попробовать обойтись. Еще и кеширование в подарок получите.

Answer 6

[Yagoda123]

PS.

Нет, машины удалены по ДЦ, не виртуалки. Фронтэнд точно выделенный сервер (win 2008), тоннель — linux vps

А почему бы не поднять на win 2008 виртуальную машину с Linux, и весь трафик прогонять через эту виртуалку?

Comments

[Ajex]

В таком случае трафик будет заходить на виндовую машину, а этого бы не хотелось. Просто он там очень дорогой и фильтрация на самом винсервере не будет иметь ни какого толку. Поэтому нужен все же отдельный фильтрующий сервер.
Пока рабочий вариант ipip, также попытаюсь в тесте сделать с haproxy.
Может у кого какие еще светлые идеи по поводу топика, буду очень признателен за них.
И за толковый мануал, как это сделать на ipip, также буду благодарен.