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

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

Я уже попытался выполнить следующий localhost

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

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

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

1
задан 28 November 2014 в 15:19
1 ответ

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

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

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

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

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

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

Эта диаграмма сетевого фильтра может помочь вам понять расположение loc пакеты, созданные союзником в глобальном потоке.

2
ответ дан 3 December 2019 в 21:09

Теги

Похожие вопросы