The OpenNET Project / Index page

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

PBR на freeBSD посредством pf (freebsd pf firewall nat)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: freebsd, pf, firewall, nat,  (найти похожие документы)
From: Кравчук Андрей <krava13@gmail.com.> Newsgroups: email Date: Mon, 8 Jun 2009 17:02:14 +0000 (UTC) Subject: PBR на freeBSD посредством pf Доступ к внутренним ресурсам сети с нескольких внешних IP адресов ipnat pf и ipfilter+ipmon - это совершенно разные вещи (я наивно полагал, что натится все через ipnat, а, файрволится через pf). Короче ipnat нам не нужен. Конфигурационный файл pf - /etc/pf.conf, a pf.rules. Редактируй только его, то не будет работать :) ipfw + natd - использовать не рекомендую из-за запутанности правил и связки natd + ipfw. При работе с ipfw+natd ttl вырастал до бешенных резмеров что привело к тому, что пинги ходили с задержками в 2-3 секунды Собственно, установка: Ядро device pf device pflog device pfsync options ALTQ Подключение к системе в файле /etc/rc.conf pf_enable="YES" Настройка правил pf. Сохраняем на всякий случай оригинальный файл настроек pf: cp pf.conf pf.conf.orig удаляем все из pf.conf Правила /etc/pf.conf web_server="192.168.100.55" #наш веб сервер, к которому нужно сделать доступ из двух внешних IP lan_net="192.168.100.0/24" # внутрення сеть, в которой находится веб-сервер int_if="rl2" # внутренний интерфейс (он один для всех) ext_if1="nve0" # первый внешний интерфейс ext_if2="rl3" #второй внешний интерфейс ext_gw1="192.168.0.15" # первый gw для первого внешнего интерфейса ext_gw2="192.168.2.1" # второй gw для второго внешнего интерфейса # первым делом редиректим все, что идет на 80-й порт (www) с первого интерф. на вебсервер на 80-й порт rdr on nve0 inet proto tcp to nve0 port www -> $web_server port 80 # теперь редиректим все со второго внешнего интерфейса на навебсервер на 80-й порт. rdr on $ext_if2 inet proto tcp to $ext_if2 port www -> $web_server port 80 #rdr on rl2 inet proto tcp from any to any port www -> 127.0.0.1 port 3128 # натим первый канал на первом внешнем интерфейсе nat on $ext_if1 inet from any to any -> { $ext_if1 } # натим второй внешний канал на втором внешнем интефейсе nat on $ext_if2 inet from any to any -> { $ext_if2 } # Ставим вот такую связку (2 правила) для того, чтобы пакеты у # нас возвращались не по default-route, а туда куда нам нужно. В # данном случае к пользователю, который # запрашивает доступ к web серверу через второй внешний интерфейс. pass in quick on $int_if from $lan_net to $int_if pass in on $int_if route-to ($ext_if2 $ext_gw2) from $lan_net to any Используемая литература. 1. Огненный блокпост, Хакер № 099, стр 4. http://www.xakep.ru/magazine/xa/099/154/1.asp - Разница между файрволлами 2. Policy base routing на основе pf. Сообщение от Запуниди Сергей email on 23-Авг-07, 20:59 на Opennet.ru. https://www.opennet.ru/openforum/vsluhforumID1/63044.html - Смотри сообщение № 3, там все доступно написано 3. Мои вопросы на "Форуме системных администраторов" http://forum.sysfaq.ru/index.php?showtopic=19127 - как все начиналось и к чему пришло Благодарности Incognito http://forum.sysfaq.ru/index.php?showuser=6 o.k. http://forum.sysfaq.ru/index.php?showuser=2768 Сергей Супрунов (amsand at rambler.ru) Запуниди Сергей (zap at proc.ru)

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Обсуждение [ RSS ]
  • 1.1, AdVv (ok), 12:27, 10/06/2009 [ответить]  
  • +/
    Блин фразу "ipfw + natd - использовать не рекомендую из-за запутанности правил и
    связки natd + ipfw. При работе с ipfw+natd ttl вырастал до бешенных резмеров что привело к тому, что пинги ходили с задержками в 2-3 секунды" надо на баш отправить.

     
     
  • 2.2, Xaionaro (?), 23:21, 11/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Да вообще, писал человек достаточно слабый :). Хотя я лично тоже не рекомендую natd, но всё-таки совсем по другим причинам :). А именно, natd очень не экономичен в плане ресурсов CPU. Да и вообще, тот же pf, лично по-моему, значительно более "мощный" (по функционалу) и удобный, чем ipfw.
     
     
  • 3.3, AdVv (ok), 14:46, 12/06/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Да вообще, писал человек достаточно слабый :). Хотя я лично тоже не
    >рекомендую natd, но всё-таки совсем по другим причинам :). А именно,
    >natd очень не экономичен в плане ресурсов CPU. Да и вообще,
    >тот же pf, лично по-моему, значительно более "мощный" (по функционалу) и
    >удобный, чем ipfw.

    natd единственный под FreeBSD справляется с задачей nat для pptp соединений. PF этого не умеет до сих пор. Свистелок типа os detection и pfauth в ipfw  нет, но их необходимость сомнительна. Функционала ipfw достаточно для любых реальных задач по обработке траффика, никакого "значительного" превосходства тут не может быть в принципе. На мой взгляд у всех unixlike файрволов сходный синтаксис и возможности. В плане производительности natd вероятно уступает in kernel реализациям, хотя насколько сильно лично я не измерял. Для средних размеров организации на современном железе ее хватает за глаза, ну а для магистралей существуют совсем другие решения. И еще надо заметить что ipfw  часть FreeBSD, а PF всетаки порт с другой системы. В некоторых случаях ipfw оказывается гибче. Если есть желание почитайте http://nuclight.livejournal.com/


     

  • 1.4, dimanoname (?), 15:31, 27/06/2009 [ответить]  
  • +/
    статьи такого уровня запудривают ньюбам моск, искажая их представление о ФриБСД вцелом.имхо:)
     

    игнорирование участников | лог модерирования

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




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру