The OpenNET Project / Index page

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

Policy-Based Routing (PBR) в ОС FreeBSD (freebsd firewall ipfw policy forward nat)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: freebsd, firewall, ipfw, policy, forward, nat,  (найти похожие документы)
From: Александр Мори <morya@apexnet.dp.ua.> Date: Mon, 20 Sep 2004 18:21:07 +0000 (UTC) Subject: Policy-Based Routing (PBR) в ОС FreeBSD Оригинал: http://ipfw.ism.kiev.ua/pbr.html Когда возникает необходимость в PBR? В сегодняшних компьютерных сетях высокой производительности, возникает необходимость в выполнении пересылки пакетов соответственно определенной политике (правилу или набору правил), которая, в некотором отношении, выходит за границы традиционных принципов работы протоколов маршрутизации. PBR используется там, где, в силу различных обстоятельств, необходимо дифференцировать трафик по какому-либо признаку, и выбирать различный дальнейший маршрут для каждого случая отдельно. Классическим решением работы по двум и более каналам является регистрация автономной системы (AS) и получения сети независимых адресов. Затем по одному из протоколов внешнего шлюза - BGP или EGP - строятся маршруты прохождения трафика через один или другой канал. Однако регистрация AS и получение независимой сети адресов - дело дорогое и достаточно сложное, причем для орагнизации подключения корпоративной сети не всегда оправдано. Достоинства PBR Bыбор маршрута, основанный на источнике - позволяет пропускать трафик, приходящий из различных мест, через разные каналы подключения к Интернет Эффективное использование имеющихся каналов подключения к Интернет Расширение возможностей динамической маршрутизации Что такое PBR? PBR предоставляет механизм реализации пересылки (forwarding)/ маршрутизации (routing) пакетов данных, основанный на политике, представляющей собой набор правил, определенной администраторами сети. Это предоставляет более гибкий механизм для обработки пакетов на маршрутизаторах, дополняя существующий механизм, предоставленный протоколами маршрутизации. Маршрутизаторы выбирают дальнейший путь следования пакетов данных по полю "адрес назначения", основываясь на информации из таблицы статических маршрутов или полученной от динамических протоколов маршрутизации, как, например Routing Information Protocol (RIP), Open Shortest Path First (OSPF), или Enhanced Interior Gateway Routing Protocol (Enhanced IGRP). Вместо выбора дальнейшего маршрута, основанного на адресе назначения, PBR позволяет администраторам сети определить свои правила, по которым будет осуществляться маршрутизация пакетов. Сфера применения отдел A \ / ISP 1 -- |--- [шлюз] ---| Internet отдел B / \ ISP 2 -- Наиболее часто на практике PBR используется в ситуации, которая представлена на рисунке. Т. е. когда какая-либо организация имеет 2 или более канала подключения к Интернет. В стандартном случае один канал является основным (через него организация выходит в Интернет), а второй - вспомогательным (он подключается, когда неисправен первый канал, в остальное время обычно используется для доступа к локальным ресурсам одного из провайдеров, т.е. mp3, video и т.д.). При таком варианте эффективность использования двух каналов чрезвычайно низка. Конечно, и такой вариант имеет право на существование, но рано или поздно перед развивающейся организацией появляется задача более эффективного использования имеющихся каналов подключения к Интернет или, возможно, разделения этих каналов между своими отделами (например, отдел производства будет использовать канал на ISP1, а отдел маркетинга - канал на ISP2). Именно в этом случае на помощь приходит policy-based routing. Практическая реализация в ОС FreeBSD В ОС FreeBSD policy-based routing осуществляется с помощью механизма ip forwarding и пакетного фильтра ipfw. Чтобы включить возможность пакетной фильтрации в ОС FreeBSD необходимо вставить в файл конфигурации ядра ОС следующие строки: options IPFIREWALL options IPDIVERT options IPFIRWALL_FORWARD В результате мы активируем следующие механизмы: пакетный фильтр, NAT (сетевая трансляция адресов, позволяет разделять один канал выхода в Интернет между множеством пользователей) и механизм ip forwarding. Рассмотрим следующий вариант. Имеется сервер с ОС FreeBSD с двумя каналами доступа к Интернет (ISP1, ISP2) и двумя подключения локальной сети (отдел А, отдел Б). Примем следующую конфигурацию сетевых интерфейсов: rl0 - 1.1.1.1 /24(gateway 1.1.1.254 ISP1) rl1 - 2.2.2.2 /24(gateway 2.2.2.254 ISP2) rl2 - 3.3.3.3/24 (lan1, отдел А) rl3 - 4.4.4.4 /24(lan2, отдел Б) Поставим такую задачу, чтобы пользователи lan1 выходили в Интернет через первого провайдера ISP1, а пользователи lan2 - через ISP2. Заранее оговорю, что приведенные ниже примеры будут работать вне зависимости от того, какой маршрут по умолчанию (через ISP1 или ISP2) определен в настройках ОС. Сначала необходимо запустить NAT на интерфейсах rl0 и rl1: natd -a 1.1.1.1 -p 8668 natd -a 2.2.2.2 -p 8778 Создадим набор правил для ipfw: ipfw 10 add divert 8668 ip from 3.3.3.0/24 to any ipfw 20 add divert 8778 ip from 4.4.4.0/24 to any ipfw 30 add fwd 1.1.1.254 ip from 1.1.1.1 to any ipfw 40 add fwd 2.2.2.254 ip from 2.2.2.2 to any ipfw 50 add divert 8668 ip from any to 1.1.1.1 ipfw 60 add divert 8778 ip from any to 2.2.2.2 В некоторых случаях имеется только одно подключение к локальной сети и необходимо "пропустить" через другой канал доступа к Интернет не локальную сеть, а один или несколько компьютеров. Допустим, есть только lan1 и через ISP1 в Интернет будет "выходить" компьютер с ip адресом 3.3.3.10 Опять же запускаем NAT: natd -a 1.1.1.1 -p 8668 natd -a 2.2.2.2 -p 8778 Следующий набор правил пакетного фильтра ipfw решает эту задачу: ipfw 10 add divert 8668 ip from 3.3.3.10 to any ipfw 20 add divert 8778 ip from any to any ipfw 30 add fwd 1.1.1.254 ip from 1.1.1.1 to any ipfw 40 add fwd 2.2.2.254 ip from 2.2.2.2 to any ipfw 50 add divert 8668 ip from any to 1.1.1.1 ipfw 60 add divert 8778 ip from any to 2.2.2.2 Иногда возникает и более сложная задача, когда необходимо не "жестко" разделять каналы, а когда пользователи, допустим, lan1 должны "выходить" в Интернет через ISP1, но также должны "видеть" и локальные ресурсы второго провайдера, и наоборот, пользователи lan2 "выходят" в Интернет через ISP2 и "видят" ресурсы ISP1. Допустим, локальные ресурсы ISP1 находятся по адресам 5.5.5.0/24, а ресурсы ISP2 -6.6.6.0/24. Конечно, не забываем запустить NAT: natd -a 1.1.1.1 -p 8668 natd -a 2.2.2.2 -p 8778 Для этого случая правила ipfw выглядят так: ipfw 10 add divert 8778 ip from 3.3.3.0/24 to 6.6.6.0/24 ipfw 20 add divert 8668 ip from 3.3.3.0/24 to any ipfw 30 add divert 8668 ip from 4.4.4.0/24 to 5.5.5.0/24 ipfw 40 add divert 8778 ip from 4.4.4.0/24 to any ipfw 50 add fwd 1.1.1.254 ip from 1.1.1.1 to any ipfw 60 add fwd 2.2.2.254 ip from 2.2.2.2 to any ipfw 70 add divert 8668 ip from any to 1.1.1.1 ipfw 80 add divert 8778 ip from any to 2.2.2.2 Некоторые замечания Реализация PBR в ОС FreeBSD средствами ipfw достаточна проста. Однако в некоторых ситуациях могут возникать непредвиденные осложнения, при которых рассмотренные выше примеры окажутся неработоспособными. Это произойдет, например, если на Вашем маршрутизаторе настроен web сервер (или какой-то другой сервис), который привязан к ip адресу внешнего интерфейса. Тогда необходимо вставить перед правилами, осуществляющим policy-based routing, правила, которые разрешат пользователям осуществить доступ к внешним интерфейсам. Важным моментом также является порядок и нумерация правил. Очень осторожно относитесь к этим вещам. Например, если в последнем примере все правила будут иметь один и тот же номер, то ничего хорошего из этого не выйдет. Это связано с особенностями обработки правил divert. Как известно, в ipfw каждый пакет проходит цепочку правил от правил с меньшими номерами к большим номерам до совпадения параметров пакета с параметрами правила. При "попадании" пакета в правило выполняются предписанные им действия, и дальнейшее прохождение по цепочке останавливается (пакет, конечно, может еще попасть в правила пакетного фильтра, например, при прохождении его через следующий сетевой интерфейс). Но при "попадании" пакета в правила divert прохождение по цепочке не останавливается, а продолжается с правила, номер которого превышает текущее. Т.е. если правила имеют одинаковый номер, то после правил divert в правила fwd пакет не "попадет". Вообще, как ведет себя пакет после "попадания" в правила divert определяется той программой, которой он обрабатывается. В нашем случае это natd. А natd работает именно так, как описано выше. Если же Вы все сделали как надо, но все равно ничего не работает, то вставьте в правила параметр log. Например: ipfw 10 add divert 8778 log ip from 3.3.3.0/24 to 6.6.6.0/24 или ipfw 50 add fwd 1.1.1.254 log ip from 1.1.1.1 to any Это позволит вам посмотреть в /var/log/security как "ходят" пакеты, в какие правила "попадают" (для этого необходимо включить в конфигурационном файле ядра ОС опцию IPFIREWALL_VERBOSE). Незаменимым инструментом при отладке также является программа tcpdump. С ее помощью Вы можете своими глазами увидеть и проверить все параметры пакетов данных, которые проходят через Ваш маршрутизатор.

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

Обсуждение [ RSS ]
  • 1, MasTiCorE (?), 15:50, 28/04/2005 [ответить]  
  • +/
    эээмм... без ната никак? или в бсд нет аналога ip rule линуксового?
     
  • 2, наступивший на грабли (?), 12:27, 20/10/2005 [ответить]  
  • +/
    в 5.4 ядро должно быть скомпилено с
    options         IPFIREWALL_FORWARD_EXTENDED
     
  • 3, zyxman (?), 20:56, 26/07/2006 [ответить]  
  • +/
    а есть возможность перехватывать tcpdump пакеты идущие с сервера на котором natd до того как natd их "поправил" ?
     
  • 4, второй наступивший на грабли (?), 20:32, 24/01/2007 [ответить]  
  • +/
    Спасибо огромное первому наступившему на грабли
    я извелся весь уже )
    и дополнительный вопрос это только в 5.4 или во всех последующих тоже?
     
  • 5, svol (ok), 10:38, 20/02/2009 [ответить]  
  • +/
    должен добавить, что в семерке при использовании кернел ната пришлось сделать
    sysctl net.inet.ip.fw.one_pass=0

    надеюсь, это сэкономит кому-то время и нервы.

     

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




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

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