Настройка маршрутизатора под управлением системы FreeBSD. Настраиваем шлюз в Интернет на базе FreeBSD Как прописать маршруты для роутера freebsd вручную

АЛЕКСЕЙ БЕРЕЖНОЙ

Настраиваем шлюз в Интернет на базе FreeBSD

Использование FreeBSD на небольших роутерах для связи с внешним миром уже давно перестало быть чем-то выдающимся. Эта простая в использовании, нетребовательная к ресурсам и обслуживанию операционная система почти идеально подходит для решения подобных задач.

Нам понадобится

  • Аппаратное обеспечение . Чтобы вывести внутреннюю сеть в Интернет, достаточно компьютера Pentium III 600 МГц, 256 Мб RAM, 10 Гб HDD, 2 сетевые карты. Конфигурация взята с запасом, для полноценной работы сети малого офиса (около 50 пользователей) вполне хватило бы Pentium II 400 МГц, c 128 Мб RAM. Но в дальнейшем может возникнуть желание установить на этот же шлюз, к примеру, прокси-сервер, лучше выбрать конфигурацию более высокого уровня.
  • Операционная система : FreeBSD 5.5 или 6.1.
  • Дополнительно : из-за того, что данный компьютер подлежит непрерывному использованию, рекомендую доставить внутрь корпуса дополнительные вентиляторы чтобы обеспечить принудительное нагнетание/отток воздуха для охлаждения. Практически все современные корпусы ATX позволяют сделать это.

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

Настройка сетевых интерфейсов

Необходимо уточнить имена интерфейсов сетевых карт, под которыми их распознает операционная система.

# ifconfig

Должно появиться что-то подобное:

rl0: flags=8843 mtu 1500

Options=8

Ether 00:xx:xx:xx:xx:xx

Status: active

xl0: flags=8843 mtu 1500

Options=9

Ether 00:zz:zz:zz:zz:zz

Media: Ethernet autoselect (100baseTX)

Status: active

plip0: flags=108810 mtu 1500

lo0: flags=8049 mtu 16384

Inet6::1 prefixlen 128

В компьютере установлены две сетевые карты c именами интерфейсов rl0 и xl0.

В нашем случае интерфейс rl0 будет «смотреть» во внешний мир, а xl0 – во внутреннюю сеть. IP- адрес внутреннего интерфейса: 192.168.9.2 , маска подсети 255.255.255.0, имя интерфейса xl0; IP-адрес внешнего интерфейса 83.xxx.xxx.xxx, маска подсети 255.255.255.224, имя интерфейса rl0.

Уточнить, сетевым картам каких производителей соответствуют те или иные сетевые адреса, можно, заглянув в файл GENERIC в каталоге /usr/src/sys/i386/conf:

# more /usr/src/sys/i386/conf/ GENERIC

В нем находим соответствующие строчки:

device rl # RealTek 8129/8139

device xl # 3Com 3c90x (``Boomerang"", ``Cyclone"")

Таким образом, интерфейс rl0 соответствует сетевой карте RealTek 8129/8139 и ее аналогам. Сетевой интерфейс xl0 соответствует сетевой карте 3Com.

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

  • Шлюз провайдера – по умолчанию 83.xxx.xxx.1.
  • В сети присутствуют компьютеры пользователей – 192.168.9.31, 192.168.9.32.
  • Наш домен (условно) – ourdomain.ru.
  • Имя хоста (компьютера) – ourhost.ourdomain.ru.

Выполняем настройку сетевых карт. Можно использовать утилиту sysinstall (/stand/sysinstall для FreeBSD 5.5 и /usr/sbin/sysinstall для FreeBSD 6.1) Но поскольку нам известны все необходимые параметры, то для упрощения процесса и экономии времени мы будем задавать параметры путем редактирования соответствующих конфигурационных файлов.

Настройки сетевых интерфейсов во FreeBSD хранятся в файле /etc/rc.conf. Открываем его на редактирование:

# vi /etc/rc.conf

И добавляем следующие строки:

# Задаем внутренний интерфейс

ifconfig_xl0="inet 192.168.9.2 netmask 255.255.255.0"

# Задаем внешний интерфейс

ifconfig_rl0="inet 83.xxx.xxx.xxx netmask 255.255.255.224"

# Задаем шлюз провайдера по умолчанию

defaultrouter="83.xxx.xxx.1"

# Имя хоста

hostname="ourhost.ourdomain.ru"

# Указываем, что сервер будет работать как маршрутизатор

gateway_enable="YES"

После чего перезагружаем компьютер:

# reboot

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

После загрузки проверяем:

# ifconfig

Вывод команды ifconfig:

rl0: flags=8843 mtu 1500

Options=8

Inet6 fe80::215:58ff:fe3e:8fb1%rl0 prefixlen 64 scopeid 0x1

Inet 83.xxx.xxx.xxx netmask 0xffffffe0 broadcast 83.xxx.xxx.yyy

Ether 00:xx:xx:xx:xx:xx

Media: Ethernet autoselect (100baseTX)

Status: active

xl0: flags=8843 mtu 1500

Options=9

Inet6 fe80::20a:5eff:fe62:ade2%xl0 prefixlen 64 scopeid 0x2

Inet 192.168.9.2 netmask 0xffffff00 broadcast 192.168.9.255

Ether 00:zz:zz:zz:zz:zz

Media: Ethernet autoselect (100baseTX)

Status: active

plip0: flags=108810 mtu 1500

lo0: flags=8049 mtu 16384

Inet6::1 prefixlen 128

Inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4

Inet 127.0.0.1 netmask 0xff000000

Файл rc.conf, на мой взгляд, можно назвать ключевым файлом конфигурации. Очень большое число параметров, используемых системой, задается в виде соответствующих переменных в этом файле. В том числе настройки сетевых интерфейсов, файервола и NAT, используемых нами.

Настройка шлюза

Мы будем использовать «родной» для FreeBSD файервол IPFW. Для этого мы должны внести некоторые изменения в ядро системы. Если возникли дополнительные вопросы по перекомпиляции ядра, советую прочитать дополнительный материал: http://freebsd.org.ru/how-to/kernelconfig.html .

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

Исходники ядра по умолчанию лежат в каталоге /usr/src/sys/i386/conf. Соответственно переходим в данный каталог:

# cd /usr/src/sys/i386/conf

Как правило, изменяют файл GENERIC, содержащий опции ядра, устанавливаемого по умолчанию. Для этого делаем копию данного файла:

# cp GENERIC ourkernel

Открываем на редактирование новый файл ourkernel:

# vi ourkernel

и добавляем следующие опции:

Options IPFIREWALL #firewall

Options IPFIREWALL_VERBOSE ?

#enable logging to syslogd(8)

Options IPFIREWALL_FORWARD ?

#enable transparent proxy support

Options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity

Options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default

Options DUMMYNET

Options IPDIVERT #divert sockets

После сделанных изменений можно приступать к перекомпиляции ядра.

Выполняем команды:

# config ourkernel

# cd /usr/src/sys/i386/compile/ourkernel

# make depend

# make

# make install

Перегружаемся:

# reboot

Если после перезагрузки сервер работает нормально, приступаем к настройке файервола.

Для организации работы файервола используются следующие переменные, добавляемые при необходимости в файл rc.conf.

Разрешает или запрещает использование файервола:

# Set to YES to enable firewall functionality

firewall_enable="NO"

Имя и местоположение файла, отвечающего за инициализацию файервола.

# Which script to run to set up the firewall

firewall_script="/etc/rc.firewall"

При установке данного правила в «YES» подавляется вывод на дисплей:

firewall_quiet="NO"

Разрешить/запретить ведение лога событий:

firewall_logging="NO"

Тип настройки файервола:

firewall_type="UNKNOWN"

по умолчанию FreeBSD использует правила из файла /etc/rc.firewall.

В нем есть несколько готовых шаблонов:

  • open – файервол разрешает прохождение всех пакетов.
  • client – рекомендуется для защиты только этого компьютера. То есть файервол настроен как стандартный клиентский компьютер. Он разрешает все исходящие соединения и запрещает все входящие соединения, кроме соединений по 25 порту.
  • simple – предполагается для настроек простых шлюзов и т. д. То есть в качестве простейшего файервола, защищающего внутреннюю сеть от проникновения извне. Мы будем настраивать более гибкую систему правил, поэтому данный шаблон нами не используется не будет.
  • closed – Разрешается трафик через локальный интерфейс lo0. Прохождение остального трафика определяется правилом по умолчанию. Как правило, это запрет любого доступа, исключая внутренний интерфейс lo0 (попросту говоря, разрешен только доступ «к самому себе»)
  • UNKNOWN – запретить загрузку файервольных правил из конфигурационного скрипта по умолчанию. Файервол никак не настраивается. Будет он пропускать трафик или нет, зависит от конфигурации ядра системы. Используется по умолчанию.

Эту же переменную в значении «filename» – «имя_файла» – можно использовать для задания собственного конфигурационного файла для файервола.

Например:

firewall_type="/etc/rc.firewall.newconfig"

будет загружать настройки из созданного файла /etc/rc.firewall.newconfig.

«firewall_flags=””» – служит для передачи дополнительных аргументов при использовании firewall_type со значением filename.

Наша задача состоит в том, чтобы создать систему, отвечающую следующим критериям:

  • Простота администрирования.
  • Возможность модификации «на лету», незаметно для пользователей. Поэтому такие операции, как разрыв соединений и тем более перезагрузка для нас нежелательны.
  • Гарантия того, что наша система будет работать на большинстве машин.

В нашем примере скрипта все компьютеры локальной сети делятся на две условные группы: одна группа привилегированная – это те, кому разрешен доступ в Интернет, используя наиболее употребительные сервисы, такие как:

  • HTTP – порт 80;
  • HTTPS – порт 443;
  • FTP – порты 20, 21 и от 1025 до 65535;
  • SMTP-протокол для пересылки почты – порт 25;
  • POP3-протокол для приема сообщений – порт 110.

Есть и другая группа, компьютерам из которой разрешен доступ только к внешнему корпоративному серверу c IP-адресом 83.xxx.xxx.2 (только протоколы SMTP и POP3).

Мы должны добиться, чтобы можно было изменять привилегированную группу, что называется, «на лету», по возможности не разрывая установленных соединений. Для этого мы из нашего скрипта вызываем дополнительный скрипт rc.firewall.local.inet. Достаточно отредактировать и перезапустить этот дополнительный скрипт, не затрагивая всех остальных настроек файервола.

Дополнительно мы должны предусмотреть ситуацию, когда меняются параметры сети, такие как IP-адрес шлюза провайдера. Для этого мы будем использовать в скрипте локальные переменные. Например, при изменении шлюза по умолчанию достаточно изменить значение переменной intgateway и перезапустить скрипт rc.firewall.run.

Вот наш пример скрипта:

# vi rc.firewall.run

#!/bin/sh

extip="83.xxx.xxx.xxx"

intip="192.168.9.2"

intnet="192.168.9.0/24"

mailserver="83.xxx.xxx.2"

intgateway="83.xxx.xxx.1"

/sbin/ipfw -f flush &

/sbin/ipfw add 180 divert natd ip from ${intnet} to any out xmit fxp0

/sbin/ipfw add 190 divert natd ip from any to ${extip}

# ICMP

/sbin/ipfw add 500 allow icmp from any to any

# SSH

/sbin/ipfw add 10000 allow tcp from any to any 22

/sbin/ipfw add 10010 allow tcp from any 22 to any

# DNS

/sbin/ipfw add 11000 allow tcp from any to any 53

/sbin/ipfw add 11010 allow tcp from any 53 to any

/sbin/ipfw add 11020 allow udp from any to any 53

/sbin/ipfw add 11030 allow udp from any 53 to any

# Web FTP

/sbin/ipfw add 12000 allow tcp from me to any 20,21,80,443

/sbin/ipfw add 12010 allow tcp from any 20,21,80,443 to me

/sbin/ipfw add 12020 allow udp from me to any 20,21

/sbin/ipfw add 12030 allow udp from any 20,21 to me

# Script for the privilege group

/bin/sh /etc/rc.firewall.local.inet

# Deny other computer of LAN

/sbin/ipfw add 12960 deny tcp from ${intnet} to any 20,21,80,443

/sbin/ipfw add 12970 deny tcp from any 20,21,80,443 to ${intnet}

/sbin/ipfw add 12980 deny udp from ${intnet} to any 20,21

/sbin/ipfw add 12990 deny udp from any 20,21 to ${intnet}

/sbin/ipfw add 13000 allow tcp from ${intnet} to ${mailserver} 25,110

/sbin/ipfw add 13010 allow tcp from ${mailserver} 25,110 to ${intnet}

/sbin/ipfw add 55010 allow tcp from any to any 1024-65534

/sbin/ipfw add 55020 allow tcp from any 1024-65534 to any

/sbin/ipfw add 55030 allow tcp from any 1024-65534 to any

/sbin/ipfw add 55040 allow tcp from any to any 1024-65534

/sbin/ipfw add 55050 allow udp from any to any 1024-65534

/sbin/ipfw add 55060 allow udp from any 1024-65534 to any

/sbin/ipfw add 55070 allow udp from any 1024-65534 to any

/sbin/ipfw add 55080 allow udp from any to any 1024-65534

# Deny all

/sbin/ipfw add 65534 deny ip from any to any

Создаем и редактируем скрипт rc.firewall.local.inet для работы с привилегированной группой адресов:

# vi /etc/ rc.firewall.local.inet

#!/bin/sh

intnet="192.168.9.0/24"

privgroup={31,32}

/sbin/ipfw delete 12310

/sbin/ipfw delete 12320

/sbin/ipfw delete 12330

/sbin/ipfw delete 12340

/sbin/ipfw add 12310 allow tcp from ${intnet}${privgroup} to any 20,21,80,443,1025-65535

/sbin/ipfw add 12320 allow tcp from any 20,21,80,443,1025-65535 to ${intnet}${privgroup}

/sbin/ipfw add 12330 allow udp from ${intnet}${privgroup} to any 20,21,1025-65535

/sbin/ipfw add 12340 allow udp from any 20,21,1025-65535 to ${intnet}${privgroup}

В скрипте для изменения состава привилегированной группы необходимо отредактировать переменную privgroup, добавив/удалив в ней номер хоста в локальной подсети.

Например, чтобы добавить два компьютера с IP-адресами 192.168.9.33 и 192.168.9.45, нужно записать «privgroup={31-33,45}».

Использовать правила типа «/sbin/ipfw delete NNNNN» при старте системы, когда такого правила не было – немножко некрасиво. При попытке удалить несуществующее правило система выдает на консоль сообщение следующего вида:

ipfw: rule 13031: setsockopt(IP_FW_DEL): Invalid argument

При этом система продолжает нормально работать.

Если все делать строго, то нужно создавать два скрипта: один запускать при старте, второй – при изменениях на ходу. Но тогда нужно будет вносить соответствующие изменения в оба скрипта.

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

Зато теперь мы можем после внесения соответствующих изменений просто перезапустить скрипт для привилегированной группы.

# /bin/sh rc.firewall.local.inet

Также мы можем вносить изменения и перезапускать скрипт rc.firewall.run, хотя, по замыслу, это нам придется делать гораздо реже, чем в случае со скриптом привелигированной группы.

# /bin/sh rc.firewall.run

Поскольку мы написали свой собственный скрипт, обнуляющий существующие правила и запускающий альтернативную конфигурацию файервола, нужно подумать, как его запустить.

Во FreeBSD есть замечательный механизм запуска пользовательских программ: файл rc.local. По умолчанию он отсутствует в системе.

Раз мы уже создаем данный файл, добавим в него команду запуска демона natd, который отвечает за поддержку NAT.

Демон natd запускается из файла rc.conf. (Опять этот файл, поистине он играет ключевую роль для всей системы FreeBSD в целом!)

Механизм запуска этого файла из rc.conf выполняется посредством следующих переменных:

# -- путь к самому файлу natd

natd_program="/sbin/natd"

# Разрешить NAT (если firewall_enable == YES)

natd_enable="YES"

# Внешний интерфейс или IPaddress для использования

natd_interface=""

# Дополнительный флаги запуска natd

natd_flags=""

Но в этом случае мы будем использовать вызов демона natd посредством rc.local. Команда:

# vi /etc/rc.local

автоматически создает файл /etc/rc.local и открывает его на редактирование.

Добавляем в него следующие строки:

# Команда запуска natd

/sbin/natd -n rl0

# где «-n rl0» - имя интерфейса, на котором запускается NAT

# И запускаем наш скрипт для установки правил для файервола:

/bin/sh /etc/rc.firewall.run

Перезагружаемся и проверяем доступ к нужным ресурсам Интернета с компьютера из локальной сети.

  1. Эви Немет, Гарт Снайдер, Скотт Сибасс, Трент Р.Хейн. UNIX. Руководство системного администратора. «BHV», «Питер», 2004 г.
  2. Алексей Федорчук, Алексей Торн. FreeBSD. Установка, настройка, использование. BHV, 2003 г.
  3. Филипп Торчинский. Практическое пособие администратора UNIX. «Символ», 2003 г.

Использование FreeBSD на небольших роутерах для связи с внешним миром уже давно перестало быть чем-то выдающимся. Эта простая в использовании, нетребовательная к ресурсам и обслуживанию операционная система почти идеально подходит для решения подобных задач.

Нам понадобится

Аппаратное обеспечение . Чтобы вывести внутреннюю сеть в Интернет, достаточно компьютера Pentium III 600 МГц, 256 Мб RAM, 10 Гб HDD, 2 сетевые карты. Конфигурация взята с запасом, для полноценной работы сети малого офиса (около 50 пользователей) вполне хватило бы Pentium II 400 МГц, c 128 Мб RAM. Но в дальнейшем может возникнуть желание установить на этот же шлюз, к примеру, прокси-сервер, лучше выбрать конфигурацию более высокого уровня.

Операционная система : FreeBSD 5.5 или 6.1.

Дополнительно: из-за того, что данный компьютер подлежит непрерывному использованию, рекомендую доставить внутрь корпуса дополнительные вентиляторы чтобы обеспечить принудительное нагнетание/отток воздуха для охлаждения. Практически все современные корпусы ATX позволяют сделать это.

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

Настройка сетевых интерфейсов

Необходимо уточнить имена интерфейсов сетевых карт, под которыми их распознает операционная система.

Должно появиться что-то подобное:

rl0: flags=8843 mtu 1500
options=8
ether 00:xx:xx:xx:xx:xx

status: active
xl0: flags=8843 mtu 1500
options=9
ether 00:zz:zz:zz:zz:zz
media: Ethernet autoselect (100baseTX)
status: active
plip0: flags=108810 mtu 1500
lo0: flags=8049 mtu 16384
inet6::1 prefixlen 128


В компьютере установлены две сетевые карты c именами интерфейсов rl0 и xl0.

В нашем случае интерфейс rl0 будет «смотреть» во внешний мир, а xl0 – во внутреннюю сеть. IP- адрес внутреннего интерфейса: 192.168.9.2 , маска подсети 255.255.255.0, имя интерфейса xl0; IP-адрес внешнего интерфейса 83.xxx.xxx.xxx, маска подсети 255.255.255.224, имя интерфейса rl0.

Уточнить, сетевым картам каких производителей соответствуют те или иные сетевые адреса, можно, заглянув в файл GENERIC в каталоге /usr/src/sys/i386/conf:

# more /usr/src/sys/i386/conf/ GENERIC

В нем находим соответствующие строчки:

device rl # RealTek 8129/8139

device xl # 3Com 3c90x (“Boomerang”, “Cyclone”)

Таким образом, интерфейс rl0 соответствует сетевой карте RealTek 8129/8139 и ее аналогам. Сетевой интерфейс xl0 соответствует сетевой карте 3Com.

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

Шлюз провайдера – по умолчанию 83.xxx.xxx.1.
В сети присутствуют компьютеры пользователей – 192.168.9.31, 192.168.9.32.
Наш домен (условно) – ourdomain.ru.
Имя хоста (компьютера) – ourhost.ourdomain.ru.

Выполняем настройку сетевых карт. Можно использовать утилиту sysinstall (/stand/sysinstall для FreeBSD 5.5 и /usr/sbin/sysinstall для FreeBSD 6.1) Но поскольку нам известны все необходимые параметры, то для упрощения процесса и экономии времени мы будем задавать параметры путем редактирования соответствующих конфигурационных файлов.

Для редактирования будем использовать текстовый редактор vi, присутствующий практически в любой системе UNIX. Для администраторов, пока незнакомых с редактором, могу порекомендовать замечательную статью Максима Мошкова http://www.lib.ru/unixhelp/vi.txt и http://www.lib.ru/unixhelp/vibegin.txt.

Настройки сетевых интерфейсов во FreeBSD хранятся в файле /etc/rc.conf. Открываем его на редактирование:

# vi /etc/rc.conf

И добавляем следующие строки:

# Задаем внутренний интерфейс
ifconfig_xl0="inet 192.168.9.2 netmask 255.255.255.0"
# Задаем внешний интерфейс
ifconfig_rl0="inet 83.xxx.xxx.xxx netmask 255.255.255.224"
# Задаем шлюз провайдера по умолчанию
defaultrouter="83.xxx.xxx.1"
# Имя хоста
hostname="ourhost.ourdomain.ru"
# Указываем, что сервер будет работать как маршрутизатор
gateway_enable="YES"

После чего перезагружаем компьютер:

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

После загрузки проверяем:

Вывод команды ifconfig:

rl0: flags=8843 mtu 1500
options=8
inet6 fe80::215:58ff:fe3e:8fb1%rl0 prefixlen 64 scopeid 0x1
inet 83.xxx.xxx.xxx netmask 0xffffffe0 broadcast 83.xxx.xxx.yyy
ether 00:xx:xx:xx:xx:xx
media: Ethernet autoselect (100baseTX)
status: active
xl0: flags=8843 mtu 1500
options=9
inet6 fe80::20a:5eff:fe62:ade2%xl0 prefixlen 64 scopeid 0x2
inet 192.168.9.2 netmask 0xffffff00 broadcast 192.168.9.255
ether 00:zz:zz:zz:zz:zz
media: Ethernet autoselect (100baseTX)
status: active
plip0: flags=108810 mtu 1500
lo0: flags=8049 mtu 16384
inet6::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000

Файл rc.conf, на мой взгляд, можно назвать ключевым файлом конфигурации. Очень большое число параметров, используемых системой, задается в виде соответствующих переменных в этом файле. В том числе настройки сетевых интерфейсов, файервола и NAT, используемых нами.

Настройка шлюза

Мы будем использовать «родной» для FreeBSD файервол IPFW. Для этого мы должны внести некоторые изменения в ядро системы. Если возникли дополнительные вопросы по перекомпиляции ядра, советую прочитать дополнительный материал: http://freebsd.org.ru/how-to/kernelconfig.html.

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

Исходники ядра по умолчанию лежат в каталоге /usr/src/sys/i386/conf. Соответственно переходим в данный каталог:

# cd /usr/src/sys/i386/conf

Как правило, изменяют файл GENERIC, содержащий опции ядра, устанавливаемого по умолчанию. Для этого делаем копию данного файла:

# cp GENERIC ourkernel

Открываем на редактирование новый файл ourkernel:

и добавляем следующие опции:

#
options IPFIREWALL #firewall
options IPFIREWALL_VERBOSE ?
#enable logging to syslogd(8)
options IPFIREWALL_FORWARD ?
#enable transparent proxy support
options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity
options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default
#
options DUMMYNET
#
options IPDIVERT #divert sockets

После сделанных изменений можно приступать к перекомпиляции ядра.

Выполняем команды:

# config ourkernel
# cd /usr/src/sys/i386/compile/ourkernel
# make depend
# make
# make install

Перегружаемся:

Если после перезагрузки сервер работает нормально, приступаем к настройке файервола.

Для организации работы файервола используются следующие переменные, добавляемые при необходимости в файл rc.conf.

Разрешает или запрещает использование файервола:

# Set to YES to enable firewall functionality
firewall_enable="NO"

Имя и местоположение файла, отвечающего за инициализацию файервола.

# Which script to run to set up the firewall
firewall_script="/etc/rc.firewall"

При установке данного правила в «YES» подавляется вывод на дисплей:

firewall_quiet="NO"

Разрешить/запретить ведение лога событий:

firewall_logging="NO"

Тип настройки файервола:

firewall_type="UNKNOWN"

по умолчанию FreeBSD использует правила из файла /etc/rc.firewall.

В нем есть несколько готовых шаблонов:

open – файервол разрешает прохождение всех пакетов.

client – рекомендуется для защиты только этого компьютера. То есть файервол настроен как стандартный клиентский компьютер. Он разрешает все исходящие соединения и запрещает все входящие соединения, кроме соединений по 25 порту.

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

closed – Разрешается трафик через локальный интерфейс lo0. Прохождение остального трафика определяется правилом по умолчанию. Как правило, это запрет любого доступа, исключая внутренний интерфейс lo0 (попросту говоря, разрешен только доступ «к самому себе»)

UNKNOWN – запретить загрузку файервольных правил из конфигурационного скрипта по умолчанию. Файервол никак не настраивается. Будет он пропускать трафик или нет, зависит от конфигурации ядра системы. Используется по умолчанию.

Эту же переменную в значении «filename» – «имя_файла» – можно использовать для задания собственного конфигурационного файла для файервола.

Например:

firewall_type="/etc/rc.firewall.newconfig"

будет загружать настройки из созданного файла /etc/rc.firewall.newconfig.

«firewall_flags=””» – служит для передачи дополнительных аргументов при использовании firewall_type со значением filename.

Наша задача состоит в том, чтобы создать систему, отвечающую следующим критериям:

Простота администрирования.

Возможность модификации «на лету», незаметно для пользователей. Поэтому такие операции, как разрыв соединений и тем более перезагрузка для нас нежелательны.

Гарантия того, что наша система будет работать на большинстве машин.

В нашем примере скрипта все компьютеры локальной сети делятся на две условные группы: одна группа привилегированная – это те, кому разрешен доступ в Интернет, используя наиболее употребительные сервисы, такие как:

HTTP – порт 80;
HTTPS – порт 443;
FTP – порты 20, 21 и от 1025 до 65535;
SMTP-протокол для пересылки почты – порт 25;
POP3-протокол для приема сообщений – порт 110.

Есть и другая группа, компьютерам из которой разрешен доступ только к внешнему корпоративному серверу c IP-адресом 83.xxx.xxx.2 (только протоколы SMTP и POP3).

Мы должны добиться, чтобы можно было изменять привилегированную группу, что называется, «на лету», по возможности не разрывая установленных соединений. Для этого мы из нашего скрипта вызываем дополнительный скрипт rc.firewall.local.inet. Достаточно отредактировать и перезапустить этот дополнительный скрипт, не затрагивая всех остальных настроек файервола.

Дополнительно мы должны предусмотреть ситуацию, когда меняются параметры сети, такие как IP-адрес шлюза провайдера. Для этого мы будем использовать в скрипте локальные переменные. Например, при изменении шлюза по умолчанию достаточно изменить значение переменной intgateway и перезапустить скрипт rc.firewall.run.

Вот наш пример скрипта:

# vi rc.firewall.run
#!/bin/sh
extip="83.xxx.xxx.xxx"
intip="192.168.9.2"
intnet="192.168.9.0/24"
mailserver="83.xxx.xxx.2"
intgateway="83.xxx.xxx.1"
#
/sbin/ipfw -f flush &
#
/sbin/ipfw add 180 divert natd ip from ${intnet} to any out xmit fxp0
/sbin/ipfw add 190 divert natd ip from any to ${extip}
# ICMP
/sbin/ipfw add 500 allow icmp from any to any
# SSH
/sbin/ipfw add 10000 allow tcp from any to any 22
/sbin/ipfw add 10010 allow tcp from any 22 to any
# DNS
/sbin/ipfw add 11000 allow tcp from any to any 53
/sbin/ipfw add 11010 allow tcp from any 53 to any
/sbin/ipfw add 11020 allow udp from any to any 53
/sbin/ipfw add 11030 allow udp from any 53 to any
# Web FTP
/sbin/ipfw add 12000 allow tcp from me to any 20,21,80,443
/sbin/ipfw add 12010 allow tcp from any 20,21,80,443 to me
/sbin/ipfw add 12020 allow udp from me to any 20,21
/sbin/ipfw add 12030 allow udp from any 20,21 to me
#
# Script for the privilege group
/bin/sh /etc/rc.firewall.local.inet
# Deny other computer of LAN
/sbin/ipfw add 12960 deny tcp from ${intnet} to any 20,21,80,443
/sbin/ipfw add 12970 deny tcp from any 20,21,80,443 to ${intnet}
/sbin/ipfw add 12980 deny udp from ${intnet} to any 20,21
/sbin/ipfw add 12990 deny udp from any 20,21 to ${intnet}
#
#
/sbin/ipfw add 13000 allow tcp from ${intnet} to ${mailserver} 25,110
/sbin/ipfw add 13010 allow tcp from ${mailserver} 25,110 to ${intnet}
#
/sbin/ipfw add 55010 allow tcp from any to any 1024-65534
/sbin/ipfw add 55020 allow tcp from any 1024-65534 to any
/sbin/ipfw add 55030 allow tcp from any 1024-65534 to any
/sbin/ipfw add 55040 allow tcp from any to any 1024-65534
/sbin/ipfw add 55050 allow udp from any to any 1024-65534
/sbin/ipfw add 55060 allow udp from any 1024-65534 to any
/sbin/ipfw add 55070 allow udp from any 1024-65534 to any
/sbin/ipfw add 55080 allow udp from any to any 1024-65534
# Deny all
/sbin/ipfw add 65534 deny ip from any to any

Создаем и редактируем скрипт rc.firewall.local.inet для работы с привилегированной группой адресов:

# vi /etc/ rc.firewall.local.inet
#!/bin/sh
intnet="192.168.9.0/24"
privgroup={31,32}
#
/sbin/ipfw delete 12310
/sbin/ipfw delete 12320
/sbin/ipfw delete 12330
/sbin/ipfw delete 12340
#
/sbin/ipfw add 12310 allow tcp from ${intnet}${privgroup} to any 20,21,80,443,1025-65535
/sbin/ipfw add 12320 allow tcp from any 20,21,80,443,1025-65535 to ${intnet}${privgroup}
/sbin/ipfw add 12330 allow udp from ${intnet}${privgroup} to any 20,21,1025-65535
/sbin/ipfw add 12340 allow udp from any 20,21,1025-65535 to ${intnet}${privgroup}

В скрипте для изменения состава привилегированной группы необходимо отредактировать переменную privgroup, добавив/удалив в ней номер хоста в локальной подсети.
Например, чтобы добавить два компьютера с IP-адресами 192.168.9.33 и 192.168.9.45, нужно записать «privgroup={31-33,45}».

Использовать правила типа «/sbin/ipfw delete NNNNN» при старте системы, когда такого правила не было – немножко некрасиво. При попытке удалить несуществующее правило система выдает на консоль сообщение следующего вида:

ipfw: rule 13031: setsockopt(IP_FW_DEL): Invalid argument

При этом система продолжает нормально работать.

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

Зато теперь мы можем после внесения соответствующих изменений просто перезапустить скрипт для привилегированной группы.

# /bin/sh rc.firewall.local.inet

Также мы можем вносить изменения и перезапускать скрипт rc.firewall.run, хотя, по замыслу, это нам придется делать гораздо реже, чем в случае со скриптом привелигированной группы.

# /bin/sh rc.firewall.run

Поскольку мы написали свой собственный скрипт, обнуляющий существующие правила и запускающий альтернативную конфигурацию файервола, нужно подумать, как его запустить.

Во FreeBSD есть замечательный механизм запуска пользовательских программ: файл rc.local. По умолчанию он отсутствует в системе.

Раз мы уже создаем данный файл, добавим в него команду запуска демона natd, который отвечает за поддержку NAT.

Демон natd запускается из файла rc.conf. (Опять этот файл, поистине он играет ключевую роль для всей системы FreeBSD в целом!)

Механизм запуска этого файла из rc.conf выполняется посредством следующих переменных:

# -- путь к самому файлу natd
natd_program="/sbin/natd"
# Разрешить NAT (если firewall_enable == YES)
natd_enable="YES"
# Внешний интерфейс или IPaddress для использования
natd_interface=""
# Дополнительный флаги запуска natd
natd_flags=""

Но в этом случае мы будем использовать вызов демона natd посредством rc.local. Команда:

# vi /etc/rc.local

автоматически создает файл /etc/rc.local и открывает его на редактирование.

Добавляем в него следующие строки:

# Команда запуска natd
/sbin/natd -n rl0
# где «-n rl0» - имя интерфейса, на котором запускается NAT
#
# И запускаем наш скрипт для установки правил для файервола:
/bin/sh /etc/rc.firewall.run

Перезагружаемся и проверяем доступ к нужным ресурсам Интернета с компьютера из локальной сети.

1. Эви Немет, Гарт Снайдер, Скотт Сибасс, Трент Р.Хейн. UNIX. Руководство системного администратора. «BHV», «Питер», 2004 г.
2. Алексей Федорчук, Алексей Торн. FreeBSD. Установка, настройка, использование. BHV, 2003 г.
3. Филипп Торчинский. Практическое пособие администратора UNIX. «Символ», 2003 г.

Не так давно нужно было поставить гейт в Интернет для одного интернет-кафе. Кафе имело доступ к Интернету через ADSL-модем с Ethernet интерфейсом и локалку на 50 компьютеров со статическими адресами. Решено было поставить именно шлюз, а не купить обычной роутер с NAT, так как в роутерах все равно крутится урезанный линукс, а шлюз на базе ПК имел гораздо больше возможностей. К тому с таким количеством компьютеров использование прокси-сервера для кеширования веб-страниц давало определенную экономию траффика. Машинка имела параметры уровня Pentium2-600 с 256 Mb оперативной памяти. Вариант установки оффтописка отпадал из-за слабых мощностей и ненадежности и отсутствия гибкости. К тому же FreeBSD идеально подходит для гейтов в силу малой требовательности ресурсов и надежности работы. Насколько мне известно по хоум-провайдингу, гейты на FreeBSD могут спокойно натить полосу до 500-600 mbit/sec

Итак, дано - установить FreeBSD на компьютер, настроить NAT, настроить прозрачный прокси.

Не буду утомлять читателей описанием установки, благо это подробно описано и иллюстрировано в .
После установки я , включив в него дополнительные опции, а именно

options IPFIREWALL #добавил поддержку файрволла
options IPFIREWALL_VERBOSE #логгирование
options IPFIREWALL_VERBOSE_LIMIT=100 #органичение количества записей в лог
options IPFIREWALL_DEFAULT_TO_ACCEPT #файерволл "открыт" по умолчанию
options IPFIREWALL_FORWARD
options IPDIVERT #включение поддержки перенаправления пакетов
options DUMMYNET #может понадобится для ограничения скорости

После пересборки ядра настала очередь правки /etc/rc.conf для включения NAT. NAT будет использовать в виде отдельного демона. У меня на шлюзе стояло 2 сетевые карточки, одна смотрела в интернет через модем (настроенный в режиме моста), вторая в локальную сеть.
Соотвественно, первая была re0 и имела адрес вида 213.230.x.x, вторая rl0 - адрес 192.168.0.1

Правим /etc/rc.conf

defaultrouter=213.230.x.x #указываем основной шлюз
ifconfig_re0="inet 213.230.x.x netmask 255.255.255.252" #задаем внешний интернетовский адрес
ifconfig_rl0="inet 192.168.0.1 netmask 255.255.255.0" #задаем внутренний адрес
gateway_enable="YES" #зайдествуем режим шлюза
natd_enable="YES" #включем NAT
nat_interface="re0" #указываем натируемый интерфейс
nat_flags="-f /etc/natd.conf" #файл настройки демона NAT
firewall_enable="YES"

nameserver 195.158.0.1
nameserver 195.158.0.3

После сохранения и перезагрузки (это не обязательно, можно поднять интерфейсы и демон не перезагружая, но проверить как что поднимается все же нужно), проверяем доступность в обоих сетках, пропинговав локальные машины и хосты в интернете.
Уже на данном этапе интернет доступен локальным компьютерам, единственное что нужно дополнительно настроить на них, так это указать на них шлюз по умолчанию 192.168.0.1 и в строке DNS-сервера также прописать 192.168.0.1

Пришла очередь поставить squid. Для начала обновляем .
После успешного обновления переходим собственно к установке.

#cd /usr/ports/www/squid31/
#make install clean

После окончания установки идем править файл настройки squid, находящегося по адресу /usr/local/etc/squid/squid.conf


# Adapt to list your (internal) IP networks from where browsing
# should be allowed
#Здесь указываются подсетки, которые имеют доступ к нашей проксе, у нас подсетка 192.168.0.0, потому оставляем только ее
#acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/24 # Указываем сеть 192.168.0.1-254
#IPv6 Not Available:acl localnet src fc00::/7 # RFC 4193 local private network range
#IPv6 Not Available:acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80 # https
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # httpss
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # https-mgmt
acl Safe_ports port 488 # gss-https
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling https
acl CONNECT method CONNECT

#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
https_access allow manager localhost
https_access deny manager

# Deny requests to certain unsafe ports
https_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
https_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#https_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
https_access allow localnet
https_access allow localhost

# And finally deny all other access to this proxy
https_access deny all

# Squid normally listens to port 3128 - Порт, на котором будет висеть прокси
https_port 127.0.0.1:3128 intercept #transparent для версий ниже 3.1

# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

# Uncomment and adjust the following to add a disk cache directory.
cache_dir ufs /var/squid/cache 500 16 256
cache_mem 256 MB
# Leave coredumps in the first cache dir
coredump_dir /var/squid/cache

# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|?) 0 0% 0
refresh_pattern . 0 20% 4320

#/usr/local/sbin/squid -z

Стартуем его

#/usr/local/etc/rc.d/squid -start

Если Squid успешно запустился - открываем любой бразуер, указываем нашу проксю вида 192.168.0.1:3128 и пробуем открыть например тот же google.com.
Открылся? Замечательно, вписываем в /etc/rc.conf

squid_enable="YES"

И делаем его прозрачным, добавив правило в файрволл.

ipfw add fwd 192.168.0.1,3128 tcp from 192.168.0.0/24 to any 80

После этого, на клиентском компьютере убираем прокси с браузера и пробуем открыть другую страницу. Паралелльно можно смотреть файл /var/log/squid/access.log, в котором фиксируются обращения к прокси. Если все работает, в логи появляются записи - поздравляю. Теперь все веб-запросы от клиентских компьютеров будут прозрачно кешироваться, экономя вам траффик.
На этом первоначальная настройка гейта завершена.

UPD. Иногда нужно раздавать интернет не всем в локальной сети, а некоторым пользователям. Тогда можно прикрутить к сквиду авторизацию. Это делается путем добавления в конфиг

auth_param basic program /usr/local/libexec/squid/ncsa_auth /usr/local/etc/squid/internet_users
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

acl squidusers proxy_auth REQUIRED

# htpasswd -c /etc/squid/internet_users synergix
New password: *******
Re-type new password: *******
Adding password for user synergix

Ключ -с необходимо указывать только один раз, при создании файла с паролями. В последующем добавлять пользователей нужно без этого ключа. Итак, мы получили файл с примерно таким содержимым.


synergix:89XzEEI/P0e56

Где synergix - имя пользователя, а 89XzEEI/P0e56 - хеш его пароля. Для добавления нового пользователя в существующий файл необходимо выполнить следующую команду

# htpasswd -b /etc/squid/internet_users second_user 1234567
Adding password for user second_user

Посмотрим -

# cat /etc/squid/internet_users
syenrgix:89XzEEI/P0e56
second_user:EAJezc5eLXrV2

Выставим права для файла

# chmod 440 /usr/local/etc/squid/internet_users
# chown squid:squid /usr/local/etc/squid/internet_users

#/usr/local/etc/rc.d/squid reload

Многие новички в сетях и FreeBSD сталкиваются с вопросом:

«Как соединить две сети если сервер на FreeBSD имеет физическое подключение к обеим сетям?»

Иными словами сервер FreeBSD должен выступать в роли router (маршрутизатор).

Итак, что мы имеем:

  • Ethernet сеть
  • Две подсети класса «С» (/24 — маска 255.255.255.0)
  • Сервер FreeBSD с двумя сетевыми картами
  • Клиенты в обеих подсетях

Наша задача, чтобы клиенты из подсети 192.168.1.0/24 могли обмениваться трафиком с клиентами из подсети 192.168.0.0/24.

Сначала настроим сервер FreeBSD и заставим его передавать (маршрутизировать) пакеты из одной подсети в другую.

За это отвечает параметр net.inet.ip.forwarding , посмотрим в какое значение он имеет:

# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0

На данный момент его значение «0», а это значит, что сервер FreeBSD не будет выполнять маршрутизации.

Включим эту функцию:

# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1

Так мы изменили значение с «0» на «1». Теперь нужно сделать, так чтобы после ребута это значение всегда было 1-цой. Это можно сделать 2-мя способами:

  1. в файл /etc/rc.conf добавить строчку: gateway_enable=»YES»
  2. в файл /etc/sysctl.conf добавить строчку: net.inet.ip.forwarding=1

На сервере у нас есть две сетевые карты и соответственно два интерфейса: em0 и em1.

Пусть em0 «смотрит» в сеть слева, а em1 в сеть справа. Назначим IP-адреса для интерфейсов FreeBSD сервера:

# ifconfig em0 add 192.168.1.1/24
# ifconfig em1 add 192.168.0.1/24

Примечание :

Если на команду ifconfig вы получаете ответ:
command not found
воспользуйтесь командой
# whereis ifconfig
ifconfig: /sbin/ifconfig /usr/share/man/man8/ifconfig.8.gz /usr/src/sbin/ifconfig
которая укажет где именно располагается утилита ifconfig
как видно из результата выполнения команды whereis утилита ifconfig находится /sbin/ifconfig
вводите полный путь до утилиты ifconfig, тогда надпись command not found появляться не будет и команда будет выполняться

Посмотрим что получилось:

# ifconfig -a

em0 : flags=8843 metric 0 mtu 1500 ether 00:02:a5:4e:92:48 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 media : Ethernet autoselect (100baseTX ) status : active em1 : flags=8802 metric 0 mtu 1500 ether 00:02:a5:4e:92:49 inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 media : Ethernet autoselect (100baseTX ) status : active

Рассмотрим что все это значит:

em0 и em1 — имена сетевых интерфейсов
флаг UP — означает что сетевая карта включена, если этого флага не будет, то пакеты не будут приниматься на этом интерфейсе (для включения воспользуйтесь командой: ifconfig ИМЯ_ИНТЕРФЕЙСА up)
ether — это mac-адрес этой сетевой карты
inet — назначенный IP-адрес для этого интерфейса и broadcast адрес для этой подсети
media — информация о скорости и дуплексе интерфейса
status — текущий статус интерфейса. Если status: no carrier, то это означает, что на сетевой карте нет линка.

Сохраним настройки, чтобы IP-адреса назначались интерфейсам после ребута сервера, для этого необходимо добавить в файл /etc/rc.conf следующие строчки:

ifconfig_em0=»inet 192.168.1.1 netmask 255.255.255.0″
ifconfig_em1=»inet 192.168.0.1 netmask 255.255.255.0″

Если на сервере вы используете firewall, например ipfw, то добавим правила разрешающие проход пакетов из одной сети в другую:

ipfw add 100 allow ip from 192.168.1.1/24 to 192.168.0.1/24
ipfw add 110 allow ip from 192.168.1.0/24 to 192.168.1.1/24

Теперь настройте клиентские компьютеры:

  • Выставить IP-адрес из нужной подсети: 192.168.1.ХХХ или 192.168.0.ХХХ
  • Выставить маску подсети 255.255.255.0
  • Выставить шлюз по умолчанию: для подсети 192.168.1.ХХХ это 192.168.1.1, а для подсети 192.168.0.ХХХ это 192.168.0.1 (именно эти IP-адреса на интерфейсах нашего FreeBSD сервера)

Наступило время проверить есть ли связь сервера и клиентов. Для этого возьмем заведомо рабочий клиентский компьютер из 2-х сетей, например это будут компьютеры с IP-адресами:

  • 192.168.1.11
  • 192.168.0.15

Воспользуемся утилитой ping на сервере:

# ping 192.168.1.11

Если результат будет таким:

PING 192.168.1.11 (192.168.1.11): 56 data bytes
64 bytes from 192.168.1.11: icmp_seq=0 ttl=64 time=0.466 ms
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.238 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.272 ms
^C
— 192.168.1.11 ping statistics —
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.238/0.325/0.466/0.100 ms

Значит все хорошо и связь между сервером и клиентом есть. Проделайте тоже самое с 192.168.0.15.

Если результат ping отрицательный, то убедитесь что на клиентском компьютере правильно выставлен IP-адрес и маска подсети, а так же наличие линка на сетевой карте.

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

Так же воспользуемся утилитой ping, но уже на компьютере с IP-адресом 192.168.1.11:

ping 192.168.0.15

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

Если ответа нет, то воспользуемся утилитой tracert (для Windows) или traceroute (для FreeBSD):

tracert 192.168.0.15

Если сразу «идут звездочки»:

1 * * *

То проверьте правильность выставление шлюза по умолчанию.

Если трасса выглядит так:

1 192.168.1.1 (192.168.1.1) 0.421 ms 0.447 ms 0.485 ms
2 * * *

То пакет доходит до сервера, убедитесь что firewall сервера не блокирует пакеты и что клиентский компьютер с IP-адресом 192.168.0.15 правильно настроен и «видит» сервер (проверьте IP-адрес, маску подсети, шлюз по умолчанию и наличие ping до сервера)

Вы все проверили, но по прежнему ничего не работает? Воспользуемся утилитой tcpdump на сервере, которая покажет пакеты проходящие через интерфейсы сервера:


и

Запустите пинг с одного клиентского компьютера из одной подсети на другой клиентский компьютер в другой подсети (как мы делали в примерах выше) и смотрите в вывод команды tcpdump на сервере, который будет примерно таким:

# tcpdump -ni em0

12:17:23.398376 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 49222, seq 0, length 64
12:17:24.399906 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 49222, seq 1, length 64

Т.е. компьютер 192.168.1.11 посылает пакет ICMP echo request до компьютера 192.168.0.15, но ответов мы не видим. Посмотри передает ли сервер эти пакеты на другую сетевую карту:

# tcpdump -ni em1

12:21:18.167017 IP 192.168.1.11 >
12:21:19.168022 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 5, length 64

Видим, что запросы передаются на другой интерфейс сервера, но ответов по прежнему нет. Проверьте настройки компьютера 192.168.0.15 и отсутствие у него проблем с физическим подключением к сети.

Когда все работает вывод будет таким:

12:21:17.165998 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 3, length 64
12:21:17.171199 IP 192.168.0.15 > 192.168.1.11: ICMP echo reply, id 50246, seq 3, length 64
12:21:18.167017 IP 192.168.1.11 > 192.168.0.15: ICMP echo request, id 50246, seq 4, length 64
12:21:18.171353 IP 192.168.0.15 > 192.168.1.11: ICMP echo reply, id 50246, seq 4, length 64

Мы видим стандартый вывод «запрос-ответ», когда на пакет ICMP echo request приходит ответ в виде пакета ICMP echo reply

Дистрибутив фрюхи часто называют самым подходящим для решения прикладных сетевых задач в локальной сети. Сегодня мы займемся решением одной из сетевых задач — настройкой шлюза на Freebsd 10 для доступа в интернет из локалки. Это простой, популярный и востребованный функционал сервера, который можно расширять дополнительными возможностями.

Будем использовать следующую версию системы для решения нашей задачи по настройке шлюза:

# uname -v FreeBSD 10.2-RELEASE-p8 #0 r292756M: Sat Dec 26 22:49:34 MSK 2015 root@freebsd:/usr/obj/usr/src/sys/GENERIC

На сервере установлены 2 сетевые карты:

  • hn0 — внешний интерфейс, получает интернет от провайдера, настройки по dhcp
  • hn1 — локальная сеть, адрес 10.20.30.1, установлен вручную

В нашу задачу по настройке программного freebsd роутера будет входить настройка маршрутизации на сервере, установка и настройка ipfw, включение nat, настройка локального dhcp и dns сервера.

Подготовка сервера к настройке шлюза

Информацию о выданных leases dhcp сервера dnsmasq можно посмотреть в файле /var/db/dnsmasq.leases .

Анализ сетевой активности в freebsd с помощью iftop

Иногда хочется посмотреть, что происходит на роутере и кто использует интернет в данный момент. По-умолчанию, в системе нет готового средства для получения этой информации. На помощь нам придет простая программа iftop, которая позволяет в режиме реального времени посмотреть активность на сетевом интерфейсе.

Устанавливаем iftop на настроенный Freebsd шлюз:

# pkg install iftop

Запускаем iftop с указанием интерфейса и отображением используемых портов:

# iftop -i hn1 -P

Видим любопытную картину — кто, куда, по какому порту и с какой скоростью лезет.

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

Заключение

Подведем итог того, что сделали. За короткое время настроили полноценный шлюз (по сути программный роутер) на базе Freebsd 10 для обеспечения выхода в интернет клиентов за сервером. При этом обеспечили автоматическое получение настроек. Даже на скромном виртуальном сервере такой шлюз способен переварить достаточно большой траффик.

Вся настройка занимает буквально 10-15 минут. Основное время уходит на сборку ядра. Чем выше версия Freebsd, тем дольше оно собирается, несмотря на то, что скорости железа существенно возрастают.

Пройдемся по пунктам и разберемся с тем, что конкретно мы сделали:

  1. Подготовили сервер к настройке шлюза.
  2. Пересобрали ядро с необходимыми параметрами.
  3. Настроили ipfw и nat, включили маршрутизацию.
  4. Установили и настроили dnsmasq для раздачи сетевых настроек по dhcp и dns сервера.
  5. Установили iftop для простейшего анализа сетевой активности на внешнем интерфейсе.

Этого достаточно для полноценной работы шлюза на Freebsd 10. Если есть необходимость подсчета пользовательского траффика или ограничения доступа к определенным ресурсам, можно к нему.

Случайные статьи

Вверх