The OpenNET Project / Index page

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

[FreeBSD] Распределение трафика между двумя каналами (ipfw fwd + NAT) (freebsd ipfw forward nat)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: freebsd, ipfw, forward, nat,  (найти похожие документы)
From: Дмитрий Новиков <dmn@nnz.ru> Newsgroups: http://www.artmagic.ru/labs/ Date: Mon, 4 Dec 2002 13:01:37 +0000 (UTC) Subject: [FreeBSD] Распределение трафика между двумя каналами (ipfw fwd + NAT) Оригинал: http://www.artmagic.ru/labs/short/2-channels-managment-FreeBSD.shtml Распределение трафика между каналами в для FreeBSD Зачастую стречается ситуация, когда имеется 2 канала для выхода в Интернет. Чаще всего для увеличения отказоустойчивасти сервер подключется к 2-м каналам. При этом, один канал работает как основной а второй- в качестве запасного. Но зачастую необходимо распределить трафик между каналами (хотя бы потому, что на каждый канал имеется лимит трафика от провайдера). Классическим решением работы по двум и более каналам является регистрация автономной системы (AS) и получение сети независимых адресов. Потом по протоколу BGP строятся маршруты прохождения трафика через один или другой канал. Но регистрация AS и получение независимой сети адресов дело дорогое и достаточно сложное и для организации подкючения корпоративной сети не всегда оправдано. Ведь решить проблему распределения трафика между каналами можно решить с помощью свяки системы NAT и Sorce Routing (маршрутизация по источнику). Кроме того, эта связка позволяет распределить трафик не только на основе пунктов назначения, но и на основе исходных сетей. Ниже будет показано, как распределять трафик между двумя каналми на основе OC FreeBSD. Итак, допустим, что имеется два выхода в Интернет: 1. Через интерфейс с IP: 195.1.1.1 c шлюзом 195.1.1.254 2. Через интерфейс с IP: 212.1.1.1 c шлюзом 212.1.1.254 Трудность очевидна: в нормальном режиме (без применения динамической маршрутизации) у OC FreeBSD один шлюз "по умолчанию" (ровн как и у любой другой ОС) и все пакеты "складываются" в этот шлюз. С помощью механизма можно "обходить" шлюз по умолчанию и направлять потоки другие каналы. Для того, чтобы механизм ip forwarding заработал, необходимо включить в ядре FreeBSD опции IPFIREWALL, IP DIVERT, IPFIREWALL_FORWARD. Более подробно, как подготовить ядро, можно прочитать здесь. После этого появиться возможность применять команду ipfw fwd <альтернативный шлюз>, которая перенаправляет поток в обход шлюза по умолчанию и вообще статических маршрутов. В нашем примере, для того чтобы сеть 212.1.2.0/24 "ходила" через интерфейс 212.1.1.1 нужно записать правило (или запустить команду): ipfw add fwd 212.1.1.254 ip from 212.1.2.0/24 to any В качестве альтернативного шлюза мы указываем шлюз второго канала. Приведенный пример показывает как воспользоваться командой ipfw fwd но это применение для сети реальных адресов. Теперь усложним задачу и будем распределять трафик из одной сети с фиктивными адресами (что чаще всего и бывает на практике подключения корпоративных сетей). Допустим, у нас имеется корпоратвная сеть с адресами 10.1.0.0/16, подключенная к серверу доступа. Примем первый канал как основной. Для него нужно применить стандартную схему вывода сети в Интернет (см. статью). - Default route ставим 195.1.1.254 (route add default 195.1.1.254) route add default 195.1.1.254 или прописать в /etc/rc.conf defaultrouter="195.1.1.254" - запускаем NAT на интерфейсе адреса 195.1.1.1 (например пусть это будет fxp0) natd -a 195.1.1.1.1 - запускаем нужные правила ipfw divert... порт для NAT используем стандартный. ipfw add 100 divert natd ip from 10.1.0.0/16 to any ipfw add 200 divert natd ip from any to 195.1.1.1 После этого сеть 10.1.0.0 будет выходить в Интернет через канал (1). Теперь запустим еще один демон NAT на другом порту (например 8672): natd -a 212.1.1.1 -p 8672 Поставим задачу выпустить через альтернативный канал хост 10.1.1.100. Для этого: - "Завернем" трафик с хоста 10.1.1.100 в альтернативный NAT ipfw add 20 divert 8672 ip from 10.1.1.100 to any - И уже "свернутый" адрес проведем в алтернативный шлюз ipfw add 50 fwd 212.1.1.254 ip from 212.1.1.1 to any - Также не забудем "обратный" divert ipfw add 60 divert 8672 ip from any to 212.1.1.1 Важно, чтобы эти правила шли перед правилами NAT по умолчанию (обратите внимание на нумерацию правил!). Итак, теперь вся сеть идет через один канал а хост из этой же сети идет через другой. Гибкость написания правил ipfw позволяет задавать любую логику распределения трафика. Для этого нужно лишь вставлять правила отправки на альтернативный NAT (между правилом 20 и 50). Например: ipfw add 21 divert 8672 ip from 10.1.2.0/24 to any - отправит часть сети (подсеть класса C) в другой канал. ipfw add 21 divert 8672 tcp from 10.1.1.0/16 to any 5190 - отправит трафик ICQ в другой канал.

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

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Христо Топов (?), 05:21, 01/11/2003 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как разпределит трафик динамически между ети двумями входящими каналов для всех хостам в сети
     
     
  • 2.2, McLone (?), 07:38, 11/11/2003 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно придется вскоре строить такое у себя, напишу сюда чё и как... Заюзаю, пожалуй, ipf/ipnat методом round-robin по state-записям, наверное... (имеется ввиду и  statefull-ICMP тоже :-) Aли OpenBSD'шный pf... Хотя глядя на сорцы/динамику development'a ipf 4.0 betas, надеюсь что доделают...
     

  • 1.3, Khul (?), 16:28, 23/04/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все хорошо, красиво и удобно. Только работать не хочет.
    "- Также не забудем "обратный" divert
    ipfw add 60 divert 8672 ip from any to 212.1.1.1"

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

     
     
  • 2.7, Phil (??), 12:17, 21/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Такая же проблема - они уходят не в неизвестном направлении а с дефаулт роутера =( ... соответственно твое правило не срабатывает. Бъюсь 3 день над этим - как разберусь - отпишу.
     
     
  • 3.8, Phil (??), 12:45, 21/02/2007 [^] [^^] [^^^] [ответить]  
  • +/
    По этой теме:
    IPFIREWALL_FORWARD_EXTENDED нужно добавить в опции при сборке ядра. Иначе все будет ходить через дефаулт роутер (tcpdump ом проверьте), по этому и не срабатывает правило диверта обратного с дополнительного канала. Угробил на это 3 дня - Сарумян лучший =).
     

  • 1.4, Мстислав (?), 17:43, 23/04/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хочу сделать у себя подобное. Имеется машина с 3-мя сетевыми интерфейсами. 1-й внутренный (10.x.x.x), 2-й и 3-й внешние (линки на разных провов). Демон natd висит на одном из внешних. На второй внешний вешаться не хочет...Ессно, добавлять второго демона пытаюсь с ключами -a,-p и -n.
    Что я делаю не так? Или так вообще работать не будет?
     
  • 1.5, togkskbr (??), 14:31, 03/06/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    попробывал по этой статье тоже пакеты уходят в неизвестном направлении,  нарыл http://ipfw.ism.kiev.ua/pbr.html попробывал работает
     
  • 1.6, Валера (??), 05:02, 26/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Привет.Не могу Нат настроить, для ппп...
    Везде читаю для Фри 4.Х, а для 6?
    Для ФРИБСД 4.4. все описывается вот так:
    /sbin/ipfw add divert natd all from 192.168.11.199 to any via ng0
    Но у МЕНЯ 6.0.!!!
    Детальней:
    подключение к Инету:tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
    inet 193.238.152.25 --> 193.238.152.1 netmask 0xffffffff

    Подключение к mpd:
    ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1400
    inet 192.168.10.1 --> 192.168.11.200 netmask 0xffffffff
    ng1: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1400
    inet 192.168.10.1 --> 192.168.11.199 netmask 0xffffffff
    ng2 и т.д.

    Надо натить: ng0,ng1,ng2...ngXX==>tun0
    ИП известны для каждого отдельного ngXX и для каждого можно запустить свое правило(свой скрипт).

    Это скорее постановка задачи, которую не могу решить...
    ЗЫ:ОСЬ FreeBSD+ipfw+natd(хотя не принципиально)

    А вопрос звучит так:
    есть множество ngXX и tun0, надо что бы каждый из ngXX мог ходить в Сеть за tun0...
    Помогите с реализацией?

     
     
  • 2.11, dj_gans (?), 20:05, 02/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Привет.Не могу Нат настроить, для ппп...
    >Везде читаю для Фри 4.Х, а для 6?

    Была точно такая же задача, но немного другие условия:
    локалка 192.168.0.1/27, на нее смотрит сетевуха xl0 с адресом 192.168.0.1
    внешка через VPN 10.10.0.1, не нее смотрит fxp0 с адресом 10.10.12.22
    прописываем mpd адреса нашей локалки:
    pptp0:
        new -i ng0 pptp0 pptp0
        set ipcp ranges 192.168.0.1/32 192.168.0.21/32
        load pptp_standart
    и т.п.
    далее рулим их из-под ната во внешку, на которую смотрит fxp0:

    /sbin/ipfw add 1 divert natd all from 192.168.0.0/27 to any out via fxp0
    /sbin/ipfw add 2 divert natd all from any to 10.10.12.22 in via fxp0

    т.е. при входящем подключении через mpd клиент попалает в локалку, а из нее, как все, во внешку. замечания/предложения приветствуются.

     

  • 1.9, Artem (??), 15:25, 07/08/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    IPFIREWALL_FORWARD_EXTENDED при попытке добавить в ядро этой опции отвечает
    unknown option "IPFIREWALL_FORWARD_EXTENDED"
    FreeBSD 6.2
     
     
  • 2.10, togkskbr (??), 17:13, 02/10/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >IPFIREWALL_FORWARD_EXTENDED при попытке добавить в ядро этой опции отвечает
    >unknown option "IPFIREWALL_FORWARD_EXTENDED"
    >FreeBSD 6.2

    почитай файл NOTES (расположение читай в аннотации к GENERIC)

     

  • 1.12, Владимир (??), 11:50, 26/10/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    у меня в 6.2 настроена маршрутизация между двумя каналами. По одному идёт мир а по другому укр. В теме http://www.opennet.ru/openforum/vsluhforumID1/76913.html есть примеры ipfw и обьяснение как там всё  устроено.
     
  • 1.13, Серей (?), 18:27, 23/11/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    здраствуйте, ситуация идентичная, только нат у меня 1 и его весь хочу отправить через альтернативный шлюз. Но как ни старался, все что получается - это все запросы идут через дефолтовый (после ната), а возврат идет через альтернативный. Причем адрес источника - айпишник альтернативного интерфейса(нат отрабатывает красиво). По какойто причине не срабатывает форвард. На альтернативном интерфейсе нет ниодного исходящего пакета. Хелп.
     
     
  • 2.14, sysnotok (?), 10:40, 25/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    та же проблема. FreeBSD 7.0 Есть какое нибудь решение-то?
     
     
  • 3.15, zuborg (?), 14:28, 21/04/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Скорей всего проблема не в том что fwd не работает, а в том что tcpdump этого не показывает
    Сам целый день голову ломал, как починить.
    Оказалось, что если на локал-хосте смотреть через tcpdump, то можно видеть что траф идет через default интерфейс, или вообще никудой не идет, тогда как fwd отрабатывает нормально и пакеты идут так как настроено.
    Проверить можно tcpdump-ом на удаленной стороне, или даже банальным выдергиванием кабеля из вторичного интерфейса - пакеты перестанут проходить (хотя раньше проходили и tcpdump показывал что они шли и идут через основной интерфейс)
    Проверено для 7.0, другие не проверял
     

  • 1.16, Alex (??), 10:19, 23/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Здравствуйте! Проблема с natd. На сервере 2 сетевых карты, для локалки и интернета, кроме того есть туннель через gif0. Не могу настроить чтобы трафик заворачивался из туннеля. Мой трафик туда уходит, ответы tcpdump показывает, но они не попадают в divert а исчезают бесследно.
    Правила ipfw:
    00010 count log logamount 500 ip from any to any via gif0
    00100 count ip from any to any in recv dc0
    00200 count ip from any to any out xmit dc0
    00300 count tcp from any to me 25 in recv dc0
    00310 count tcp from any 80,443 to me in recv dc0
    00410 allow ip from any to any via lo0
    00510 allow ip from 194.39.131.174 to any
    00610 allow ip from any to 194.39.131.174
    00710 allow esp from any to any
    00810 allow ipencap from any to any
    00910 allow udp from any to any 500
    01010 divert 8765 log logamount 500 ip from 192.168.10.203 to 194.117.106.129 out xmit gif0
    01110 divert 8765 log logamount 500 ip from 194.117.106.129 to any

    4 дня провел за чтением манов и поиском информации в Интернете. Ничего не помогло...

     
     
  • 2.17, Alex (??), 06:54, 25/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Дополнение: туннель ipsec.
    Проблема решилась пересборкой ядра с параметром IPSEC_FITERGIF.
     

  • 1.18, Евгений (??), 11:10, 08/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Здравствуйте!
    У меня вопрос. А если у меня NAT построен не на natd, а на ipnat (ipf)? Пишу в ipfw правило ipfw add 15 fwd x.x.x.1 all from y.y.y.y/32 to not me in recv xl0 (xl0 - локалка, xl1 - основной канал, xl2 - дополнительный)
    map xl1 y.y.y.0/24 -> z.z.z.z/32 proxy port ftp ftp/tcp
    map xl1 y.y.y.0/24 -> z.z.z.z/32 portmap tcp/udp 40000:65000
    map xl1 y.y.y.0/24 -> z.z.z.z/32
    map xl2 y.y.y.0/24 -> x.x.x.2/32 proxy port ftp ftp/tcp
    map xl2 y.y.y.0/24 -> x.x.x.2/32 portmap tcp/udp 40000:65000
    map xl2 y.y.y.0/24 -> x.x.x.2/32
    tcpdump показывает, что пакеты форвардятся, но предварительно пройдя через нат и получив IP = z.z.z.z, тот который на основном интерфейсе xl1
    udp пакеты (traceroute) при этом бегают так как и хотелось бы, а вот tcp :( Как побороть эту проблему?
     

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

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




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

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