Пример :
iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-
192.168.1.10
Ключ -- to - destination указывает, какой IP адрес должен быть подставлен в качестве адреса места
назначения. В выше приведенном примере во всех пакетах, пришедших на адрес 15.45.23.67, адрес
назначения будет изменен на один из диапазона от 192.168.1.1 до 192.168.1.10. Как уже указывалось
выше, все пакеты из одного потока будут направляться на один и тот же адрес, а для каждого нового
потока будет выбираться один из адресов в указанном диапазоне случайным образом. Можно также
определить единственный IP адрес. Можно дополнительно указать порт или диапазон портов, на
который (которые) будет перенаправлен траффик. Для этого после ip адреса через двоеточие укажите
порт, например --to-destination 192.168.1.1:80, а указание диапазона портов выглядит так: --to-destination
192.168.1.1:80-100. Указание портов допускается только при работе с протоколом TCP или UDP, при
наличии опции --protocol в критерии.
Действие DNAT достаточно сложно в использовании и требует дополнительного пояснения.
Рассмотрим простой пример. У нас есть WEB сервер и мы хотим разрешить доступ к нему из Интернет.
Мы имеем только один реальный IP адрес, а WEB-сервер расположен в локальной сети. Реальный IP
адрес $INET_IP назначен брандмауэру, HTTP сервер имеет локальный адрес $HTTP_IP и, наконец
брандмауэр имеет локальный адрес $LAN_IP. Для начала добавим простое правило в цепочку
PREROUTING таблицы nat:
iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP
В соответствии с этим правилом, все пакеты, поступающие на 80-й порт адреса $INET_IP
перенаправляются на наш внутренний WEB-сервер. Если теперь обратиться к WEB-серверу из
Интернет, то все будет работать прекрасно. Но что же произойдет, если попробовать соединиться с ним
из локальной сети? Соединение просто не установится. Давайте посмотрим как маршрутизируются
пакеты, идущие из Интернет на наш WEB-сервер. Для простоты изложения примем адрес клиента в
Интернет равным $EXT_BOX.
1. Пакет покидает клиентский узел с адресом $EXT_BOX и направляется на $INET_IP
2. Пакет приходит на наш брандмауэр.
3. Брандмауэр, в соответствии с вышеприведенным правилом, подменяет адрес назначения и передает
его дальше, в другие цепочки.
4. Пакет передается на $HTTP_IP.
5. Пакет поступает на HTTP сервер и сервер передает ответ через брандмауэр, если в таблице
маршрутизации он обозначен как шлюз для $EXT_BOX. Как правило, он назначается шлюзом по-
умолчанию для HTTP сервера.
6. Брандмауэр производит обратную подстановку адреса в пакете, теперь все выглядит так, как будто
бы пакет был сформирован на брандмауэре.
7. Пакет передается клиенту $EXT_BOX.
А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же
локальной сети. Для простоты изложения примем адрес клиента в локальной сети равным $LAN_BOX.
1. Пакет покидает $LAN_BOX.
2. Поступает на брандмауэр.
3. Производится подстановка адреса назначения, однако адрес отправителя не подменяется, т.е.
исходный адрес остается в пакете без изменения.
4. Пакет покидает брандмауэр и отправляется на HTTP сервер.
5. HTTP сервер, готовясь к отправке ответа, обнаруживает, что клиент находится в локальной сети
(поскольку пакет запроса содержал оригинальный IP адрес, который теперь превратился в адрес
назначения) и поэтому отправляет пакет непосредственно на $LAN_BOX.
6. Пакет поступает на $LAN_BOX. Клиент "путается", поскольку ответ пришел не с того узла, на
который отправлялся запрос. Поэтому клиент "сбрасывает" пакет ответа и продолжает ждать
"настоящий" ответ.
Проблема решается довольно просто с помощью SNAT. Ниже приводится правило, которое выполняет
эту функцию. Это правило вынуждает HTTP сервер передавать ответы на наш брандмауэр, которые
затем будут переданы клиенту.
iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT \
--to-source $LAN_IP
Так как цепочка POSTROUTING обрабатывается самой последней и к этому моменту пакет уже
прошел процедуру преобразования DNAT, поэтому критерий строится на базе адреса назначения
$HTTP_IP.
Если вы думаете, что на этом можно остановиться, то вы ошибаетесь! Представим себе ситуацию,
когда в качестве клиента выступает сам брандмауэр. Тогда, к сожалению, пакеты будут передаваться на
локальный порт с номером 80 самого брандмауэра, а не на $HTTP_IP. Чтобы разрешить и эту проблему,
добавим правило:
iptables -t nat -A OUTPUT --dst $INET_IP -p tcp --dport 80 -j DNAT \
--to-destination $HTTP_IP
Действие REDIRECT
Действие REDIRECT выполняет перенаправление пакетов и потоков на другой порт той же самой
машины. К примеру, можно пакеты, поступающие на HTTP порт перенаправить на порт HTTP proxy.
Действие REDIRECT очень удобно для выполнения "прозрачного" проксирования (transparent
proxying), когда машины в локальной сети даже не подозревают о существовании прокси.
REDIRECT может использоваться только в цепочках PREROUTING и OUTPUT таблицы nat.
Ключ : --to-ports
Пример :
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
Ключ --to-ports определяет порт или диапазон портов назначения. Без указания ключа --to-ports,
перенаправления не происходит, т.е. пакет идет на тот порт, куда и был назначен. В примере,
приведенном выше, --to-ports 8080 указан один порт назначения. Если нужно указать диапазон портов,
то мы должны написать нечто подобное --to-ports 8080-8090. Этот ключ можно использовать только в
правилах, где критерий содержит явное указание на протокол TCP или UDP с помощью ключа
--protocol.
Вот мы и рассмотрели основные моменты касающиеся трансляции адресов с помощью linux iptables .