Как сделать резервный шлюз

Добавил пользователь Алексей Ф.
Обновлено: 04.10.2024

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

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

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

add net 8x.25y.0.0: gateway 10.0.1.1

Destination Gateway Flags Refs Use Netif Expire

8x.25y/16 10.0.1.1 UGS 0 2 rl0

route_meganet="-net 8x.25y 10.0.1.1"

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

Ещё один пример маршрутизации

Условное перенаправление трафика

Распределение трафика по типу

Эта схема будет работать и без последующего NAT-преобразования, но при условии, что IP-адрес, заданный на rl0 (и к которому мы привязываем Squid) будет из диапазона, выданного нам провайдером, предоставляющим подключение на данном канале. Это даст гарантию, что и входящий трафик будет маршрутизирован должным образом.

Распределение нагрузки по подсетям

Использование для этой цели fwd-правил очевидно (с той же поправкой на дальнейшую NAT-трансляцию):

ipfw add 4900 fwd 10.0.1.1 ip from 192.168.0.0/25 to any

Но в данном случае можно использовать распределение нагрузки и на базе NAT, запущенного на данном компьютере (рис. 2).

Например, так это можно осуществить, используя ipfw и два экземпляра natd:

Назначение fwd-правил, думаю, уже пояснять не требуется. Решение той же задачи с помощью фильтра pf:

nat on rl0 from 192.168.0.0/25 to any -> 10.0.1.2

nat on rl1 from 192.168.0.128/25 to any -> 10.1.1.2

pass out route-to (rl0 10.0.1.1) from 10.0.1.2 to any

pass out route-to (rl1 10.1.1.1) from 10.1.1.2 to any

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

acl subnet1 src 192.168.0.0/255.255.255.240

acl subnet2 stc 192.168.0.128/255.255.255.240

tcp_outgoing_address 10.0.1.2 subnet1

tcp_outgoing_address 10.1.1.2 subnet2

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

from 192.168.0.0/24 to any keep state

Этим правилом входящий трафик на внутреннем интерфейсе (т.е. исходящий для пользователей) будет распределяться между интерфейсами rl0 и rl1 с соответствующими шлюзами по алгоритму round-robin (т.е. внешний интерфейс будет меняться циклически – первое соединение будет использовать rl0, второе – rl1, третье – снова rl0 и так далее). Опция keep state сохраняет состояние, благодаря чему все пакеты в рамках одного соединения будут использовать один и тот же шлюз. В итоге нагрузка будет распределяться между двумя каналами – нельзя сказать, что трафик поделится абсолютно поровну, но при рассмотрении за большой период времени можно считать, что балансировка будет приближаться к этому.

В ipfw тоже есть возможность реализовать нечто подобное, но на другом принципе. Здесь в правило можно включить опцию prob N, где N – число от 0 до 1, указывающее вероятность, с которой правило будет применяться к пакетам, подходящим по остальным критериям. В паре с действием skipto можно попробовать реализовать нечто подобное:

ipfw add 500 check-state

ipfw add 1000 prob 0.4 skipto 2000 ip from any to any in via ed0

ipfw add 1500 fwd 10.0.1.1 ip from 192.168.0.0/24 to any out keep-state

ipfw add 2000 fwd 10.1.1.1 ip from 192.168.0.0/24 to any out keep-state

В отличие от балансировки по методу round-robin, здесь есть возможность распределять трафик между интерфейсами в любой пропорции. Кстати, такой механизм можно реализовать и в pf – используя опцию probability, работающую аналогично опции prob в ipfw.

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

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

На странице описывается как с помощью OpenVPN и двух независимых интернет-каналов низкой надёжности организовать надёжное подключение удалённой сети (или системы) к центральной сети.

Приведённое решение может быть полезно и без использования VPN — для решения задачи автоматического выбора основного шлюза.

Содержание

Есть два канала связи с Интернетом, через двух независимых провайдеров. Один из каналов является основным, второй — резервным. Резервный канал нужно использовать только тогда, когда недоступен основной.

Нужно сделать так, что бы как только Интернет становится недоступным через одно из соединений (не имеет значения из-за того что пропала связь с провайдером, или потому что проблемы у провайдера), автоматически менять маршрут по умолчанию и использовать другой канал.

Как только связь через основной канал восстанавливается, необходимо возвращаться на его использование.

Рассмотреть ситуацию, когда компьютер входит в другую сеть через OpenVPN:

OpenVPN должен перестартовывать после смены маршрута;
(Важно!) когда OpenVPN-соединение установлено, маршрут по умолчанию направлен в частную сеть через OpenVPN.

Если OpenVPN не используется, ничего страшного — задача только упрощается.

Схема включения шлюза gw в Интернет и локальную сеть (LAN), показана ниже.

CENTRAL VPN HUB — центральный VPN-концентратор, на который нужно держать VPN-канал;
GW1 — шлюз первого провайдера, на интерфейсе с нашей стороны установлен IP-адрес IP1 (предпочитаемый канал, отмечен двойной линией);
GW2 — шлюз второго провайдера, на интерфейсе с нашей стороны установлен IP-адрес IP2.

На шлюзе gw работает VPN-клиент, который через Интернет должен устанавливать туннель на центральный VPN-сервер (CENTRAL VPN HUB).

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

IP1 — адрес первого интерфейса (eth1);
IP2 — адрес второго интерфейса (eth2);
GW1 — адрес шлюза, доступного через первый интерфейс;
GW2 — адрес шлюза, доступного через второй интерфейс;
DEFAULTGW — адрес предпочитаемого (один из GW1 и GW2) шлюза (если он работает, лучше использовать его).

Пример файла /etc/network/gateways

Для того чтобы избежать случайного внутреннего противоречия в настройках, стоит использовать эти адреса и при настройке интерфейсов. Например, для Debian GNU/Linux, если настройка интерфейса выполняется статически через файл /etc/network/interfaces:

(если при настройке интерфейса нужно указывать и маску, следует добавить соответствующую переменную в файл /etc/network/gateways и использовать её при настройке интерфейса).

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

Автоматическая правка файла /etc/network/gateways возможно с помощью скрипта, который вызывается при поднятии соответствующего интерфейса.

Для Debian GNU/Linux это можно сделать или указав скрипт в директиве up в файле /etc/network/interfaces или разместив в соответствующем каталоге, например /etc/ppp/ip-up.d/.

Пример скрипта который вызывается при поднятии интерфейса показан ниже. Здесь интерфейс соответствует каналу 1, и поэтому он правит переменные GW1 и IP1.

Пример. Скрипт автоматической правки файла /etc/network/gateways, вызываемый при подъёме интерфейса.

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

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

трафик с интерфейса eth1 должен уходить через GW1;
трафик с интерфейса eth2 должен уходить через GW2.

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

Эту задачу можно решить с помощью policy routing, настройка которой в Linux возможна с помощью iproute2.

Например для шлюзов GW1 и GW2, которые описываются в /etc/network/gateways:

Основной маршрут нужно изменить, когда он перестаёт работать. Как проверить, что маршрут больше не работает?

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

Лучший способ — проверять доступность сервера, на который должен быть установлен туннель через тот или иной канал. Это можно сделать путём отправки ICMP-запросов с того или иного интерфейса.

Скрипт использует второй способ. Каждые 30 секунд (CHECK_INTERVAL) выполняется проверка. Как только связь через приоритетный шлюз теряется, а связь через второй шлюз при этом есть, производится переход на использование второго шлюза в качестве основного.

При восстановлении связи через приоритетный шлюз, скрипт переводит систему на использование его в качестве основного (default gateway).

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

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

GW_CONF — имя файла /etc/network/gateways (или другое, если он называется иначе)
OPENVPN_UPLINK — имя конфигурации OpenVPN;
CHECK_INTERVAL — периодичность проверки доступности удалённой точки через шлюзы, в секундах.

Имя конфигурации OPENVPN_UPLINK определяет имя конфигурационного файла OpenVPN и процесс openvpn, который должен быть перезапущен после смены маршрута. Например,

соответствует конфигурационный файл

IP-адрес VPN-сервера, с которым должен устанавливаться туннель, и на возможность связи с которым постоянно проверяются шлюзы, определяется из этого конфигурационного файла, из директивы remote.

Скрипт может быть размещён, например, здесь:

Скрипт должен вызываться автоматически при старте системы. Например, в /etc/rc.local:

или в /etc/network/interfaces

Скрипт /usr/local/sbin/change_default_route

Вышеописанный способ маршрутизации в зависимости от источника (policy routing) не будет работать для систем внутри сети, доступных через NAT.

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

Один из способов решения проблемы описан ниже.

Для решения проблем с трансляцией соединений внутрь сети, необходимо использовать схему с промежуточным шлюзом:

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

Введение

Чтобы не перенастраивать маршруты клиентов в случае выхода из строя основного шлюза, можно пойти двумя путями: перестроить таблицы маршрутизации или отдать IP-адрес отказавшего шлюза другому узлу. Каждый способ имеет свои плюсы и минусы. Протоколы динамической маршрутизации, вроде RIP, OSPF, EIGRP или BGP, требуют поддержки со стороны роутеров, плюс придется повозиться с настройками. Для простых сетей второй вариант реализовать на порядок проще, к тому же он имеет свои плюсы.

Сетевой протокол дупликации общего адреса CARP (Common Address Redundancy Protocol) позволяет использовать один IP-адрес несколькими хостами, работающими в пределах одного сегмента сети и имеющими один виртуальный MAC (link layer). Этот IP-адрес клиенты и устанавливают в маршруте по умолчанию, поэтому изменять сетевые настройки в случае выхода из строя мастер-шлюза нет необходимости. Настроив CARP, затем можно смело проводить обслуживание одного из узлов шлюзового кластера (изменять конфигурацию с перезагрузкой, обновлять ПО, проводить плановую модернизацию), не беспокоясь, что офис на какое-то время останется без интернета.

OpenBSD/FreeBSD CARP

Впервые CARP появился в 2003 году в ОС OpenBSD 3.5 как ответ на патентование компанией Cisco протоколов VRRP (Virtual Router Redundancy Protocol) и HSRP (Hot Standby Router Protocol). Впоследствии поддержка протокола была портирована в FreeBSD, NetBSD, DragonFly BSD и реализована для Linux-систем.

Работает CARP следующим образом. В случае выхода главного узла из состава redundancy group (группа избыточности) его IP и идентификатор подхватывает один из резервных узлов, имеющий более высокий приоритет. Для определения своей работоспособности главный узел использует объявления (IP Protocol 112, защищены при помощи SHA-1 HMAC), как только они прекращаются, делается вывод о сбое. Резервный узел, взяв на себя IP, начинает рассылать объявления. Выбирается такой узел просто: кто быстрее начнет рассылать объявления, тот и главный. Для этого в настройках каждого роутера используются параметры advbase и advskew. Интервал рассылки рассчитывается по формуле advbase + advskew/255, то есть чем меньше значения, тем чаще узел рассылает объявления, а значит, вероятность того, что он станет мастером, выше. Когда мастер-шлюз восстанавливает работоспособность, управление снова переходит к нему (это необязательно, и в некоторых реализациях такое поведение можно отключить).

Другие статьи в выпуске:

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

Обычно CARP используется для обеспечения отказоустойчивости роутеров и брандмауэров, хотя в некоторых реализациях он позволяет распределять нагрузку посредством балансировки ARP (arpbalance).

Конфигурирование CARP в OpenBSD и FreeBSD, по сути, ничем не отличается, только используются разные файлы. Текущие установки можно просмотреть при помощи команды

Разрешаем форвардинг и включаем CARP:

Активированный параметр net.inet.carp.preempt позволит узлу участвовать в выборе мастера, при этом если откажет хотя бы один из CARP-интерфейсов, то advskew автоматически устанавливается в 240 и инициируются выборы мастер-шлюза. В случае если необходима балансировка, используем net.inet.carp.arpbalance, указав режим балансировки: arp, ip, ip-stealth или ip-unicast.

CARP-интерфейс создается на лету при помощи команды ifconfig carp create . Для постоянных установок директивы прописываются в /etc/rc.conf (FreeBSD) или /etc/hostname.* (OpenBSD). Помимо стандартных для сетевых интерфейсов параметров, необходимо указать пароль, установить группу vhid и расставить приоритеты advskew.

Настраиваем параметры CARP

Интерфейсы конфигурируются как обычно (это можно сделать во время установки OC), разберем только то, что относится непосредственно к CARP и pfsync. В FreeBSD:

По окончании проверяем работу интерфейсов командой ifconfig carp .

Есть еще один момент, о котором стоит упомянуть. Все интерфейсы CARP разделены на группы (по умолчанию группа carp, ifconfig -g ), каждой можно назначать счетчик demotion counter, позволяющий задавать некоторые ограничения: устанавливать master при загрузке, ограничивать число отказоустойчивых carp.

На резервном узле настройки полностью аналогичны, только в вызов ifconfig добавляем значение advskew. Покажу на примере OpenBSD:

Параметр carpdev можно не указывать, в этом случае CARP использует физический интерфейс, который соответствует той же подсети, что и назначенный IP для виртуального интерфейса.

Теперь настала очередь псевдоинтерфейса pfsync:

Такой вариант удобен в том случае, когда шлюзов несколько, так как для передачи используется мультикаст. Как вариант, можно указать конкретный IP:

На данный момент пакетный фильтр блокирует передачу служебной информации, необходимо добавить пару разрешающих правил в /etc/pf.conf :

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

Теперь можно проверять. Выключаем основной шлюз, IP и МАС подхватывает резервный шлюз, при этом существующие соединения не обрываются. Хотя в случае активных VPN-туннелей есть свои особенности.

Настройка CARP в интерфейсе pfSense Устанавливаем виртуальный IP в pfSense

Монитор интерфейсов ifstated

Демон ifstated(8) — еще одно интересное дополнение, которое может с успехом использоваться вместе с CARP. Контролируя состояние интерфейсов и сервисов сети, он в ответ на изменившиеся условия выполняет определенные команды. Это может быть что угодно: принудительная смена мастера в CARP, изменение таблицы маршрутизации и правил pf, контроль доступности сервисов и так далее. При этом логику работы админ задает сам, это позволяет автоматизировать действия в ответ практически на любые внештатные ситуации.

Для активации демона при загрузке следует добавить в MARKDOWN_HASH745bb3c68db813fb59fc6fe8d144ffa2MARKDOWN_HASH строку MARKDOWN_HASHc8a735a8f8116e06505cb1473e48d887MARKDOWN_HASH . Все настройки производятся в MARKDOWN_HASHedc89ceeb4e8b5ca84e62c665d983178MARKDOWN_HASH , в справочной странице ifstated.conf(5) можно найти несколько хороших примеров. После настроек желательно прогнать работу командой MARKDOWN_HASH8943b8c22172c54b5a4fc6dcc77f2faaMARKDOWN_HASH , чтобы посмотреть результат.

Сохраняем состояние IPsec VPN

Конфигурацию IPsec трогать не будем (демон должен стартовать с опцией -S), остановимся лишь на настройке собственно sasyncd.

Устанавливаем корректные права доступа:

Настройки на подчиненном шлюзе аналогичны, только в peer указываем IP-адрес основного шлюза (172.16.0.1).

Перезапускаем isakmpd и смотрим результат. Трафик между роутерами у нас разрешен, поэтому обмен должен происходить без проблем.

Чтобы sasyncd стартовал при загрузке системы, в конфиг /etc/rc.conf.local добавляем запись:

Справочная страница sasyncd Конфигурационный файл sasyncd.conf

А что же Linux?

Итак, ставим UCARP. В Ubuntu и Debian он уже есть в репозитории, поэтому собирать ничего не нужно:

Реализация в виде userspace имеет свои особенности, UCARP, по сути, обычная программа, которую можно запустить любым способом, в том числе из стартовых скриптов. В официальномreadme показан только общий для всех дистрибутивов принцип, помогающий понять, как построен UCARP. Пользователям Ubuntu/Debian повезло больше, поскольку мантейнер положил в пакет все нужные скрипты и предоставил хорошее описание (/usr/share/doc/ucarp).

Прописываем на мастер-сервере:

Второй интерфейс прописываем по аналогии, изменяем только IP-адрес и значение ucarp-vid.

Теперь резервный роутер:

Все готово, можно использовать.

Дела виндовые

Использование Windows в качестве маршрутизатора не такая плохая идея, как это кажется на первый взгляд. Тем более что этот вариант предусмотрен самими разработчиками. Достаточно вспомнить большое количество сервисов: VPN, DirectAccess, Remote Desktop Service (RDS), да и собственно сервер маршрутизации и удаленного доступа Windows (RRAS), обеспечивающий подключение клиентов к интернету. Доступность любой из этих ролей потребует наличия второго сервера, а вот инструменты отказоустойчивости придется выбирать в зависимости от сервиса и версии ОС. Служба RRAS и связанные с ней VPN, а также RDS уже давно поддерживают балансировку сетевой нагрузки (NLB, Network Load Balancing), и проблем с их использованием нет никаких. Но например, в Win2k8R2 DirectAccess ограничен развертыванием только на одном сервере, и, чтобы обеспечить резервирование, приходится задействовать отказоустойчивый кластер Hyper-V, настроенный для динамической миграции. В таком сценарии все равно функционирует только один сервер DirectAccess. В Win 2012 роль DirectAccess совместно работает с RRAS и, главное, поддерживает NLB, конфигурацию которой легко настроить прямо в мастере настройки роли. Также можно использовать решения по NLB от сторонних поставщиков.

Сама служба RRAS поддерживает RIP, умеющий динамически обновлять маршрутную информацию. Кроме того, в Win 2012 доступна функция объединения сетевых карт, позволяющая также организовать балансировку нагрузки и обеспечить отказоустойчивость (LBFO).

В Win 2012 DirectAccess интегрирован с RRAS

При настройке сервера RRAS потребуется выбрать топологию

WARNING

В документации Microsoft можно встретить упоминание о протоколе CARP. Это одноименный протокол, который позволяет выдавать клиенту содержимое с определенного сайта.

Настройка CARP в pfSense

Один из самых популярных дистрибутивов-роутеров — построенный на FreeBSD pfSense, поэтому нелишним будет разобрать, как настроить в нем CARP. Переходим в Firewall -> Virtual IPs -> CARP settings -> Synchronize Enabled и начинаем заполнять поля. Активируем Synchronize States, выбираем нужный интерфейс в Synchronize Interface. По умолчанию таблица синхронизируется при помощи мультикаста, но можно отправлять по конкретному IP, указав его в pfsync Synchronize Peer IP. Это достаточный минимум.

Разработчики pfSense пошли дальше, и c резервным роутером можно синхронизировать все настройки сервера (учетные записи, сертификаты, правила, задания, установки сервисов и прочее). Для этого в Configuration Synchronization Settings (XMLRPC Sync) следует указать логин и пароль админа второго роутера и отметить флажками данные, которые необходимо отправлять.

Теперь переходим во вкладку Virtual IPs, нажимаем + и конфигурируем виртуальный IP. Выбираем в Type -> CARP и далее заполняем все предложенные поля: IP-адрес, пароль, номер VHID и значения частоты синхронизации (Advertising Frequency, на основном — 0).

Включаем NAT, переходим в Firewall -> NAT -> Outbound, выбираем Automatic outbound NAT rule generation и нажимаем Save, это автоматически создаст правила для LAN, которые нужно отредактировать под IP CARP. В Firewall -> Rules добавляем правило, разрешающее подключения для pfsync-интерфейса (add allow all from any to any).

Заключение

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

Тема ( Как поднять шлюз для локальной сети ) данной заметки в последствии ляжет в серию заметок по практическому развертыванию PXE сервера в локальной сети, данный сервер будет служить удаленным развертыванием операционных систем на рабочих местах. В роли таких систем будут иметь место рассмотрены на моем блоге: Windows, Ubuntu. Согласитесь не хочется же каждый раз проделывать такие шаги (на месте), как:

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

это в моем случае станция (а именно Ubuntu 12.04.4 Server amd64) выступающая в роли сопряжения двух сетей, одна сеть в которой работают локальные пользователи (малое предприятие) и сеть с выходом в интернет. Вот эта станция и ведет маршрутизацию трафика изнутри сети наружу. Также на данной станции можно разворачивать различные сервисы, такие как прокси сервер, учет за использование интернета, логирование подключений во вне, предоставление различных сервисов снаружи так и многих других.

Станция с установленной операционной системой:

Ubuntu 12.04.4 Server amd64

Станция оснащена двумя сетевыми картами:

eth0 – смотрит интернет (может получать IP адрес динамически, может иметь статический, я опишу оба варианта)

eth1 – смотрит в локальную сеть (подключение к локальной сети, будет иметь статический IP 192.168.10.1 и маску 255.255.255.0

Также, для тестирования нам понадобится клиентская машина, которая будет находиться в локальной сети (операционная система значения не имеет).

Eth0 – от интернет центра (или провайдера интернет)получил по dhcp адрес 192.168.1.51

Далее редактируем сетевые настройки сетевых интерфейсов :

ekzorchik@srv-serv:~$ sudo nano /etc/network/interfaces

настраиваем eth0 (по которому осуществляется подключение к интернет)

iface eth0 inet dhcp

если IP адрес от провайдера статический, то настройки в файл вносятся так:

iface eth0 inet static

настраиваем eth1 ( по которому идет подключение из локальной сети)

iface eth1 inet static

Сохраняем внесенные изменения и перезапускаем демон сети :

ekzorchik@srv-serv:~$ sudo /etc/init.d/networking restart

Проверим работу сетевого интерфейса (это eth1) с назначенным для него статическим адресом, для этого понадобиться машина (в моем случаем это рабочая станция с осью Windows 7) на которой произведем следующие изменения в настройках сетевой карточки (потому как, у меня пока отсутствует служба автоматического присваивания адресов в сети, т. е. DHCP) , а именно из пула маски /24 пропишем произвольный адрес, к примеру: 10.9.9.5 и маску подсети 255.255.255.0 и шлюз 10.9.9.1

, после чего нужно попробовать вызвав окно командной строки и послать ICMP запрос ( с помощью утилиты ping) на адрес шлюза 10.9.9.1 – запросы должны проходить успешно:

C:\Users\ekzorchik>ping 10.9.9.1

Отлично, теперь снова займемся настройкой шлюза , а именно произведем его дополнение установив пакет dnsmasq, он необходим для перенаправления DNS запросов, вышестоящим серверам:

ekzorchik@srv-serv:~$ sudo apt-get install dnsmasq -y

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

так произошло, потому как на шлюзе передача пакетов с одного интерфейса на другой не настроена, разрешим перенаправление пакетов : (сняв комментарий со строки)

ekzorchik@srv-serv:~$ sudo nano /etc/sysctl.conf

Сохраненяем внесенные изменения и перечитываем настройки :

ekzorchik@srv-serv:~$ sudo sysctl -p

, по поводу что обозначает параметр советую обратиться к справочной системе ( man sysctl), там довольно таки понятно изъяснено.

Также необходимы правила для маршрутизации пакетов :

ekzorchik@srv-serv:~$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

ekzorchik@srv-serv:~$ sudo iptables -A FORWARD -i eth1 -o eth0 -j REJECT

ekzorchik@srv-serv:~$ sudo iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS —clamp-mss-to-pmtu

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

ekzorchik@srv-serv:~$ sudo bash -c "iptables-save > /etc/ip"

ekzorchik@srv-serv:~$ sudo chmod +x /etc/ip

Вносим изменения в настройки сетевого интерфейса :

ekzorchik@srv-serv:~$ sudo nano /etc/network/interfaces

iface eth0 inet dhcp

pre-up iptables-restore /etc/ip

Сохраняем внесенные изменения в настройки сетевого интерфейса и перезапускаем службу сети :

ekzorchik@srv-serv:~$ sudo /etc/init.d/networking restart

ekzorchik@srv-serv:~$ sudo reboot

Перейдя к клиентской системе и в настройках сетевого интерфейса прописав адрес DNS сервера

Не заслуживающий доверия ответ:

Работает, на основе этой заметки можно поднять и куда более сложные и интересные в реализации вещи, где в качестве шлюза будет использоваться система Ubuntu 12.04.4 Server amd64.

Но заметка еще не завершена, далее я покажу, как сделать, чтобы адреса в локальной сети назначались не вручную, а автоматически (т. е. Поднимем службу DHCP, некоторые нюансы взяты из моей заметки ориентированной на Ubuntu 10.10) : — для этого также потребуется пакет dnsmasq:

Перед редактированием dnsmasq.conf советую сделать его резервную копию:

ekzorchik@srv-serv:~$ sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.original

Переходим к редактированию: (очищаем сперва его содержимое)

ekzorchik@srv-serv:~$ sudo bash -c "cat > /etc/dnsmasq.conf"

по сочетание клавиш Ctrl + C прерываем действие команды

Приводим конфигурационный файл к виду:

ekzorchik@srv-serv:~$ sudo nano /etc/dnsmasq.conf

Сохраняем внесенные изменения и проверяем, что конфигурационный файл по синтаксису корректен :

ekzorchik@srv-serv:~$ /usr/sbin/dnsmasq --test

dnsmasq: syntax check OK.

Перезагружаем службу dnsmasq:

ekzorchik@srv-serv:~$ sudo /etc/init.d/dnsmasq restart

* Restarting DNS forwarder and DHCP server dnsmasq

На клиентской системе изменяем настройки сетевого адаптера выставив со статического значения на динамическое:

Открываем командную строку и смотрим, какой IP адрес присвоился системе от DHCP сервера:

C:\Users\ekzorchik>ipconfig

, как видно из скриншота ниже адрес имеет значение: 10.9.9.8

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

Если нужно для определенной машины использовать только статический IP адрес, то не нужно указывать в ручную его, достаточно воспользоваться таким параметром, как резервирование нужного IP адреса и MAC— адреса сетевой карточки: (пример)

узнаем со шлюза mac адрес у ip адреса станции:

ekzorchik@srv-serv:~$ ping 10.9.9.8 -c 1 && arp -a | grep 10.9.9.8

PING 10.9.9.8 (10.9.9.8) 56(84) bytes of data.

64 bytes from 10.9.9.8: icmp_req=1 ttl=128 time=0.493 ms

— 10.9.9.8 ping statistics —

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.493/0.493/0.493/0.000 ms

pc.polygon.local (10.9.9.8) at 08:00:27:a4:94:1d [ether] on eth1

и в файл dnsmasq.conf вносим параметр – dhcp-host :

ekzorchik@srv-serv:~$ sudo nano /etc/dnsmasq.conf

dhcp-host= 08:00:27:a4:94:1d , 10.9.9.9

Проверяем конфиг на ошибки:

ekzorchik@srv-serv:~$ /usr/sbin/dnsmasq --test

dnsmasq: syntax check OK.

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

ekzorchik@srv-serv:~$ sudo service dnsmasq restart

смотрим на клиенткой системе ip адрес — он должен быть 10.9.9.9 – все так и есть.

Обновляем настройки сетевой карточки:

C:\Users\ekzorchik>ipconfig /renew

См. какой сетевой адрес присвоился:

C:\Users\ekzorchik>ipconfig | findstr /i "IPv4-*"

Работает. Вот собственно и все минимальные действия чтобы поднять шлюз для малого предприятия на системе Ubuntu 12.04.4, ну а дальше советую смотреть мои заметки на моем блоге если нужны дополнительные усовершенствования или адаптация под конкретную задачу. С уважением автор блога – ekzorchik.

One comment

Здравствуйте, очень полезна ваша статья….проделал как по инструкции на виртуальной машине, все работает.
Вот только есть одна проблема sams не считает трафик и вообще такое ощущение что его нет в на сервере, так как он не блокирует и воооще ничего не делает.
Подскажите как с помощью вашего руководства поднятия шлюза можно еще и заставить работать sams!?

Comments are closed.

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще :)

Карта МКБ: 4432-7300-2472-8059

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

Читайте также: