Тайна незанятого xl0 или получаем контроль над своей сетью

    Как вы все помните, в конце предыдущего поста я обещал более подробно рассмотреть вкратце и максимально доступно следующие вопросы:

    1. Настройка DHCP
    2. Поднимаем свой DNS по минимуму
    3. Съем статистики по интерфейсам при помощи snmp и отрисовывание красот в cacti
    4. Лимитирование по трафику пользователей внутри сети
    5. Ведение детальной статистики по тому, как куда и кем расходуется трафик
    6. Настройка бекапа каналов в случае наличия еще одного провайдера (а о xl0 все и забыли)
    7. Разруливание трафика между несколькими каналами средствами ipfw
    image

    В свете предыдущих обсуждений хотелось бы напомнить:
    — статьи сии из серии “FreeBSD for dummies”
    — нет, я не буду писать про pf и altq
    — успокойтесь с хардовыми решениями и проксями на винде – не о них идет речь
    — нет, про squid & sarg ни слова – не наш метод, хотя ж никто не запрещал?
    — 10.10.10.0/24 и 172.16.0.0/24 потому что не 123.123.123.122 и не 222.222.222.222 мне глаз не режет
    — так делать нельзя и не рекомендуется – это не руководство, это просто демонстрация концепции в общем. В идеале не должно быть всяких allow from any to any, доступа к mysql под рутом итд. Ну вы поняли :)

    Итак поехали по порядку

    Сверяемся для начала с нашей красивой сферической сетью в вакууме и решаем что было-бы хорошо раздавать всем сетевые настроечки (айпишку, маску, шлюз, днс-ы) автоматом

    image

    Установка isc-dhcpd не должна вызывать никаких сложностей:
    #cd /usr/ports/net/isc-dhcp40-server/
    #make install

    После чего в /etc/rc.conf добавляем следующее:
    dhcpd_enable="YES"
    dhcpd_flags="-q"
    dhcpd_conf="/usr/local/etc/dhcpd.conf"
    dhcpd_ifaces="fxp0"


    Далее правим наш /usr/local/etc/dhcpd.conf следующим удобным образом:
    option domain-name-servers 192.168.0.1;
    default-lease-time 3600;
    max-lease-time 43200;
    authoritative;
    ddns-update-style none;
    log-facility local7;
    one-lease-per-client true;
    deny duplicates;

    subnet 192.168.0.0 netmask 255.255.255.0 {
    default-lease-time 3600;
    option domain-name "office";
    option subnet-mask 255.255.255.0;
    option routers 192.168.0.1;

    include "/usr/local/etc/dhcp_subnets.conf";

    }


    Зачем так извратно? А чтобы проще было потом добавлять хосты в сабнет автоматом избегая возни с закзывающей «}»

    Поехали теперь смотреть что-же будет наш сабнет представлять из себя:

    /usr/local/etc/dhcp_subnets.conf

    и для теста вбиваем следующее:
    host hostmariya {
    hardware ethernet 00:a1:b0:01:bc:77;
    fixed-address 192.168.0.2;
    }


    Все вроде, пробуем это все дело стартовать
    # /usr/local/etc/rc.d/isc-dhcpd start


    Оппаньки – запустилось. Ок.
    Как вы могли заметить по опциям option domain-name-servers 192.168.0.1 сейчас мы будем по ускоренной программе подымать свой DNS сервер. Будет он у нас только форвардящим, ибо мы полностью пока что полагаемся на безупречность нашего провайдера. Да и свои зоны пока что вести не будем. Будем просто раздавать Наталье Васильевне и Григорию Сергеичу интернеты. Даже на двух провайдеров мы будем полагаться.
    Почему двух?
    ВНЕЗАПНО появляется второй провайдер, более быстрый и дешевый. А от старого мы отказываться так не собираемся – зачем добру пропадать. Будем использовать его как резервный линк.

    Смотрим /etc/namedb/named.conf

    Раскаментиваем
    forward only;


    Начинаем слушать наш внутренний fxp0
    listen-on { 127.0.0.1; 192.168.0.1; };


    Раскоментиваем форвардеров которые у нас будут иметь вид допустим 10.10.10.2 и 172.16.0.2 (да да – второй провайдер у нас уже живет на сетевухе xl0 на которой висит айпишка допустим 172.16.0.1)
    forwarders {
    10.10.10.2;
    172.16.0.1;
    };


    Сохраняемся и пробуем запускать:
    #/usr/sbin/named -t /var/named -u bind


    Тестим запустилось ли хотябы:
    #ps aux | grep named
    bind 10095 0.0 0.7 4280 3484 ?? Ss 7:58PM 0:00.11 /usr/sbin/named -t /var/named -u bind


    Вроде запустилось

    а работает ли?

    # nslookup
    > server 127.0.0.1
    Default server: 127.0.0.1
    Address: 127.0.0.1#53
    > google.com
    Server: 127.0.0.1
    Address: 127.0.0.1#53

    Non-authoritative answer:
    Name: google.com
    Address: 74.125.127.100
    Name: google.com
    Address: 74.125.45.100
    Name: google.com
    Address: 74.125.67.100


    Работает! Отличненько.

    Пишем в /etc/rc.conf строчечку
    named_enable="YES"


    исправляемся в /etc/resolv.conf
    на
    nameserver 127.0.0.1


    Как уже говорилось у нас появился еще один провайдер которого мы хотели бы использовать как основного?
    Открываем наш страдальческий /etc/firewall.conf и в том месте где у нас все натиться делам допустим так:
    #internet natting and preserving
    ${FwCMD} add 1799 divert 8671 ip from table\(2\) to not table\(9\)
    ${FwCMD} add 1800 divert 8672 ip from table\(2\) to not table\(9\) out via xl0
    ${FwCMD} add 1847 fwd 172.16.0.2 ip from me to 213.180.204.8
    ${FwCMD} add 1849 fwd 10.10.10.2 ip from 10.10.10.1 to not table\(9\)
    ${FwCMD} add 1850 fwd 172.16.0.2 ip from 172.16.0.1 to not table\(9\)
    ${FwCMD} add 2099 divert 8671 ip from any to 10.10.10.1 in via rl0
    ${FwCMD} add 2100 divert 8672 ip from any to 172.16.0.1 in via xl0


    Ну и подымаем второй natd для нового провайдера:
    /sbin/natd -u -p 8672 -a 172.16.0.1


    Давайте в кратце разберем как это работает чтобы в будущем мы не путались:
    • Правило 1799 это прямой заворот трафика от нашей сети из таблички 2 в natd
    • Правило 1800 аналогично предыдущему но уже для резервного канала и естественно туда ничего не попадет пока существует 1799
    • Правила 1847 предназначено только для прокидывания нужного нам хоста по которому мы будем контролировать живость канала сквозь нового провайдера (172.16.0.2)
    • Правила 1849 и 1850 жестко рассказывают куда девать трафик появившийся на соответствующих сетевухах
    • Ну и 2099 и 2100 соответственно обратные диверты в natd

    Логика работы проста – если живы правила 1799, 1849, 2099 интернет ходит новым провайдером который 172.16.0.2 если же они отсутствуют трафик «неожиданно» устремляется в 10.10.10.2 =)
    Переключалку такую мы с вами напишем чуть позже.

    Смотрим что шло следующим пунктом нашей программы на сегодня. Ой… snmp и установка apache+mysql+php+cacti… А можно на следующий раз отложим? Ну-у-у пожалуйста-а-а! Ну хотябы установку и настройку cacti. Давайте сейчас будем ставить биллинг, а мониторить и допиливать до красивости все это мы будем в финале?
    Договорились? ;) Тогда поехали.

    Для таких микрозадач использовать мы будем опенсорсный биллинг stargazer который является самым простым и предсказуемым решением из тех что я до сих пор видел.
    Для его установки нам потребуется:
    1. mysql в котором мы будем хранить данные биллинга
    2. так как стройные костыли и подпорки мы будем писать на php поставим уж и php + apache
    3. собственно последний стабильный stargazer

    Для начала рекомендую ознайомиться хотя-бы с вот такой минимальной докой либо с другими посвященными установке связки apache+php+mysql. Опишу вкратце.

    Поехали ставить mysql.
    # cd /usr/ports/databases/mysql50-server/
    # make install
    # /usr/local/bin/mysqladmin -u root -p password ourpassword


    Начинаем ставить php
    # cd /usr/ports/lang/php5/
    # make install


    И собираем расширения поддержки mysql, gd, iconv ну и еще что нам может понадобиться в будущем

    # cd /usr/ports/lang/php5-extensions
    # make install


    Пробуем все ли установилось так как нам хотелось бы:
    # apachectl start
    # echo "<?php phpinfo(); ?>" > /usr/local/www/data/test.php


    Ну и собственно проверяем все ли получилось так как хотелось зайдя браузером по адресочку 192.168.0.1/test.php

    Отлично. Теперь начинаем ставить то для чего все это затеивалось:
    # fetch www.stg.dp.ua/download/server/2.406/stg-2.406.src.tgz
    # tar zxvf stg-2.406.src.tgz
    # cd stg-2.406
    # cd projects/stargazer/
    # ./build
    #gmake install
    #cd ../convertor/
    #./build


    Теперь будем конвертировать дефолтную текстовую базу в mysql. Правим convertor.conf:

    Комментируем store_postgresql:
    #<DestStoreModule store_postgresql>
    # server = localhost
    # database = stargazer
    # user = stg
    # password = 123456
    #



    Раскоменчиваем и приводим к нужному виду store_mysql:
    <DestStoreModule store_mysql>
    # Имя пользователя БД
    dbuser = root

    # Пароль пользователя БД
    rootdbpass = ourpassword

    # Имя БД на сервере
    dbname = stg

    # Адрес сервера БД
    dbhost = localhost



    Пробуем конвертиться:
    # ./convertor


    Пустая база конвертиться моментально. Начинаем конфигурить stargazer.
    Прописываем классы трафика
    # vim /etc/stargazer/rules
    ALL 192.168.0.0/24 DIR1
    ALL 0.0.0.0/0 DIR0


    Подганяем под реалии жизни конфиг:
    #vim /etc/stargazer/stargazer.conf


    По минимуму правим названия направлений:
    DirName0 = internet
    DirName1 = local
    DirName2 =
    DirName3 =
    DirName4 =
    DirName5 =
    DirName6 =
    DirName7 =
    DirName8 =
    DirName9 =



    Строим модуль захвата трафика cap_bpf так чтобы он считал его на интерфейсе смотрящем во внутреннюю сеть
    <Module cap_bpf>
    iface = fxp0



    Коментируем все что относиться к <StoreModule store_files> и по аналогии с конвертером подключаем модуль <StoreModule store_mysql>:
    <StoreModule store_mysql>
    dbuser = root
    rootdbpass = ourpassword
    dbname = stg
    dbhost = localhost



    Пробуем запускать сам stargazer:
    #stargazer


    И проверяем как запустились
    #tail /var/log/stargazer.log


    Если мы видим что-то похожее на Stg started successfully. Значит есть шансы на жизнь ;)
    Загружаем windows конфигуратор по адресу stg.dp.ua/download/sgconfig/1.91.9/sgconfig.1.91.9.win.exe и после установки в настройках ставим коннект на 192.168.0.1:5555
    Логин/пароль по умолчанию admin/123456. После логина мы должны увидеть что-то типа

    image

    С умолчальным пользователем test которого тут, же смело удаляем.

    image

    Меняем пароль админа, либо добавляем новых. Добавляем исходя из старой схемы для теста нашу Марию Ивановну из бухгалтерии с айпишкой 192.168.0.2

    image

    Будет она у нас «всегда Online» потому, что незачем в условиях офиса использовать auth_ia требующий указывать логин/пароль для доступа к сети.
    В поля UserData0 и UserData1 вбиваем скорость и MAC и вот зачем:
    Логика работы stargazer очень проста и гибка. В моменты когда пользователь появляеться онлайн, отсоединяется, удаляется и добавляется исполняються следующие скрипты:
    OnConnect
    OnDisconnect
    OnChange
    OnUserAdd
    OnUserDel


    О назначении которых, несложно догадаться по их названиям. Все они находяться в /etc/stargazer/

    Начинаем подганять их под наши реалии
    Для начала создаем еще 2 скриптика на PHP (не даром же ставили его ;) при помощи которых мы будем получать скорость и МАС пользователя из базы.
    Скрипт /etc/stargazer/GetSpeed с содержанием
    #!/usr/local/bin/php
    <?php
    $login=$argv[1];
    $link = mysql_connect("localhost", "root", "ourpassword");
    mysql_select_db("stg");
    $query = 'SELECT `Userdata0` FROM users where `login`= "'.$login.'"';
    $result = mysql_query($query);
    while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
    foreach ($line as $col_value) {
    print ($col_value);
    }
    }
    ?>


    И /etc/stargazer/GetMac вида
    #!/usr/local/bin/php
    <?php
    $login=$argv[1];
    $link = mysql_connect("localhost", "root", "ourpassword");
    mysql_select_db("stg");
    $query = 'SELECT `Userdata1` FROM users where `login`= "'.$login.'"';
    $result = mysql_query($query);
    while ($line = mysql_fetch_array($result, MYSQL_ASSOC)) {
    foreach ($line as $col_value) {
    print ($col_value);
    }
    }
    ?>


    Назначаем им права для выполнения
    #chmod a+x /etc/stargazer/GetMac /etc/stargazer/GetSpeed


    Тестим их на тему работоспособности для ранее созданного пользователя:
    # /etc/stargazer/GetSpeed mariya
    512
    /etc/stargazer/GetMac mariya
    00:a1:b0:01:bc:77


    Отлично!

    Начинаем думать что же будет случаться когда пользователь появляется онлайн и выпадает в оффлайн.
    Итак Что же будет случаться при появлении пользователя онлайн:
    # OnConnect
    IFACE="fxp0"
    LOGIN=$1
    IP=$2
    CASH=$3
    ID=$4
    SPEED=`/etc/stargazer/GetSpeed $LOGIN`
    MAC=`/etc/stargazer/GetMac $LOGIN`
    SCOUNT="Kbit/s"
    fwcmd="/sbin/ipfw -q"
    arpcmd="/usr/sbin/arp"
    cur_date=`date \+\%Y.\%m.\%d`
    cur_time=`date \+\%H:\%M:\%S`

    # DELETE RULEZ
    ${fwcmd} delete `expr $ID '*' 10 + 10001`
    ${fwcmd} delete `expr $ID '*' 10 + 10002`
    ${fwcmd} delete `expr $ID '*' 10 + 10003`
    ${fwcmd} delete `expr $ID '*' 10 + 10004`
    ${fwcmd} delete `expr $ID '*' 10 + 10005`

    # ADD RULEZ

    # fix user mac to ip
    ${arpcmd} -S $IP $MAC

    #SPEED CONTROL
    ${fwcmd} pipe `expr $ID + 101` config bw $SPEED$SCOUNT queue `expr $SPEED '/' 8`Kbytes
    ${fwcmd} pipe `expr $ID + 901` config bw $SPEED$SCOUNT queue `expr $SPEED '/' 8`Kbytes

    # ALLOWS CONTROL
    ${fwcmd} add `expr $ID '*' 10 + 10001` allow icmp from $IP to me
    ${fwcmd} add `expr $ID '*' 10 + 10001` allow icmp from me to $IP
    ${fwcmd} add `expr $ID '*' 10 + 10002` pipe `expr $ID + 101` ip from $IP to any via $IFACE in
    ${fwcmd} add `expr $ID '*' 10 + 10003` pipe `expr $ID + 901` ip from any to $IP via $IFACE out
    ${fwcmd} add `expr $ID '*' 10 + 10004` allow ip from $IP to any
    ${fwcmd} add `expr $ID '*' 10 + 10005` allow ip from any to $IP

    # ADD TO LOG
    echo "<=;$cur_date;$cur_time;$ID;$LOGIN;$IP;$CASH;$SPEED;`expr $ID + 101`;$MAC" >> /var/stargazer/allconnect.log


    и что будет случаться если он выпадает из онлайна:
    # OnDisconnect
    LOGIN=$1
    IP=$2
    CASH=$3
    ID=$4

    fwcmd="/sbin/ipfw -q"

    # TIME FORMAT
    cur_date=`date \+\%Y.\%m.\%d`
    cur_time=`date \+\%H:\%M:\%S`

    # DELETE RULEZ FRO IPFW
    ${fwcmd} delete `expr $ID '*' 10 + 10001`
    ${fwcmd} delete `expr $ID '*' 10 + 10002`
    ${fwcmd} delete `expr $ID '*' 10 + 10003`
    ${fwcmd} delete `expr $ID '*' 10 + 10004`
    ${fwcmd} delete `expr $ID '*' 10 + 10005`
    ${fwcmd} pipe `expr $ID + 101` delete
    ${fwcmd} pipe `expr $ID + 901` delete
    echo "=>;$cur_date;$cur_time;$ID;$LOGIN;$IP;$CASH" >> /var/stargazer/allconnect.log


    Думаю здесь все понятно – мы просто подымаем/удаляем соответствующие внтуренним ID пользователя правила шейпинга и делающие ему allow дальше чем наш локальный интерфейс fxp0.
    Помниться у нас изначально они ничем не ограничивались ибо в самом конце стояло allow ip from any to any? Нет проблем.
    Добавляем в /etc/firewall.conf что-то типа
    ${FwCMD} add 101 allow all from 192.168.0.1 to any
    ${FwCMD} add 101 allow all from any to 192.168.0.1
    ${FwCMD} add 65533 deny all from table\(2\) to any
    ${FwCMD} add 65534 deny all from any to table\(2\)


    Теперь пробуем по включать/повыключать «всегда Online» для нашего подопытного пользователя и смотрим /var/stargazer/allconnect.log
    Хозяйке на заметку: всегда полезно контролировать на глаз что и как ходит и по каким правилам при помощи
    #ipfw show


    Все – в минимальном варианте биллинг доставили. Вы спросите а зачем нам считать деньги? Да очень просто – мы же хотели нашей Марьивановне выдавать не более 500 мег интернетов в месяц либо просто выдавать ей в ручную по надобности определенную скорость с определенным количеством трафика? Нет проблем. Просто приравниваем 1мег к одной денюжке для простоты расчета. Допустим так

    image

    В общем простор для творчества есть.

    По-моему статья получилась какой-то крайне затянутой и мрачной. Явно пора заокругляться.

    В следующий раз если карма позволит обещаюсь таки рассказать как сделать переключалку на резервный канал, рисовать вот такие красивые графички при помощи cacti

    image

    и как удобно оформить отображение статистики по трафику собранной установленным нами сегодня stargazer.

    ЗЫ и да – мой русский неученый в школе с предыдущего раза как не прискорбно не улучшился :(
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 25

      +2
      Статья понравилась, занес в избранное. Если бюджет урезан, то отличное решение.
        +4
        Побольше бы на хабре таких статей.
          +3
          спасибо — буду стараться :)
          0
          Спасибо, то что надо!
            0
            рисовать вот такие красивые графички при помощи cacti
            буду с нетерпением ждать
            0
            А почему б уже не использовать нат из ядра?
              0
              ну как минимум потому что фря скажем 6.2 а под 7 целевой биллинг собирался до недавнего времени с бубном :)
                0
                Та старгейзер это еще то существо :)

                *Думает как бы разработчики не далил пилюлей при следующем совместном распитии пива*
                  0
                  Сколько у вас natd забирает ресурсов, если не секрет? Если Василий, Аркадий и Семен одновременно вместе с Клавдией Петровной и Григорием Сергеичем p2p у себя запустят? :)))

                  За статью спасибо.
                    0
                    не секрет

                    uptime
                    11:11AM up 123 days, 2:05, 1 user, load averages: 0.12, 0.10, 0.13

                    Около 300 василиев и клавдиев
                      0
                      Около 700 наталий и петров тоже (активно качающих)

                      uptime
                      10:56AM up 123 days, 37 mins, 1 user, load averages: 0.28, 0.34, 0.32

                      Два разных хоста, полет нормальный, раскидка по 4 разным natd на каждом. sysctl минимально кручен.
                  0
                  шпаргалку в мемориз=)
                    +1
                    Отличные статьи, nightfly!
                    Продолжай в том же духе.

                    Добавил кармы.
                      0
                      А я думал подкатом и правда книга ):
                        0
                        Ну, если автор допишет что планировал и подредактирует, то считайте книга готова. :)
                        0
                        Понравилось, хотел бы попробовать, но сразу вопрос а как MAC узнать?
                          0
                          ну либо посмотреть что лежит в arp -a либо arpwatch как более интерестный вариант
                          +2
                          Если FreeBSD >=7, то лучше natd заменить на kernel NAT:
                          собрать ядро с options IPFIREWALL_NAT
                          или подгружать модуль ipfw_nat.ko

                          Соответственно, правила в фаерволе подправить:

                          ${fwcmd} nat 1 config unreg_only ip 10.10.10.1
                          ${fwcmd} nat 2 config unreg_only ip 172.16.0.1
                          #
                          ${FwCMD} add 1799 nat 1 ip from table\(2\) to not table\(9\)
                          ${FwCMD} add 1800 nat 2 ip from table\(2\) to not table\(9\) out via xl0

                          ${FwCMD} add 2099 nat 1 ip from any to 10.10.10.1 in via rl0
                          ${FwCMD} add 2100 nat 2 ip from any to 172.16.0.1 in via xl0
                            +1
                            как-то у вас странно шейпинг реализован
                            как минимум эти 6 правил
                            ${fwcmd} add `expr $ID '*' 10 + 10001` allow icmp from $IP to me
                            ${fwcmd} add `expr $ID '*' 10 + 10001` allow icmp from me to $IP
                            ${fwcmd} add `expr $ID '*' 10 + 10002` pipe `expr $ID + 101` ip from $IP to any via $IFACE in
                            ${fwcmd} add `expr $ID '*' 10 + 10003` pipe `expr $ID + 901` ip from any to $IP via $IFACE out
                            ${fwcmd} add `expr $ID '*' 10 + 10004` allow ip from $IP to any
                            ${fwcmd} add `expr $ID '*' 10 + 10005` allow ip from any to $IP

                            можно заменить двумя
                            ${fwcmd} add `expr $ID '*' 10 + 10002` pipe `expr $ID + 101` ip from $IP to any via $IFACE in
                            ${fwcmd} add `expr $ID '*' 10 + 10003` pipe `expr $ID + 901` ip from any to $IP via $IFACE out

                            установив net.inet.ip.fw.one_pass=1, тогда pipe будет работать как allow, т.е. пакет будет выбрасываться из ipfw при выполнении действия pipe.
                            в таком случае 2 нижних правила не нужны.
                            также icmp можно разрешить проще
                            ${fwcmd} add 100 allow icmp from $local_net to me
                            ${fwcmd} add 101 allow icmp from me to $local_net
                            как-то так.

                            в таком случае будет достаточно при онлайне абонента добавить правила
                            ${fwcmd} add `expr $ID '*' 10 + 10002` pipe `expr $ID + 101` ip from $IP to any via $IFACE in
                            ${fwcmd} add `expr $ID '*' 10 + 10003` pipe `expr $ID + 901` ip from any to $IP via $IFACE out
                            что сразу уменьшит общее число правил в 3 раза.

                            но все равно количество правил в ipfw будет зашкаливать. субъективно году в 2006-м на тогдашнем железе 1000 правил в ipfw добавляло 6-10 мс при прохождении пакета, т.е. пинг у людей зверски вырастал.

                            но можно пойти и дальше и ограничиться вообще двумя правилами для шейпинга любого количества абонентов, а именно использовать таблицы
                            вот простенький пример
                            входящие пайпы
                            /sbin/ipfw pipe 1 config mask dst-ip 0xffffffff bw 88Kbit/s
                            /sbin/ipfw pipe 2 config mask dst-ip 0xffffffff bw 1100Kbit/s

                            исходящие пайпы
                            /sbin/ipfw pipe 101 config mask src-ip 0xffffffff bw 88Kbit/s
                            /sbin/ipfw pipe 102 config mask src-ip 0xffffffff bw 1100Kbit/s

                            и всего 2 правила
                            /sbin/ipfw add 2000 pipe tablearg ip from any to «table(1)» via $IFACE out
                            /sbin/ipfw add 2100 pipe tablearg ip from «table(2)» to any via $IFACE in

                            шейпинг производится в этом случае на внутреннем интерфейсе
                            и все(!!)
                            включить инет юзеру можно добавив его айпишник в таблицы
                            в таком формате:
                            /sbin/ipfw table 1 add 192.168.100.1 1
                            /sbin/ipfw table 2 add 192.168.100.1 101
                            , где таблица 1 — для включения шейпинга входящего трафика, таблица 2 — для исходящего трафика, 192.168.100.1 — айпи юзера, 1 и 101 номера входящего и исходящего пайпа соответственно.

                            т.е. мы 2-мя правилами в фаере зашейпили всех наших юзеров. когда я это сделал в 2006-м нагрузка на машину уменьшилась раз в 5-7 (тогда я резко перешел от примерно 2000 правил к 15)

                            вы если что, обращайтесь в личку, с удовольствием поделюсь опытом.
                            например про бгп, про шейпинг на layer2, про сегментацию сети на вланы и т.п.
                              0
                              ну и natd — это аццкая жесть.
                              kernel nat не пробовал, когда я натил, его еще не было.
                              но вот нат в pf — это супер-пупер, проц грузит гораздо меньше natd и работает на уровне ядра, а не в юзерспейсе.
                              ipnat же сцуко утекал памятью и вешал ядро при больших нагрузках (3000-4000 юзеров)
                              но самый кайф — это вообще избавиться от серых айпишников, раздать всем паблики и торжественно вырубить нат! что я и проделал года 3 назад, до сих пор блаженствую )
                                0
                                >>ну и natd — это аццкая жесть.
                                согласен :)

                                Правда на скоростях меньше 20-30Мбит самое то.

                                >>но вот нат в pf — это супер-пупер, проц грузит гораздо меньше natd и работает на уровне ядра, а не в юзерспейсе.
                                дык он же сколько помниться не работает по людски на smp машинах?

                                >>kernel nat не пробовал, когда я натил, его еще не было.
                                а вот кстати очень рекомендую — он нереально быстр. Уже как годика полтора нарадоваться не могу. Для средней самосборной железки там 400 мбит далеко не предел.
                                0
                                Спасибо. В принципе очевидно что при количестве юзеров уже более нескольких десятков оригинальная заготовка неадекватна :)

                                Сам режу давно табличками что кстати при больших количествах пользователей дает _внезапно_ ощутимый прирост производительности.
                                0
                                Спасибо, за статью, а вот можно ли сегодня поставить stargazer на FreeBSD 8.4?

                              Only users with full accounts can post comments. Log in, please.