1. Почему рекомендуется создавать пул не менее чем из 2х или 4х адресов?
2. Как определить, какой белый адрес из пула получит абонент?
3. После подключения NAT стали отваливаться неактивные SSH сессии
4. Сколько "серых" IP можно спрятать за одним "белым" в CGNAT?
5. Как поменять параметры уже существующего и используемого пула?
6. Как выдать конкретный адрес абоненту с NAT 1:1?
7. Диагностика NAT
8. Как найти абонента за NAT? Работа с abuse letters

Неблокирующий алгоритм диспетчеризации в DPI, распределяющий сессии по рабочим потокам, накладывает ограничение на то, какой белый IP адрес может быть назначен абоненту из пула:

- Чтобы гарантированно абонент получил свой белый адрес, необходимо чтобы в пуле было не меньше адресов, чем рабочих потоков (в типовой конфигурации это 2 для СКАТ-6 и 4 для СКАТ-10 и выше).

Узнать число рабочих потоков можно командой

expr $(ps -p `pidof fastdpi` H -o comm|grep wrk|wc -l) / $(ps -p `pidof fastdpi` H -o comm|grep rx|wc -l)

- Если в пуле всего один адрес, то не всем абонентам он может быть назначен, а только тем, которые попадут под алгоритм балансировки

Посмотреть, какой белый адрес был назначен серому, можно командой

fdpi_ctrl list status --service 11 --ip 192.168.4.20

В NAT 1:1 белый адрес выделяется сразу при назначении услуги, в CG-NAT в момент начала сессии

Также выделенный абоненту белый адрес рапортуется в Radius Accounting в целях его логгирования в биллинге.

Заранее предсказать какой-именно адрес будет выдан абоненту из пула невозможно: это зависит от разных факторов и в частности от текущей загрузки пула.

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

У NAT нет возможности отличить, умерла сессия аварийно или просто в ней нет никакой активности, и закрывает такие долго висящие сессии по таймауту неактивности. Такое поведение предусмотрено стандартом и поддержано большинством производителей CG-NAT.

В СКАТ время жизни сессий можно корректировать следующими параметрами

lifetime_flow=60
lifetime_flow_long=600

где lifetime_flow_long время жизни в секундах неактивных TCP-сессий, lifetime_flow остальных.

Поэтому при необходимости поддержания долгоиграющих неактивных соединений рекомендуется использовать механизм tcp keep-alive, когда периодически в сессии передается пустой пакет, который сигнализирует, что сессия все еще активна.

Настроить tcp keep-alive можно как индивидуально для приложения на стороне сервера или клиента, так и на уровне операционной системы для всех приложений сразу.

Пример настройки на ssh сервере

в файл /etc/ssh/ssh_config добавляем строку
ServerAliveInterval 60

Пример настройки на ssh клиенте

в файл ~/.ssh/config добавляем строки
Host *
  ServerAliveInterval 60
или в командной строке
ssh -o TCPKeepAlive=yes -o ServerAliveInterval=60 user@example.com

Пример настройки для всех приложений в centos

в файл /etc/sysctl.conf добавляем строки
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 20