The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

NAT во FreeBSD с помощью IPFilter (ipnat) (freebsd nat ipfilter firewall proxy ftp howto)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: freebsd, nat, ipfilter, firewall, proxy, ftp, howto,  (найти похожие документы)
From: Evgueni V. Gavrilov <aquatique at rusunix.org> Date: Mon, 17 May 2004 18:21:07 +0000 (UTC) Subject: NAT во FreeBSD с помощью IPFilter (ipnat) Оригинал: http://aquatique.rusunix.org/ipnat.html NAT во FreeBSD с помощью IPFilter (ipnat) Содержание * Введение * Подготовка * Простенький stateful NAT * Перенаправление (redirect) * FTP proxy * Использование отдельного IP-адреса для трансляций на внешнем интерфейсе * Безусловная полная трансляция * Контроль над трансляцией Введение -------- Синдром гамака является одним из ключевых моментов деградации сисадмина. Он начинается с того, что стабильность и неподвижность становятся синонимами. Когда-то, до того, как IPFilter включили в состав FreeBSD, единственным нормальным способом сделать NAT во FreeBSD был natd. Это извращение работало через divert socket и висело демоном. natd до сих пор может быть в некоторых случаях актуален. Мы же рассмотрим использование ipnat из IPFilter в качестве средства для Network Address Translation (NAT). Этот документ не является пошаговым howto for dummies - подразумевается, что не нужно объяснять, что например после изменения /etc/syslog.conf ему нужно послать сигнал HUP, а файлы, куда он будет писать, создавать нужно самостоятельно и как "применять" изменённые правила. Если Вы считаете, что ещё не совсем освоились с *nix и с FreeBSD в частности, то по этой теме можно почитать: ipnat(1), ipnat(5), ipnat(8) ipf(5), ipf(8), ipfstat(8), ipftest(1), ipmon(8) Здесь и далее будет считаться, что IPFilter у нас как минимум версии 3.4.29. Если в Вашем случае это не так - то Вы ещё не совсем вылезли из гамака, хотя уже тот факт, что Вы читаете этот текст, является доказательством Вашего на то желания. Подготовка ---------- Итак, рассмотрим ситуацию: мы имеем 2 интерфейса - fxp0 (200.200.200.1), смотрящий в большой и злой интернет, и dc0 (192.168.0.1), смотрящий во внутреннюю сеть. Задача: сделать возможность пользователям внутренней сети открывать TCP/UDP соединения к внешним хостам без использования socks5/http proxy и т.п. В ядре нам понадобятся всего 2 строчки: options IPFILTER options IPFILTER_LOG После этого IPFilter доступен нам во всей своей красе. Также в /etc/rc.conf нужно добавить строчку gateway_enable="yes" или в /etc/sysctl.conf добавить строчку net.inet.ip.forwarding=1. Теперь всё готово - пакеты перебрасываются между интерфейсами. Осталось контролировать их переброс и заменять в них IP адрес с внутреннего на внешний и наоборот. Простенький stateful NAT ------------------------ Начнём с простого stateful NAT т.е. IP пакеты с внешнего интерфейса для получателя во внутренней сети будут транслироваться только в том случае, если пользователь сам установил это соединение. Все остальные пакеты, пришедшие на внешний интерфейс для получателя во внутренней сети бы будем блокировать (см. redirect далее, если какие-то пакеты извне нужно всегда пробрасывать внутрь). Для соединений, установленных пользователем, мы будем создавать запись в state table с помощью простого правила IPFilter: pass out quick on fxp0 proto tcp from 192.168.1.149 to any flags S/FSRA keep state (для TCP-соединений) и pass out quick on fxp0 proto udp from 192.168.1.149 to any keep state (для UDP-соединений). Можно вместо двух правил сделать одно общее как для TCP, так и для UDP: pass out quick on fxp0 proto tcp/udp from 192.168.1.149 to any keep state однако в таком правиле мы не сможем отслеживать tcp-пакеты с флагом SYN с помощью flags, в результате чего любой пакет из внутренней сети будет создавать запись в state table (если её не было), а не те пакеты, которые являются первыми в установке TCP-соединения (с флагом SYN). Что удобнее/лучше/больше подходит - решайте сами. Следом за этим правилом мы поместим правило, блокирующее все пакеты для внутренней сети: block in quick on fxp0 from any to 192.168.0/16. Под это правило будут попадать пакеты, не являющиеся частью соединений, запрошенных из внутренней сети либо пакеты из соединений, которых нет в state table Теперь сама трансляция. Занесём в файл трансляций (по умолчанию это /etc/ipnat.rules) правило: map fxp0 192.168.1.149/32 -> 200.200.200.1/32 portmap tcp/udp 20000:20099 В результате мы получаем следующую картину: при установке TCP-соединения самый первый пакет (с флагом SYN) из внутренней сети с хоста 192.168.1.149 при уходе в большой и злой интернет будет подвержен простому преобразованию - адрес хоста, запросившего установку соединения будет изменён с 192.168.1.149 на 200.200.200.1. Порт будет также изменён на первый доступный из диапазона от 20000 до 20099. Как можно заметить, в данном случае хост 192.168.1.149 может открыть наружу не более 100 соединений. Всё что осталось - применить правила. ;-) Для удобства отслеживания работы NAT можно добавить строчку в syslog.conf: local0.* /var/log/ipmon.log и запустить утилиту мониторинга работы IPFilter - ipmon с ключами -Dvas (стать демоном, показывать более детальную информацию, отслеживать все утройства IPFilter (NAT, state table и сам IPFilter) и работать через syslog). Если получаемый log-файл кажется сумбурным - не торопитесь включать только NAT опцией -o N. Правила IPFilter попадающие в лог можно туда направлять с другой facility. Для этого достаточно в каждое правило с флагом log добавить facilty: block in log level local2.info quick on fxp0 from any to 192.168.0/16 а в syslog.conf добавить ещё одну строку: local2.* /var/log/ipfilter.block.log. В результате сего деяния в /var/log/ipmon.log будет попадать информация о NAT (созданные трансляции, закрытые трансляции) и state table (создание записи и её удаление), а в файл /var/log/ipfilter.block.log пакеты, которые были блокированы. Если не желаете, чтобы в большом количестве правил была указана facility и правила были короче - можно отвергнуть возможность работы ipmon через syslog и заставить его писать прямо в файл; например так: ipmon -Dv -o NS /var/log/NAT.log (трансляции и state table протоколируем в файл /var/log/NAT.log) и ipmon -Dv -o I /var/log/ipfilter.log (работу самого фильтра протоколируем в файл /var/log/ipfilter.log). Стоит заметить, что одним правилом можно транслировать несколько хостов. Например заменив в правилах ipnat и IPFilter 192.168.1.149/32 на 192.168.128/25 мы будем транслировать пакеты хостов из внутренней сети из диапазона от 192.168.1.128 до 192.168.1.254. Перенаправление (редирект) -------------------------- Если существует необходимость безусловно транслировать какие-то пакеты, пришедшие извне (например чтобы WWW/SMTP сервер из внутренней сети) был доступен снаружи - используется редирект (redirect). Простой вариант: транслировать пакеты от любого хоста. rdr fxp0 200.200.200.1/32 port 8080 -> 192.168.1.17 port 80 tcp В данном случае любой пакет, пришедший на порт 8080 внешнего интерфейса 200.200.200.1 будет "проброшен" на 192.168.1.18 порт 80. Естественно, что хост 192.168.1.17 лучше поместить в таблицу трансляций как было описано в "Простеньком stateful NAT" и с учётом того, что инициироваться соединение будет снаружи - добавить правила IPFilter, которые бы разрешали их. В случае, если ipmon протоколирует работу IPFilter, допущенную ошибку можно будет легко увидеть. Редирект можно делать не всех пакетов, а выборочно на основании их отправителя: rdr fxp0 from 212.118.165.100/32 to 200.200.200.1/32 port = 6000 -> 192.168.1.89 port 6000 Этим правилом будут транслироваться пакеты, пришедшие на 200.200.200.1 порт 6000 только с хоста 212.118.165.100 Не стоит забывать создавать правила IPFilter, разрешающие прохождение таких пакетов. Хотя, если ipmon настроен и запущен, то он быстро об этом напомнит. ;-) FTP proxy --------- Итак, всё работает замечательно, за исключением FTP. Это обусловлено тем, что в ходе установки соединения, по которому будут передаваться данные, указывается IP-адрес клиента, который в нашем случае принадлежит частной сети. ipnat способен в таких случаях быть "прокси-сервером" - то есть "ковыряться" в данных, передаваемых FTP-серверу и от него, и транслировать адреса из внутренних во внешние и наоборот. Для этого используется такое правило: map fxp0 192.168.1.149/32 -> 200.200.200.1/32 proxy port ftp ftp/tcp proxy-правило должно обязательно стоять перед другими правилами (за исключением redirect). Использование отдельного IP-адреса для трансляций на внешнем интерфейсе ----------------------------------------------------------------------- Если у Вас имеется в наличии не 1 IP-адрес, а сегмент сети, может быть удобным транслировать не с тех адресов, которые установлены на внешнем интерфейсе (fxp0), а с других. При этом важным является то, что на самом внешнем интерфейсе (fxp0) этот IP-адрес устанавливать нет никакой необходимости. ipnat делая трансляцию не открывает сокетов - об этом нужно помнить. Допустим, что сеть 200.200.200.0/24 полностью принадлежит нам. В таком случае, во всех правилах трансляции мы можем ставить не реальный IP-адрес, установленный на внешнем интерфейсе (fxp0), а другой, например 200.200.200.200 (также можно по желанию сделать PTR запись для этого хоста в зоне 200.200.200.in-addr.arpa). Безусловная полная трансляция ----------------------------- Если существует необходимость транслировать абсолютно все пакеты, пришедшие на какой-либо адрес (не забывайте, что этот IP-адрес необязательно должен быть установлен на внешнем интерфейсе fxp0) - используется правило bimap. bimap fxp0 192.168.1.66/32 -> 200.200.200.100/32 и/или bimap fxp0 192.168.1.66/32 -> 200.200.200.100/32 portmap tcp/udp Контроль над трансляцией ------------------------ Безусловно глупо настраивать NAT не глядя в протоколы, генерируемые ipmon'ом. Также возможно будет полезным ограничивать способность устанавливать соединения изнутри к привилегированным портам внешних хостов. Всё это можно и нужно настроить по желанию.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

Обсуждение [ RSS ]
 
  • 1.1, Алексей, 13:33, 07/12/2004 [ответить] [смотреть все]
  • +/
    Могут ли быть одновременно включены опции IPFILTER и IPFIREWALL? Если natd уже работает (т.е. natd_enable="YES"), то может ли одновременно с ним работать ipnat (i.e. ipnat_enable="YES")?
     
     
  • 2.2, Adminz, 16:26, 03/02/2005 [^] [ответить] [смотреть все]
  • +/
    Здравствуйте 8 Без всяких прелюдий, прямо к делу Необходимо фильтровать и сч... весь текст скрыт [показать]
     
  • 2.3, Ilja, 02:37, 10/06/2005 [^] [ответить] [смотреть все]  
  • +/
    >Могут ли быть одновременно включены опции IPFILTER и IPFIREWALL? Если natd уже
    >работает (т.е. natd_enable="YES"), то может ли одновременно с ним работать ipnat
    >(i.e. ipnat_enable="YES")?

    Mogut. Tolko v etom slu4ae ipnat ne budet vlijat na NAT, t.e. vsem zapravliat budet natd.
    Sobstvenno uspeshno ispolzuju sistemu: ipf-ipnat-ipfw.

     
  • 1.4, Виталий, 16:14, 17/03/2006 [ответить] [смотреть все]  
  • +/
    А что насчёт pptp-proxy?
    Как пример надо выпустить n машин через ipnat в мир в направлении единого pptp сервера.
     
  • 1.5, bit, 09:29, 05/09/2007 [ответить] [смотреть все]  
  • +/
    Рульно! Респект! Просто и доходчиво! От этого можно плясать!
    Сенкью вери мач! :) За труд!
     
  • 1.6, scompick, 07:43, 24/02/2010 [ответить] [смотреть все]  
  • +/
    Люблю живые статьи. Так держать!
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:





      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor