Домашний интернет-шлюз. начальная настройка 6-портового мини-компьютера на ubuntu server 20.04 lts

Правила для конкретного сетевого интерфейса или IP-адреса

На сервере может быть несколько сетевых интерфейсов. Обычно их как минимум два — внешний сетевой и так называемый loopback-интерфейс 127.0.0.1, доступ к которому извне невозможен, если отсутствует соответствующее перенаправление пакетов. У вас также может как минимум еще один IP-адрес, используемый совместно с алиасом сетевого интерфейса, или еще один физический сетевой интерфейс. И на каждом IP-адресе или сетевом интерфейсе могут работать определенные сервисы. Например, на одном веб-сервер Apache, а на втором сервер службы доменных имен bind9. И когда вы разрешаете соединения на определенный порт без указания этого сетевого интерфейса, вы открываете доступ к этому порту на всех интерфейсах. Поэтому есть два способа сузить область действия разрешения.

Первый способ — указать IP-адрес, для которого будет разрешен доступ.

iptables -t filter -A INPUT -d 234.234.234.234 -p tcp -m tcp --dport 22 -j ACCEPT

Этот пример показывает, как можно использовать адрес назначения в правиле iptables. При этом также можно использовать адрес источника:

iptables -t filter -A INPUT -s 123.123.123.123 -d 234.234.234.234 -p tcp -m tcp --dport 22 -j ACCEPT

В данном пример мы уже ограничиваем доступ двумя адресами, что позволяет получить доступ по SSH к серверу по адресу 234.234.234.234 с адреса 123.123.123.123, с остальных адресов доступ вы получить не сможете.

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

iptables -t filter -A INPUT -i eth0 -s 123.123.123.123 -p tcp -m tcp --dport 22 -j ACCEPT

Такой вариант разрешает доступ по SSH на сетевом интерфейсе eth0, на остальных сетевых интерфейсах доступ по SSH будет отсутствовать.

Всё, что мы только что рассмотрели — это только самое начало, в следующей части будет продолжение…

Настройка серверов частной сети

Примечание: Данный раздел нужно выполнить на остальных серверах (wordpress-1, wordpress-2, mysql-1 и mysql-2).

Поскольку в частной сети сетевых интерфейсов и портов довольно много, вместо списка IP-адресов и портов проще будет создать белый список IP-адресов.

Подключитесь по SSH к серверу tunnel-1:

Затем подключитесь по SSH к частному интерфейсу одного из оставшихся серверов:

Будучи на сервере частной сети, удалите все текущие правила и установите политику по умолчанию ACCEPT:

Разрешите серверу tunnel-1 подключаться по SSH к текущему VPS.

Разрешите трафик loopback:

Разрешите публичный и частный трафик, инициированный с вашего сервера. Это позволит вашему серверу получить доступ к Интернету (например, чтобы загрузить обновления или программное обеспечение):

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

На серверах wordpress_1 и wordpress_2 разрешите HTTP-доступ к haproxy-www (порт 80).

Цепочки INPUT и FORWARD должны иметь политику по умолчанию Drop

Обратите внимание, что цепочка OUTPUT использует политику ACCEPT, поскольку серверам в частной сети можно доверять:. Сохраните настройки брандмауэра

Для этого понадобится пакет iptables-persistent. Установите его:

Сохраните настройки брандмауэра. Для этого понадобится пакет iptables-persistent. Установите его:

Во время установки пакета вам будет предложено сохранить текущие правила. Выберите yes.

Теперь брандмауэр на сервере haproxy-www имеет такие настройки:

• Поддержка SSH с сервера tunnel-1 к частной сети.
• Поддержка loopback трафика.
• Поддержка исходящего трафика серверов частной сети
• Поддержка входящего трафика, поступающего от серверов из белого списка.
• Сброс входящего трафика с других ресурсов.

Перенаправление портов

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

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

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

#!/bin/bashEXT_IP="xxx.xxx.xxx.xxx" INT_IP="xxx.xxx.xxx.xxx" EXT_IF=eth0 INT_IF=eth1 FAKE_PORT=$1  LAN_IP=$2     SRV_PORT=$3   iptables -t nat -A PREROUTING -d $EXT_IP -p tcp -m tcp --dport $FAKE_PORT -j DNAT --to-destination $LAN_IP:$SRV_PORTiptables -t nat -A POSTROUTING -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j SNAT --to-source $INT_IPiptables -t nat -A OUTPUT -d $EXT_IP -p tcp -m tcp --dport $SRV_PORT -j DNAT --to-destination $LAN_IPiptables -I FORWARD 1 -i $EXT_IF -o $INT_IF -d $LAN_IP -p tcp -m tcp --dport $SRV_PORT -j ACCEPT

Настройка блокировки доступа к сайту по странам

Дальше можно пойти двумя путями:

1. Блокировать доступ определенным странам.
2. Разрешить доступ списку стран, а от остальных закрыться.

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

Итак, у нас есть список ip адресов и подсетей, разделенных по странам. Списки очень большие, руками их обрабатывать не получится. Мы это дело автоматизируем, а пока пройдемся по теории. Разберемся с управлением списками в ipset. Для начала создадим список и назовем его — blacklist.

# ipset -N blacklist nethash

Этой командой я создал список blacklist типа nethash. Строго говоря, я создаю не список, а набор данных типа nethash. В данном случае это набор данных адресов подсетей. Именно в виде набора подсетей выглядят списки доступа стран по ip. Если у вас есть список ip адресов, то тип данных будет iphash. Более подробно о типах данных можно посмотреть в документации.

Добавим в наш список несколько подсетей.

# ipset -A blacklist 5.43.240.0/21
# ipset -A blacklist 5.100.64.0/18
# ipset -A blacklist 5.159.112.0/21

Посмотрим содержимое списка blacklist.

# ipset -L blacklist
Name: blacklist
Type: hash:net
Revision: 3
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16880
References: 0
Members:
5.100.64.0/18
5.43.240.0/21
5.159.112.0/21

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

Их можно изменить таким образом:

# ipset create blacklist nethash hashsize 16348 maxelem 131072

Проверяем:

# ipset -L blacklist
Header: family inet hashsize 16384 maxelem 131072
Size in memory: 262544

Обратите внимание на занимаемую память. На маленьком VPS это может стать проблемой

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

Список мы создали, теперь его надо подключить в iptables. Для этого добавляем правило блокировки.

# iptables -A INPUT -m set --match-set blacklist src -j DROP

Смотрим, что получилось в правилах:

# iptables -L INPUT -v -n

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

# ipset -N whitelist nethash

Добавляем в него подсети.

# ipset -A whitelist 6.43.240.0/21
# ipset -A whitelist 7.100.64.0/18
# ipset -A whitelist 8.159.112.0/21

Создаем правило в iptables, по которому к нашему серверу будут иметь доступ только адреса из списка. Сначала у меня стояли вот эти два правила, которые разрешают доступ к веб серверу всем.

iptables -A INPUT -i $WAN -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i $WAN -p tcp --dport 443 -j ACCEPT

Я их изменил на следующие.

iptables -A INPUT -i $WAN -m set --match-set whitenet src -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i $WAN -m set --match-set whitenet src -p tcp --dport 443 -j ACCEPT

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

Принцип работы ipset рассмотрели. Теперь автоматизируем все и создадим полный список ip адресов по странам, которым будет разрешен доступ к сайту. Я для этого написал простенький скрипт. Привожу его с комментариями.

#!/bin/bash
# Удаляем список, если он уже есть
ipset -X whitelist
# Создаем новый список
ipset -N whitelist nethash
# Скачиваем файлы тех стран, что нас интересуют и сразу объединяем в единый список
wget -O netwhite http://www.ipdeny.com/ipblocks/data/countries/{ru,ua,kz,by,uz,md,kg,de,am,az,ge,ee,tj,lv}.zone
echo -n "Загружаем белый список в IPSET..."
# Читаем список сетей и построчно добавляем в ipset
list=$(cat netwhite)
for ipnet in $list
 do
 ipset -A whitelist $ipnet
 done
echo "Завершено"
# Выгружаем созданный список в файл для проверки состава
ipset -L whitelist > w-export

Запускаете скрипт, он скачивает и объединяет списки нужных вам стран, затем добавляет их в ipnet и в конце делает экспорт в файл. Посмотрите на этот файл. Список в нем должен совпадать с исходным списком, плюс несколько информационных строк в самом начале. На этом все. Если вы добавили правила в iptables, ограничение доступа по ip уже начало работать.

Таблица форвардинга

При настройке iptables мы уже использовали таблицу форвардинга, но единственное, что мы делали — это очищали правила командой

iptables -F FORWARD

В этой таблице не рекомендуется фильтровать трафик, рекомендуется ее использовать только для перенаправления трафика. Фильтрацию необходимо выполнять либо до форвардинга, либо уже после. В таблице FORWARD вы определяете, куда должны форвардиться пакеты, а куда нет. Например:
— разрешить форвардинг между eth0 и eth1
— разрешить форвардинг между eth0 и eth2
— запретить форвардинг между eth1 и eth2
Правила в таком случае могут выглядеть так:

iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth2 -j ACCEPT
iptables -A FORWARD -i eth2 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth2 -j DROP
iptables -A FORWARD -i eth2 -o eth1 -j DROP

либо еще короче:

iptables -A FORWARD -i eth1 -o eth2 -j DROP
iptables -A FORWARD -i eth2 -o eth1 -j DROP

Сохранение введенных правил при перезагрузке

Все введенные в консоли правила — после перезагрузки ОС будут сброшены в первоначальное состояние (читай — удалены). Для того чтобы сохранить все введенные команды iptables, существует несколько путей. Например, один из них — задать все правила брандмауэра в файле инициализации . Но у данного способа есть существенный недостаток: весь промежуток времени с запуска сетевой подсистемы, до запуска последней службы и далее скрипта rc.local из SystemV операционная система будет не защищена. Представьте ситуацию, например, если какая-нибудь служба (например NFS) стартует последней и при ее запуске произойдет какой-либо сбой и до запуска скрипта rc.local. Соответственно, rc.local так и не запуститься, а наша система превращается в одну большую дыру.

Поэтому самой лучшей идеей будет инициализировать правила netfilter/iptables при загрузке сетевой подсистемы. Для этого в Debian есть отличный инструмент — каталог /etc/network/if-up.d/, в  который можно поместить скрипты, которые будут запускаться при старте сети. А так же есть команды iptables-save и iptables-restore, которые сохраняют создают дамп правил netfilter из ядра на  и восстанавливают в ядро правила со  соответственно.

Итак, алгоритм сохранения iptables примерно следующий:

• Настраиваем сетевой экран под свои нужны с помощью
• создаем дамп созданный правил с помощью команды iptables-save > /etc/iptables.rules
• создаем скрипт импорта созданного дампа при старте сети (в каталоге /etc/network/if-up.d/) и не забываем его сделать исполняемым:

# cat /etc/network/if-up.d/firewall
#!/bin/bash
/sbin/iptables-restore < /etc/iptables.rules
exit 0
# chmod +x /etc/network/if-up.d/firewall

Дамп правил, полученный командой iptables-save имеет текстовый формат, соответственно пригоден для редактирования. Синтаксис вывода команды iptables-save следующий:

# Generated by iptables-save v1.4.5 on Sat Dec 24 22:35:13 2011
*filter
:INPUT ACCEPT  
:FORWARD ACCEPT 
.......
# комментарий
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
...........
-A FORWARD -j REJECT
COMMIT
# Completed on Sat Dec 24 22:35:13 2011
# Generated by iptables-save v1.4.5 on Sat Dec 24 22:35:13 2011
*raw
......
COMMIT

Строки, начинающиеся на # — комментарии, строки на * — это название таблиц, между названием таблицы и словом COMMIT содержатся параметры, передаваемые команде iptables. Параметр COMMIT — указывает на завершение параметров для вышеназванной таблицы. Строки, начинающиеся на двоеточие задают цепочки, в которых содержится данная таблица в формате:

:цепочка политика 

где цепочка — имя цепочки, политика — политика цепочки по-умолчанию для данной таблицы, а далее счетчики пакетов и байтов на момент выполнения команды.

В RedHat функции хранения команд iptables выполняемых при старте и останове сети выполняет файл /etc/sysconfig/iptables. А управление данным файлом лежит на демоне iptables.

Как еще один вариант сохранения правил, можно рассмотреть использование параметра up в файле /etc/network/interfaces с аргументом в виде файла, хранящего команды iptables, задающие необходимые правила.

Итог

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

Что такое Iptables?

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

Виды пакетов

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

Соответственно в фильтре iptables все пакеты делятся на три аналогичные цепочки:

• Input — обрабатывает входящие пакеты и подключения. Например, если какой-либо внешний пользователь пытается подключиться к вашему компьютеру по ssh или любой веб-сайт отправит вам свой контент по запросу браузера. Все эти пакеты попадут в эту цепочку;
• forward — эта цепочка применяется для проходящих соединений. Сюда попадают пакеты, которые отправлены на ваш компьютер, но не предназначены ему, они просто пересылаются по сети к своей цели. Как я уже говорил, такое наблюдается на маршрутизаторах или, например, если ваш компьютер раздает wifi;
• output — эта цепочка используется для исходящих пакетов и соединений. Сюда попадают пакеты, которые были созданы при попытке выполнить ping losst.ru или когда вы запускаете браузер и пытаетесь открыть любой сайт.

Но если вы думаете что можно просто полностью закрыть цепочку Input для увеличения безопасности, то вы очень сильно ошибаетесь. При работе сети используются обе цепочки input и output. Например, вы пытаетесь выполнить ping, данные отправляются через output, но ответ приходит через input. То же самое происходит при просмотре сайтов и других действиях. А вот цепочка forward может вообще не использоваться если ваш компьютер не является маршрутизатором. Так что настройка iptables должна выполняться очень аккуратно.

Правила и действия

Перед тем как перейти к созданию списка правил iptables нужно рассмотреть как они работают и какие бывают. Для каждого типа пакетов можно установить набор правил, которые по очереди будут проверяться на соответствие с пакетом и если пакет соответствует, то применять к нему указанное в правиле действие. Правила образуют цепочку, поэтому input, output и forward называют цепочками, цепочками правил. Действий может быть несколько:

• ACCEPT — разрешить прохождение пакета дальше по цепочке правил;
• DROP — удалить пакет;
• REJECT — отклонить пакет, отправителю будет отправлено сообщение, что пакет был отклонен;
• LOG — сделать запись о пакете в лог файл;
• QUEUE — отправить пакет пользовательскому приложению.

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

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

• prerouting — в эту цепочку пакет попадает перед обработкой iptables, система еще не знает куда он будет отправлен, в input, output или forward;
• postrouting — сюда попадают все проходящие пакеты, которые уже прошли цепочку forward.

Но это еще не все. У нас еще есть таблицы iptables, с которыми тоже желательно разобраться.

Заключение

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

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

1. Подготовили сервер Debian к настройке шлюза.
2. Настроили маршрутизацию, iptables, нат. Проверили, что весь функционал восстанавливается после перезагрузки.
3. Установили и настроили простой dhcp сервер и кэширующий dns сервер — dnsmasq. С его помощью автоматизировали поучение сетевых настроек пользователями.
4. Установили простое средство мониторинга сетевой активности в консоли в режиме реального времени с помощью утилиты iftop.

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

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

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

• Познакомитесь с Terraform.
• Изучите систему управления конфигурацией Ansible.
• Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
• Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
• В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .

Помогла статья? Подписывайся на telegram канал автора