FreeBSD 9.x — Интернет шлюз (роутер) с использованием IPFW kernel NAT

В качестве интернет-шлюза (роутера) сервер с ОС FreeBSD используют довольно часто. Для того, чтобы использовать наш сервер в качестве интернет-шлюза необходимо наличие двух сетевых интерфейсов (строго говоря, можно и одним обойтись, но тогда подключаемое оборудование должно поддерживать VLAN, и это уже совсем другая история). Для начала глянем на состояние сетевых интерфейсов нашего сервера, для этого существует «волшебная» команда:

$ ifconfig

результат выполнения команды:

Состояние сетевых интерфейсов

Как не трудно догадаться, в нашем сервере имеется два физических сетевых интерфейса — em0 и em1 (интерфейс lo0 называют «петлевым», его пока рассматривать не будем).

Интерфейс em0 подключается к провайдеру (в качестве «эксперементального» провайдера у меня используется аппаратный роутер — что то типа D-Link DIR-320 и ему подобных…). На данном этапе мы рассмотрим наиболее простой способ получения: сетевая карта em0 получает от провайдера (моего роутера) ip-адрес (ip-address), маску подсети (netmask), основной шлюз (default gateway) и DNS-сервер (DNS), при этом не требуется какой либо авторизации у провайдера. Сетевая карта em0 настроена на получение ip-адреса (и остальных параметров) по протоколу DHCP — это определяется следующими строками в файле /etc/rc.conf:

ifconfig_em0=»DHCP»
ifconfig_em0=»SYNCDHCP»

Первая строка определяет что сетевая карта em0 должна получать ip-адрес по протоколу DHCP, а вторая строка определяет получение ip-адреса в «синхронном» режиме (такой режим необходим для корректного запуска некоторых сетевых демонов при старте системы). По устоявшейся терминологии, сетевой интерфейс, подключенный к провайдеру называют «внешним». Как видно, сетевой интерфейс получил от DHCP сервера следующие параметры: ip-адрес 192.168.77.110, маска подсети 255.255.255.0. Естественно,  DHCP сервер провайдера должен был «выдать» основной шлюз и DNS-сервер. Основной шлюз можно определить по таблице маршрутизации, вот и посмотрим ее с помощью другой «волшебной» команды:

$ netstat -rn

результат таков:

Таблица маршрутизации

Нас интересует только секция inetrnet: (соответствует протоколу IPv4). Самое пристальное внимание мы должны обратить на следующие строки:

Destination        Gateway            Flags    Refs      Use  Netif Expire

default               192.168.77.77  UGS      0            7      em0

1-я строка — это название столбцов таблицы маршрутизации, означают следующее (перечислим только интересующие нас):

Destination — направление

Gateway  — шлюз

Flags  — флаги

Use — использование, указывает какое количество раз был задействован маршрут

Netif — сетевой интерфейс

Expire  — указывает, не закончил ли действие маршрут

2-я строка описывает основной маршрут. Стоит запомнить, что основной маршрут (его еще называют маршрут по-умолчанию) — необходимое условие наличия доступа в интернет на сервере! Поясним содержимое строки:

default — собственно и указаывает на то, что маршрут является основным (по-умолчанию)

192.168.77.77 — ip-адрес основного шлюза (шлюза по-умолчанию), именно на этот адрес пойдут запросы по основному маршруту

em0  — сетевой интерфейс, на который будут отправляться запросы на основной шлюз.

Теперь мы убедились, что шлюз по-умолчанию у нас получен. Осталось проверить есть ли у нас DNS — сервер, для этого посмотрим содержимое файла /etc/resolv.conf, в нем присуствует вот такая строка:

nameserver 192.168.77.77

Это и есть ip-адрес DNS сервера (в данном случае DNS-сервером является наш роутер). Таким образом, сетевая карта em0 получила все необходимые параметры для доступа в интернет. Стоит еще раз обратиться к результату выполнения команды ifconfig и посмотреть состояние сетевого интерфейса em0, нас интересует следующая строка:

status: active

это означает что сетевой интерфейс активен и работоспособен.

Самое время проверить наличие интернета на сервере, пропингуем какой — нибудь сайт:

$ ping -t3 adobe.ru

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

PING adobe.ru (213.252.95.237): 56 data bytes
64 bytes from 213.252.95.237: icmp_seq=0 ttl=116 time=25.497 ms
64 bytes from 213.252.95.237: icmp_seq=1 ttl=116 time=25.307 ms
64 bytes from 213.252.95.237: icmp_seq=2 ttl=116 time=26.731 ms

— adobe.ru ping statistics —
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 25.307/25.845/26.731/0.631 ms

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

Интерфейс em1 в устоявшейся терминологии называется «внутренним», именно через него к серверу будут подключаться компьютеры локальной сети. Параметры сетевого интерфейса em1 (ip-адрес 172.16.0.100, маска подсети 255.255.255.0) определены следующей строкой в файле /etc/rc.conf:

ifconfig_em1=» inet 172.16.0.100 netmask 255.255.255.0″

Состояние сетевого интерфейса (status: active) em1 не вызывает подозрений. Приходим к выводу, что обе сетевые карты работают нормально и можно приступать к настройке сервера.

Чтобы сервер выполнял функции интернет-шлюза, в файл  /etc/rc.conf добавим следующую строку (это делается от имени пользователя root):

gateway_enable=»YES»

Данный параметр вступит в силу после перезагрузки сервера, но перезагрузку будем делать после настройки NAT и Firewall.

Приступим к реализации основной задачи — настройке NAT. И NAT и Firewall можно реализовать как штатными средствами ОС, так и с помощью сторонних программ. На данный момент в состав ядра ОС FreeBSD 9.x входит ipfw2 который и firewall (ipfw), и NAT (ipfw nat) Одно из основных достоинств — быстродействие (поскольку ipfw2 реализован в ядре ОС — работает очень быстро, ресурсов «кушает» мало). Один из недостатков — не самый легкий для понимания и настройки инструмент (в связи с чем многие не используют ipfw2, заменяя его чем-то более «дружелюбным» в настройке). Firewall можно задействовать и без пересборки ядра, но функцию NAT нужно обязательно включить в ядро системы. Так что пересобирать ядро все равно придется, плюс ко всему производительность системы будет выше (да и конфигурировать оную можно будет более гибко). Для начала скопируем файл конфигурации ядра под новым именем ROUTER (подразумевается, что ОС работает на платформе i386, если платформа вашего сервера amd64 — скорректируйте команды с учетом этого), не забываем все это выполнять от имени пользователя root:
testrouter# cd /sys/i386/conf/ && cp GENERIC ROUTER

редактируем конфигурационный файл ROUTER нашего будущего ядра, в него нужно добавить следующие строки:

options   IPFIREWALL                                      #включаем ipfw
options   IPDIVERT                                           #возможность заворачивать пакеты,
                                                                           #без этого NAT (NATD) не заработает
options   IPFIREWALL_VERBOSE                     #включаем логирование работы ipfw
options   IPFIREWALL_VERBOSE_LIMIT=5    #ограничение на количество
                                                                           #одинаковых логов — защита против
                                                                           #атак
options   IPFIREWALL_NAT                             #включаем ipfw NAT
options   LIBALIAS                                           #включаем в ядро необходимые
                                                                          #библиотеки libalias
options   ROUTETABLES=2                              #две таблицы маршрутизации
options   DUMMYNET                                       #включаем функцию шейпера трафика
options   HZ=»1000″                                       #ускорение работы гигабитного сетевого адаптера

ВАЖНО! Перед сборкой ядра, проверьте наличие строки:
device bpf
в конфигурационном файле ROUTER, если такой строки нет — добавьте! Эта строка определяет наличие так называемого устройства bpf (Berkeley Packet Filter), вкомпилированного в ядро. Устройство bpf необходимо для работы DHCP сервера, реализация которого еще предстоит. Как правило, устройство bpf уже присутствует в конфигурационном файле ядра GENERIC, но, дабы в последствии не пересобирать ядро еще раз, стоит проверить вышеуказанный параметр заранее.

Cобираем ядро:

testrouter# cd /usr/src && make buildkernel KERNCONF=ROUTER

Время сборки ядра занимает от 20 минут и больше в зависимости от производительности вашей платформы. И мешать ему в этом не стоит — пока собирается ядро весело гоняем чаи с плюшками. Устанавливаем новое ядро (в отличие от предыдущей, данная процедура выполняется значительно быстрее):

testrouter# make installkernel KERNCONF=ROUTER

Новое ядро собрано и установлено, для использования нового ядра нужно перезагрузить сервер, но пока что этого делать не стоит. На данный момент правила firewall не заданы, а значит все возможности сетевого доступа к нашему серверу будут закрыты (и накагого удаленного доступа тоже не будет, и PuTTY Вам не поможет!). Вообще, первоначальную настройку firewall нужно производить в непосредственной близости от сервера — ибо ошибки не избежны.
Настраиваем запуск ipfw и NAT при старте системы, для чего в файл /etc/rc.conf добавляем строки:
firewall_enable=»YES»
firewall_nat_enable=»YES»
firewall_script=»/etc/fw_script.01″

В файл /etc/sysctl.conf добавим следующие строки:

# для работы ipfw NAT
net.inet.ip.fw.one_pass=1

# для ведения логов ipfw
net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose_limit=5

Создаем первоначальный файл скрипта конфигурации:
touch /etc/fw_script.01

############### Скрипт fw_script.01 c командами ipfw #############
#создаем символьные подмена для более удобного написания правил
exface=»em0″                            # внешний сетевой интерфейс сервера
inface=»em1″                             # внутренний сетевой интерфейс сервера
in_ip=»172.16.0.100″               # ip-адрес внутреннего интерфейса сервера
# префикс команды, параметр -q означает «тихую» работу
pre_com=»ipfw -q»
# для начала удаляем все существующие правила!
$pre_com -f flush
# разрешение трафика на петлевом интерфейсе – необходимо для работы ОС
# Операционная система UNIX использует интерфейс lo0 и IP-адрес
# 127.0.0.1 для внутренних нужд. Таким образом, firewall должен
# обеспечивать беспрепятственный обмен данными на указанных интерфейсе и
# IP-адресе.
$pre_com add 100 allow ip from any to any via lo0
# запрет ip трафика от любого источника на всю сеть loopback интерфейса
$pre_com add 200 deny ip from any to 127.0.0.0/8
# запрет ip трафика со всей сети loopback интерфейса на любой источник
$pre_com add 300 deny ip from 127.0.0.0/8 to any
# разрешаем беспрепятственному прохождению трафика внутри нашей локальной сети!!!
$pre_com add 400 allow all from any to any via $inface
# включаем kernel NAT на интерфейсе em0 с параметрами
# сбрасывать таблицу соединений при смете ip-адреса сетевого интерфейса
# пытаться сохранить порты
# по-умолчанию запрещать входящие подключения
$pre_com nat 1 config log if $exface reset same_ports deny_in
# все что проходит через внешний интерфейс перенаправляем в NAT
$pre_com add 1030 nat 1 ip from any to any via $exface

Не забываем сделать скрипт исполняемым:

testrouter# chmod u+x /etc/fw_script.01

Отмечу, что выше указаный скрипт с набором правил ipfw2 является минимально рабочим, и, конечно, он не идеален. Скрестим пальцы и перезагрузим сервер:

testrouter# reboot

Если сервер загрузился без ошибок — уже не плохо. Если при этом удалось на него удаленно зайти (из локальной сети, конечно, ибо из вне мы доступ не открывали) — то все очень даже хорошо!!! Проверяем таблицу маршрутизации и доступность интернета (это мы уже делали ранее).

Проверяем работу firewall, для чего выведем список правил:

testrouter# ipfw list

результат должен быть таким:

00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 allow ip from any to any via em1
01030 nat 1 ip from any to any via em0
65535 deny ip from any to any

далее проверим работу NAT, для чего отобразим его состояние:

testrouter# ipfw nat show

результат будет примерно таким:

nat 1: icmp=0, udp=1, tcp=3, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=4

Вот теперь настал торжественный момент — настройка клиентов локальной сети!

ВАЖНО!!!
Наш сервер сконфигурирован как интернет-шлюз, но он пока что НЕ может обрабатывать DNS запросы!!! В связи с этим на клиентах DNS-сервером должен быть указан НЕ внутренний интерфейс нашего сервера (в данном случае 172.16.0.100), а DNS-сервер провайдера (напоминаю что адрес DNS сервера получается по внешнему сетевому интерфейсу нашего сервера и хранится в файле /etc/resolv.conf). Таким образом, настройки сетевых интерфейсов на клиентах локальной сети нужно сделать вручную:
ip-адрес 172.16.0.XХХ
маска подсети 255.255.255.0
основной шлюз 172.16.0.100
DNS-сервер взять из файла /etc/resolv.conf на нашем сервере — в нашем случае это 192.168.77.77

Вот (в качестве примера) настройки сетевой карты одного из ПК в локальной сети:

Настройки сетевой карты ПК в локальной сети

Что же, можно проверять доступность интернета на ПК в локальной сети. На компьютере с операционной системой Microsoft Windows® Нажимаем клавиши +, в открывшемся окне «Запуск программы» набираем команду cmd:

Окно "Запуск программы"

  Нажимаем кнопку , откроется окно командной строки:

Окно командной строки

 Сначала проверим доступность нашего сервера, вводим команду (в нашем случае сервер в локальной сети имеет ip-адрес 172.16.0.100):

ping 172.16.0.100

и нажимаем клавишу , если сервер доступен:  

Сервер доступен

 Можно проверять доступность удаленных ресурсов, вводим команду:

ping adobe.ru

и нажимаем клавишу , смотрим результат:

Внешний сетевой ресурс в интернете доступен

Если внешний ресурс в интернете доступен (пингуется) — можете смело открывать браузер и серфить в интернете! Если вместо нормального пинга получается это:

Не удалось обнаружить узел

Следует проверить настройки сетевой карты на ПК в локальной сети. Можно проверить доступность ресурса по ip-адресу, вводим команду:

ping 213.252.95.237

и нажимаем клавишу , и если по ip-адресу ресурс все же доступен:

Узел доступен по ip-адресу

стоит проверить правильность указания адреса DNS — сервера в настройках сетевой карты. Если же Вы все сделали по инструкции, а ОНО все равно не работает, вероятнее всего не было контроля на одном из этапов (очень часто бывает с более-менее «продвинутыми» пользователями). Совет тут только один: еще раз все перепроверить!

Мы настроили наш интернет-шлюз в минимальной конфигурации. Но хотелось бы, что бы наш сервер и клиентов локальной сети настраивал автоматически (выдавал ip-адрес, маску подсети, шлюз, DNS-сервер…) —  как это делает самый дешевый аппаратный роутер. Таки вылкам: тут Вы познаете премудрости DNS-сервиса, а тут — узнаете о том, как настроить службу DHCP (рекомендую настраивать именно в такой последовательности — сначала DNS, заntv — DHCP). Более требовательные могут настроить «прозрачный» доступ через proxy-cервер, дабы смотреть статистику доступа к WEB-страницам. Желаю успехов.

Источник :  http://суперхрюн.рф/index.php/freebsd/5-freebsd-9-x-internet-shlyuz-router?start=1

Запись опубликована в рубрике *Lan&Wan, *Unix,*Linux. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Я не спамер This plugin created by Alexei91