iptables redirect на другой ip
Iptables: немного о действии REDIRECT, его ограничениях и области применения
Данная заметка повествует о действии REDIRECT в iptables, его ограничениях и области применения.
Iptables и REDIRECT
Действие REDIRECT предназначено для перенаправления пакетов с одного набора портов на другой внутри одной системы, не выходя за пределы хоста.
Работает REDIRECT только в цепочках PREROUTING и OUTPUT таблицы nat. Таким образом, область применения сводится только к перенаправлению с одного порта на другой. Чаще всего это используется для прозрачного прокси, когда клиент из локальной сети коннектится на 80 порт, а шлюз редиректит пакеты на локальный порт прокси:
Допустим, надо сменить порт приложения только перенаправлением при помощи iptables, не трогая настроек демона. Пусть новый порт будет 5555, а порт приложения 22. Таким образом, надо сделать редирект с порта 5555 на 22.
REDIRECT и удаленный клиент
Первый шаг очевиден и будет таким же, что и в примере выше:
Однако, правило будет работать только для внешних клиентов и только при открытом порте приложения.
REDIRECT и локальный клиент
Предыдущее правило для самого хоста с iptables не сработает, т.к. пакеты с localhost не попадают в таблицу nat. Чтобы кейс сработал на локальной машине — надо добавить редирект в цепочку OUTPUT таблицы nat:
Теперь локальный клиент тоже может подключиться по 5555 порту.
REDIRECT и закрытый порт
Смысл кейса в том, чтобы использовать левый порт, а порт приложения держать закрытым, но если выполнить DROP правило в INPUT цепочке по 22 порту, то 5555 тоже перестанет отвечать. Собственно, хитрость в том, чтобы открыть порт приложения в INPUT цепочке, а дропать его в mangle:
Полный набор правил
Редирект с сетевым и локальным доступом при закрытом порте приложения:
iptables перенаправить с одного ip на другой ip
Пробовал разными средствами. Любые решения не работают для определённого адреса.
На пинг 140.50.0.1 получаю «destination network unreachable». После перенаправления получаю тоже самое.
На пинг 192.168.1.140 получаю «host unreachable». После перенаправления пингуется.
Видимо, дело в том, что сети 140.50.X.X не существует (а её и нет).
Как заставить iptables перенаправлять адреса в таких случаях?
Вы, товари, по-моему какой-то ерундой занимаетесь. Да еще и внятно изложить что делаете не в состоянии.
Есть адрес в сети. Нужно все пакеты адресуемые ему с локальной машины перенаправить на другой адрес посредством iptables этой самой локальной машины. Что ж непонятного?
Ни одного из множества опробованных средств так и не описал. А вот такое пробовал?
Да, в таком виде сработало. Спасибо.
Подтверждаю, описал проблему плохо и сумбурно. Ни толком структуру сети не обозначил, ни остального.
Проброс и перенаправление портов в iptables
Проброс трафика за NAT или проброс трафика на другой сервер
Чаще всего проброс трафика используется, если мы находимся в локальной сети и от внешнего мира отделены шлюзом. Для того, чтобы открыть доступ для локальных служб (ssh, web, ftp), нам необходимо пробросить порты. Поскольку в качестве шлюза мы будем использовать сервер на Linux, то осуществлять данные действия будем с помощью iptables.
Определимся с переменными, которые будут использоваться в статье:
Проброс портов
Рассмотрим пример
Если входящий пакет пришёл извне на шлюз (1.2.3.4), но предназначен веб-серверу (порт 80), то адрес назначения подменяется на локальный адрес 192.168.1.50. И впоследствии маршрутизатор передаст пакет в локальную сеть.
Дальше принимается решение о маршрутизации. В результате пакет пойдёт по цепочке FORWARD таблицы filter, поэтому в неё надо добавить разрешающее правило. Оно может выглядеть, например, так:
Рассмотрим пример
Пропустить пакет, который пришёл на внешний интерфейс, уходит с внутреннего интерфейса и предназначен веб-серверу (192.168.1.50:80) локальной сети.
Есть два способа избежать данной ситуации.
Рассмотрим пример
Если пакет предназначен веб-серверу, то обратный адрес клиента заменяется на внутренний адрес шлюза.
Этим мы гарантируем, что ответный пакет пойдёт через шлюз.
Надо дополнительно отметить, что это правило важно только для внутренних клиентов. Ответ внешним клиентам пойдёт через шлюз в любом случае.
Но, пока что, для нормальной работы этого недостаточно. Предположим, что в качестве клиента выступает сам шлюз.
В соответствии с нашими предыдущими правилами он будет гонять трафик от себя к себе и представлять исходящие пакеты транзитными.
Рассмотрим пример
Теперь для удобства запилим скрипт, чтобы не прописывать правила каждый раз вручную.
rules.sh
Теперь, чтобы обеспечить доступ извне к локальному FTP по адресу 192.168.1.52, достаточно набрать в консоли от имени супер-пользователя:
Перенаправление портов
Перенаправление портов нужно в том случае, если мы хотим «замаскировать» внутреннюю службу, обеспечив к ней доступ извне не по стандартному, а совсем по другому порту.
Набор правил для iptables будет отличаться несущественно, поэтому приведу сразу пример итогового скрипта для ленивых.
Перенаправление (forward) портов iptables
Рассмотрим перенаправление (forward) на двух примерах:
1. с внешнего IP на внутренний сервер (без masquerade, IP-адрес источника сохраняется);
2. forward с использованием masquerade, с подменой IP-адреса источника (в локалку, и просто с сервера на сервер).
Пример 1: FORWARD (снаружи в локальную сеть, DNAT, меняется только адрес назначения)
Причем мы хитрые и хотим, чтобы наш веб сервер из интернета не был виден на 443 порту, а был доступен, скажем, на 1293 порту (примерно вот так: https://1.2.3.4:1293).
Итак, мы хотим перенаправить входящие из интернет на порт 1293 на порт 443 сервера в локальной сети.
IF_EXT=»eth0″ # Внешний сетевой адаптер
IF_INT=»eth1″ # Внутренний сетевой адаптер
IP_EXT=»1.2.3.4″ # Внешний IP
IP_INT=»192.168.1.1″ # Внутренний IP
FAKE_PORT=»1293″ # Фейковый порт, доступен из интернет
LOCAL_SRV=»192.168.1.28″ # Web сервер в LAN
SRV_PORT=»443″ # Настоящий порт
PREROUTING
Каждый пакет, попадающий на интерфейс, сначала предварительно обрабатывается (prerouting). Нам нужно, чтобы до того, как шлюз примет решение о маршрутизации (типа, а что с этим делать-то?), всем пакетам, пришедшим на внешний ($IF_EXT) интерфейс на порт 1293 (например, так: https://1.2.3.4:1293), был бы изменен пункт назначения на IP и порт сервера во внутренней сети. Т.е. шлюз «подкорректирует» destination пришедшего пакета так, чтобы можно было принять правильное решение о маршрутизации.
Дальше пакет попадет в цепочку FORWARD.
FORWARD
Пример 2: FORWARD с одного ip на другой (DNAT с MASQUERADE, меняется адрес источника и назначения)
Не всегда перенаправление совершается из/в локальную сеть. Бывает, что необходимо сделать проброс соединения на какой-то сервер, используя промежуточный. Это может быть необходимо для дополнительной фильтрации подключаемых клиентов, для разделения нагрузки и других задач.
Есть хост с публичным IP-адресом (1.1.1.1), ему может быть сопоставлено доменное имя, для которого могут быть выпущены SSL-сертификаты и прочее.
(!) Естественно, хосты 2.2.2.2 и 3.3.3.3 должны разрешать трафик на соответствующие порты!
Вот идея правил iptables на сервере 1.1.1.1:
Комментарии к скрипту:
1) INPUT разрешен только для 22/tcp, для ssh.
Отладка
На удаленном компьютере-клиенте запустите что-то вроде «telnet 1.1.1.1 25». Пакет должен прийти на 1.1.1.1:25. Это можно контролировать, запустив на сервере 1.1.1.1 в консоли команду:
Если все правильно, то на удаленном клиенте пойдет сеанс связи с SMTP-сервером 2.2.2.2.
Перенаправить трафик с одного IP-адреса и порта на другой IP-адрес и порт
При управлении серверами очень часто встречается перенаправление трафика.
Предположим, у нас есть сервер с запущенными определенными службами, но по какой-либо причине мы меняем одну из этих служб (Я не знаю, например pop3, который является портом 110) на другой сервер. Обычным и наиболее частым делом было бы просто изменить IP-адрес в записи DNS, однако, если кто-то использовал IP-адрес вместо поддомена, это повлияет на это.
Как начать перенаправлять трафик?
Во-первых, мы должны включить пересылка на сервере, для этого поставим следующее:
echo «1» > /proc/sys/net/ipv4/ip_forward
Вы также можете использовать эту другую команду, если предыдущая не работает для вас (со мной это случилось на CentOS):
sysctl net.ipv4.ip_forward=1
Затем перезапустим сеть:
service networking restart
В дистрибутивах RPM, таких как CentOS и другие, это будет:
service nertwork restart
Теперь перейдем к важному, сообщим серверу через Iptables что перенаправить:
То есть, следуя приведенному мною примеру, предположим, что мы хотим перенаправить весь трафик, который наш сервер получает через порт 110, на другой сервер (пример: 10.10.0.2), который по-прежнему будет получать этот трафик через 110 (это та же услуга):
Сервер 10.10.0.2 будет видеть, что все пакеты или запросы приходят с IP-адреса клиента, если они хотят проплыть запросы, то есть, что 2-й сервер видит, что запросы поступают с IP-адресом 1-го сервера (и в который мы применяем перенаправление), также можно было бы поместить эту вторую строку:
Некоторые вопросы и ответы
В примере я использовал один и тот же порт оба раза (110), однако они могут без проблем перенаправлять трафик с одного порта на другой. Например, предположим, что я хочу перенаправить трафик с порта 80 на порт 443 на другом сервере, для этого это будет:
Конец!
Как я уже сказал, это iptables, вы можете применить то, что уже известно, чтобы сервер делал именно то, что вы хотите 😉
Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.
Полный путь к статье: Из Linux » Сети / Серверы » Перенаправить трафик с одного IP-адреса и порта на другой IP-адрес и порт