Почему DNAT на 127.0.0.1 требует особой осторожности
Разберитесь с route_localnet при перенаправлении внешнего трафика на прокси-компонент, привязанный к loopback.
Служба слушает 127.0.0.1:1080. Правило DNAT направляет входящий трафик на этот адрес, но соединение не устанавливается. Служба может быть исправна, а правило NAT — совпадать: адреса loopback IPv4 обрабатываются при маршрутизации особым образом.
Параметр route_localnet в Linux определяет, считаются ли адреса 127/8 марсианскими при маршрутизации. Значение по умолчанию сохраняет обычную границу loopback. Исключение для конкретного интерфейса может быть уместно при осознанно спроектированном локальном перенаправлении.
Это объясняет, почему работающее правило с другой машины может зависеть от sysctl, который вы не скопировали. Но это не оправдывает включение параметра повсюду.
Допущение о безопасности меняется вместе с маршрутом
Привязка к loopback часто используется потому, что вспомогательный компонент не имеет собственной аутентификации клиентов. Если трафик с другого интерфейса может быть направлен туда, один лишь адрес привязки уже не описывает доступную аудиторию. Ограничьте источники входа, назначение и порт в реальном наборе правил, включая трафик, заявляющий loopback-адреса источника или назначения, где это уместно.
Проверьте сетевое пространство имён, в котором находится служба. Loopback контейнера — не loopback хоста, и изменение настройки интерфейса хоста не создаёт автоматически слушателя в контейнере.
rp_filter отвечает на другой вопрос — о проверке пути источника. Его глобальное отключение не является общей заменой пониманию маршрутизации loopback. Точно так же ip_nonlocal_bind касается привязки сокетов к нелокальным адресам, а не исправности этого пути DNAT.
Наконец, перенаправляемый протокол должен соответствовать слушателю. Отправка необработанного HTTP или TLS на порт SOCKS по-прежнему требует транслятора; исключение в маршрутизации не может обеспечить недостающее согласование.