Назад | Перейти на главную страницу

Прозрачно перенаправить локальный порт на удаленный сервер

У меня есть демон StatsD, работающий на удаленном сервере (x.x.x.x) в 8125. Я бы хотел переслать 127.0.0.1:8125 к x.x.x.x:8125.

Я уже пробовал запустить на локальном хосте следующее

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p udp --dport 8125 -j DNAT --to x.x.x.x:8125
iptables -t nat -A OUTPUT -p udp --dport 8125 -j DNAT --to-destination x.x.x.x:8125
iptables -t nat -A POSTROUTING -d x.x.x.x -j MASQUERADE

Но это неправильно.

echo "test.test.test:1|c" | nc -w 1 -u localhost 8125

Сбой с ошибкой NC: Ошибка записи: В соединении отказано

echo "test.test.test:1|c" | nc -w 1 -u 127.0.0.1 8125

Не работает без ошибок

echo "test.test.test:1|c" | nc -w 1 -u x.x.x.x 8125

Работает правильно

Кроме того, вызовет ли такое перенаправление портов какие-либо проблемы с безопасностью?

Это невозможно.

Пакеты, созданные локальными процессами, не участвуют в плане пересылки.

Как следствие, вы не сможете использовать PREROUTING и FORWARD цепочки в таблицах будут проходить локально сгенерированные пакеты, но только OUTPUT (в raw/mangle/nat/filter таблицы) и POSTROUTING (в mangle/nat столы) цепочки пока решение о маршрутизации уже принято, и вы не можете его изменить.

Фактически, с вашей текущей настройкой iptables ваши правила будут делать следующее, учитывая ваш вариант использования:

  • Первое правило: недостигнутые.
  • Второе правило: пакеты DNAT, генерируемые локально, для x.x.x.x на интерфейсе обратной связи.
  • Третье правило: замаскируйте пакеты, проходящие через ваш петлевой интерфейс, с IP-адресом вашего петлевого интерфейса.

Итак, результат: локальные пакеты будут пытаться достичь x.x.x.x:8125 на вашем интерфейсе обратной связи.

это схема netfilter может помочь вам понять расположение локально сгенерированных пакетов в глобальном потоке.