xneo, можно например так http://gor.od.ua/doc/linux-ip/nat-stateless.html

xneo, ну а цель то какая? есть patch-o-matic и там какой-то xt_RAWNAT. Должно работать.
где-то в этом же проекте был специальный патч отключающий трекинг полностью. правда, есть особенность - интерфейсы ядра меняются и все то, что я знал об этом раньше может устареть.

xneo, так сколько у вас белых адресов ? Если меньше чем серых - бросьте эту затею. Таблица nat-сессий все равно нужна для трансляции в обратную сторону.
Приходит ответный пакет и маршрутизатор должен по номеру порта выбрать из таблицы адрес, на который нужно его отправить (и оттранслировать) . Все способы трансляции адресов без таблицы рассчитаны на редкие случаи когда есть четкое соответствие между внутренними и внешними IP. например 192.168.0. 1 меняется на 12.34.45. 1

Единственное, можно ПОПРОБОВАТЬ не загружать модуль conntrack для iptables, хотя он наоборот помогает раннему срабатыванию правил iptables. Только для этого их нужно еще и составить с умом.

И вообще, о каком объеме трафика речь ?

xneo, поставьте для начала хорошие сетевые карты с множеством очередей - сможете загрузить дополнительные ядра процессора. Пересмотрите правила с использованием conntrack и может даже ipset.

Большинство знакомых мне провайдеров уровня кишлака отказались в конце концов от писироутеров. Я понимаю, что можно и на них на ssd строить надежную инфраструктуру, но люди всю идею портят. Они хотят сертификатики и откатики.

xneoО соответствии адресов (один внешний = один внутренний) я понимаю, так и планируем
Непонятно. А почему тогда вы их без ната не пустите?

Другое дело, что даже крупным провайдерам тяжко выделяют ipv4-адреса. Динамические пулы не из пальца высосаны. Членский взнос в RIPE пропорционален объему используемых адресов. В любом случае nat не нужен.

xneo, в перспективе все равно понадобится какие-нибудь сервера BRAS. Безопаснее для клиента, адреса экономятся, гибкость раздачи адресов, масштабируемость. И NAT, опять же, исключен.