В различных версиях ядра Linux используются разные механизмы фильтрации сетевых пакетов.

Самый ранний с исторической точки зрения механизм ipfw, управляемый командой ipfwadm, использовался в ядрах 1.2 - 2.2.

В версии 2.2.10 появился механизим ipchains, который позволил создавать "подпрограммы" из правил, но ещё не умел отслеживать состояние соединений.

С версии 2.4 появился механизм с поддержкой состояний — netfilter, который управляется программой iptables.

С версии 3.13 добавлен механизм nftables, заменяющий iptables, ip6tables, arptables и ebtables. nftables управляется утилитой nft.

В настоящий момент основным механизмом предлагается сделать bpfilter, на основе виртуальной машины eBPF.

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

iptables — явное создание, удаление, печать правил netfilter

UFW — генерация правил на основе существующих шаблонов в Ubuntu

Создание ключей с помощью EasyRSA

Для того, чтобы администратору не пришлось вникать в подробности работы с openssl, вместе с OpenVPN поставляется набор скриптов для генерации ключей — EasyRSA.

Для работы OpenVPN с авторизацией по ключам требуется не менее семи файлов.

Серверная константа для Diffie-Hellman — dh1024.pem. Создается командой build-dh.

Ключ и самоподписанный сертификат удостоверяющего центра (CA) — ca.key, ca.crt. Создаются командой build-ca.

Ключ сервера и сертификат ключа сервера, подписанный ca.key, — server.key, server.crt. Создаются командой build-key-server.

Ключи и сертификаты для клиентов. Сертификаты подписаны ca.key. Создаются командой build-key или build-key-pass.

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

Конфигурация ключей на сервере:

dh /etc/openvpn/dh1024.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key

Конфигурация ключей на клиенте:

ca ca.crt
cert client.crt
key client.key

Сертификат удостоверяющего центра ca.crt обычно один и тот же, что на сервере, что на клиенте. Он используется для верификации целостности собственного ключа (проверка, что ключ соответствует сертификату и что сертификат подписан CA) и для проверки сертификата партнера.

Если заменить (испортить) ca.crt то при попытке соединения выдается ошибка VERIFY ERROR: depth=0, error=unable to get local issuer certificate

Окончание времени жизни сертификатов

С настройками по умолчанию EasyRSA генерирует сертификаты на десять лет. Через десять лет после выпуска сертификата CA срок его действия закончится на сервере и у всех клиентов. Кроме того, поскольку сертификат сервера обычно генерируют сразу вслед за созданием CA, в то же время закончится и срок действия сертификата сервера. При попытке подключиться клиентам выдается ошибка VERIFY ERROR: depth=0, error=certificate has expired: CN=server, serial=123

Для решения проблемы надо средствами openssl перевыпустить сертификат CA. Новый сертификат CA надо будет установить на сервере и у всех клиентов.

Генерация самоподписанного сертификата CA с использованием атрибутов из старого сертификата:

mv ca.crt old-ca.crt
openssl x509 -in old-ca.crt -days 3650 -out ca.crt -signkey ca.key

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

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

Обновление сертификата средствами openssl:

openssl x509 -x509toreq -in server.crt -signkey ca.key -out server.csr
openssl x509 -in server.csr -out server.crt -signkey ca.key -req -days 3650

VLAN

$ nmcli con add type vlan ifname VLAN10 dev enp1s0 id 10
Connection 'vlan-VLAN10' (37750b4a-8ef5-40e6-be9b-4fb21a4b6d17) successfully added.

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

1. Файл, описывающий сокет, на котором ожидается соединение;
2. Файл, описывающий сервис - программу, которую надо запустить после подключения клиента к сокету.

В файле сокета ListenStream - указывает на протокол TCP (для UDP используется параметр ListenDatagram=). В качестве значения ListenStream может быть указан номер порта или пара IP:Port. Параметр Accept=yes указывает на то, что для каждого подключения надо стартовать отдельный экземпляр программы. Чтобы проинформировать приложение о свойствах соединения, ему передаются переменные окружения REMOTE_ADDR и REMOTE_PORT.

/etc/systemd/system/baz.socket:

[Unit]
Description=Baz Socket

[Socket]
ListenStream=127.0.0.1:9999
Accept=yes

[Install]
WantedBy=sockets.target

Имя файла сервиса должно заканчиваться на @, чтобы указать, что одновременно может быть запущено много экземпляров данной программы. В данной конфигурации стандартный ввод программы будет назначен на /dev/null, стандартный вывод будет перенаправлен в сокет, сообщения об ошибках будут сохранены в логах journald. Программа может быть написана на чем угодно. Переменным окружения VAR1 и VAR2 будут назначены значения "word1 word2" и 'word3" соответственно, текущий каталог будет изменен на /tmp, вместо %i будет подставлено имя экземпляра программы, которое также будет видно в списке запущенных сервисов между @ и .service.

/etc/systemd/system/baz@.service:

[Unit]
Description=Baz Service
Requires=baz.socket

[Service]
Type=simple
Environment="VAR1=word1 word2" VAR2=word3
ExecStart=/usr/local/baz %i
WorkingDirectory=/tmp
StandardInput=socket
StandardOutput=socket
StandardError=journal
TimeoutStopSec=5

[Install]
WantedBy=multi-user.target

/usr/local/bin/baz:

#!/bin/bash
pwd
echo ${VAR1}
echo ${VAR2}
echo $1

Отключение IPv6 в ядре

Добавляем в файл /etc/sysctl.conf (или куда-нибудь в /etc/sysctl.d/50-noipv6.conf) строки

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Обновляем текущую конфигурацию ядра sysctl -p.

Применяем настройки к сетевым интерфейсам systemctl restart network

Проверяем адреса на сетевых интерфейсах ip addr

Отключение IPv6 в Apache

В конфигурации исправляем директиву Listen 80 на

Listen 0.0.0.0:80

Отключение IPv6 в Squid

Добавляем в squid.conf

dns_v4_first on

Отключение IPv6 в Postfix

В main.cf

inet_protocols = ipv4

Отключение IPv6 в BIND

Для того, чтобы сам BIND не использовал IPv6 при запуске надо указать опцию -4. В CentOS это делается строчкой в файле /etc/sysconfig/named

OPTIONS="-4"

Дополнительно можно добавить в named.conf опцию

listen-on-v6 port 53 { none; };

Для того, чтобы BIND не выдавал записи AAAA (адреса IPv6) клиентам, подключенным по IPv4 необходимо добавить в файл named.conf опцию

filter-aaaa-on-v4 yes;

Для доступа к сетевым картам в Linux используются так называемые интерфейсы. Интерфейсы это не файлы устройств и их нет в каталоге /dev. Интерфейсы создаются динамически и не всегда связаны с сетевыми картами. Например интерфейс ppp0 - это интерфейс VPNа, организованного по протоколу PPTP, а интерфейс lo это виртуальная сетевая карта с адресом localhost (127.0.0.1). В Linux имена интерфейсов традиционно состоят из мнемонического типа интерфейса и его порядкового номера. Карты ethernet доступны через интерфейсы eth0, eth1 и т.д. В системах, использующих systemd способ именования другой - интерфейсы имеют имена вида enp2s0 (en -Ethernet, p - PCI, 2 - номер на шине) Список всех интерфейсов можно посмотреть командой ifconfig -a или ip link.

Привязка интерфейса к карте

При наличии нескольких сетевых карт возникает вопрос о порядке их нумерации. В CentOS 6 эта задача возложена на подсистему обнаружения и конфигурации устройств - udev. В системах с systemd правила именования встроены в udev, но могот быть переопределены, как написано ниже.

Конфигурационный файл переименования интерфейсов обновляется автоматически при первом обнаружении очередной сетевой карты и находится в файле /etc/udev/rules.d/70-persistent-net.rules. Файл состоит из строк такого содержания:

# PCI device 0x1af4:0x1000 (virtio-pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:29:24:1e", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Видно, что нумерация опирается на аппаратный (MAC) адрес карты. Если в компьютере заменить карту, то интерфейс eth0 станет недоступным, а новая карта получит имя eth1. Если есть желание вручную назначить имена картам, то можно отредактировать этот файл, выставив желаемые соответствия между MAC адресами именами интерфейсов (возможно потребуется перезагрузка).

ifcfg

Классическая утилита конфигурации сетевых интерфейсов ifcfg

#просмотр списка активных интерфейсов
ifcfg

#просмотр конфигурации конкретного интерфейса
ifcfg eth0

#просмотр списка доступных интерфейсов
ifcfg -a

#настройка ip адреса и активация интерфейса
ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up 

#деактивация интерфейса
ifconfig eth0 down

route

Настройка таблицы маршрутизации route

#добавление шлюза по умолчанию
route add default gw 192.168.0.1

#добавление маршрута в локальную сеть
 route add -net 192.56.76.0 netmask 255.255.255.0 dev eth0

#добавление маршрута в удаленную сеть
route add -net 192.57.66.0 netmask 255.255.255.0 gw 192.168.0.2

#удаление маршрута
route del -net 192.57.66.0 netmask 255.255.255.0 gw 192.168.0.2

#просмотр таблицы маршрутизации
route
#или
netstat -r

ip

В современных дистрибутивах линукса на смену ifconfig и route приходит универсальная утилита ip

#просмотр списка доступных интерфейсов
ip link

#просмотр статистики по интерфейсам
ip -s link

#просмотр ip адресов
ip addr

#просмотр таблицы маршрутизации
ip route

DNS

Адреса серверов DNS и имя локального домена вписываются в файл /etc/resolv.conf

search example.com
nameserver 8.8.8.8

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

Конфигурация xinetd, как правило, разделяется на две части: значения по умолчанию – /etc/xinetd.conf и настройки для отдельных служб, по одному файлу в каталоге /etc/xinetd.d/ на службу.

Чтобы запустить свою сетевую службу, необходимо создать ещё один файл в /etc/xinetd.d/. Имя файла особого значения не имеет, но обычно выбирается по имени службы. Предположим, что служба называется mynetd, запускается от имени пользователя user1 и выполняет команду sleep 10. Служба должна ожидать TCP соединение на порту 8888.

Конфигурационный файл /etc/xinetd.d/mynetd будет выглядеть так:

service mynetd
{
    disable = no
    # Если не написать UNLISTED, то xinetd будет искать имя службы и номер порта
    # в файле /etc/services
     type = UNLISTED

    # stream = TCP, datagram = UDP
    socket_type = stream
    port = 8888
    # Можно считать, что для протокола TCP wait всегда равен 'no',
    # а для протокола UDP – всегда 'yes'
    wait = no

    user = user1
    # При считывании конфигурации файл службы должен существовать и заданный пользователь
    # должен иметь право на его выполнение
      server = /bin/sleep
      server_args = 10
}

Параметр wait интерпретируется следующим образом: если socket_type = datagram и wait = yes, то при появлении на порту данных стартует новый процесс со входом/выходом, перенаправленным в сокет. Пока этот процесс не завершится, xinetd не контролирует наличие новых данных на порту, оставляя их запущенной программе. Если поставить wait = no, то на каждую дейтаграмму будет запускаться новый процесс, разделяющий со своими предшественниками общий сокет. В такой ситуации невозможно предсказать, какой копии программы достанутся входные данные из сокета. В принципе, такой подход возможен, если обработка дейтаграммы идёт долго, а писать многопоточный сервис лень. Для TCP ситуация обратная, wait = yes имеет смысл только для многопоточных программ, иначе первый процесс захватит сокет и не отдаст его, пока программа не завершится.

Ограничение трафика на маршрутизаторе делается в два этапа:
1. Классификация пакетов с помощью netfilter или фильтров iproute2
2. Создание нескольких очередей пакетов с помощью iproute2

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

Классификация пакетов с iptables

Первый этап выполняется с помощью программы /sbin/iptables.

Маркируем пакеты в зависимости от каких либо параметров, например по размеру, номеру порта, ip адресу. Для специфических случаев можно дописывать свои модули для netfilter. Например модуль IP2P http://www.ipp2p.org позволяет выбирать пакеты p2p сетей.

Приписываем класс пакета в соответствии с проставленными меткам

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

iptables -t mangle -A POSTROUTING -o eth0 -s 0/0 --source-port 80 -j CLASSIFY --set-class 1:10

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

Пример классификации P2P трафика. Классы для различных интерфейсов определяются независимо, что позволило использовать класс 1:20 для входящего и для исходящего трафика.

iptables -t mangle -A PREROUTING -p tcp -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -p tcp -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp -m ipp2p --ipp2p -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -p tcp -m mark --mark 1 -j CONNMARK --save-mark

iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 1 -j CLASSIFY --set-class 1:20
iptables -t mangle -A POSTROUTING -o eth1 -m mark --mark 1 -j CLASSIFY --set-class 1:20

Создание очередей пакетов

Этап второй выполняется с помощью /sbin/tc.

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

Теперь каждый пакет попадает в свою очередь. Если очередь переполняется, пакеты отбрасываются не доходя до аппаратного уровня.
Пример: Общая пропускная способность канала 10 Мбит/с. Внешний интерфейс eth0, внутренний eth1. Ограничиваем исходящий трафик P2P сетей из предыдущего примера полосой 32 Кбит/с, входящий 256 Кбит/с.

/sbin/tc qdisc add dev eth0 root handle 1: htb default 10
/sbin/tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit
/sbin/tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit
/sbin/tc class add dev eth0 parent 1:1 classid 1:20 htb rate 32kbit

/sbin/tc qdisc add dev eth1 root handle 1: htb default 10
/sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate 10mbit
/sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate 10mbit
/sbin/tc class add dev eth1 parent 1:1 classid 1:20 htb rate 256kbit

Пример стартового скрипта /etc/init.d/shaper (написан не мною и не связан с примером iptables)

#!/bin/sh
# init script written by shane at knowplace dot org
# this script only creates the qdiscs and classes required for shaping, it
# does NOT create the necessary filters

INTERFACE='eth0'
rc_done=" done"
rc_failed=" failed"

return=$rc_done

TC='/sbin/tc'

tc_reset ()
{
# Reset everything to a known state (cleared)
$TC qdisc del dev $INTERFACE root 2> /dev/null > /dev/null
}

tc_status ()
{
echo "[qdisc - $INTERFACE]"
$TC -s qdisc show dev $INTERFACE
echo "------------------------"
echo
echo "[class - $INTERFACE]"
$TC -s class show dev $INTERFACE
}

tc_showfilter ()
{
echo "[filter - $INTERFACE]"
$TC -s filter show dev $INTERFACE
}

case "$1" in

start)
echo -n "Starting traffic shaping"
tc_reset
U320="$TC filter add dev $INTERFACE protocol ip parent 1:0 prio 0 u32"
#
# dev eth0 - creating qdiscs & classes
#
$TC qdisc add dev $INTERFACE root handle 1: htb default 60
$TC class add dev $INTERFACE parent 1: classid 1:1 htb rate 116kbit
$TC class add dev $INTERFACE parent 1:1 classid 1:10 htb rate 32kbit ceil 116kbit prio 0
$TC class add dev $INTERFACE parent 1:1 classid 1:20 htb rate 22kbit ceil 116kbit prio 1
$TC class add dev $INTERFACE parent 1:1 classid 1:30 htb rate 22kbit ceil 116kbit prio 2
$TC class add dev $INTERFACE parent 1:1 classid 1:40 htb rate 20kbit ceil 116kbit prio 3
$TC class add dev $INTERFACE parent 1:1 classid 1:50 htb rate 18kbit ceil 116kbit prio 4
$TC class add dev $INTERFACE parent 1:1 classid 1:60 htb rate 2kbit ceil 116kbit prio 5
$TC qdisc add dev $INTERFACE parent 1:10 handle 10: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:20 handle 20: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:30 handle 30: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:40 handle 40: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:50 handle 50: sfq perturb 10
$TC qdisc add dev $INTERFACE parent 1:60 handle 60: sfq perturb 10
tc_status
;;

stop)
echo -n "Stopping traffic shaper"
tc_reset || return=$rc_failed
echo -e "$return"
;;

restart|reload)
$0 stop && $0 start || return=$rc_failed
;;

stats|status)
tc_status
;;

filter)
tc_showfilter
;;

*)
echo "Usage: $0 {start|stop|restart|stats|filter}"
exit 1

esac
test "$return" = "$rc_done" || exit 1
##################################

Примечания.

В параметрах iptables цель CLASSIFY в iptables может использоваться только в таблице mangle и только в цепочке POSTROUTING.

В параметрах tc встречаются сокращения:
qdisc – Classful Queuing Disciplines – базовый объект связанный с сетевым интерфейсом и обеспечивающий управление очередями
htb – Hierarchical Token Bucket – имя собственное одного из планировщиков очередей пакетов в ядре Linux

Имена классов имеют вид M:N. M: эквивалентно M:0 и используется для создания общего корня очередей (хэндлера) связанного напрямую с интерфейсом.