Туннели во внутренние сети идут или тоже через внешку? Посмотрите, сколько внешнего трафика приходится на сами туннели. Снимите дамп трафика, проанализируйте в wireshark - у него отличные возможности в этом плане.
Lindon_cano: На самом деле разницы в производительности этих таргетов практически нет, потому что они отрабатывают из таблицы nat, через которую проходит лишь первый пакет каждого соединения. Для остальных пакетов уже существующих соединений (для которых уже есть записи в таблице коннтрака) эти таргеты не выполняются. А определить подходящий адрес не составляет труда: нужный айпи-адрес берётся из маршрута, который для данных пакетов уже известен (так как MASQUERADE/SNAT может выполняться только на этапе POSTROUTING).
Vi: eno1:0 и eno1:2 это не отдельные интерфейсы, а лишь алисы (псевдонимы), а по факту являются лишь различными адресами на одном физическом интерфейсе eno1 (см. вывод команды ip address list dev eno1). Вы не можете использовать алиасы для проверки интерфейсов (в сопоставлениях --input-interface и --output-interface) - правила добавятся, но работать не будут - ни один пакет под эти сопоставления не подпадёт. Используйте сопоставление именно по адресам.
Так же можно отказаться от ядерного модуля и использовать для сбора данных демон ULOGD2, который так же умеет экспорт в netflow, а так же сразу писать данные в базу данных, что может быть очень удобно.
Через таблицу nat проходят только первые пакеты соединения, для которых создаются записи в таблице коннтрака (то есть пакеты с состоянием NEW). Если же для пакета уже есть соответствующее соединение в таблице коннтрака (ESTABLISHED, RELATED и т.п.), то пакет в таблицу nat уже не попадёт. Лучше всего использовать новый форк iptables netflow с опцией nat events - он не требует добавления правил в файерволл и берёт данные из событий трассировщика соединений, что позволяет экспортировать статистику netflow с адресами до и после трансляции. Вот как-то так. Много информации по этому таргету вместе с обсуждением и ссылками на репозиторий можно найти здесь - forum.nag.ru/forum/index.php?showtopic=53979 (можно читать примерно с 10ой страницы).
Александр: iptables занимается только управлением правилами: конвертирует набор правил между текстовым форматом, с которым работает пользователь, и бинарным форматом, с которым работает ядро. Текстовые правила парсятся и из них создаётся бинарное представление, которое через сокет передаётся ядру. Блоб содержит описания правил в бинарном формате (какие сопоставления (match) необходимо делать и с какими параметрами, и что делать с теми пакетами, которые подходят под правила). Ядро получает этот блоб и сохраняет у себя в памяти. При обработке сетевых пакетов, для каждого пакета на определённом этапе вызываются функции подсистемы netfilter, которая уже вызывает функции x_tables, которые занимаются тем, что прогоняют пакет по правилам из сохранённого блоба, и выполняют над ними действия, если пакеты подходят по правилам. Это в самом упрощённом виде.
Василий: Дело в том, что трассировка соединений не бесплатна, и вызывает некоторое повышение нагрузки. Особенно это заметно в случаях какого-нибудь DDoS'а или Syn-flood'а. Чтобы снизить нагрузку на ЦПУ, можно отключить трассировку соединений для некоторой части трафика (например, оставить трассировку только для транзитного трафика, для которого делается NAT, а для остального трафика - отключить, а сам фильтрацию сделать stateless). Вот как-то так.
Покажите, пожалуйста, iptables-save -c (полный дамп правил вместе со счётчиками), а так же покажите вывод команд ip route get mark и ip route get from iif - они покажут, какие маршруты будут выбираться для пакетов с заданной меткой и для пакетов, пришедших на определённый интерфейс с определённого айпи-адреса. Возможно, где-то что-то не отрабатывает должным образом. Не забывайте сбрасывать роут-кэш и таблицы коннтрака после изменения правил маршрутизации. Удобно, так же, для траблшутинга использовать nflog + tcpdump/wireshark.
"все, что прилетает на lan0.1 маскарадилось на lan0.2, а lan1.2 маскарадился на lan1.1." - объясните подробнее, что Вы хотите получить. Маскардинг - это лишь вид НАТ в linux, и не более того. Возможно, Вы имели что-то другое, так как на решение о маршрутизации маскардинг не влияет никаким образом.
Сначала сжали, а потом закодировали или наоборот? Если сначала сжали, а потом поксорили, то проще, так как нам известны определённые структуры текста и узнать ключ проще. Иначе просто перебором, пока не получим хоть что-то похожее на правду.
По ценам сложнее, так как обычно прайс-листами не светят, а договориваются о приемлемом ценнике в каждом конкретном случае. Если для теоретического проекта, то можно взять для примера прайс-листы на аналогичное не-SDN оборудование.
PBR - Policy Based Routing - маршрутизация осуществляется не только по адресу назначения, но и по другим критериям (метки, адрес источника, входящий интерфейс и т.п.). Конфиг лучше в текстовом виде. Покажите, что выдал вам провайдер (адреса, маски и шлюзы).
