Вот примерное объяснение того, что может пойти не так.
Перед iptables правила:
X (X = 2 в начальном примере OP) IP-адреса источника с 2 ^ 16 возможными портами источника и 1 адресом и портом назначения:
X * 2^16 возможных соединений.
После iptables правила: X источников были сжаты в один источник
1 * 2^16 возможных соединений.
X * 2 ^ 16 соединений не может соответствовать только 2 ^ 16 соединениям. Конфликт исходного порта будет происходить все чаще и чаще и будет решаться сменой исходного порта, но найти свободный исходный порт, не конфликтующий с другим потоком, будет все сложнее: начнет увеличиваться падение производительности, могут даже начать происходить отброшенные пакеты.
Произойдет ли это по-другому, если iptables были заменены на nftables? Нет. В обоих случаях они не являются частями, разрешающими столкновение. Это разрешение выполняется в том же общем бэкэнде Netfilter: в nf_nat
модуль ядра, возможно, повторяя несколько раз, если это необходимо, и даже отказываясь (например, отбрасывая новый коннтрек запись и пакет, инициировавший его предварительное создание).
Причина в том, что исходный NAT выполняется, когда есть единственное возможное место назначения (сервер): его следует избегать.
Возможные обходные пути:
не используйте исходный NAT. Вместо этого следует установить адекватную маршрутизацию (даже если для этого требуется множественная адресация или туннель), чтобы 10.10.10.10 не приходилось видеть один источник 50.50.50.50. Вопрос не объясняет, зачем нужен этот SNAT, поэтому невозможно более подробно остановиться на нем.
иметь несколько адресов источников для балансировки нагрузки и распределения давления порта источника. Это может быть достигнуто с iptables с использованием статистика
модуль для балансировки нагрузки на несколько СНАТ
цели.
Переключение на nftables обычно является улучшением, но в данном случае это не похоже на решение.