Предисловие
В процессе работы иногда приходиться подключать клиентов либо уже с присутствующими машинами на FreeBSD (распространенный вариант – держат там рабочие файлошары на самбах) либо ставить им такое решение по запросу, для максимально удобного решения насущных проблем клиента.

Статья рассчитана на читателя крайне слабо знакомого с FreeBSD. Думаю людям, что-то, понимающим эта статья будет крайне отвратительна – рекомендую дальше не читать и не травмировать себя.

Необходимый набор знаний – общее знакомство с *nix подобными операционными системами (любой линукс , возможно макось), хладнокровное отношение к консоли и базовые представления о работе сети.
Статья клеилась из подручной шпаргалки, писанной для нашего персонала и предназначенной для начального обучения. Человек 5 по крайней мере по этой писанине в свое время чему-то научились засим и считаю что оно имеет право на существование.

Установка FreeBSD уже очень подробно и даже в красивых картинках описана очень хорошо и доступно на нашем сайте и о ней мы скромно умолчим. Кроме того установка FreeBSD для человека ранее устанавливавшего допустим Debian либо FreeBSD проблем составить не должна.

После-предисловие и ответы на ваши первые мысли
— да я знаю про существование pfnat, ipnat, ng_nat – если вы тоже знаете такие слова, пожалуйста, дальше не читайте (см. еще раз выше)
— да я знаю, что pf быстрее но не считаю целесообразным его использование при потоках менее 50-60 Мбит
— нет, мы не будем исходя, из поставленных в заголовке задач строить полноценную балансировку на round robin
— нет, не линукс – потому что статья не о нем.
— и не макось – хотя да, можно… наверное.
— еще раз – про pf но уже на более быстрых вещах поговорим в следующий раз
— да, исходя из опыта ядерный ipfw nat быстрее на процентов 20, на его использование очень просто перейти после понятия сути работы с natd
— нет, и про 2850 мы промолчим
— да, я действительно считаю ipfw достаточно гибким. Серьезно.
— нет, я не люблю squid, polipo, privoxy – потом объясню почему

Итак, начинаем заниматься непосредственно решением поставленных задач раздачи интернета, и рассмотрим сферическую сеть стихийной планировки в вакууме.

Что хотим сделать:
• Тривиальный и практический минимум — хождение нашей сети в интернет
• Будем считать, что в интернет смотрит сетевуха rl0 с адресом 10.10.10.1 а в нашу внутреннюю сеть сетевуха fxp0 с адресом 192.168.0.1 и еще одна никуда не воткнутая сетевуха xl0 (далее мы возможно узнае для чего мы можем ее использовать)

Нам потребуются:
1. Машина с установленным FreeBSD
2. немножко времени
3. 2 чашки кофе

Для начала собираем и устанавливаем ядро, поскольку в идущее из коробки GENERIC не включены IPFIREWALL и IPDIVERT нужные сейчас нам, зато включено много чего не нужно. В принципе процесс сборки ядра описан уже неоднократно и повторяться более чем нету смысла, но написание пошагового и доступного руководства чувствую, требует этой рутины.

Итак сборка ядра:

#cd /usr/src/sys/i386/conf
# cp GENERIC MYROUTER
#vim MYROUTER

Правим конфиг ядра под наши минимальные ну или по желанию не минимальные нужды (читать отдельно):

ident MYROUTER
options IPFIREWALL
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_FORWARD
options DUMMYNET
options IPDIVERT
options HZ=1000
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100

и собираем:
#config MYROUTER
#cd ../compile/MYROUTER
#make depend
#make

Бекапим старое ядро если случиться что-то страшное:

#cp –R /boot/kernel /boot/good

и инсталлим новое ядро

#make install

Примечание – если натить мы собрались на внешней железке либо другом хосте а тут только контролировать утилизацию канала, то IPDIVERT совсем ненужен, можно свободно обойтись подгрузкой ipfw модулем и обойтись без пересборки ядра.

Начинаем играться с NAT-ом, ради чего все это и затеивалось:

в /etc/rc.conf засовываем

defaultrouter=«10.10.10.2» #шлюз по умолчанию
ifconfig_rl0=«inet 10.10.10.1 netmask 255.255.255.0»
ifconfig_fxp0=«inet 192.168.0.1 netmask 255.255.255.0»
gateway_enable=«YES» # таки да — будем
firewall_enable=«YES» # врубаем ipfw
firewall_script=»/etc/firewall.conf» # отсюда наше ipfw должно брать правила
natd_enable=«YES» # врубаем natd
natd_interface=«rl0» # и подсказываем ему где мы будем натить (сетевуха смотрящая в интернет)

Вот так рекомендуется всюду. Лично мне привычнее пускать natd не на интерфейсе а на конкретной айпишке с конкретно указанным портом для диверта. Делать это можно например из того же /etc/firewall.conf в виде /sbin/natd -u -p 8671 -a 10.10.10.1 (Для чего так удобно делать тоже рассмотрим в случае PBR)

Далее создаем вышеупомянутый /etc/firewall.conf

Во многих мануалах которые мне попадались на глаза предлагается в простейшем варианте вот так:

#!/bin/sh
FwCMD=»/sbin/ipfw -q»
${FwCMD} -f flush
${FwCMD} add divert natd all from any to any via rl0
${FwCMD} add 65535 allow all from any to any

divert from any to any via вообще некрасивый вариант засим дальше, если будем делать что-то, то сделаем более красиво:

#!/bin/sh
/sbin/natd -u -p 8671 -a 10.10.10.1
FwCMD=»/sbin/ipfw -q»
${FwCMD} -f flush

# Networks define
${FwCMD} table 2 add 192.168.0.0/24
${FwCMD} table 9 add 10.10.10.8/32
#internet natting and preserving
${FwCMD} add 1799 divert 8671 ip from table\(2\) to not table\(9\) out via rl1
${FwCMD} add 2099 divert 8671 ip from any to 10.10.10.1 in via rl0

На будущее запоминаем что в table(2) у нас живут сети либо хосты которые мы будем натить, а в table(9) те хосты трафик к которым NAT-ить мы не хотим. Как пример у нас там упоминался хост 10.10.10.8 который стоит в сети 10.10.10/24 и допустим исполняет функции нашего офисного %название_сервиса%. На нем соответственно для того чтобы из сети 192.168/24 мы могли достучаться до него нужно вбить статический раут до 10.10.10.1

Итак возвращамся к задаче и ставим права на выполнение

#chmod a+x /etc/firewall.conf

После чего можно посмотреть в небо, перекреститься и перезагрузиться
#reboot

После загрузки есть шанс что мы увидим рабочий NAT и наши пользователя смогут таки увидеть страдальческий Интернет, прописав у себя айпишки из диапазона 192.168.0.0/24 и указав шлюзом по умолчанию 192.168.0.1 плюс Провайдерский DNS (свой мы еще не подымали).

Проверяется работа nat методом
#ipfw show

В результате чего мы должны увидеть что-то похожее на

1265581 168080800 divert 8671 ip from table(2) to not table(9) out via rl0
769868437 668041277852 divert 8671 ip from any to 10.10.10.1 in via rl0

Ясно что пропустили мы многое например выкидывание мусора оставшегося на память от GENERIC, тюнинг опций ядра для обеспечения человеческого быстродействия при мульйонах сессий и грандиозном потоке, порезку всякого мусора на интерфейсах но об этом в следущий раз если захотите.

Поехали дальше по реально возникающим задачам, которые могут ВНЕЗАПНО встать перед нами.

Довольно часто возникает задача обеспечения различной пропускной способности на разные хосты.
Допустим, Светлане Денисовне не нужен в процессе работы очень быстрый интернет и начальство желает, чтобы у нее персонально канал выглядел как симметричное 256 Кбит/с. ОК, нет проблем:

ipfw pipe 10256 config bw 256Kbit/s queue 32Kbytes
ipfw pipe 20256 config bw 256Kbit/s queue 32Kbytes
ipfw add 10000 pipe 10256 ip from 192.168.0.6 to not table\(9\) via fxp0 in
ipfw add 10000 pipe 10256 ip from not table\(9\) to 192.168.0.6 via fxp0 out

Убедившись в работоспособности можно продублировать все это в /etc/firewall.conf. Никогда не протестировав очередное правило, даже казалось бы, самое очевидное не добавляйте его в конфиг – у вас всегда будет путь к оступлению без излишних нервов.
Если скорость нужно резать на всю сеть, либо еще как-то по маске то более логично было бы сделать, допустим, вот так:

${FwCMD} pipe 9999 config bw 512Kbit/s queue 64Kbytes mask dst-ip 0xffffffff
${FwCMD} pipe 9998 config bw 512Kbit/s queue 64Kbytes mask dst-ip 0xffffffff
${FwCMD} add 5000 pipe 9999 ip from table\(2\) to not table\(9\) via fxp0 in
${FwCMD} add 5000 pipe 9998 ip from not table\(9\) to table\(2\) via fxp0 out

Крутя маску в пайпе мы можем сделать либо «вот такая скорость на всех» либо «вот такая скорость каждому» как указано в примере.

Что еще хотелось бы после этого сделать? Очень многое если честно!

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

Как  хочеться чтобы все в финале выглядело?
Хотябы вот так:

Эти 7 пунктов совместно с ускоренной установкой биллинга (картинка выше) хотелось бы рассмотреть в следующей статье если кому-то будет интересно.

Взято на ХАБРЕ