Это маршрутизация проблема. iptables не маршрутизирует, но на маршрутизацию могут влиять адреса, которые он может изменить, и вот почему iptables часто ошибочно предполагается, что он выполняет маршрутизацию. Из-за этого iptables не может быть в решение проблемы (но иногда может быть частью такого решения).
Более того, любая попытка изменить Ответить пакет, использующий NAT Netfilter/iptables, игнорируется: нат table срабатывает только для первого пакета потока: не для ответа: iptables -t nat -A OUTPUT -p tcp --match multiport --sports 8443,8080 -j DNAT --to 172.24.248.201 никогда не совпадет. И если бы можно было сделать так, чтобы это совпадало, это не сработало бы, потому что получателем ответа должен быть источник исходного запроса, видимый реальным сервером: фактический IP-адрес удаленного клиента, а не LB L3.
Ниже приведен простой способ сделать это правильно на реальном сервере: политика маршрутизации.
В этой конкретной проблеме и ответе я предполагаю Ядро Linux >= 4.17 для «Расширяет поддержку соответствия правил fib, чтобы включить соответствие спорту, dport и ip proto», что позволяет избежать сложного использования iptables для маркировки пакетов (но в любом случае потребуется политика маршрутизации).
Необходимо убедиться, что выделенные порты реального сервера не могут перекрывать динамический диапазон портов реального сервера (используется, когда сервер является клиентом, например, для запросов DNS или обновления системы):
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
Убедитесь, что нижний порт выше самого высокого порта реального сервера, используемого для службы. Здесь: 32768 > 8443 достаточно.
Добавьте таблицу маршрутизации для определенного трафика, предназначенного для использования L3 LB в качестве шлюза. Таблица 248201 — это произвольно выбранное значение. Я предполагаю, что интерфейс реального сервера называется eth0, пожалуйста, адаптируйте:
ip route добавить по умолчанию через 172.24.248.201 dev eth0 таблица 248201
Добавьте селекторы: по одному на диапазон портов. Это может быть один широкий диапазон (пока нет взаимодействия с динамическими портами, это не имеет значения) или X правил для X отдельных портов. Для одного диапазона:
ip правило добавить iif lo ipproto tcp sport 8000-8443 поиск 248201
куда если ло представляет собой специальный синтаксис для локально инициируемого исходящего трафика и на самом деле не относится к вот интерфейс.
Теперь весь предполагаемый обратный трафик будет маршрутизироваться с использованием L3 LB в качестве шлюза. Любой другой трафик будет использовать обычный шлюз по умолчанию, если это необходимо.
я не думаю СРФ должно быть проблемой, если включено, если обычный шлюз сервера по умолчанию не использует другой интерфейс. Если бы это было проблемой, это могло бы быть установить свободный режим вместо.
Делать только в том случае, если без него не получится (да и то, eth0 может быть достаточно вместо все ниже):
sysctl -w net.ipv4.conf.all.rp_filter=2
