Общая задача межсетевого экранирования

Цель: избавиться от нежелательного сетевого трафика (в случае МЭ для Unix речь идёт о программной защите)

Задачи: работа с сетевым трафиком:

1. Фильтрация
2. Ограничение
3. Перенаправление
4. Преобразование
5. Отслеживание

Причины:

• Административные требования
• Расширение логики TCP/IP

Примеры использования МЭ в TCP/IP

(Это далеко не все примеры )

1. Аппаратный уровень — ?

2. Интерфейсный уровень — фильтрация MAC и отслеживание подмены/дублей

3. Сетевой

   1. Фильтрация по IP, антиспуф
   2. Ограничение пропускной способности по IP (недостатки), приоритизация
   3. Policy routing
   4. NAT «1 — 1»
   5. Грубый подсчёт сетевой активности

4. Транспортный

   1. Фильтрация по порту
   2. Ограничение пропускной способности TCP и количества TCP-соединений
   3. «Проброс портов» без модификации пакета, используется редко (почему?)
   4. NAT «много — 1», «проброс портов»
   5. Отслеживание активности по портам (например, запредельное количество TCP-соединений)

5. Прикладной. В основном все задачи должно делать само приложение. Исключения: контент-фильтрация (например, почтовый антивирус, антиспам) и поиск информации для определения «состояния потока данных» (например, для работы DNS по UDP).

Организация «МЭ уровня ядра»

1. Поддержка изменяемой логики работы TCP/IP в ядре
2. Язык задания этой логики
3. Утилиты пространства пользователя для оперативной работы с ядерной составляющей
4. Сложность понятия «пакет» в стеке TCP/IP ядра («пакет» какого уровня?)
5. Сложность фиксации точки принятия решения (различные пути обработки пакетов)

Три-четыре примера языка описания МЭ

Общий принцип: свод правил МЭ состоит из одиночных записей вида

тест пакета → действие

Заметно влияние Нормальных Алгоритмов Маркова

1. «Линейный» (ipfw) воспроизводит работу НАМ: правила в столбик, first wins
   • Достоинства: простота, гибкость
   • Недостатки: неструктурированность, трудно отследить точку принятия решения, goto
2. «Граф» (iptables) представляет собой несколько НАМ-машин («цепочек»), передающих друг другу пакеты, first wins
   • Достоинства: большинство типичных задач требуют только дополнения имеющихся цепочек ⇒ очевидный граф
   • Недостатки: сложные задачи требуют конструирования новых цепочек и логико «прыжков» из одной в другую ⇒ неочевидный граф
3. «Таблица» (pf): правила просматриваются по принципу last wins (т. е применяются все, а потом принимается решение, что делать с пакетом)
   • Достоинства: возможность использования сложных атомарных правил и именованных групп правил («якорей»), хеш-таблиц, гарантированное время прохождения пакета
   • Недостатки: долгое прохождение пакета через длинные списки правил,

Альтернативный подход (shorewall): компилировать высокоуровневое описание (скажем, структуры сети и абонентских служб) в нечитаемой множество правил.

Работа в FreeBSD и ipfw

Настройки VirtualBox

• Внешний интерфейс: «VirtualBox NAT» ⇒ 10.0.2.15/24

• Внутренний интерфейс 10.30.50.1/24
• Доступ по ssh localhost:2212

• каталог с образом

FreeBSD

Особенности FreeBSD

• Базовая дистрибуция + пакеты (пакетный диспетчер pkg)

• Установка пакетов в /usr/local (в т. ч. /usr/local/etc, /usr/local/man и т. п.)

• Приверженность legacy (nvi, ifconfig, netstat, route, sh)

• Пользователь toor (tcsh в качестве оболочки для root)

• Редактор: vi, ee или установить vim (pkg install vim)

• Оболочка: sh или установить bash/zsh

• Просмотр сокетов (в т. ч. TCP): sockstat

• Достаточно полная и связная система man-страниц; /usr/share/doc и /usr/share/examples

Подсистема запуска служб RC

История развития rc:

• /etc/rc → … + /etc/rc.conf→ … + /etc/defaults/rc.conf

• … + /etc/rc.d/; service (start, stop, restart, rcvar, onestart и т.п.)

  • Зависимости служб,

• Включение cлужбы в /etc/rc.conf: служба_enabled="YES"

IPFW

Основная статья: IPFW в FreeBSD handbook (несколько устаревший русский перевод

Архитектура

• Список правил вида: действие ← фильтр

  • полный вид:RULE_NUMBER set SET_NUMBER ACTION log LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT OPTIONS

  • например, 420 allow tcp from any to me 80 in via em0 setup

• Финальные действия (вида «побеждает первый»): allow, deny и т. п.

• Проходные действия: log, count, skipto и т. п.

• Последнее правило: 65535 deny ip from any to any (net.inet.ip.fw.default_to_accept="1" ⇒ 65535 allow …)

Утилита ipfw: работа со списком правил

• add, delete, swap и т. п.

• flush и что будет, если выполнить только ipfw flush

• автоматическая нумерация (шаг 100)

• list, show и zero

Запуск: service ipfw и /etc/rc.firewall

• Виды профилей МЭ по умолчанию (open, simple, silent и т. п.)
• Кастомный профиль: имя shell-сценария

Задача удалённого редактирования правил:

• Отредактировать сценарий или настройки
• Перезагрузить ipfw
• В течение тайм-аута ждать подтверждение
• Если подтверждения нет, вернуться к исходному набору правил

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

Примерная реализация:

• /usr/share/examples/ipfw/change_rules.sh

Д/З

Скачать и заставить работать стендовую виртуальную машину (два файла с именем FW_что-то там).

Поменять на simple значение firewall_type в /etc/rc.conf (МЭ перезапускается с помощью service ipfw restart) . Почему при этом нельзя подключиться к машине по SSH? Как исправить?

Использование IPFW

Базовые статьи FreeBSD Handbook, ipfw, divert, dummynet

Общий вид правила:

[rule_number] [set set_number] [prob match_probability] action [log [logamount number]] [altq queue] [{tag | untag} number] body

action:

• allow, deny, unreach ICMPTYPE, reset; count
• check-state (+первое правило с keep-state/limit)
• skipto#, call# / return
• divert DIVPORT, tee DIVPORT
• fwd IP [PORT]
• pipe#, qeue#
• reass
• setfib#

• Прочее: nat#, netgraph COOKIE, ngtee COOKIE (см. netgraph)

body: [proto from src to dst] [options]

proto (/etc/protocols), all

src,dst: any | me | table# | addr(+/mask) addrlist [ports]

ports: port,port-port[ports]

OPTIONS

• bridged layer2
• mac(dst-mac,any src-mac,any) mac-typeTYPE
• icmptypesTYPES
• protoPROTO
• in out
• {recv|xmit|via}IFACE
• ipidLIST iplenLIST ipoptionsSPEC ipprecedencePREC ipsec iptosSPEC ipttlLIST ipversionVER
• frag
• dscpSPECS
• diverted diverted-loopback diverted-output
• dst-ipIP dst-portPORTS src-ipADDRS src-portPORTS
• keep-state limit{src-addr|src-port|dst-addr|dst-port}#
• tcpackACK tcpdatalenLIST tcpflagsSPEC tcpseqSEQ tcpwinLIST tcpoptionsSPEC established (RST|ACK), setup (tcpflags syn,!ack)
• taggedLIST
• gidGID, uidUID
• fib#
• jail#
• lookup {dst-ip|dst-port|src-ip|src-port|uid|jail}#
• verrevpath versrcreach antispoof

LOOKUP TABLES — аналог таблиц маршрутизации (+/MASK), но +порт,jail#,IP и ifacename

SETS OF RULES — 0-31 (неубиваемый), нумерация правил общая, enable/disable/flush, move, swap

STATEFUL FIREWALL

    ipfw add check-state
    ipfw add allow tcp from my-subnet to any setup keep-state
    ipfw add deny tcp from any to any

Dynamic rules are created when a packet matches a keep-state or limit rule

ipfw -d -e show

DIVERT SOCKET:

• divert

• просто bind(2)

• Пример: natd

DUMMYNET

• pipe, queue, sched
• pipe # config …:
  • bw bandwidth|iface
  • delay ms-delay
  • burst size (если труба была пустая, пускать больше)
  • profile filename (сложный профиль)
  • buckets hash-table-size
  • mask mask-specifier
  • noerror
  • plr packet-loss-rate
  • queue {slots | sizeKbytes}
  • red | gred параметры

LOG:

• syslog (net.inet.ip.fw.verbose=1)

• fconfig ipfw0 create ⇒ …

Д/З

Разбор группы правил из FreeBSD handbook.

Практиковаться можно на виртуальной машине FW

Введение в FreeBSD PF

Daniel Hartmeier (CX, 2001) (ip/ipnat gone)

http://ru.wikipedia.org/wiki/Packet_Filter

ядро + pfctl

Принципы:

• Last wins:
  • оптимизация правил и быстрый просмотр (⇒ большие объёмы правил, напр., генераты)
  • предсказуемое время
  • ⇒ быстрый поиск (таблицы адресов)
  • «якоря» (множества правил)
  • …
• Команда = задача:
  • ⇒ списки и макросы (развёртываются в несколько правил) + таблицы
  • комплексные понятия (напр., state: +icmp, обслуживающий соединения; +UDP, NAT, …)
  • умолчания (напр., keep state по умолчанию, разные тайминги и т. п.)
  • различные формы (напр, адрес-ip ≠ адрес-FQDN, можно и то и то)
  • Атомарные задачи: scrub, reassemble, antispoof, OS fp, …
  • очереди и шейпинг

Уровень IP и выше.

Порядок правил:

1. options
2. normalization
3. queueing
4. translation
5. filtering

pfctl

Command Purpose

pfctl -e Enable PF.

pfctl -d Disable PF.

pfctl -F all -f /etc/pf.conf Flush all NAT, filter, state, and table rules and reload /etc/pf.conf.

pfctl -s [ rules | nat state ] Report on the filter rules, NAT rules, or state table.

pfctl -vnf /etc/pf.conf Check /etc/pf.conf for errors, but do not load ruleset. -a anchor

pflog

dev pflog0 + pflogd (=tcpdump)

Пример

#
# Firewall for Home or Small Office
# http://www.openbsd.org/faq/pf/example1.html
#


# macros
ext_if="em0"
int_if="le0"

tcp_services="{ 22, 13 }"
icmp_types="echoreq"

comp3="10.30.50.3"

# options
set block-policy return
set loginterface $ext_if

set skip on lo

# scrub
scrub in

# nat/rdr
nat on $ext_if inet from !($ext_if) -> ($ext_if:0)

rdr on $ext_if proto tcp from any to any port 80 -> $comp3

# filter rules
block in

pass out

antispoof quick for { lo $int_if }

pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services

pass in on $ext_if inet proto tcp from any to $comp3 port 80 synproxy state

pass in inet proto icmp all icmp-type $icmp_types

pass quick on $int_if no state

pfsync/CARP

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-pf.html

http://www.freebsd.org/cgi/man.cgi?query=pfctl

http://www.freebsd.org/cgi/man.cgi?query=pf.conf

http://www.openbsd.org/faq/pf/filter.html

Особенности FreeBSD/OpenBSD PF

OpenBSD: отказ от разделения преобразующих (nat, rdr) и фильтрующих (bass, block) команд.

pass out on ext_interface from src_addr to dst_addr nat-to ext_addr

    или

match out on ext_interface from src_addr to dst_addr nat-to ext_addr
…
pass out on ext_interface from src_addr to dst_addr
 
    и

pass in on ext_interface other_filters port ext_port rdr-to int_server [int_port]

см. в PF FAQ

Синтетическое понятие «состояние» PF

Состояние — это набор информации, необходимый для преобразования/перенаправления/допуска потока данных. См., например, два состояния, сохранённых для ping из внутренней сети.

fw-bsd# pfctl -ss
No ALTQ support in kernel
ALTQ related functions disabled
all tcp 10.0.2.15:22 <- 10.0.2.2:38548       ESTABLISHED:ESTABLISHED
all tcp 10.0.2.15:22 <- 10.0.2.2:38559       ESTABLISHED:ESTABLISHED
all tcp 10.30.50.1:18550 -> 10.30.50.3:22       ESTABLISHED:ESTABLISHED
all tcp 10.30.50.3:80 (10.0.2.15:80) <- 10.0.2.2:35520       FIN_WAIT_2:FIN_WAIT_2
all tcp 10.0.2.2:35520 -> 10.30.50.3:80       FIN_WAIT_2:FIN_WAIT_2
all udp 10.30.50.1:53 <- 10.30.50.3:59363       SINGLE:MULTIPLE
all udp 10.0.2.15:55546 -> 192.168.11.1:53       MULTIPLE:SINGLE
all icmp 144.76.222.201:3782 <- 10.30.50.3:3782       0:0
all icmp 10.0.2.15:25608 (10.30.50.3:3782) -> 144.76.222.201:25608       0:0

Понятия "modulate sate" и "synproxy state". Назначение SYN proxy.

Списки, макросы и таблицы

• Списки: одно правило в pf.conf → N правил

• Макросы: переменные
• Таблицы: логарифмический поиск, модификация из userspace без модификаций правил

Пример поиска по таблице. Обратите внимание на особенность интерпретации записи вида «!адрес»

Заполнение таблицы по параметру overload.

Разбор примера

# Firewall for Home or Small Office
# http://www.openbsd.org/faq/pf/example1.html

# macros
ext_if="em0"
int_if="le0"

tcp_services="{ 22, 13 }"
icmp_types="echoreq"

comp3="10.30.50.3"

# options
set block-policy return
set loginterface $ext_if

set skip on lo

# scrub
scrub in

# nat/rdr
nat on $ext_if inet from !($ext_if) -> ($ext_if:0)

rdr on $ext_if proto tcp from any to any port 80 -> $comp3

# filter rules
block in

pass out

antispoof quick for { lo $int_if }

pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services

pass in on $ext_if inet proto tcp from any to $comp3 port 80 synproxy state

pass in inet proto icmp all icmp-type $icmp_types

pass quick on $int_if no state

Замечание (на лекции было замято): параметр loginterface определяет, из какого интерфейса пакеты будут перекладываться в pflog0, чтобы их можно было проанализировать pflogd.

Д/З

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

1. FW-PFBSD: сервер, доступ по ssh localhost -p2212, доступ на 80-порт http://localhost:8012

2. FW-client: клиент с единственной сетью (intnet), адрес 10.30.50.3 (можно попасть из консоли virtualbox или ssh с сервера)

Что можно сделать:

• Посмотреть правила в /etc/pf.conf

• Посмотреть, во что они превращаются: pfctl -sa

• Обратить внимание на якорь (подробнее о якорях — на одной из следующих лекций)

• Подключиться к http://localhost:8012 (проброс на сервер → проброс средствами PF на клиент)

  • Посмотреть таблицу состояний pfctl -ss

• Подключиться с клиента куда-нибудь по какому-нибудь протоколу

  • Посмотреть таблицу состояний pfctl -ss

Linux IPTables

Виды МЭ (условно):

• линейный (ipfw)
• табличный (pf)
• графовый (iptables)

IPTables

Ключевая ссылка IPTables HowTo

Общее устройство https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html (довольно старый перевод):

• ядерная часть + утилита управления iptables

• «Пакеты» транспортного и сетевого уровня

• Правила обработки пакетов: условие → действие по принципу «кто первый попал»

• Правила объединены в цепочки (действие выглядит как переход в другую цепочку)
• Цепочки бывают разного типа (это называется «цепочка из таблицы»)
• Переход между цепочками по умолчанию:

Естественный граф обработки проходящих пакетов:

• Возврат из пользовательских цепочек

Команды (над цепочками):

• -A, -D, -R №, -I №
• -F, -Z
• -N, -X

Параметры:

• -t Table (по умолчанию — filter)

Действия:

• ACCEPT, DROP, REJECT, RETURN
• SNAT, DNAT, MASQUERADE, NETMAP
• LOG, ULOG
• MARK, CONNMARK
• QUEUE
• …

Условия:

• -s, -d (IP); -i, -o (iface)
• -p протокол, --sport, --dport
• --icmp-type №

• -m подмодуль

  • mark, connmark
  • conntrack, state (TCP)
  • helper (прикладной уровень)
  • owner (как имя процесса, так и IDs)
  • recent

Особенности IPTables

Различие «BSD» и «Linux» подхода к разработке

• «Linux»: upstream → пакет → хранилище → дистрибутив. Все пакеты примерно равноправны и подчиняются дисциплине разработки. Приоритет пакетов выбирается при формировании дистрибутива
• «BSD»: базовый дистрибутив + upstream → пакеты. Больше ответственности за базовый дистрибутив, меньше — за пакеты.

IPTables extensios

Базовая статья: iptables-extensions

Разбор примера

ALT Linux Centaurus Server 7.0.3 по умолчанию+проброс порта):

[root@srv ~]# iptables-save  
# Generated by iptables-save v1.4.18 on Fri Apr  4 14:38:01 2014
*mangle
:PREROUTING ACCEPT [27:2118]
:INPUT ACCEPT [27:2118]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [20:2782]
:POSTROUTING ACCEPT [20:2782]
COMMIT
# Completed on Fri Apr  4 14:38:01 2014
# Generated by iptables-save v1.4.18 on Fri Apr  4 14:38:01 2014
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 10.0.2.15/32 -p tcp -m tcp --dport 2222 -j DNAT --to-destination 192.168.62.2:22
-A OUTPUT -d 10.0.2.15/32 -p tcp -m tcp --dport 2222 -j DNAT --to-destination 192.168.62.2:22
-A POSTROUTING -o enp0s3 -j MASQUERADE
COMMIT
# Completed on Fri Apr  4 14:38:01 2014
# Generated by iptables-save v1.4.18 on Fri Apr  4 14:38:01 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -f -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j ULOG --ulog-prefix icount --ulog-cprange 48 --ulog-qthreshold 50
-A INPUT -i enp0s3 -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -i enp0s3 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i enp0s3 -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -i enp0s3 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i enp0s3 -p udp -m udp --dport 22 -j ACCEPT
-A INPUT -i enp0s3 -p icmp -j ACCEPT
-A INPUT -i enp0s3 -j DROP
-A FORWARD -f -j DROP
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j ULOG --ulog-prefix fcount --ulog-cprange 48 --ulog-qthreshold 50
-A FORWARD -d 192.168.62.2/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A FORWARD -d 10.0.2.0/24 -i enp0s3 -j ACCEPT
-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A FORWARD -i enp0s3 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i enp0s3 -j DROP
-A OUTPUT -f -j DROP
-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -j ULOG --ulog-prefix ocount --ulog-cprange 48 --ulog-qthreshold 50
COMMIT
# Completed on Fri Apr  4 14:38:01 2014

Д/З

• Пронаблюдать свод правил на Linux-стенде (машина FW-Centaurus). Можно установить самостоятельно (например, отсюда); в настройках машины надо задать два сетевых интерфейса, а при установке выбрать «установку сервера».

  • 22 порт → 2204

  • 8080 порт (веб-конфигуратор) → 8084 (точнее, https://localhost:8084 )

• Зайти в веб-конфигуратор, раздел «Внешние сети» и пр. Поменять настройки, посмотреть, что изменилось

Ограничение трафика

Цели:

• Приоритизация потоков
• Честное распределение пропускной способности
• Резервирование канала
• Имитация reallife сети
• …

Задачи:

• Классификация потоков
• Bandwidth: очереди и работа с ними
• Учёт специфики протоколов

Строго говоря, это отдельные задачи.

Замечание: незачем ограничивать уже полученный трафик ⇒ на отправку.

PF

Базовая статья: PF: Packet Queueing and Prioritization

PriQ

• Линейная структура: общая труба → очереди с приоритетами
• Строгая приоритизация (+RR в рамках одного приоритета)

Пример:

Root Queue (2Mbps)
    Queue A (priority 1) 
    Queue B (priority 2) 
    Queue C (priority 3)
    Queue D (priority 3)

Области применения: emergency-трафик, обслуживающий трафик на загруженных каналах (например, пустые TCP ACK при скачивании; см. пояснения в конце раздела «Assigning Traffic to a Queue»

CBQ

Иерархические очереди. Аналогия: река с притоками («водная система»)

• BW очереди = ∑ BW подочередей
  • borrow
  • приоритет (только на случай нехватки родительского BW)

RED и ECN

TCP: саморегуляция путём выбрасывания пакета.

Проблема: переполнение очереди ⇒ рестарт почти всех TCP-соединений

Решение: выбрасывать пакеты заранее: чем полнее очередь, тем больше вероятность потери пакета

Проблема: ограничение трафика путём увеличения трафика?

Протокол ECN

Задание в /etc/pf.conf

Описание очередей:

altq on fxp0 cbq bandwidth 2Mb queue { std, ssh, ftp }
  queue std bandwidth 50% cbq(default)
  queue ssh bandwidth 25% { ssh_login, ssh_bulk }
    queue ssh_login bandwidth 25% priority 4 cbq(ecn)
    queue ssh_bulk bandwidth 75% cbq(ecn)
  queue ftp bandwidth 500Kb cbq(borrow red)
…
pass out on $oif from any to any tcp queue std
pass out on $oif from any to any port 22 queue(ssh_bulk, ssh_login)
pass out on $oif from any to any port 20 queue ftp

HFSC

Базовая статья: Hierarchical Fair Service Curve (HFSC). Quality of Service for FreeBSD and OpenBSD Иерархические очереди плюс:

• разделение обещанного (realtime) и допустимого (upperlimit) трафика
• задание кривой пропускания (скажем, чем дольше передача, тем ниже BPS)
• без приоритизации вообще

Linux TC (первая попытка)

Базовая статья Linux Advanced Routing & Traffic Control HOWTO

• Разделение МЭ и управления очередями.
• Модульный принцип:

  • Множество модулей: например, NetEm — аналог DummyNet для BSD; используется на интерфейсном уровне

  • Дублирование функций (см. tc-htb(8): «HTB is meant as a more understandable and intuitive replacement for the CBQ qdisc in Linux»

  • Ещё модули (далеко не все!): http://lartc.org/manpages

Ограничение трафика: Linux TC и интерфейсный уровень

ToS

Поле IP-пакета. 4 бита (+3+1резервный) таблица отсюда:

TC

Базовые статьи:

• Linux Advanced Routing & Traffic Control HOWTO / Chapter 9. Queueing Disciplines for Bandwidth Management

• русский перевод

• попроще на Хабре

Userspace + поддержка в ядре + модули.

Отдельная подсистема (≠netfilter).

Работа с очередями пакетов («дисциплина обработки»):

• приоритизация (жесткое упорядочивание)
• переупорядочивание
• ограничение пропускной способности

Термины:

• дисциплина — очередь (или иная динамическая структура) пакетов и правила её обработки

• класс — поток пакетов; на конце этого потока либо очередь (по умолчанию fifo), либо родительский класс (тогда классы иерархические)

• фильтр — сканирование пакетов на предмет записывания их в классы

Бесклассовые очереди

Prioritized FIFO (pfifo_fast)

Чистая приоритизация. Три приоритетных очереди в зависимости от ToS.

Token Bucket Filter (TBF)

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

• ⇒ средняя скорость отсылки пакетов не превышает скорость прибытия жетонов
• ⇒ т. н. burst: если очередь пакетов пуста, а очередь из N жетонов полна, и внезапно™ прибывает много пакетов, первые N пакетов отошлются быстрее

Пример:

# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540

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

Stochastic Fairness Queueing (SFQ)

Чистое переупорядочивание.

Трафик классифицируется по «потокам» (грубо говоря, TCP-соединениям), каждый поток направляется в отдельную FIFO-очередь, а отсылка пакетов происходит по одному из каждой очереди.

Классовые очереди

Классы — потоки пакетов с определёнными свойствами (например, скорость отсылки или пропускная способность). Иерархические подклассы должны соответствовать этим свойствам (например, скорость отсылки или пропускная способность не выше, чем у родительского класса).

Классы и дисциплины (=очереди) в дереве обработки пакетов:

10:1  10:2   12:1  12:2   концевые классы
   \   /       \   /
    10:         12:       дисциплины
    |            | 
    |     11:    |        концевой класс
    |      |     | 
   1:10  1:11  1:12       классы 
      \    |    /
       \   |   /
        \  |  /
         \ | /
          1:1             класс
           |
          1:              корневая дисциплина

Идентификатор очереди всегда заканчивается на «:0» (или, что то же самое, на «:»).

Процесс:

1. Постановка пакета в классовую очередь:
   1. Постановка пакета в корневую очередь
   2. Классификация пакета

   3. Постановка пакета в очередь уровня k>0

   4. Классификация пакета

   5. Постановка пакета в очередь уровня l>k

   6. …
2. Отсылка пакета из классовой очереди:
   1. Прохождение очереди уровня N и передача в очередь уровня N-1
   2. …
   3. Прохождение корневой очереди и отсылка пакета

Пример:

1. 1: →  1:1 → 1:12 → 12: → 12:2

2. 12: → 1:

CBQ

Классы на основании времени ожидания отсылки пакета.

Считается малопонятной и устаревшей.

PRIO

Приоритетная классификация по ToS (как в pfifo), но пакеты помещаются в класс, который можно обработать дальше в графе. Класс :1 наиболее приоритетный.

Пример:

полоса  0    1    2
       sfq  tbf  sfq
       10:  20:  30:    дисциплины
        |    |    |
       1:1  1:2  1:3    классы
          \  |  /
           \ | /
            \|/ 
            1:          корневая дисциплина

Задание с помощью tc:

# tc qdisc add dev eth0 parent 1:1 handle 10: sfq
# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq                                

Hierarchical Token Bucket (HTB)

Классы на основании пропускной способности (по алгоритму TBF).

Пример:

   10:    20:    30:    sfq-очереди
     |      |     |
     1:10   1:20  1:30  подклассы
     5Mbit 3Mbit 1Kbit   
        \   |   /
         \  |  /
          \ | /
           1:1          класс
            |
           1:           корневая дисциплина (htb)

Описание классов:

# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k

Задание очередей:

# tc qdisc add dev eth0 root handle 1: htb default 30
# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
# tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

Классификация с помощью фильтра u32 (класс 30: по умолчанию) — разброс по 25 и 80 порту.

# U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
# $U32 match ip dport 80 0xffff flowid 1:10
# $U32 match ip sport 25 0xffff flowid 1:20

Примеры экзотических дисциплин

• CoDel — пакеты выбрасываются, если и так слишком долго задерживаются в очереди

• choke — вариант RED: если очередной пакет заходит за LO-mark и принадлежит тому же потоку данных, что и случайно выбранный из очереди пакет, выбрасыватся оба (⇒ чем толще поток, тем выше вероятность)

• drr — (deficit round robin), вариант SFQ с ручным разбиением на потоки (классы)

• …

Фильтры

(Again: работает не на уровне iptables)

Базовая статья: Advanced filters for (re-)classifying packets

• u32 — поля IP (и TCP/UDP)

  • В примере выше 0xffff — это битовая маска

• fw — пакеты, помеченные iptables
• route — куда направлен пакет
• hfsc — реализация HFSC для linux
• stab — подстановка других размеров пакетов при обработке их очередями
• …

МЭ на интерфейсном уровне

Задачи МЭ на интерфейсном уровне:

• Работа непосредственно с фреймами (фильтрация, перенаправление и отслеживание MAC-адресов и их полей)
• Обработка (по возможности) TCP/IP-трафика в сетевых мостах (bridge)
• Ограничение трафика и имитация свойств «настоящей» сети
• Работа на стыке интерфейсного и сетевого уровней (например, ARP)

Сетевой мост (bridge)

FreeBSD (возможна также настройка в /etc/rc.conf):

# ifconfig bridge0 create
# ifconfig bridge0 addm fxp0 stp fxp0 addm fxp1 stp fxp1
# ifconfig fxp0 bridge0 192.0.2.10 netmask 255.255.255.0

Linux

root@mbb-1:~ # brctl addbr mybridge
root@mbb-1:~ # brctl addif mybridge eth0
root@mbb-1:~ # brctl addif mybridge eth1
root@mbb-1:~ # ip addr add dev mybridge 192.168.100.5/24

Spanning Tree Protocol (STP)

Spanning Tree Protocol — пример того, что должно быть реализовано помимо простого перебрасывания фреймов из интерфейса в интерфейс. Задача: если топология сетевых устройств имеет циклы, избавиться от них.

1. Все главные (рассылка оповещений-фреймов с ID)
2. Если принятое оповещение главнее, пересылка его вместо своего (с добавлением также и собственного ID и стоимости пересылки)
3. Остаётся один главный
4. Если оповещение принято из нескольких интерфейсов, все более дорогие интерфейсы деактивируются

Алгоритм неидеальный, имеется множество неидеальных же модификаций (см.).

Имитация сети

образы виртуальных машин с Linux и FreeBSD в каталогах ALC703EFW и FWE-BSD соответственно. У каждой машины 3 сетевых интерфейса:

• типа «NAT» — для доступа по ssh из хост-системы (посмотрите, какой порт пробрасывается)
• 2 «внутренних» (сеть «intnet» и «intnet2»), собранных в мост

FreeBSD dummynet

• на сайте автора, Луиджи Риццо

• в документации по ipfw (раздел «TRAFFIC SHAPER (DUMMYNET) CONFIGURATION»)

Dummynet поддерживает абстрактные очереди и планировщики, но нас интересует «pipe» — имитация подключения к среде передачи данных заданной паршивости. Часть ipfw.

Пример: Файл /etc/rc.conf:

[root@fwe-bsd ~]# cat /etc/rc.conf
hostname="fwe-bsd.fw.cs.msu.su"
ifconfig_em0="dhcp"
dumpdev="NO"

sshd_enable="YES"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm le0 addm le1 up"
ifconfig_le0="up"
ifconfig_le1="up"

firewall_enable="YES"
firewall_type="/etc/rc.ebridge"
dummynet_enable="YES"

Файл /etc/rc.ebridge:

pipe 1 config bw 10Mbit/s
add pipe 1 ip from any to any via le* layer2
add allow ip from any to any via em0 layer2
add allow ip from any to any via lo0
add allow ip from any to any

Linux TC netem

Базовая статья: NETEM By Linux Foundation и tc-netem manual page

Network Emulator — модуль tc qdisc, привязывается непосредственно к интерфейсу (на выходе пакета).

Пример (если root-очередь в tc не указана, по умолчанию — pfifo_fast):

root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 1156 bytes 14 pkt (dropped 0, overlimits 0 requeues 1)
 backlog 0b 0p requeues 1
root@host-15 ~ # tc qdisc add dev enp0s8 root netem rate 256kbit delay 100ms
root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc netem 8001: root refcnt 2 limit 1000 delay 100.0ms rate 256000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

Пример использования нескольких настроек в Etcnet. Конфигурационные файлы:

root@host-15 ~ # grep -r . /etc/net/ifaces/[be]*
/etc/net/ifaces/bridge/options:TYPE=bri
/etc/net/ifaces/bridge/options:HOST='enp0s8 enp0s9'
/etc/net/ifaces/enp0s3/options:BOOTPROTO=dhcp
/etc/net/ifaces/enp0s3/options:TYPE=eth
/etc/net/ifaces/enp0s3/options:CONFIG_WIRELESS=no
/etc/net/ifaces/enp0s3/options:CONFIG_IPV4=yes
/etc/net/ifaces/enp0s8/options:TYPE=eth
/etc/net/ifaces/enp0s8/qos/1/qdisc#delay:netem delay 0.5ms loss 0.05% 25% corrupt 0.05%
/etc/net/ifaces/enp0s8/qos/1/qdisc#loss:netem loss 0.33% 25% corrupt 0.33%
/etc/net/ifaces/enp0s8/qos/1/qdisc#rate:netem loss 0.05% 25% corrupt 0.05% rate 10mbit
/etc/net/ifaces/enp0s8/qos/1/qdisc#LOSS:netem loss 5% 10% corrupt 5%
/etc/net/ifaces/enp0s8/qos/1/qdisc:pfifo_fast
/etc/net/ifaces/enp0s9/options:TYPE=eth
/etc/net/ifaces/enp0s9/qos/1/qdisc:pfifo_fast
/etc/net/ifaces/enp0s9/qos/1/qdisc#delay:netem delay 0.5ms loss 0.05% 25% corrupt 0.05%
/etc/net/ifaces/enp0s9/qos/1/qdisc#loss:netem loss 0.33% 25% corrupt 0.33%
/etc/net/ifaces/enp0s9/qos/1/qdisc#LOSS:netem loss 5% 10% corrupt 5%
/etc/net/ifaces/enp0s9/qos/1/qdisc#rate:netem loss 0.05% 25% corrupt 0.05% rate 10mbit

Пояснение. Общая задача стенда — имитировать «плохую» сеть между enp0s9 и enp0s8 различной степени паршивости. Для этого на их выход вешается netem.

alt:Etcnet включает в себя понятие «профиль»: при перезапуске сети вида service network restartwith профиль будут использованы настроечные файлы с именами вида файл#профиль, и только если соответствующего файла нет — файл:

root@host-15 ~ # service network restart
 . . .
root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 . . .
root@host-15 ~ # service network restartwith loss
 . . .
root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc netem 1: root refcnt 2 limit 1000 loss 0.33% 25% corrupt 0.33%
 . . .
root@host-15 ~ # service network restartwith rate
 . . .
root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc netem 1: root refcnt 2 limit 1000 loss 0.05% 25% corrupt 0.05% rate 10000Kbit

Основные возможности dummynet и netem

Сетевой мост и МЭ уровня TCP/IP (ipfw)

Базовая статья: Filtering Bridges Включение (обратите внимание на «прозрачную» коммутацию в ядре вместо создания виртуального сетевого интерфейса типа if_bridge):

# sysctl net.link.ether.bridge.config=fxp0:0,xl0:0
# sysctl net.link.ether.bridge.ipfw=1
# sysctl net.link.ether.bridge.enable=1

Фрагмент правил МЭ ipfw (xl0 смотрит «внутрь», fxp0 — наружу, но всё равно обслуживается единый сегмент локальной сети):

# Outbound
add pass tcp from any to any in via xl0 setup keep-state
add pass udp from any to any in via xl0 keep-state
add pass ip from any to any in via xl0
# Local traffic (my IP is 1.2.3.4)
add pass tcp from 1.2.3.4 to any setup keep-state
add pass udp from 1.2.3.4 to any keep-state
add pass ip from 1.2.3.4 to any
# Inbound ssh
add pass tcp from any to any 22 in via fxp0 setup keep-state
# Inbound SMTP
add pass tcp from any to relay 25 in via fxp0 setup keep-state
# Inbound DNS
add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
add pass udp from any to ns 53 in via fxp0 keep-state
# Inbound icmp
add pass icmp from any to any
# Inbound Ephemeral port (IANA standard only)
add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state
add pass udp from any to any 49152-65535 in via fxp0 keep-state

Пояснения:

• Пакеты, отправляемые с самой машины, надо разрешать отдельно (т. к. они не «получены» ни откуда)

• Волшебные слова relay и ns заработают только если уже работает DNS (это поля MX и NS нашего домена)

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

МЭ интерфейсного уровня в Linux: ebtables

Базовая статья: ebtables/iptables interaction on a Linux-based bridge

• Пакет попадает в ebtables, если он пришёл или уходит через коммутируемый интерфейс

• Пакет покидает ebtables, если его нужно обработать уровнем выше

• Маршрутизация (routing) vs. коммутация (bridging) ⇒ цепочка BROUTE

  • DROP в BROUTE означает только выкидывание из ebtables и передачу на уровень IP

Обратите внимание, что уровнем выше может быть IPTables (а не просто «application», как на схеме)

• Подобно netfilter, ebtables состоит из цепочек и таблиц (путаница та же самая )

Возможности ebtables:

• Фильтр по полям фрейма:
  • mac-адреса интерфейсов (отправителя, входящий и выходящий на мосту, получателя), в т. ч. т. н. Bridge Group Addres
  • по полю «протокол» (фрейма!)
  • …
• Фильтры-модули:

  • поля arp

  • поля ip (включая порты транспортного уровня!)

  • ограничитель limit

  • классификатор mark

  • поля stp

  • vlan

  • …

• Действия-модули (параметры для "-J")

  • arpreply — порождение произвольного ARP-ответа

  • snat/dnat — подмена MAC-адресов

  • mark — маркировка пакета

  • redirect — «тупая» подмена MAC-адреса

Linux arptables

Базовая статья: ARPTABLES manual page

Структура:

• три цепочки: INPUT, OUTPUT, FORWARD
• одна таблица: filter
• фильтры по полям arp (К. О. гарантирует это)

• дополниетльный модуль mangle для подмены адресов

Туннелирование и IPSec

«Определение»: инкапсуляция трафика внутрь специального сетевого протокола

Задачи:

• Организация общего адресного пространства
• Аутентификация и шифрование трафика целиком

Простейшее решение: использовать прикладной уровень:

1. Подключение и авторизация

   • Клиент                                           Сервер
     VPN-клиент ---> eth0: 5.6.7.8 ---> (Интернет) ---> eth0: 1.2.3.4 ---> VPN-сервер

2. Создание виртуальных сетевых tun или tap интерфейсов и настройка их как обычных сетевых карт:

   • Клиент                                           Сервер
     VPN-клиент <--> eth0: 5.6.7.8 <--> (Интернет) <--> eth0: 1.2.3.4 <--> VPN-сервер
      |                                                                     |
     tun0: 192.168.10.2                                                    tun0: 192.168.10.1

3. Обмен данными через туннель:

   • VPN-клиент <--> eth0: 5.6.7.8 <--> (Интернет) <--> eth0: 1.2.3.4 <--> VPN-сервер
      |                                                                     |
     tun0: 192.168.10.2 <-- (Пакет для 102.168.10.1)                 … <-- tun0: 192.168.10.1

     На всем протяжении пути от 5.6.7.8 до 1.2.3.4 пакет не меняется.
   • TCP over TCP ⇒ использование UDP
   • Паразитная нагрузка (поля транспортного и прикладного уровней)

   • Примеры: vtun, OpenVPN, …

Использовать сетевой уровень ( «IP over IP») :

• Параметры виртуального сетевого интерфейса: собственный IP-адрес и IP-адреса концов туннеля

  • Всякий попавший в tun0 пакет инкапсулируется в IP-пакет (например, протокола GRE) с адресами конца туннеля, а этот пакет маршрутизируется

• Проблемы с NAT вида «много в один»
• Шифрование и аутентификация отсутствуют

Пример: настройка GRE-тоннеля

• На одной стороне:

  # ip a show dev enp0s8
  2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
      link/ether 08:00:27:4c:12:2a brd ff:ff:ff:ff:ff:ff
      inet 10.30.50.3/24 brd 10.30.50.255 scope global enp0s8
      inet6 fe80::a00:27ff:fe4c:122a/64 scope link 
         valid_lft forever preferred_lft forever
  # ip tunnel add tun mode gre remote 10.50.70.3 local 10.30.50.3
  # ip a a 192.168.0.30/24 dev tun
  # ip l set up dev tun 
  [root@uneexclient ~]# ip a show dev tun
  5: tun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN 
      link/gre 10.30.50.3 peer 10.50.70.3
      inet 192.168.0.30/24 scope global tun
      inet6 fe80::5efe:a1e:3203/64 scope link 
         valid_lft forever preferred_lft forever

  На другой строне:

  # ip a show dev enp0s8
  2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
      link/ether 08:00:27:d8:46:fd brd ff:ff:ff:ff:ff:ff
      inet 10.50.70.3/24 brd 10.50.70.255 scope global enp0s8
      inet6 fe80::a00:27ff:fed8:46fd/64 scope link 
         valid_lft forever preferred_lft forever
  # ip tunnel add tun mode gre remote 10.30.50.3 local 10.50.70.3
  # ip a a 192.168.0.50/24 dev tun
  # ip a show dev tun
  5: tun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN 
      link/gre 10.50.70.3 peer 10.30.50.3
      inet 192.168.0.50/24 scope global tun
      inet6 fe80::5efe:a32:4603/64 scope link 
         valid_lft forever preferred_lft forever
  # ping 192.168.0.30
  PING 192.168.0.30 (192.168.0.30) 56(84) bytes of data.
  64 bytes from 192.168.0.30: icmp_req=1 ttl=64 time=1.54 ms
  …
  # traceroute -n 192.168.0.30
  traceroute to 192.168.0.30 (192.168.0.30), 30 hops max, 60 byte packets
   1  192.168.0.30  1.145 ms  1.145 ms  1.195 ms

Виртуальные машины с GRE-туннелем: одна, другая, маршрутизатор (замена интернету) .

IPSec

Базовая статья: An Illustrated Guide to IPsec, смотреть на картинки обязательно.

• Происхождение: IPv6.
• Назначение: «прозрачный» IP с аутентификацией и шифрованием
  • ⇒ универсальность
  • ⇒ задача: аутентификация
  • ⇒ задача: шифрование
  • ⇒ свойство: сохранение (по возможности) исходных IP-полей
• Использование различных алгоритмов шифрования (как стороны договорятся)
• Протокол обмена ключами с множеством вариантов использования

Четыре вида (2×2):

1. Сокрытие трафика:

   • (нет): Authentication Header (AH)

   • (да): Encapsulating Security Payload (ESP)

2. Какой уровень протоколов защищаем:

   • (транспортный): Transport Mode

   • (сетевой): Tunnel Mode

Authentication Header (AH)

Только аутентификация (контрольные суммы), все IP-поля, по возможности, сохраняются

AH + Transport

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета остаются неизменными, кроме:

   • proto=TCP → proto=AH (51)

   • pkt_len=size → pkt_len=size+AH_size

2. Между заголовком и контентом IP-пакета добавляется сам AH (с полем next=TCP)

3. В целях аутентификации вычисляется контрольная сумма всех полей, кроме тех, что меняются по дороге, а также контента (TCP-пакета)

   • ⇒ вычисляется контрольная сумма полей src_IP и dst_IP

AH + Tunnel

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета остаются неизменными, кроме:

   • proto=TCP → proto=AH (51)

   • pkt_len=size → pkt_len=size+AH_size+IP_header_size`

2. Между заголовком и исходным IP-пакетом в неизменном виде вставляется сам AH (с полем next=IP)

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

   • ⇒ вычисляется контрольная сумма полей src_IP и dst_IP как IPSec-пакета, так и туннелируемого IP-пакета

Encapsulating Security Payload (ESP)

Шифрование и (по необходимости) аутентификация.

ESP + Transport

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета остаются неизменными, кроме:

   • proto=TCP → proto=ESP (50)

   • pkt_len=size → pkt_len=new_size

2. Далее следует ESP-секция, содержащая заголовок ESP, исходный TCP-пакет и метаданные TCP-пакета, в которой шифруется всё, кроме заголовка

   • ⇒ шифруются также метаданные, например поле next=TCP

3. Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей ESP-секции.

ESP + Tunnel

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета никого не интересуют, потому что они есть внутри туннелируемого контента; поле proto=ESP (50)

2. Далее следует ESP-секция, содержащая заголовок ESP, исходный IP-пакет и метаданные IP-пакета, в которой шифруется всё, кроме заголовка

   • ⇒ шифруются также метаданные, например поле next=IP

3. Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей ESP-секции.

«And the winner is… oops… er… never mind»

Вывод: в жизни можно использовать только ESP и лучше в туннельном виде:

• AH не совместим с NAT вида «много→один»
• ESP+Transport требует настройки IPSec на всех абонентах сети

Ну, и чем это лучше других туннелей?

Виды VPN (первый заход)

• «Old Windows style»: PPP+GRE
• «New Windows style»: ipsec+l2tp
• OpenVPN
• …

МЭ на прикладном уровне, а также что не попало в лекции

Туннеллирование (продолжение)

Протоколы туннелирования: тысячи их

L2TP

Основной RFC — 2661. Базовая статья — Layer_2_Tunneling_Protocol

• Развитие PPTP:
  • Предназначен для туннелирования PPP через «любую» среду передачи данных (UDP, IP, ATM, Frame Relay, …)

    • ⇒ Очень большой

• Разделяются понятия «туннель» и «сеанс внутри туннеля»
• Управляющий протокол создания туннеля и установления сеанса надёжен, а надёжность данных не гарантируется
• Поддерживаются «входящие звонки», «исходящие звонки», простой туннель и даже какой-то «multihop»
• Не имеет механизма аутентификации ⇒ используется пара L2TP + IPSec ESP Transport

Пример простого L2TP-туннеля с помощью iproute2: ip l2tp (без задействования управляющего протокола) Управляющий протокол реализуется специальным демоном (вариантов много)

IPSec

См. предыдущую лекцию.

Ключи и обмен ими

• Аутентификация в IPSec использует HMAC (симметричное шифрование) ⇒ нужен т. н. shared secret.

• IPSec «поддерживает любые механизмы аутентификации» ⇒ сложный протокол IKE для устаноления т. н. security association (SA) (используемого набора механизмов шифрования и аутентификации).

  • Привет и спасибо Диффи и Хеллману

  • pre-shared secrets

  • IPSECKEY DNS

  • KINK

  • …
• Потому (и в процессе) этими ключами надо управлять

OpenVPN

Базовая статья OpenVPN

• Простая клиент-сервернеая структура
• Авторизация по PSK или паролю
• Протокол прост в реализации (см. поддерживаемые архитектуры)
• Наких RFC не написано

• Примеры настройки: простейший, ещё

МЭ на прикладном уровне

Проблема: многообразие протоколов.

Общие задачи:

• Контентная фильтрация/ограничение
  • Антиспам/Антивирус

  • l7filter (дохленький?)

  • …
• Ретрансляция (возможно, с изменением полей прикладного протокола)
  • «Классический» прокси (например, squid)

  • FTP (например, ftp-proxy)

  • TLS и разное жульничество с ним
  • …

Не вошло

• Эффективные сетевые подсистемы (netgraph, netmap про netmap на Хабре, …)

• Взаимодействие с packer processors (для большой загрузки)

• Высокоуровневые МЭ: shorewall

• Проксирование и иная ретрансляция
• Антиспам/антивирус/скоринг контента
• Подсчёт статистики
• …