![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Предыдущая: Преобразование Сетевых Адресов] [Содержание] [Следующая: Сокращения для написания правил]
Давайте рассмотрим пример:
rdr on tl0 proto tcp from any to any port 80 -> 192.168.1.20
Эта строка перенаправляет трафик входящий на 80 TCP порт (веб сервер) на машину внутри сети с ip 192.168.1.20. Поэтому, даже несмотря на то, что 192.168.1.20 находится за шлюзом и внутри вашей сети, внешний мир может иметь к этой машине доступ.
Часть правила from any to any может быть весьма полезна. Если вы знаете какой адрес или подсеть должны иметь доступ к веб серверу на 80 порт, то вы можете это указать:
rdr on tl0 proto tcp from 27.146.49.0/24 to any port 80 -> \
192.168.1.20
Это будет перенаправлять только указанную подсеть. Обратите внимание, это означает, что вы можете перенаправлять определённые входящие хосты на определённые машины находящиеся за натом. Это может оказаться полезным. Например, вы можете давать удалённым пользователями доступ на их собственные рабочие компьютеры, если вы знаете кто с какого IP адреса будет соединяться:
rdr on tl0 proto tcp from 27.146.49.14 to any port 80 -> \
192.168.1.20
rdr on tl0 proto tcp from 16.114.4.89 to any port 80 -> \
192.168.1.22
rdr on tl0 proto tcp from 24.2.74.178 to any port 80 -> \
192.168.1.23
Диапазон портов также может быть перенаправлен:
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20 port 6000
rdr on tl0 proto tcp from any to any port 5000:5500 -> \
192.168.1.20 port 7000:*
Эти примеры показывают перенаправление портов от 5000 до 5500 включительно, на машину 192.168.1.20. В правиле #1 порт 5000 перенаправляется на 5000, 5001 на 5001, и т.д. В правиле #2 указанный диапазон портов перенаправляется на 6000 порт. И в правиле #3 порт 5000 перенаправляется на 7000, 5001 на 7001, и т.д.
Единственное исключение для этого правила это когда ключевое слово pass используется с rdr правилом. В этом случае перенаправленные пакеты будут пропущены сквозь работу фильтра: эти пакеты не будут оцениваться правилами фильтрации. Это сокращённый путь добавления фильтрующего правила pass для каждого правила перенаправления. Воспринимайте это как обыкновенное rdr правило (без ключевого слова pass) объединённое с фильтрующим правилом pass, с ключевым слово keep state. Однако, если вы хотите использовать более специфичные фильтрующие опции, такие, как synproxy, modulate state, и т.д. то вам необходимо отдельно использовать pass правило, потому что эти опции не работают в правилах перенаправления.
Также помните, что трансляция происходит до фильтрации, фильтр будет видеть уже транслированные пакеты с преобразованным ip адресом и портом, указанными в rdr правилах. Рассмотрим такой сценарий:
Перенаправляющее правило:
rdr on tl0 proto tcp from 192.0.2.1 to 24.65.1.13 port 80 \
-> 192.168.1.5 port 8000
Пакет до обработки rdr правилом:
Пакет после обработки rdr правилом:
Фильтр увидит пакет в том виде, в котором он представлен после трансляции.
Подобные риски могут быть минимизированы, если держать систему к которой имеется доступ из вне в сильно ограниченной сети. Эту сеть часто зовут Демилитаризованной Зоной (DMZ) или Приватная Сервисная Сеть (PSN). Таким образом, если веб сервер взломан, последствия могут быть ограничены DMZ/PSN сетью, где фильтруется доступ в и из неё.
server = 192.168.1.40
rdr on $ext_if proto tcp from any to $ext_if port 80 -> $server \
port 80
Но когда правила перенаправления проверяются клиентом из LAN сети, это не работает. Причина в том, что правила перенаправления применяются только для пакетов, которые проходят через указанный интерфейс($ext_if, внешний интерфейс в примере). Соединение на внешний адрес брандмауэра от хоста в локальной сети не означает, что пакет пойдёт через внешний интерфейс. TCP/IP стэк на брандмауэре сравнивает адрес назначения входящих пакетов со своими собственными адресами и алиасами и определяет подключение к самому себе, после того, как пакеты прошли внутренний интерфейс. Такие пакеты физически не проходят через внешний интерфейс, и стэк не симулирует такой проход. Таким образом, PF никогда не видит эти пакеты на внешнем интерфейсе, и правило перенаправления указанное на внешнем интерфейсе не применяется.
Добавление второго правила перенаправления на внутреннем интерфейсе не даст желаемого результата. Когда локальный клиент соединяется на внешний интерфейсе брандмауэра, инициализационный пакет TCP рукопожатия достигает брандмауэр через внутренний интерфейс. Правила перенаправления сработает, адрес назначения поменяется на адрес внутреннего сервера. Пакет будет переброшен обратно через внутренний интерфейс и достигнет внутреннего сервера. Но исходный адрес не будет преобразован и всё ещё будет содержать адрес локального клиент, поэтому отправит ответ напрямую клиенту, брандмауэр никогда не увидит ответ и не сможет правильно выполнить обратное преобразование. Клиент принимает ответ от не предполагаемого источника и отбрасывает его. TCP рукопожатие не состоится и соединение не установится.
Всё же часто необходимо для клиентов в локальной сети соединяться на внутренний сервер, как внешние клиенты и делать это прозрачно. Существует несколько решений этой проблемы:
Возможно настроить DNS сервер так, чтобы ответ на запросы от локальных хостов отличался от ответа на внешние запросы, таким образом локальные клиенты будут принимать внутренний адрес сервера. Тогда они будут соединяться на прямую к локальному сервер, и брандмауэр не запутается во всём этом. Подобный метод снижает локальный трафик, потому что пакеты не будут посылаться через брандмауэр.
Добавление дополнительного сетевого интерфейсе на брандмауэр и перемещение локального сервера из клиентской сети в специальную сеть (DMZ), позволяющую перенаправление соединений от локальных клиентов, так же как перенаправление внешних соединений. Использование отдельных сетей имеет несколько преимуществ, включая улучшенную безопасность путём изоляции сервера от остающихся локальных хостов. Если сервер (который в нашем случае доступен из Интернета) будет взломан, он не сможет получить доступ к другим локальным хостам напрямую, потому как все соединения проходят через брандмауэр.
Может быть установлено TCP проксирование на брандмауэре, принимать соединения на внутреннем интерфейсе и перенаправлять на прослушиваемый проксируемый порт. Когда локальный клиент соединяется на брандмауэр, прокси принимает соединение, устанавливает второе соединение с внутренним сервером и передаёт данные между этими двумя соединениями.
Примитивное проксирование может быть организовано с помощью inetd(8) и nc(1). Указанная запись в /etc/inetd.conf создаст прослушиваемый сокет прикреплённый к кольцевому адресу (127.0.0.1) и 5000 порту. Соединения передаются на 80 порт, на сервер 192.168.1.10.
127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w \
20 192.168.1.10 80
Указанное перенаправляющее правило пробрасывает 80 порт на внутренний интерфейс к прокси:
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
127.0.0.1 port 5000
С добавлением NAT правила на внутреннем интерфейсе преобразование исходного адреса описанное выше будет достигнуто.
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> \
$server
no nat on $int_if proto tcp from $int_if to $int_net
nat on $int_if proto tcp from $int_net to $server port 80 -> \
$int_if
Инициализационный пакет от клиента будет снова преобразован, когда будет пробрасываться обратно через внутренний интерфейс, замена клиентского исходного адреса на внутренний адрес брандмауэра. Внутренний сервер будет отвечать обратно брандмауэру, который может сделать обратно NAT и RDR преобразования, когда пробрасывается локальному клиенту. Эта конструкция сложный комплекс, потому что он создаёт два отдельных стейта для каждого отражённого соединения. Необходимо принять меры для предотвращения работы NAT с другим трафиком, например соединения из внешних хостов (через другие перенаправления) или трафик самого брандмауэра. Обратите внимание, что rdr правило показанное выше заставляет TCP/IP стэк просматривать пакеты прибывающие на внутренний интерфейс с адресом назначения во внутреннию сеть.
Лучше использовать ранее упомянутое решение, взамен этого.
[Предыдущая: Преобразование Сетевых Адресов] [Содержвание] [Следующая: Сокращения для написания правил]
![[back]](../../../images/back.gif){kind=small}
www@openbsd.org