Linux. Настройка NAT-сервера, маршрутизатора и прерываний при увеличении объемов трафика

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

Прерывания.

Распределение прерываний сетевых карт по отдельным ядрам — это первая проблема, с которой сталкивается системный администратор при увеличении нагрузки на linux-маршрутизатор. Но, так как в сети данная тема освещена достаточно подробно, надолго останавливаться на этом вопросе мы не будем. Необходимо лишь отметить, что при ручном раскидывании прерываний необходимо остановить сервис irqbalance, так как этот сервис используется для автоматического распределения прерываний между разными ядрами процессоров. Естественно, если эта работа выполняется вручную, то сервис лучше остановить. 
Кроме того, необходимо внести соответствующие исправления в файл автозагрузки, так как после перезагрузки сервера все прерывания опять «соберутся» на одном ядре. 
После рестарта сервера, некоторые сетевые карты могут получить новые номера прерываний. В связи с этим в настройках /etc/rc.local лучше не вносить вручную конкретные номера прерываний. Оптимальный вариант – автоматизация процесса с помощью специального скрипта распознавания сетевых карт и прерываний.

Маршрутизатор.

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

Итак,

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

/sbin/ifconfig eth0 mtu 9000

Увеличиваем значение MTU на коммутаторах:
Эта процедура, производимая на коммутационном оборудовании, как правило называется jumbo-frame. Например, для Cisco Catalyst 3750 необходимо выполнить следующие команды:

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

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

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

/sbin/ifconfig eth0 txqueuelen 10000

Значение по умолчанию — 1000. Для гигабитных линков необходимо установить 10000. В принципе, значение этого параметра, это — объем буфера передачи. После того, как буфер наполняется до указанного значения, данные физически передаются в сеть.
При этом следует иметь в виду, что при изменении размера MTU в настройках одного типа сетевого оборудования, то же самое необходимо проделать и на интерфейсе сопряженной аппаратуры. То есть, например, при увеличении MTU до 9000 в настройках linux-роутера необходимо включить jumbo-frame также и на порту коммутатора, к которому данный роутер подключен. Иначе, сеть хотя и будет работать, но с «глюками», «через раз».
Выводы.
В результате вышеописанных изменений, в сети заметно возрастут «пинги». Однако общая пропускная способность при этом существенно возрастет, а также снизится нагрузка на активное оборудование.

Сервер NAT.

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

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

Для выполнения своей задачи, NAT-сервер должен постоянно «помнить» обо всех, проходящих через него соединениях. Неважно, «аська» это или чей-то «пинг» — все эти сессии NAT-серверу необходимо отслеживать у себя в памяти (для этого используется специальная таблица). Когда сессия закрывается, соответствующая информация из таблицы удаляется. Так как размер этой таблицы фиксирован, то при большом количестве проходящего через сеть трафика объема таблицы начинает не хватать. При этом NAT-сервер начинает жутко глючить: прерывать сессии, «дропать» пакеты. Интернет начинает работать с ужасными перебоями, а на NAT-сервер становится просто невозможно попасть даже по SSH.
Чтобы избежать подобных неприятностей, необходимо своевременно увеличивать размер таблицы, соответственно проходящему через NAT-сервер трафику:

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

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

/sbin/sysctl net.netfilter.nf_conntrack_max

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

/sbin/sysctl net.netfilter.nf_conntrack_count

Увеличение объема hash-таблицы
Соответственно необходимо увеличить и хэш-таблицу, где записываются списки conntrack-записей.

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

При этом можно использовать следующее простое правило: 
hashsize = nf_conntrack_max / 8

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

NAT-сервер отслеживает только текущие (открытые) сессии, которые в это время через него проходят. После закрытия сессии информация о ней удаляется, чтобы таблица не переполнилась. Информация о закрывшихся сессиях может удаляться и по тайм-ауту. 
То есть, если в течение значительного промежутка времени в рамках соединения не происходит обмен трафиком, то такое соединение закрывается, а соответствующая информация о нем удаляется из памяти NAT-сервера.
Однако, значения тайм-аутов, установленные по умолчанию, достаточно большие. Поэтому, при увеличении потока трафика, даже при максимальном значении параметра nf_conntrack_max, можно столкнуться с переполнением таблицы и всеми вытекающими проблемами (включая разрывы соединений).
Чтобы предотвратить такие неприятности, необходимо правильно выставить тайм-ауты контроля соединений на NAT-сервере.
Проверить текущие значения можно, например, таким образом:

sysctl -a | grep conntrack | grep timeout

эта команда выдаст примерно такие сообщения:

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

Это значения тайм-аутов, указанные в секундах. Например, значение

net.netfilter.nf_conntrack_generic_timeout 

равно 900 (15 минут). То есть NAT-сервер будет хранить в своей памяти информацию о такой сессии пока по ней будет хоть какое-то движение битов в течение каждых 15 минут.
Хотя ничего страшного в этом вроде бы нет, на самом деле это слишком много.

Если вы обратите внимание на параметр net.netfilter.nf_conntrack_tcp_timeout_established, то заметите, что его значение равно 432000. Значит, обычную TCP-сессию такой NAT-сервер будет контролировать пока по ней происходит передача информации хотя бы один раз в пять дней.
Кстати, слишком большие значения тайм-аутов являются самой популярной уязвимостью в ДДОС-атаках начинающих «хакеров». Для этого даже не потребуется специфический софт – достаточно простейшего массированного флуда группы школьников, чтобы заDDOSить NAT-сервер и переполнить его NAT-таблицу (nf_conntrack_max). О последствиях такого переполнения уже было сказано выше.

Значения тайм-аутов желательно ставить в границах: 30-120 секунд. Этого времени достаточно как для стабильной работы абонентов, так и для своевременной очистки таблицы, что исключит её переполнение.
Разумеется, все соответствующие изменения необходимо сохранить в
/etc/sysctl.conf и /etc/rc.local

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

Мне понравилось! Занести себе в закладки:  

Тоже интересно:

• Раздача интернета в FreeBSD без использования моста