В качестве интернет-шлюза (роутера) сервер с ОС 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® Нажимаем клавиши
Нажимаем кнопку
Сначала проверим доступность нашего сервера, вводим команду (в нашем случае сервер в локальной сети имеет ip-адрес 172.16.0.100):
ping 172.16.0.100
и нажимаем клавишу
Можно проверять доступность удаленных ресурсов, вводим команду:
ping adobe.ru
и нажимаем клавишу
Если внешний ресурс в интернете доступен (пингуется) — можете смело открывать браузер и серфить в интернете! Если вместо нормального пинга получается это:
Следует проверить настройки сетевой карты на ПК в локальной сети. Можно проверить доступность ресурса по ip-адресу, вводим команду:
ping 213.252.95.237
и нажимаем клавишу
стоит проверить правильность указания адреса DNS — сервера в настройках сетевой карты. Если же Вы все сделали по инструкции, а ОНО все равно не работает, вероятнее всего не было контроля на одном из этапов (очень часто бывает с более-менее «продвинутыми» пользователями). Совет тут только один: еще раз все перепроверить!
Мы настроили наш интернет-шлюз в минимальной конфигурации. Но хотелось бы, что бы наш сервер и клиентов локальной сети настраивал автоматически (выдавал ip-адрес, маску подсети, шлюз, DNS-сервер…) — как это делает самый дешевый аппаратный роутер. Таки вылкам: тут Вы познаете премудрости DNS-сервиса, а тут — узнаете о том, как настроить службу DHCP (рекомендую настраивать именно в такой последовательности — сначала DNS, заntv — DHCP). Более требовательные могут настроить «прозрачный» доступ через proxy-cервер, дабы смотреть статистику доступа к WEB-страницам. Желаю успехов.
Источник : http://суперхрюн.рф/index.php/freebsd/5-freebsd-9-x-internet-shlyuz-router?start=1
RSS & RSS to Email