Iptables t nat a prerouting

О чем же пойдёт речь

Как это выглядит

Мы будем рассматривать типичную схему для офисов и для квартир, да-да именно квартир! Мало у кого есть собственный маленький сервачок дома под столом, но у большинства интернет дома раздается через роутер и в большинстве своём они тоже прошиты Linux.
Это типичная схема малого офиса. Когда к интернет подключен 1 компьютер(сервер), а остальные подключаются к интернет уже через этот сервер.

Поехали, потихонечку.

что такое NAT

Для начала нам нужно понять, что настраивать мы будем самый обыкновенный NAT(Network Address Translation). Для жаждущих, я в конце упомяну и о проксе сервере на примере squid. Как я уже сказал разжёвывать будем практически всё.
Что же такое NAT? На самом деле все просто, все компьютеры имеют физический (MAC) и сетевой (IP) адреса. Нас в данный момент интересуют IP адреса. IP адрес в пределах одной сети должен быть уникальным! А при нынешнем стандарте IPv4 уникальными могут быть всего-то 4 294 967 296 (2 32 ), что совсем не много и они практически кончились. но не переживайте вот вот вступит в широкое распространение IPv6, а там адресов навалом!
Но тут вы можете заметить, компьютеров значительно больше того числа, что позволяет IPv4 или скажете, что у друга дома такой же адрес как и у вас! И вот тут-то и заходит речь о NAT — он позволяет соединять компьютерные сети между собой используя единственный, свой IP адрес, действия фаервола при этом называется SNAT(Source NAT или подмена адреса источника). Т.е. в 99% случаев вся ваша контора выходит в интернет под 1 IP адресом, при этом внутри офиса у каждого он свой. О классах IP адресов вы сможете прочесть в интерне.

Теперь, когда мы знаем что такое NAT и для чего он нужен, можно приступать непосредственно к настройке сервера.

транзитный трафик

Все команды выполняются от имени root(суперпользователь). В Debian по умолчанию отключен так называемый транзитный трафик, т.е. по умолчанию предусмотрена работа только как единичная машина. Как вы уже догадались, без транзитного трафика нету и NAT. Для его включения достаточно изменить 1 цифру — $ echo 1 > /proc/sys/net/ipv4/ip_forward, но данная настройка слетит после перезагрузки, так что лучше поправить конфиг — $ nano /etc/sysctl.conf далее ищем строчку #net.ipv4.ip_forward=1 и убираем «решётку»(символ комментария) в начале строки и проверяем что значения равно 1! Теперь можно приступать непосредственно к конфигурированию iptables.

настраиваем iptables

В интернет, есть много статей о том как писать правила в iptables и что с их помощью можно творить, наиболее полным и приятным для чтения мне показалась статья на wikipedia.org.
И так приступим. Для начала очистим таблицы от лишних правил, вдруг там что было лишнего…
$ iptables -F
$ iptables -t nat -F
$ iptables -t mangle -F

Лишнее почистили. Очень важно понять и помнить, что правила в iptables применяются иерархически, т.е. правило стоящее выше выполнится раньше. Все цепочки по умолчанию имеют политику ACCEPT — разрешают всё. что не попало под правила данной цепочки.
Условимся, что интерфейс смотрящий в локальную сеть — eth0, а в интернет — eth1, локальная сеть имеет адреса 192.168.0.0/24, а провайдер выдал нам статический адрес 10.188.106.33(пускай и не «белый» — о типах ip адресов вы также можете посмотреть в интернет). И так пишем:
$ iptables -A FORWARD -i eth0 -o eth1 -s 192.168.0.0/24 -j ACCEPT
$ iptables -A FORWARD -i eth1 -o eth0 -d 192.168.0.0/24 -j ACCEPT
$ iptables -P FORWARD DROP

тем самым разрешили ходить транзитным пакетам через firewall для нашего диапазона ip адресов, а всё остальное запрещаем.
Теперь сам NAT:
$ iptables -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j SNAT –to-source 10.188.106.33
Этого достаточно для того что бы у вас заработал NAT.

Читайте также:  Видео где милана и папа играют
по мелочам.

На клиентах указываем ip из выбранного диапазона и указываем в качестве шлюза ip адрес нашего сервера(обычно его назначают первым из подсети — я оставлю это на ваше усмотрение). Все сетевые настройки на сервере можно провести так:
$ nano /etc/network/interfaces в нём указываются настройки ваших сетевых интерфейсов.

доступ в недры сети через шлюз или DNAT

И тут вы поняли, что в сети у вас есть Windows Server к которому у вас всегда был простой доступ по RDP, а тут вылез это назойливый шлюз на Debian! Всё очень просто — надо всего лишь добавить DNAT правило в наш iptables.
Что за зверь DNAT? DNAT (Destination NAT или подмена адреса получателя) — сетевые карты работают в таком режиме, что они принимают только пакеты адресованные именно им, а зайти на наш сервер если ip под которым он выходит в интернет сидят еще десяток машин в вашем офисе? Как запрос дойдёт именного до него? На самом деле все запросы такого рода упираются в наш шлюз. И всё что нам надо сделать это задать правила для работы с такими пакетами.
$ iptables -A PREROUTING -i eth1 -p tcp -m tcp –dport 3389 -j DNAT –to-destination 192.168.0.2
Это простое правило будет переадресовывать все пакеты приходящие на шлюз из интернет на порт TCP 3389(именно его использует RDP протокол) на ваш внутренний Windows Server. И, вуаля, у вас все работает.

итак что там с любимым squid

И хотя сейчас все работает, у всех есть интернет и все работает, некоторым всё же нужен прокси сервер. Я не буду рассказывать о настройке squid, я покажу правило которое позволит сделать его «прозрачным». В сквид надо лишь прописать волшебное слово transparent в нужном месте и он начнём корректно обрабатывать свалившееся на него запросы.
Пишем $ iptables -A PREROUTING -d! 192.168.0.0/24 -i eth0 -p tcp -m multiport –dports 80,443 -j REDIRECT –to-ports 3128 .
И что же нам это даёт? Теперь все запросы на web страницы с ваших рабочих мест по http((80) и https(443) протоколам будут перенаправляться на порт который слушает squid. Вы получает контентную фильтрацию, информацию о том кто где был и что делал в интернет, пользователь ни чего не подозревая работает как и раньше…

Читайте также:  Драйвера для монитора msi
немного безопасности

Следует хоть минимально защитить свой шлюз поэтому добавим еще пару правил
$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT
$ iptables -A INPUT -i eth1 -m conntrack –ctstate RELATED,ESTABLISHED -j ACCEPT
$ iptables -P INPUT DROP

Тем самым запретили любое общение непосредственно с шлюзом, кроме уже установленных соединений, т.е. те что были инициированы вами и вы просто получаете на них ответы. Не бойтесь наш DNAT до этих правил просто не доходит…

почему так мало?

Статья не резиновая и обо всем все-равно не расскажешь… Я привел минимальный набор действий и понятий что бы вы могли начать осваивать такую махину как шлюз на Linux. Здесь можно говорить очень и очень долго, обсуждая многие аспекты и возможности netfilter.

Итого

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Внешний выделенный IP адрес сервера 123.123.123.123/32.

На машине поднят LXC конетйнер на приватном IP адресе, который не маршрутизируется в сети общего пользования.

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

Цели можно добиться добавив правило в цепочку PREROUTING iptables.

iptables -t nat -I PREROUTING -i eth0 -p TCP -d 123.123.123.123/32 —dport 80 -j DNAT —to-destination 10.160.152.184:80

Здесь указываются приватный и публичный IP адрес, а также порты. Директивой —dport задается внешний порт. Помимо этих основных директив в качестве условий существуют сетевой интерфейс (eth0) и протокол(TCP).

Такое решение может требоваться если в контейнерах работают разные сервисы с трафик нужно переправлять с разных портов на публичном адресе.

Чтобы изменения сохранились требуется создавать скрипт, который будет подгружать их после перезагрузки. В Debian / Ubuntu достаточно установить из репозитория пакет iptables-persistent, который будет выполнять эту задачу

apt-get install iptables-persistent

В процессе установки будет предложено сохранить все правила для IPv4. Ответить нужно положительно.

Проверить актуальные правила можно выполнив iptables-save

Проброс трафика за NAT или проброс трафика на другой сервер

Чаще всего проброс трафика используется, если мы находимся в локальной сети и от внешнего мира отделены шлюзом. Для того, чтобы открыть доступ для локальных служб (ssh, web, ftp), нам необходимо пробросить порты. Поскольку в качестве шлюза мы будем использовать сервер на Linux, то осуществлять данные действия будем с помощью iptables.

Определимся с переменными, которые будут использоваться в статье:

$EXT_IP – внешний, реальный IP-адрес шлюза;
$INT_IP – внутренний IP-адрес шлюза, в локальной сети;
$LAN_IP – внутренний IP-адрес сервера, предоставляющего службы внешнему миру;
$SRV_PORT – порт службы. Для веб-сервера равен 80, для SMTP – 25 и т.д.;
eth0 – внешний интерфейс шлюза. Именно ему присвоен сетевой адрес $EXT_IP;
eth1 – внутренний интерфейс шлюза, с адресом $INT_IP;

Проброс портов

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

Читайте также:  Asus geforce gtx 560 1gb

Рассмотрим пример

Если входящий пакет пришёл извне на шлюз (1.2.3.4), но предназначен веб-серверу (порт 80), то адрес назначения подменяется на локальный адрес 192.168.1.50. И впоследствии маршрутизатор передаст пакет в локальную сеть.

Дальше принимается решение о маршрутизации. В результате пакет пойдёт по цепочке FORWARD таблицы filter, поэтому в неё надо добавить разрешающее правило. Оно может выглядеть, например, так:

Рассмотрим пример

Пропустить пакет, который пришёл на внешний интерфейс, уходит с внутреннего интерфейса и предназначен веб-серверу (192.168.1.50:80) локальной сети.

С одной стороны, этих двух правил уже достаточно для того, чтобы любые клиенты за пределами локальной сети успешно подключались к внутреннему серверу. С другой – а что будет, если попытается подключиться клиент из локальной сети? Подключение просто не состоится: стороны не поймут друг друга.

Допустим, 192.168.1.31 – ip-адрес клиента внутри локальной сети.

  1. Пользователь вводит в адресную строку браузера адрес example.com;
  2. Сервер обращается к DNS и разрешает имя example.com в адрес 1.2.3.4;
  3. Маршрутизатор понимает, что это внешний адрес и отправляет пакет на шлюз;
  4. Шлюз, в соответствии с нашим правилом, подменяет в пакете адрес 1.2.3.4 на 192.168.1.50, после чего отправляет пакет серверу;
  5. Веб-сервер видит, что клиент находится в этой же локальной сети (обратный адрес пакета – 192.168.1.31) и пытается передать данные напрямую клиенту, в обход шлюза;
  6. Клиент игнорирует ответ, потому что он приходит не с 1.2.3.4, а с 192.168.1.50;
  7. Клиент и сервер ждут, но связи и обмена данными нет.

Есть два способа избежать данной ситуации.

Первый – разграничивать обращения к серверу изнутри и извне, для этого создать на локальном DNS-сервере А-запись для example.com указывающую на 192.168.1.50

Второй – с помощью того же iptables заменить обратный адрес пакета.
Правило должно быть добавлено после принятия решения о маршрутизации и перед непосредственной отсылкой пакета. То есть – в цепочке POSTROUTING таблицы nat.

Рассмотрим пример

Если пакет предназначен веб-серверу, то обратный адрес клиента заменяется на внутренний адрес шлюза.
Этим мы гарантируем, что ответный пакет пойдёт через шлюз.

Надо дополнительно отметить, что это правило важно только для внутренних клиентов. Ответ внешним клиентам пойдёт через шлюз в любом случае.

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

Рассмотрим пример

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

rules.sh

Теперь, чтобы обеспечить доступ извне к локальному FTP по адресу 192.168.1.52, достаточно набрать в консоли от имени супер-пользователя:

Перенаправление портов

Перенаправление портов нужно в том случае, если мы хотим «замаскировать» внутреннюю службу, обеспечив к ней доступ извне не по стандартному, а совсем по другому порту.

Пусть $FAKE_PORT – обманный порт на внешнем интерфейсе шлюза, подключившись к которому мы должны попасть на адрес $LAN_IP и порт $SRV_PORT .

Набор правил для iptables будет отличаться несущественно, поэтому приведу сразу пример итогового скрипта для ленивых.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock detector