Настройка основного и двух резервных операторов на Linux-роутере с NetGWM. Линукс роутер


Опыт создания домашнего Wi-Fi маршрутизатора. Часть 2. Установка и настройка ПО

И снова здравствуйте!

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

Когда я затевал всё это движение, я предполагал, что будет непросто. Но не предполагал, что настолько. В одном из комментариев к предыдущей части статьи я клятвенно пообещал рассказать о нижеследующем «к выходным». Благоразумно умолчал к каким именно. :-) Тут ещё умудрился прихворнуть не вовремя, но всё-таки сдерживаю своё обещание.

Итак…

Напомню комплектацию:

  • материнская плата Intel D2500CC с комплектным двухядерным 64-bit процессором Intel Atom D2500, двумя гигабитными сетевыми интерфейсами
  • оперативная память SO-DIMM DDR-3 1066 4Gb Corsair
  • SSD-накопитель Crucial M500 120 GB
  • сетевая карта 1000 Mbit D-Link DGE-528T
  • mini-PCI-E Wi-Fi карта Intel 7260.HMWWB 802.11 a/b/g/n/ac + Bluetooth 4.0
  • всё это хозяйство упаковано в корпус Morex T-3460 60W
Первым делом я определил для себя круг задач, которые будет выполнять маршрутизатор, чтобы в дальнейшем мне было проще его админить.

Ещё раз уточню, что эти ваши интернеты приходят ко мне по 100 Мбитному каналу (тариф, естественно, даёт несколько меньшую скорость, но не суть). Получилось, собственно, вот что:

  • Доступ в интернет со всех устройств, имеющихся дома в распоряжении +n устройств, появляющихся эпизодически или вообще однократно
  • Домашняя локалка
  • Соответственно, маршрутизация трафика из/в интернет/локальная сеть
  • Файлохранилище (доступ по FTP или Samba)
  • Торрентокачалка
  • ed2k-сеть (ибо очень круто развита у провайдера)
  • web-сервер
В перспективе:
  • домен
  • видеонаблюдение
  • элементы «умного дома»
  • чёрт в ступе много чего интересного
Естественным в этой ситуации было выбирать из *nix-based систем. Некоторое время пришлось потратить на изучение матчасти, рыская по сети. В итоге я проделал следующий путь…
1. FreeBSD 10.1-RELEASE
Очень хотелось реализовать всё на фряхе. Плюсы её в управлении сетевыми устройствами, серверами/шлюзами/маршрутизаторами очевидны, неоспоримы и многократно воспеты гуру. Поскольку ранее дел я с фряхой близко не имел, пришлось круто раскурить Руководство по FreeBSD, сопровождая процесс чтения параллельным процессом установки на устройство последнего стабильного релиза 10.1.Небольшое отступлениеК слову, установку фряхи (да и всех описываемых далее систем) я производил при помощи замечательного устройства Zalman ZM-VE300 с терабайтным HDD внутри; сие устройство имеет на борту эмулятор оптического привода, что позволяет накидать на жёсткий диск в папку _iso образы, после чего, установив в BIOS загрузку с Zalman Virtual CD, производить загрузку и установку с этих самых образов, всё равно что, если бы они были записаны на болванку и вставлены в физический привод. Всё было замечательно, система встала, но меня ждал неприятный сюрприз, о котором я, откровенно говоря, знал, но решил-таки проверить на практике: FreeBSD напроч отказывалась видеть Wi-Fi карточку. Вернее видеть-то она её видела, но только адрес и название вендора, а что это и с чем её едят, фряха понимать не желала (драйвер устройства значился как none1). Кроме того, дальнейшее чтение мануала выявило, что в режиме точки доступа во FreeBSD работают только Wi-Fi карты на основе набора микросхем Prism. Печальбеда... Да, нашёл я также и информацию, что моя карточка в настоящий момент вообще не имеет драйвера под фряху. Даже портированного.
10. Debian 7.7.0

Расстраивался я недолго: не состоялась фряха — возьму старый добрый Debian. Установил с netinstall-образа базовую систему без графического окружения. Долго пытался понять, что не так. Стабильный релиз Debian в данный момент 7.7.0, имеет ядро версии 3.2. В этом ядре опять же нет поддержки моей многострадальной Wi-Fi сетевушки. Полез на ЛОР искать ответ, в итоге получил неутешительные выводы: надо ставить ядро посвежее (в случае Debian — тот ещё геморрой), пляски с бубном ядрами, по мнению гуру, не труъ Debian-way (так прямо и сказали: хочешь перекомпилять ядра — выбери другой дистрибутив).

11. Ubuntu Server 14.04 LTS

Плюнув на попытки круто провести время покрасноглазить, я взял знакомый и уважаемый мной дистрибутив. Уже более года он (правда версии 12.04 LTS) вертится у меня на сервере, раздающем плюшки в сети провайдера.

Из плюсов: стабильность, простота установки, настройки и администрирования, куча документации. Из минусов: необходимость дорабатывать напильником, поскольку «искаропки» получается толстоват и несколько неповоротлив.

Установка По сути не представляет ничего сложного и аналогична таковой в Debian. Производится в диалоговом режиме text-mode. Описывать детально не вижу смысла, т.к. всё это уже десятки раз пережёвано и валяется на множестве ресурсов (начиная с официальных сайтов на разных языках и заканчивая местечковыми форумами).

Важным моментом является правильная разметка и подготовка SSD. Всем прекрасно известно, что твердотельные накопители построены на технологии flash-памяти и имеют ограниченный ресурс на запись. Справедливости ради отмечу, что на просторах всемирной паутины глаголят о достаточной надёжности современных твердотельников (сравнимой с классическими жёсткими дисками). Тем не менее было бы глупо плевать на элементарные рекомендации в отношении эксплуатации SSD.

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

Первой необходимой манипуляцией при разметке накопителя является выравнивание разделов диска. Если кратко, то каждый раздел должен начинаться с сектора кратного 8. Первый раздел рекомендовано начинать с 2048 сектора (это связано с расположением в начале накопителя MBR или GPT, а «отступ» в 1 Мб берётся с запасом.

При разметке я создал 3 раздела:

  • boot — ext2
  • root — ext4
  • home — ext4
$ sudo fdisk -l Диск /dev/sda: 120.0 Гб, 120034123776 байт 255 головок, 63 секторов/треков, 14593 цилиндров, всего 234441648 секторов Units = секторы of 1 * 512 = 512 bytes Размер сектора (логического/физического): 512 байт / 4096 байт I/O size (minimum/optimal): 4096 bytes / 4096 bytes Идентификатор диска: 0x000ea779 Устр-во Загр Начало Конец Блоки Id Система /dev/sda1 * 2048 1050623 524288 83 Linux /dev/sda2 1050624 42993663 20971520 83 Linux /dev/sda3 42993664 234440703 95723520 83 Linux Как видно, все разделы начинаются с секторов, кратных 8. Таким образом доступ будет осуществляться с обращением по правильному сектору, что поможет сберечь нежный ресурс накопителя.

Далее в опциях монтирования разделов в /etc/fstab следует добавить discard — для включения TRIM и noatime — для отключения записи в метаданные времени последнего доступа к файлу.

Очередное отступление

С noatime не всё так однозначно. Например, в десктопных системах браузеры отслеживают «свежесть» своего кэша именно по времени последнего доступа, таким образом, включение данной опции влечёт за собой не уменьшение записи на диск, а наоборот — увеличение, поскольку браузер видит, что его кэш «протух» и начинает подтягивать новый. В этом случае рекомендуется использовать опцию relatime — атрибут времени доступа (atime) обновляется, но только в том случае, если изменились данные файла (атрибут mtime) или его статус (атрибут ctime). Для серверной системы это, пожалуй, не столь критично, но всё же я включил noatime для boot, а для root и home — relatime.

Все остальные советы, нагугленные на просторах сети, как то увеличение времени между сбросами буферов на диск (опция commit=[time, sec.]), отключение «шлагбаума» (опция barrier=0) и прочее не внушили мне доверия в плане приобретаемой полезности в ущерб сохранности данных и безопасности. Кроме того, я не стал выделять отдельный раздел для swap, решив, что оперативной памяти мне должно хватить для поставленных задач. Если же всё-таки возникнет необходимость в подкачке, ничто не мешает сделать swap в виде файла и смонтировать его как раздел.

Также было принято волевое решение вынести временные файлы (/tmp) в tmpfs.

В процессе установки задаются общие параметры, как то: локаль, параметры времени/геопозиции, имя системы, а также создаётся новый юзер и пароль к нему. Далее следует выбор устанавливаемого программного обеспечения, в котором я пометил для установки следующее:

  • OpenSSH server
  • DNS server
  • LAMP server
  • Print server
  • Samba file server
После загрузки в свежеустановленную систему проявилась одна крайне неприятная особенность (кстати, в Debian было то же самое): после инициализации драйверов вырубалось видео, монитор переходил в режим ожидания, и становилось непонятно система зависла или просто что-то не так с выводом. Обнаружилось, что доступ по ssh есть, и можно было бы на этом остановиться, но всегда может возникнуть ситуация, когда необходимо получить физический доступ к маршрутизатору (например, шаловливые ручонки админа поковырялись в настройках сети, и доступ через консоль категорически пропал %) ). Посёрфиф по форумам я наткнулся на решение (оказывается баг известен и проявляется именно на этой материнской плате):add to /etc/modprobe.d/blacklist.conf: blacklist gma500_gfx

run sudo update-initramfs -u sudo reboot

Пруф. В случае с Debian — /etc/modprobe.d/fbdev-blacklist.conf. После перезагрузки всё заработало.Настройка сети В процессе установки системы я выбрал в качестве сетевого интерфейса, который будет использован для установки, карту D-Link. Она уменя была подключена патчкордом к одному из LAN моего старого маршрутизатора (это было сделано для того, чтобы иметь доступ по SSH до настройки сетевых интерфейсов, а поскольку на Асусе также запущен DHCP-сервер, проблем с подключением не возникло), тестировать при таком подключении доступ в интернет не составит никаких проблем. Также в свежей системе проявился ещё один глюк:no talloc stackframe at ../source3/param/loadparm.c:4864, leaking memory Проблема связана с библиотекой авторизации libpam-smbpass, можно просто её снести, а можно поступить более изящно:$ sudo pam-auth-update снять пометку с SMB password synchronization, что отключает синхронизацию паролей системных пользователей и пользователей Samba. Устанавливаем все доступные обновления:$ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get dist-upgrade И приступаем к настройке сетевых интерфейсов. В маршрутизаторе 4 физических интерфейса и loopback:Вывод терминала$ ifconfig -a em0 Link encap:Ethernet HWaddr 00:22:4d:ad:69:f0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:17 Память:d0220000-d0240000 eth0 Link encap:Ethernet HWaddr d8:fe:e3:a7:d5:26 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::dafe:e3ff:fea7:d526/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:741 errors:0 dropped:0 overruns:0 frame:0 TX packets:477 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:482523 (482.5 KB) TX bytes:45268 (45.2 KB) eth2 Link encap:Ethernet HWaddr 00:22:4d:ad:69:ec UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:16 Память:d0320000-d0340000 lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:28 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1784 (1.7 KB) TX bytes:1784 (1.7 KB) wlan0 Link encap:Ethernet HWaddr 80:19:34:1e:fe:83 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
  • eth0 — «смотрит» в интернет, получает настройки по DHCP
  • eth2 и em0 — интегрированные в материнку сетевые адаптеры
  • wlan0 — как нетрудно догадаться, беспроводной интерфейс Wi-Fi
Устанавливаем hostapd и переводим беспроводной интерфейс в режим Master:$ sudo iwconfig wlan0 mode Master К моему величайшему сожалению такой способ не сработал, и команда вывалилась с ошибкой, поэтому я прибегнул к альтернативному способу:$ sudo apt-get install iw $ sudo iw dev wlan0 del $ sudo iw phy phy0 interface add wlan0 type __ap После чего:$ iwconfig wlan0 IEEE 802.11abgn Mode:Master Tx-Power=0 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:on Теперь необходимо сконфигурировать все сетевые интерфейсы, чтобы было удобнее с ними работать. Я решил объединить встроенные сетевушки и Wi-Fi в мост, чтобы управлять этим хозяйством как единым целым при раздаче IP-адресов по DHCP, маршрутизации и пр. Приводим к следующему виду /etc/network/interfaces:/etc/network/interfaces# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet dhcp auto wlan0 br0 # The wireless interface iface wlan0 inet manual pre-up iw dev wlan0 del pre-up iw phy phy0 interface add wlan0 type __ap # The bridge iface br0 inet static address 192.168.0.1 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 bridge_ports em0 eth2 wlan0 Перезагружаемся. Теперь видим:Вывод терминала$ ifconfig -a br0 Link encap:Ethernet HWaddr 00:22:4d:ad:69:ec inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) em0 Link encap:Ethernet HWaddr 00:22:4d:ad:69:f0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:17 Память:d0220000-d0240000 eth0 Link encap:Ethernet HWaddr d8:fe:e3:a7:d5:26 inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::dafe:e3ff:fea7:d526/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1329 errors:0 dropped:0 overruns:0 frame:0 TX packets:819 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:531178 (531.1 KB) TX bytes:125004 (125.0 KB) eth2 Link encap:Ethernet HWaddr 00:22:4d:ad:69:ec UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:16 Память:d0320000-d0340000 lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:28 errors:0 dropped:0 overruns:0 frame:0 TX packets:28 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1784 (1.7 KB) TX bytes:1784 (1.7 KB) wlan0 Link encap:Ethernet HWaddr 80:19:34:1e:fe:83 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Инициализировались все интерфейсы. Можно приступить к настройке hostapd. Пока мы тут рассуждали, версия стала, таки, 2.1. У меня получился вот такой конфиг /etc/hostapd/hostapd.conf:hostapd.confinterface=wlan0 bridge=br0 driver=nl80211 logger_syslog=-1 logger_syslog_level=4 logger_stdout=-1 logger_stdout_level=4 ssid=TEST hw_mode=g ieee80211n=1 ht_capab=[HT40-][SHORT-GI-40] channel=11 macaddr_acl=0 deny_mac_file=/etc/hostapd/hostapd.deny auth_algs=3 ignore_broadcast_ssid=1 ap_max_inactivity=300 wpa=2 wpa_passphrase=my_wpa_passphrase wpa_key_mgmt=WPA-PSK rsn_pairwise=CCMP Включаем автоматический запуск hostapd при загрузке системы, для этого в /etc/default/hostapd раскомментируем и редактируем строки:DAEMON_CONF="/etc/hostapd/hostapd.conf" DAEMON_OPTS="-B" RUN_DAEMON="yes" Далее, не мудрствуя лукаво, я настроил общий доступ. Скрипт для настройки iptables и ip-форвардинга я взял отсюда, привёл его в соответствие своим реалиям и настроил автозапуск. В результате iptables наполняются необходимым содержимым при загрузке системы. Логично, что нужно текже настроить DHCP-сервер. Решив упростить задачу до минимума, я установил dnsmasq и снёс имеющийся в наличии и конфликтующий с ним bind9. Конфиг прост:/etc/dnsmasq.conf# Configuration file for dnsmasq. # # Format is one option per line, legal options are the same # as the long options legal on the command line. See # "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details. # Never forward plain names (without a dot or domain part) domain-needed # Never forward addresses in the non-routed address spaces. bogus-priv # If you want dnsmasq to listen for DHCP and DNS requests only on # specified interfaces (and the loopback) give the name of the # interface (eg eth0) here. # Repeat the line for more than one interface. interface=br0 # This is an example of a DHCP range where the netmask is given. This # is needed for networks we reach the dnsmasq DHCP server via a relay # agent. If you don't know what a DHCP relay agent is, you probably # don't need to worry about this. dhcp-range=192.168.0.2,192.168.0.254,255.255.255.0,12h # Give a host with Ethernet address 11:22:33:44:55:66 or # 12:34:56:78:90:12 the IP address 192.168.0.60. Dnsmasq will assume # that these two Ethernet interfaces will never be in use at the same # time, and give the IP address to the second, even if it is already # in use by the first. Useful for laptops with wired and wireless # addresses. #dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.60 dhcp-host=00:11:22:33:44:55,66:77:88:99:aa:bb,MyDevice1,192.168.0.2 dhcp-host=cc:dd:ee:ff:ee:dd,cc:bb:aa:99:88:77,MyDevice2,192.168.0.3 На самом деле в конфиге ещё куча закомментированных опций, которые позволяют производить очень fine tuning, но такого набора вполне хватает для корректной работы. В принципе, с этого момента аппарат уже работает как домашний маршрутизатор. После окончания основной настройки я установил и настроил transmission-daemon, aMuled и vsftpd. Собственно говоря, настройка данных сервисов достаточно тривиальна, останавливаться детально на ней не буду. Естественно, доступ к данным ресурсам имеется только из локальной сети, если хочется получить доступ извне, необходимо будет открыть соответствующие порты в iptables. Вёб-сервер представляет из себя связку Apache 2.4.7 + MySQL Ver 14.14 Distrib 5.5.40. Пока не придумал, чем буду его заполнять: накатить готовый движок и баловаться с дизайном или же просто попрактиковаться в html и php. В любом случае сие имеет для меня прикладное значение. Возможно, в перспективе получится настроить вёб-интерфейс для мониторинга и управления маршрутизатором. После всех манипуляций остаётся настроить ведение логов: по возможности привести настройки всех процессов, ведущих логи, выводить в них только критически важные уведомления и предупреждения. Идея заключается в снижении количества операций записи, а, соответственно, и негативного влияния на SSD. Кроме того, следует настоятельно рекомендуется включить запуск по cron раз в сутки fstrim (для каждого раздела отдельно). Говорят, хуже не будет точно.

Ффух… Получилось несколько сумбурное описание моих мытарств с собственноручно собранным устройством, но удовлетворение от того, что всё работает просто неописуемо.

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

  • процессор Intel Atom D2500 — до 10 Вт
  • SSD-накопитель Crucial M500 — 3,6 Вт
По остальным крмплектующим данных сходу не нашлось, но практически везде в характеристиках сетевой карты и Wi-Fi модуля пишут «низкое энергопотребление». Если грубо накинуть на всё про всё 10 Вт (прочее железо, интегрированные сетевушки, etc), то итого получается около 25 Вт — не так уж и много, полагаю…

Вроде бы ничего не забыл, упомянул все ключевые моменты. За подробностями прошу в комментарии. Спасибо за внимание! (-;

UPD: Господин Revertis справедливо заметил, и я с ним соглашусь, что изначально при установке системы не следовало отмечать DNS-сервер, чтобы потом его сносить (речь о bind9), но в статье я описывал именно путь, который проделал — со всеми его ошибками и закоулками. И да, соглашусь, что nginx лучше, чем Apache, более того — я его даже заменю. Спасибо за совет.

habr.com

прерывания, маршрутизатор и NAT-сервер / Хабр

Написано по следам публикации Большие потоки трафика и управление прерываниями в Linux

В нашей городской сети более 30 тысяч абонентов. Суммарный объем внешних каналов — более 3 гигабит. А советы, данные в упомянутой статье, мы проходили еще несколько лет назад. Таким образом, я хочу шире раскрыть тему и поделиться с читателями своими наработками в рамках затрагиваемого вопроса.

В заметке описываются нюансы настройки/тюнинга маршрутизатора и NAT-сервера под управлением Linux, а также приведены некоторые уточнения по поводу распределения прерываний.

Прерывания

Раскидывание прерываний сетевых карт по разным ядрам — это самое первое, с чем сталкивается сисадмин при возрастании нагрузки на linux-маршрутизатор. В упомянутой статье тема освещена достаточно подробно — поэтому надолго останавливаться на этом вопросе мы не будем.

Хочу только отметить:

  • если вы вручную раскидываете прерывания, то вам необходимо остановить сервис irqbalance. Этот сервис предназначен как раз для автоматического регулирования прерываний между ядрами процессоров. Если вы делаете эту работу вручную — сервис лучше остановить;
  • не забудьте внести соответствующие правки в «автозагрузку» (например, /etc/rc.local) — т.к. после рестарта сервера все прерывания опять распределятся вкучку на одном ядре;
  • после рестарта сервера, сетевые карты могут получить (а скорее всего, именно так и будет) новые номера прерываний. Поэтому в /etc/rc.local лучше не вписывать руками конкретные номера прерываний — а автоматизировать с помощью вспомогательного скрипта распознавание, какая сетевая какое прерывание заняла.
Маршрутизатор

В первоначальной статье есть фраза «если сервер работает только маршрутизатором, то тюнинг TCP стека особого значения не имеет». Это утверждение в корне неверно. Конечно, на небольших потоках тюнинг не играет большой роли. Однако, если у вас большая сеть и соответствующая нагрузка — то тюнингом сетевого стека вам придется заняться.

Прежде всего, если по вашей сети «гуляют» гигабиты, то имеет смысл обратить свое внимание на MTU на ваших серверах и коммутаторах. В двух словах, MTU — это объем пакета, который можно передать по сети, не прибегая к его фрагментации. Т.е. сколько информации ваш один маршрутизатор может передать другому без фрагментирования. При значительном увеличении объемов передаваемых по сети данных, гораздо эффективнее передавать пакеты большего объема реже, — чем часто-часто пересылать мелкие пакеты данных.

Увеличиваем MTU на linux

/sbin/ifconfig eth0 mtu 9000

Увеличиваем MTU на коммутаторах

На коммутационном оборудовании обычно это будет называться jumbo-frame. В частности, для Cisco Catalyst 3750

3750(config)# system mtu jumbo 9000 3750(config)# exit 3750# reload

Заметьте: коммутатор затем надо перезагрузить. Кстати, mtu jumbo касаются только гигабитных линков, — 100-мбит такая команда не затрагивает.

Увеличиваем очередь передачи на linux

/sbin/ifconfig eth0 txqueuelen 10000

По умолчанию значение стоит 1000. Для гигабитных линков рекомендуется ставить 10000. В двух словах, это размер буфера передачи. Когда буфер наполняется до этого граничного значения, данные передаются в сеть.

Имейте ввиду, что если вы меняете размер MTU на интерфейсе какой-то железки — вы должны сделать то же самое и на интерфейсе её «соседа». Т.е., если вы увеличили MTU до 9000 на интерфейсе linux-роутера, то вы должны включить jumbo-frame на порту коммутатора, в который данный роутер включен. В противном случае сеть работать будет, но очень плохо: пакеты ходить по сети будут «через одного».

Итоги

В результате всех этих изменений, в сети возрастут «пинги» — но общая пропускная способность заметно возрастет, а нагрузка на активное оборудование снизится.

Сервер NAT

Операция NAT (Network Address Translation) является одной из самых дорогостоящих (в смысле, ресурсоёмких). Поэтому, если у вас большая сеть, без тюнинга NAT-сервера вам не обойтись.

Увеличение кол-ва отслеживаемых соединений

Для осуществления своей задачи, NAT-серверу необходимо «помнить» обо всех соединениях, которые через него проходят. Будь то «пинг» или чья-то «аська» — все эти сессии NAT-сервер «помнит» и отслеживает у себя в памяти в специальной таблице. Когда сессия закрывается, информация о ней из таблицы удаляется. Размер этой таблицы фиксирован. Именно поэтому если трафика через сервер идет достаточно много, а размера таблицы нехватает, — то NAT-сервер начинает «дропать» пакеты, рвать сессии, интернет начинает работать с жуткими перебоями, а на сам NAT-сервер бывает даже попасть по SSH становится просто невозможно.

Чтобы таких ужасов не происходило, необходимо адекватно увеличивать размер таблицы — в соответствии с проходящим через NAT трафиком:

/sbin/sysctl -w net.netfilter.nf_conntrack_max=524288

Настоятельно НЕ рекомендуется ставить такое большое значение, если у вас на NAT-сервере меньше 1 гигабайта оперативной памяти.

Посмотреть текущее значение можно вот так:

/sbin/sysctl net.netfilter.nf_conntrack_max

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

/sbin/sysctl net.netfilter.nf_conntrack_count

Увеличение размера hash-таблицы

Пропорционально должная быть увеличена и хэш-таблица, в которой хранятся списки conntrack-записей.

echo 65536 > /sys/module/nf_conntrack/parameters/hashsize

Правило простое: hashsize = nf_conntrack_max / 8

Уменьшение значений time-out

Как вы помниите, NAT-сервер отслеживает только «живые» сессии, которые через него проходят. Когда сессия закрывается — информация о ней удаляется, дабы таблица не переполнялась. Информация о сессиях удаляется так же по тайм-ауту. Т.е., если втечение долгого времени в рамках соединения обмена траифка нет — оно закрывается и информация о нем так же удаляется из памяти NAT-а.

Однако, по умолчанию значения тайм-аутов стоят достаточно большие. Поэтому, при больших потоках трафика даже если вы растянете nf_conntrack_max до предела — вы все равно рискуете быстро столкнуться с переполнением таблицы и разрывами соединений.

Чтобы такого не произошло, необходимо грамотно выставить тайм-ауты отслеживания соединений на NAT-сервере.

Текущие значения можно посмотреть, например, так:

sysctl -a | grep conntrack | grep timeout

В результате вы увидите что-то подобное:

net.netfilter.nf_conntrack_generic_timeout = 600 net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120 net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60 net.netfilter.nf_conntrack_tcp_timeout_established = 432000 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_close = 10 net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300 net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300 net.netfilter.nf_conntrack_udp_timeout = 30 net.netfilter.nf_conntrack_udp_timeout_stream = 180 net.netfilter.nf_conntrack_icmp_timeout = 30 net.netfilter.nf_conntrack_events_retry_timeout = 15

Это значения тайм-аутов в секундах. Как вы видите, значение net.netfilter.nf_conntrack_generic_timeout равно 600 (10 минут). Т.е. NAT-сервер будет держать в памяти информацию о сессии до тех пор, пока по ней будет «пробегать» хоть что-то хотя бы раз в 10 минут.

На первый взгляд, ничего страшного — но на самом деле это очень и очень много.

Если вы посмотрите на net.netfilter.nf_conntrack_tcp_timeout_established — то вы увидите там значение 432000. Другими словами, простую TCP-сессию ваш NAT-сервер будет отслеживать до тех пор, пока по ней не пробегает какой-нибудь пакетик хотя бы раз в 5 дней(!).

Говоря еще более простым языком, за-DDOS'ить такой NAT-сервер становится проще простого: его NAT-таблица (параметр nf_conntrack_max) переполняется «на ура» простейшим флудом — вследствие чего он будет рвать соединения и в худшем варианте быстро превратится в черную дыру.

Значения тайм-аутов рекомендуется ставить в пределах 30-120 секунд. Этого вполне достаточно для нормальной работы абонентов, и этого вполне хватит для своевременной очистки NAT-таблицы, исключающей её переполнение.

И не забудьте вписать соответствующие изменения в /etc/rc.local и /etc/sysctl.conf

Итоги

После тюнинга вы получите вполне жизнеспособный и производительный NAT-сервер. Конечно же, это только «базовый» тюнинг — мы не касались, например, тюнинга ядра и т.п. вещей. Однако, в большинстве случаев даже таких простых действий будет достаточно для нормальной работы достаточно большой сети. Как я уже говорил, в нашей сети более 30 тыс. абонентов, трафик которых обрабатывают 4 NAT-сервера.

В следующих выпусках:

  • большие потоки и высокопроизводительный шейпер;
  • большие потоки и высокопроизводительный файрвол.

habrahabr.ru

Настройка основного и двух резервных операторов на Linux-роутере с NetGWM

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

В статье об отказоустойчивом роутере мы вскользь упоминали свой корпоративный стандарт для решения этой задачи — Open Source-продукт NetGWM — и обещали рассказать об этой утилите подробнее. Из этой статьи вы узнаете, как устроена утилита, какие «фишки» можно использовать в работе с ней и почему мы решили отказаться от использования альтернативных решений.

Почему NetGWM?

Классическая схема резервирования основного шлюза в Linux, реализуемая средствами iproute2, выглядит практически во всех источниках примерно одинаково:
  • Дано: 2 провайдера.
  • Создаем для каждого оператора свою таблицу маршрутизации.
  • Создаем правила (ip rule), по которым трафик попадает в ту или иную таблицу маршрутизации (например, по источнику и/или по метке из iptables).
  • Метриками или ifupdown-скриптами определяем приоритет основного шлюза.
Подробности этой схемы легко гуглятся по запросу «linux policy routing». На наш взгляд, схема имеет ряд очевидных недостатков, которые и стали основным мотиватором создания утилиты NetGWM:
  1. Сложность внесения изменений в схему, плохая управляемость.
  2. Если количество шлюзов 3 и более, логика скриптов усложняется, как и реализация выбора шлюза на основе метрик.
  3. Проблема обнаружения пропадания канала. Зачастую, физический линк и даже шлюз оператора могут быть доступны, при этом из-за проблем внутри инфраструктуры оператора или у его вышестоящего поставщика услуг реально сеть оказывается недоступной. Решение этой проблемы требует добавление дополнительной логики в ifupdown-скрипты, а в маршрутизации на основе метрик она нерешаема в принципе.
  4. Проблема «шалтай-болтай». Такая проблема проявляется, если на высокоприоритетном канале наблюдаются кратковременные частые перерывы в связи. При этом шлюз успешно переключается на резервный. Откуда здесь, казалось бы, может взяться проблема? Дело в том, что ряд сервисов, таких как телефония, видеосвязь, VPN-туннели и другие, требуют некоторого таймаута для определения факта обрыва и установления нового сеанса. В зависимости от частоты обрывов это приводит к резкому снижению качества сервиса или его полной недоступности. Решение этой проблемы также требует усложнения логики скриптов и тоже совершенно нерешаема метриками.
Мы посмотрели, что поможет нам решить все 4 проблемы: простое и управляемое средство с поддержкой 2 и более шлюзов по умолчанию, умеющее диагностировать доступность канала и тестировать его на стабильность. И не нашли такого варианта. Именно так и появился NetGWM.

Установка из GitHub и репозитория «Флант»

NetGWM (Network GateWay Manager) — это небольшая утилита приоритезации основного шлюза, написанная на Python и распространяемая под свободной лицензией GNU GPL v3. Автор первоначальной версии — driusha (Андрей Половов).

Исходный код и документация на английском языке доступны на GitHub, а краткая документация и описание на русском языке — здесь.

Установка из GitHub:

## Предварительно в системе требуется установить: ## iproute2, conntrack, модуль python-yaml ## После этого клонируем репозиторий: $ git clone git://github.com/flant/netgwm.git netgwm ## И устанавливаем (понадобятся права суперпользователя): $ cd netgwm && sudo make install ## Добавим служебную таблицу маршрутизации, которая будет использоваться NetGWM $ sudo sh -c "echo '100 netgwm_check' >> /etc/iproute2/rt_tables" ## Добавляем в cron пользователя root вызов netgwm с той частотой, ## с которой вам бы хотелось проверять доступность основного шлюза ## (например, раз в минуту): $ sudo crontab -e */1 * * * * /usr/lib/netgwm/newtgwm.py Кроме того, готовый DEB-пакет с NetGWM можно установить из репозитория для Ubuntu компании «Флант». Установка для Ubuntu 14.04 LTS выглядит так:## Установим репозиторий: $ sudo wget https://apt.flant.ru/apt/flant.trusty.common.list \ -O /etc/apt/sources.list.d/flant.common.list ## Импортируем ключ: $ wget https://apt.flant.ru/apt/archive.key -O- | sudo apt-key add - ## Понадобится HTTPS-транспорт — установите его, если не сделали это раньше: $ sudo apt-get install apt-transport-https ## Обновим пакетную базу и установим netgwm: $ sudo apt-get update && sudo apt-get install netgwm Добавлять служебную таблицу маршрутизации и настраивать cron в Ubuntu не потребуется. Таблица автоматически добавится при установке пакета. Кроме того, при установке будет зарегистрирована служба netgwm, init-скрипт которой стартует в качестве демона небольшой shell-скрипт /usr/bin/netgwm, который, в свою очередь, читает из файла /etc/default/netgwm значение параметра INTERVAL (в секундах) и с указанной периодичностью сам вызывает netgwm.py.

Настройка

В основе работы NetGWM также лежит policy-роутинг, и нам придется предварительно настроить таблицы маршрутизации для каждого оператора.

Допустим, есть 3 оператора, и необходимо сделать так, чтобы основным оператором был оператор 1, в случае отказа — использовался оператор 2, а в случае отказа из обоих — оператор 3.

Пусть первый оператор у нас подключен к интерфейсу eth2, второй — к eth3, третий — к eth4. Первый оператор имеет шлюз 88.88.88.88, второй оператор — шлюз 99.99.99.99, третий — 100.100.100.100.

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

Настроим маркинг пакетов и conntrack:

iptables -t mangle -A PREROUTING -i eth2 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x1/0x3 iptables -t mangle -A PREROUTING -i eth3 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x2/0x3 iptables -t mangle -A PREROUTING -i eth4 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x3/0x3 iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff iptables -t mangle -A OUTPUT -o eth2 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x1/0x3 iptables -t mangle -A OUTPUT -o eth3 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x2/0x3 iptables -t mangle -A OUTPUT -o eth4 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x3/0x3 iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff iptables -t mangle -A POSTROUTING -o eth2 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x1/0x3 iptables -t mangle -A POSTROUTING -o eth3 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x2/0x3 iptables -t mangle -A POSTROUTING -o eth4 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-xmark 0x3/0x3 iptables -t mangle -A POSTROUTING -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff 2. Добавим правила маршрутизации для промаркированных пакетов. Мы это делаем с помощью скрипта, который вызывается из /etc/network/interfaces при событии post-up на интерфейсе lo:#!/bin/bash /sbin/ip rule flush # operator 1 /sbin/ip rule add priority 8001 iif eth2 lookup main /sbin/ip rule add priority 10001 fwmark 0x1/0x3 lookup operator1 /sbin/ip rule add from 88.88.88.88 lookup operator1 # operator 2 /sbin/ip rule add priority 8002 iif eth3 lookup main /sbin/ip rule add priority 10002 fwmark 0x2/0x3 lookup operator2 /sbin/ip rule add from 99.99.99.99 lookup operator2 # operator 3 /sbin/ip rule add priority 8002 iif eth4 lookup main /sbin/ip rule add priority 10002 fwmark 0x3/0x3 lookup operator3 /sbin/ip rule add from 100.100.100.100 lookup operator3 3. Объявим таблицы маршрутизации в /etc/iproute2/rt_tables:# Зарезервированные значения: 255 local 254 main 253 default 0 unspec # Служебная таблица, которую мы (или dpkg) добавили ранее: 100 netgwm_check # Таблицы для операторов, которые мы должны добавить сейчас: 101 operator1 102 operator2 103 operator3 4. Настроим NetGWM. По умолчанию, netgwm.py будет искать конфигурационный файл по адресу /etc/netgwm/netgwm.yml, однако вы можете переопределить это с помощью ключа -c. Настроим работу утилиты:# Описываем маршруты по умолчанию для каждого оператора и приоритеты # Меньшее значение (число) имеет больший приоритет. 1 - самый высокий приоритет # Обратите внимание, что для смены шлюза по умолчанию на другой достаточно просто # изменить значения приоритетов в этом файле. И уже при следующем запуске (через # минуту в нашем случае) шлюз изменится на более приоритетный (если он доступен). # Наименование оператора должно совпадать с именем таблицы маршрутизации из # /etc/iproute2/rt_tables gateways: operator1: {ip: 88.88.88.88, priority: 1} operator2: {ip: 99.99.99.99, priority: 2} operator3: {ip: 100.100.100.100, priority: 3} # Этот параметр решает проблему «шалтай-болтай», когда приоритетного # оператора (из доступных) «штормит». # Параметр определяет время постоянной доступности (в секундах), # после которого netgwm будет считать, что связь стабильна min_uptime: 900 # Массив удаленных хостов, которые будут использоваться netgwm для # проверки работоспособности каждого оператора. Здесь стоит указать либо важные # для вас хосты в интернете, либо общедоступные и стабильно работающие ресурсы, # как сделано в примере. Шлюз считается недоступным, если netgwm НЕ СМОГ # установить через него связь до ВСЕХ (условие AND) указанных хостов check_sites: - 8.8.8.8 # Google public DNS - 4.2.2.2 # Verizon public DNS # По умолчанию netgwm проверяет доступность только для самого # приоритетного шлюза. Если тот недоступен — до второго по приоритетности и т.д. # Данная опция, будучи установленной в true, заставит netgwm проверять # доступность всех шлюзов при каждом запуске check_all_gateways: false 5. Настроим действия при переключении

Если произойдет переключение, то после смены основного шлюза будут выполнены все исполняемые файлы из каталога /etc/netgwm/post-replace.d/*. При этом каждому файлу будут переданы 6 параметров командной строки:

  • $1 — наименование нового оператора;
  • $2 — IP вновь установленного шлюзе или NaN, если новый шлюз установить не удалось;
  • $3 — имя устройства нового шлюза или NaN, если шлюз установить не удалось;
  • $4 — наименование старого оператора или NaN, если шлюз устанавливается впервые;
  • $5 — IP старого оператора или NaN, если шлюз устанавливается впервые;
  • $6 — имя устройства старого оператора или NaN, если шлюз устанавливается впервые.
В скрипте можно на основании этих переменных описать логику действий в зависимости от подключаемого оператора (добавить или удалить маршруты, отправить уведомления, настроить шейпинг и т.п.). Для примера приведу скрипт на shell, отправляющий уведомления:#!/bin/bash # Определяем, что произошло: переключение или старт netgwm if [ "$4" = 'NaN' ] && [ "$5" = 'NaN' ] then STATE='start' else STATE='switch' fi # Отправляем уведомление дежурным инженерам о произошедшем case $STATE in 'start') /usr/bin/flant-integration --sms-send="NetGWM on ${HOSTNAME} has been started and now use gw: $1 - $2" ;; 'switch') /usr/bin/flant-integration --sms-send="NetGWM on ${HOSTNAME} has switched to new gw: $1 - $2 from gw: $4 - $5" ;; *) /usr/bin/logger -t netgwm "Unknown NetGWM state. Try restarting service fo fix it." ;; esac exit 6. Стартуем сервис netgwm в Ubuntu, если вы установили DEB-пакет:$ sudo service netgwm start Если вы получили NetGWM из GitHub, то установленное ранее задание в cron уже и так проверяет доступность вашего основного шлюза, дополнительных действий не требуется.

Журналирование

События по переключению NetGWM регистрирует в журнале /var/log/netgwm:$ tail -n 3 /var/log/netgwm.log 2017-07-14 06:25:41,554 route replaced to: via 88.88.88.88 2017-07-14 06:27:09,551 route replaced to: via 99.99.99.99 2017-07-14 07:28:48,573 route replaced to: via 88.88.88.88 Сохраненная история переключений помогает произвести анализ инцидента и определить причины перерыва в связи.

Проверено в production

Уже около 4 лет NetGWM используется в нашей компании на 30+ маршрутизаторах Linux разных масштабов. Надежность утилиты многократно проверена в работе. Для примера, на одной из инсталляций, с мая 2014 года NetGWM обработал 137 переключений операторов без каких-либо проблем.

Стабильность, покрытие всех наших потребностей и отсутствие проблем в эксплуатации в течение длительного времени привели к тому, что мы практически не занимаемся развитием проекта. Код NetGWM написан на Python, поэтому отсутствует и необходимость в адаптации утилиты к новым версиям операционных систем. Тем не менее, мы будем очень рады, если вы решите принять участие в развитии NetGWM, отправив свои патчи в GitHub или просто написав feature request в комментариях.

Заключение

С NetGWM мы имеем стабильную, гибкую и расширяемую (с помощью скриптов) утилиту, которая полностью закрывает наши потребности в управлении приоритетом основного шлюза.

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

P.S. Читайте также в нашем блоге: «Наш рецепт отказоустойчивого Linux-роутера» — и подписывайтесь на него, чтобы не пропускать новые материалы!

habr.com

Настраиваем роутер на Linux Ubuntu NAT + DHCP + Squid

[​IMG]​ Linux сервер чаще всего применяют для того, чтобы организовать общий доступ в интернет для определенного количества машин. Отдать предпочтение этой операционной системе можно благодаря ее низкой стоимости и относительно невысоким требованиям к железу. Чаще всего Linux сервер устанавливают первым в организации, а это может вызвать определенные сложности у администраторов, которые ранее не использовали данную операционную систему. В этой статье мы детально опишем настройку роутера (что включает в себя NAT, DHCP, Squid) на базе Ubuntu Server.

Установка и настройка первоначальных параметров.

Ubuntu Server имеет возможность предустановки выбранных ролей сервера, а также отличается от своей настольной версии тем, что в ней отсутствуют пользовательские приложения и графические оболочки GUI, хотя по большому счету это относиться к любой версии Ubuntu, а также с небольшими поправками для любого Linux дистрибутива. Установка Ubuntu Server обычно не вызывает сложностей так как происходит на русском языке в текстовом режиме. Из предложенного списка программного обеспечения, нам нужен только OpenSSH, который используется для удаленного доступа к серверу. Опытный пользователь может без проблем установить все необходимые пакеты при помощи пункта Manual package selection. Но если это первый сервер, который вы настраиваете, то лучше мы установим все необходимые для работы программы позже. Такая последовательность нужна для того, чтобы мы могли успешно справиться с возможными неполадками, которые могут возникнуть в процессе установки, а также это позволит иметь четкое представление о назначении каждого устанавливаемого пакета. Итак, после установки Ubuntu Server система перезагружается и мы видим черный экран командной строки. Конечно администраторов, которые привыкли к консоли Windows, это может слегка удивить, но следует учесть, что все серверные роли Linux настраиваются только через консоль и файлы конфигурации. Вначале следует настроить сетевые соединения. Для этого в консоли вводим:

Код:

sudo nano /etc/network/interfaces [​IMG]​ Данная команда открывает в консольном редакторе nano файл конфигурации с сетевыми интерфейсами, аналогично рисунку. Пока там прописан только один интерфейс eth0, который настроен на работу по DHCP. К eth0 в нашем случае подключен ADSL модем (хотя это может быть любая сеть провайдера), а eth2 смотрит во внутреннюю сеть. На внешнем интерфейсе IP адрес 192.168.1.2, шлюз (ADSL модем) 192.168.1.1, внутренняя сеть находиться в диапазоне 10.0.0.1 – 254. Тогда наши настройки будут выглядеть следующим образом:

Код:

auto eth0 iface eth0 inet static address 192.168.1.2 netmask 255.255.255.0 gateway 192.168.1.1 auto eth2 iface eth2 inet static address 10.0.0.1 netmask 255.255.255.0 Для сохранения изменений нажимаем сочетание клавиш Ctrl+O и для выхода — Ctrl+X. Следующий этап подразумевает настройку DNS, для этого выполняем команду:

Код:

sudo nano /etc/resolv.conf В данном файле нужно указать DNS провайдера или адреса DNS серверов иначе несможете просматривать сайты. OpenDNS:

Код:

#OpenDNS Servers nameserver 208.67.222.222 nameserver 208.67.220.220 Далее сохраняем настройки и перезагружаемся. Также вместо перезагрузки можно перезапустить сетевые службы:

Код:

sudo /etc/init.d/networking restart Попробуйте пингануть любой сайтЕсли пинг проходит значит всё хорошо.

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

Код:

sudo apt-get update А затем обновляем их до актуальной версии:

Код:

sudo apt-get upgrade Следующим этапом устанавливаем файловый менеджер подобный к Norton Commander или Far — Midnight Commander (mc):

Код:

sudo apt-get install mc Для того чтобы запустить Midnight Commander достаточно ввести его короткое имя — mc в консоли. Также для удобства рекомендуем сразу включить встроенный редактор, он намного удобней, чем nano. Для этого выполняем следующее: F9 — Настройки — Конфигурация — Встроенный редактор. Чтобы не бегать к серверу каждый раз, устанавливаем OpenSSH, он помогает удаленно управлять сервером из любого места (например, из дома) по защищенному протоколу:

Код:

sudo apt-get install ssh Для того чтобы подключиться с Windows можно использовать программу PuTTY, а для корректного отображения символов в закладке Window – Translation выбираем кодировку UTF8. Если есть необходимость ограничения доступа к серверу можно дописать в файл /etc/ssh/sshd_config параметр AllowUsers, указав пользователя, который имеет удаленный доступ по SSH, например пользователь admin:Для разрешения доступа группе пользователей используют параметр AllowGroups, а для блокировки доступа определенным группам или пользователям используют DenyGroups и DenyUsers.

Настраиваем NAT

Для того чтобы организовать общий доступ к сети интернет нужно настроить трансляцию сетевых адресов (NAT), это позволяет сетевым службам внутренней сети получить доступ к внешней сети. Для данной настройки достаточно будет выполнить одну команду, правда есть одна особенность: все будет работать только для перезагрузки. На данный момент в Linux нет механизма сохраняющего настройки iptables при перезагрузке сети или сервера. Для устранения данного неудобства мы вынесем эти настройки в отдельный скрипт, который запускается при загрузке системы. Для начала создаем файл скрипта:

Код:

sudo touch /etc/nat Затем открываем его в редакторе Midnight Commander (F4) и вносим следующий текст:

Код:

#!/bin/sh # Включаем форвардинг пакетов echo 1 > /proc/sys/net/ipv4/ip_forward # Разрешаем трафик на loopback-интерфейсе iptables -A INPUT -i lo -j ACCEPT # Разрешаем доступ из внутренней сети наружу iptables -A FORWARD -i eth2 -o eth0 -j ACCEPT # Включаем NAT iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE # Запрещаем доступ снаружи во внутреннюю сеть iptables -A FORWARD -i eth0 -o eth0 -j REJECT Внеся вышеуказанные настройки, сохраняем их (F2), а для автоматического запуска скрипта вновь открываем /etc/network/interfaces и в самом конце файла дописываем:Также не забываем дать нашему скрипту права на исполнение:

Код:

sudo chmod +x /etc/nat Перезапускаем сеть:

Код:

sudo /etc/init.d/networking restart Если нигде небыли допущены ошибки все будет работать. Для того чтобы проверить работоспособность, на машинах внутренней сети укажем в качестве шлюза и DNS адрес нашего роутера: 10.0.0.1 и пропингуем любой внешний адрес, к примеру один из OpenDNS серверов: 208.67.222.222. Вы, наверное, удивитесь — интернет не работает. Почему? Ведь мы указали наш роутер в качестве DNS сервера, а он пока что таким не является. Конечно, можно прописать DNS на клиентской машине, но если внезапно изменяться DNS сервера? Очень неудобно будет каждый раз бегать их перепрошивать. Самым приемлемым решением будет поднять на нашем роутере полноценный DNS сервер, но, как правило, это избыточно, поэтому ограничиваемся простым DNS (а также и DHCP) сервером Dnsmasq.

Код:

sudo apt-get install dnsmasq После выполнения установки открываем /etc/dnsmasq.conf, находим, раскомментируем и вносим изменения в строку, что разрешает серверу принимать DNS запросы из внутренней сети:

Код:

listen-address=127.0.0.1, 10.0.0.1 Перезапускаем DNS сервер:

Код:

sudo /etc/init.d/dnsmasq restart После правильного выполнения вышеуказанных настроек на клиентских машинах начнет работать интернет.

Настраиваем DHCP

Теперь, когда наш сервер начал работу необходимо настроить клиентские машины. Конечно, все нужные параметры можно прописать вручную, но что делать, если клиентских машин слишком много, и они расположены по всему зданию? В этом случае мы и воспользуемся протоколом DHCP. Он позволяет автоматически получать все, необходимые для корректной работы, сетевые настройки. Ранее установленный Dnsmasq и выступит в качестве DHCP сервера, который очень просто настроить. Для этого открываем /etc/dnsmasq.conf и указываем диапазон выдаваемых адресов (в нашем случае 10.0.0.100-150), сетевую маску и время использования IP адреса:

Код:

dhcp-range=10.0.0.100,10.0.0.150,255.255.255.0,12h Адреса DNS сервера и шлюза сервер из системных настроек берет автоматически. Затем еще раз перезапускаем Dnsmasq:

Код:

sudo /etc/init.d/dnsmasq restart После проделанной работы можно выставить на клиенте автоматическое получение IP адреса и убедиться в нормальной работе сервера. Выданные адреса можно посмотреть, выполнив команду:

Код:

cat /var/log/syslog | grep DHCPOFFER [​IMG]​ Все выданные IP адреса и MAC адреса будут перечислены, с указанием кому они присвоены.

Настройка кэширующего прокси-сервера Squid.

В достаточно большой сети некоторая часть трафика повторяется, и часть его иногда достигает 50%. Очень удобно кэшировать часто повторяющиеся запросы, снизив нагрузку на канал, тем самым ускорить выдачу пользователю запрашиваемых страниц и сэкономить входящий трафик. Для выполнения этих задач используем Squid — кэширующий прокси с огромными возможностями.

Код:

sudo apt-get install squid Устанавливаем прокси-сервер и настраиваем его:

Код:

sudo /etc/init.d/squid stop Открываем /etc/squid/squid.conf, находим и корректируем следующие строки, не забыв их раскомментировать: Указываем порт: http_port 3128 transparent Выполняем настройки кэша:

Код:

cache_dir ufs /var/spool/squid 4096 32 256 Указываем внутренние сети, лишние комментируем:

Код:

acl localnet src 10.0.0.0/24 # RFC1918 possible internal network #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network #acl localnet src 192.168.0.0/16 # RFC1918 possible internal network Разрешаем доступ из внутренних сетей (найти и раскомментировать):

Код:

http_access allow localnet Устанавливаем лимит использования памяти:

Код:

memory_pools on memory_pools_limit 50 MB Задаем язык вывода ошибок для пользователя

Код:

error_directory /usr/share/squid/errors/Russian-koi8-r Важное замечание! В версии Ubuntu 9.10 эта строка может выглядеть так, поэтому рекомендуем проверить правильность пути:

Код:

error_directory /usr/share/squid/errors/ru Затем сохраняем файл конфигурации. Теперь строим кэш и запускаем:

Код:

sudo /usr/sbin/squid -z sudo /etc/init.d/squid start Для того чтобы проверить настройки на клиентской машине в браузере указываем использование прокси-сервера с адресом 10.0.0.1 и портом 3128 и убеждаемся что все исправно работает. Теперь остается только настроить работу прокси-сервера, чтобы http трафик заворачивался на Squid автоматом, без прописывания прокси на клиенте. Для этого следует открыть /etc/nat и дописать в конце строку:

Код:

# Заворачиваем http на прокси iptables -t nat -A PREROUTING -i eth2 -d ! 10.0.0.0/24 -p tcp -m multiport --dport 80,8080 -j DNAT --to 10.0.0.1:3128 Перезапускаем сеть:

Код:

sudo /etc/init.d/networking restart Все настройки выполнены, и мы можем наслаждаться работой нашего сервера, который позволяет не только организовать общий доступ к сети интернет, но и кэширует http трафик и DNS запросы, а также раздает клиентским машинам для работы в сети необходимые настройки.

Код:

[B][COLOR="Blue"](C) http://mannix.ru/ubuntu/nastraivaem-router-na-linux-ubuntu-nat-dhcp-squid.html[/COLOR][/B]

 

arhiv.xaker.name

Vyatta Linux-дистрибутив для роутеров | Linuxoid

Статья напечатана в журнале Системный Администратор

В конце февраля 2007 года компания Vyatta анонсировала вторую версию разрабатываемого ей дистрибутива позволяющего превратить обычный ПК в маршрутизатор. Это решение позиционируется как конкурент продуктам нижнего уровня Cisco и Juniper. Что же такого особенного в Vyatta?

Сначала никакого дистрибутива не было. Одной из первых разработок Vyatta был программный пакет Open Flexible Router (OFR), превращающий обычный ПК в маршрутизатор. Причем отмечалось, что производительность работы и уровень безопасности соответствовал коммерческим продуктам. С самого начала курс взят на открытость, так как по мнению разработчиков, это значительно ускоряет устранение возможных недостатков и способствует быстрому развитию продукта и адаптации для всех возможных условий. Кстати Vyatta это санскритское слово, обозначающее «открытый». Компания видит свой продукт сетевым эквивалентом решений вроде Linux или Firefox, правда который противопоставляется не продуктам от Microsoft, а Cisco Systems.

Особености Vyatta

Проект Vyatta возник не на пустом месте. Основой OFR является eXtensible Open Router Platform (XORP), платформа маршрутизации с открытым кодом, работающая в укрепленном варианте Unix. Его разработкой занимается группа в International Computer Science Institute (ICSI) Беркли под руководством Atanu Ghosh, финансируют проект такие гиганты как Intel и Microsoft, а также National Science Foundation и Vyatta. В настоящее время код XORP содержит 670,000 срок на языке C++, может быть скомпилирован на Linux, OpenBSD, FreeBSD, DragonFlyBSD, NetBSD, Mac OS X и Windows Server 2003 и распространяется под BSD подобной лицензией. Поддерживаются протоколы Border Gateway Protocol (BGP, с некоторыми расширеними под IPv6), Routing Information Protocol (RIP v2 для IPv4 и RIPng для IPv6), Protocol-Independent Multicast Sparse Mode (PIM-SM), Internet Group Management Protocol (OSPFv2 (RFC2328) и OSPFv3 (RFC2740), Multicast Listener Discovery (MLD), OSPF (Open Shortest Path First), IGMP и SNMP. Проект XORP предоставляет готовый LiveCDBSD подобной или GPL лицензией. Но наряду с этим решением предлагается подписка на коммерческие редакции. Компания использует бизнес-модель применяемую Red Hat, то есть производитель планирует предложить платные услуги и поддержку для пользователей маршрутизаторов Vyatta, в то же время само программное обеспечение доступно совершенно бесплатно. дистрибутив, который можно использовать для тестирования. Хотя наверное спешить не стоит, так как Vyatta обладает большими возможностями. Так Vyatta поддерживает протокол Virtual Router Redundancy Protocol (VRRP), что позволяет применять маршрутизатор как резервный, мгновенно берущий на себя обработку в случае сбоя основного. Кроме этого в Vyatta включены разработки более чем 60 различных Open Source проектов и свой код. Распространяется дистрибутив под

Компанию основал в 2005 году Аллан Лайнванд (Allan Leinwand) который работал в Cisco еще в те времена когда штат компании насчитывал около сотни сотрудников. Одним из управляющих Vyatta является Келли Харрелл (Kelly Harrell), бывший вице-президент по маркетингу в компании MontaVista, специализирующейся на решениях со встраиваемыми версиями Linux. Вероятно поэтому одними из первых продуктов Vyatta были сетевые приставки-маршрутизаторы, работающие под управлением Linux и установленные на серверы Dell PowerEdge 850 оснащенные двумя портами Gigabit Ethernet. Последняя версия Vyatta Community Edition 2 представляет собой дистрибутив GNU/Linux на базе Debian, что прибавило ему дополнительной гибкости и возможностей, а также большую поддержку оборудования, в том числе и мультипортовых T1/E1 и T3 карт.

Работа с Vyatta CE2

Для примера настройки соединим сеть с провайдером, то есть к порту eth0 будет подключен Internet, а eth2 будет смотреть в локальную сеть . На сайте проекта можно скачать ISO-образ LiveCD дистрибутива который будет работать без установки на жесткий диск, конфигурационные файлы при этом можно сохранять на флоппи-диск или использовать TFTPVMware. сервер. Но при необходимости его можно установить на жесткий диск, а таже Flash или USB устройство. Также можно скачать готовый образ для виртуальной машины

После загрузки с образа регистрируемся как пользователь root или vyatta, пароль в обоих случаях vyatta. Во втором случае попадаем сразу в оболочку маршрутизатора. Если для входа использован root, дополнительно следует ввести команду “xorpsh”.

# xorpsh

Welcome to Vyatta on vyatta

[email protected]>

Теперь можно приступать к настройкам. Чтобы просмотреть доступные команды, достаточно ввести знак вопроса “?”. Сейчас нас интересует команда configure, набрав которую и попадаем в заветный режим настройки. Если нужно опять вернуться назад, достаточно набрать exit. Причем если нужно сохранить все внесенные изменения, то вначале следует ввести “commit”. Чтобы выйти без сохранения настроек используйте “exit discard”. Вначале следует ознакомиться с настройками по умолчанию, вводим “show” для перемещения вперед/назад используем клавиши Пробел/b.

В Vyatta (точнее XORP) используется Cisco-подобный командный интерфес к настройкам. Для доступа к редактируемым настройкам необходимо использовать команду edit, установка нового значения производится с помощью set, а удаление — delete. Поддерживается традиционное автодополнение с использованием табуляции, поэтому полностью вводить команду не обязательно. Настраиваем первый сетевой интерфейс.

# edit interfaces ethernet eth0

[edit interfaces/ethernet/eth0]

# set description “WAN”

[edit interfaces/ethernet/eth0]

# set address 192.168.1.58 prefix-length 24

[edit interfaces/ethernet/eth0]

Смотрим.

# show

> description: “WAN”

hw-id: 00:0C:29:9C:B8:75

> address 192.168.1.58 {

> prefix-length: 24

> }

Если все нормально записываем.

# commit

[edit interfaces/ethernet/eth0]

OK

Если теперь снова использовать комманду show, то в выводе уже не будут содержаться значки “>”. Это означает, что это значение уже записано. Обратите внимание на подсказку [edit interfaces/ethernet/eth0], которая помогает не заблудиться в дереве настроек, что бывает весьма полезным при глубокой вложенности. При входе в режим настройки сразу попадаем в корень, то есть подсказка будет выглядеть как [edit]. Перемещаться по дереву можно командой “up” либо для выхода в корень “exit” или “top”. Например:

# up

[edit interfaces/ethernet]

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

# delete description

Deleting:

description: “WAN”

OK

[edit interfaces ethernet eth0]

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

# set interfaces ethernet eth2 address 10.10.10.10 prefix-length 24

# set interfaces loopback lo address 10.10.10.10 prefix-length 32

# commit

Просмотреть настройки интерфейсов, можно введя “show interfaces”.

Просмотр настроек интерфейсов

Далее необходимо указать имя узла и домена к которому он принадлежит.

# set system host-name router

[edit]

# set system domain-name domain.com

[edit]

[email protected]# commit

OK

[email protected]#

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

# set protocols static route 0.0.0.0/0 next-hop 192.168.1.1

Задаем DNS сервер.

# set system name-server 192.168.1.1

В состав Vyatta входит сервер SSH, включив его в дальнейшем все настройки можно производить удаленно.

# set service ssh

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

# set service

Possible completions:

<[Enter]> Execute this command

dhcp dhcp settings

dhcp-server DHCP configuration

http Enable/disable HTTP protocol

nat NAT configuration

ssh Enable/disable SSH protocol

telnet Enable/disable telnet protocol

{ Enter text on multiple lines

Как видите есть еще веб-сервер, telnet и dhcp.

Включение NAT и создание правил firewall

Включим NAT и разрешим исходящий трафик из сети подключенной к eth2.

# create service nat rule 1

# edit service nat rule 1

# set type source

# set translation-type masquerade

# set outbound-interface eth0

# set protocols all

# set source network 10.10.10.0/24

# set destination network 0.0.0.0/0

# top

Если во внутренней сети находится веб-сервер разрешаем к нему доступ из вне.

# create service nat rule 2

# edit service nat rule 2

# set type destination

# set translation-type static

# set inbound-interface eth0

# set protocols tcp

# set source network 0.0.0.0/0

# set destination address 192.168.1.58

# set destination port-name http

# set inside-address address 10.10.10.30

# top

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

# show service nat

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

Настройка фильтрации пакетов.

Для примера разрешим доступ к сети с адреса 170.20.0.45.

# set firewall name FW-1 rule 1 action accept

# set firewall name FW-1 rule 1 source address 170.20.0.45

И привязываем к интерфейсу.

# set interfaces ethernet eth0 firewall in name FW-1

# commit

OK

Смотрим правило.

# show firewall name FW-1

rule 1 {

action: accept

source {

address: 170.20.0.45

}

}

Если требуется уточнить протокол и порт, добавляем следующие конструкции.

# set firewall name FW-1 rule 1 protocol tcp

# set firewall name FW-1 rule 1 destination port-name http

Веб-интерфейс

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

# set service http

После этого в браузере набираем IP-адрес роутера, принимаем сертификат и регистрируемся как пользователь vyatta (rootaConfigure.

Веб-интерфейс Vyatta

Правда выигрывая в наглядности, проигрываем в удобстве, так как здесь нет никаких подсказок и автодополнения, поэтому все параметры придется помнить наизусть. Для сохранения изменений необходимо нажать кнопку “Commit All Changes” врасположенную в верху меню. Во вкладках Operations и Tools можно найти некоторые утилиты с помощью которых можно проверить доступность узлов, установить дату, смонтировать дискету, просмотреть статистику сервисов ипрочее. система не пустит). Используя веб-интерфейс можно просмотреть системную информацию, произвести большую часть настроек доступных в консоли. Все они доступны во вкладке

Сохранение настроек и установка на диск

При работе в LiveCD сохранить конфигурацию на дискету очень просто, если при загрузке вставить дискету дисковод она будет смонтирована автоматически и с нее будет считана конфигурация. Для сохранения настроек вводим команду:

# save /mnt/floppy/config/config.boot

Если диск вставлен позже, можно смонтировать его обычным образом с помощью mount или использовать команду “init-floppy”.

Но использовать LiveCD вариант в работе не удобно, в рабочей системе лучше его установить на жесткий диск. Для установки потребуется диск размером всего 512 Мб и 10 Мб для сохранения настроек. Далее регистрируемся как root и запускаем установочный скрипт:

# install-system

Далее будет произведена проверка подключенных устройств, и предложен вариант создания разделов.

Partition (Auto/Parted/Skip) [Auto]:

В самом простом случае достаточно выбрать вариант, предложенный по умолчанию. По окончании будет установлен загрузчик GRUB. Чтобы вручную сохранить настройки в этом варианте достаточно ввести команду save без аргументов. Конфигурационный файл будет записан в /opt/vyatta/etc/config/config.boot.

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

www.tux.in.ua


Смотрите также