У меня есть ftp-клиент (приложение .NET, к которому у меня нет источника), который работает только в активном режиме, который должен передавать данные на ftp-сервер устройства, который говорит только в пассивном режиме.
Я ничего не могу сделать, чтобы изменить программное обеспечение на обоих концах; но все между ними - честная игра. (маршрутизация, программное обеспечение Windows или Linux, уловки с брандмауэром, ...)
Есть ли какой-нибудь софт для ftp-прокси? Или какое-то решение, которое я мог бы попробовать?
Есть (или, может быть, был?) Очень хороший демон под названием SuSE Proxy Suite. Он перехватывал FTP-трафик и позволял перенаправить ftp-клиент на какой-то конкретный backend-сервер, и, если мне не изменяет память, он также разрешал активные <-> пассивные преобразования. Я без проблем пользовался программой в довольно тяжелых условиях годами.
К сожалению моя старая закладка (http://proxy-suite.suse.de), похоже, перенаправляет себя на страницу Novell. Некоторые репозитории пакетов (FreeBSD, Debian после быстрого поиска в Google), похоже, все еще включают программное обеспечение, так что у вас может быть некоторая надежда.
У FreshPorts есть хорошее описание программного обеспечения:
http://www.freshports.org/net/proxy-suite/
РЕДАКТИРОВАТЬ: Еще кое-что. Я понятия не имею, была ли эта небольшая проблема исправлена позже (это было не в 2004 году, когда я последний раз использовал эту штуку), но по умолчанию proxy-suite работает от имени пользователя root, поскольку ему нужно привязаться к низким портам. И он работал как Really Root, так как не использовал преимущества Linux. возможности.
Сегодня должна быть возможность установить возможности файла через Setcap команда вроде этой:
sudo setcap 'cap_net_bind_service=+ep' /path/to/file
Но если это не сработает (хотя возможности и существовали, команда setcap была не очень распространенной, когда я исправлял proxy-suite), вот еще один обходной путь.
Примерно в 2004 году я написал небольшой патч, в котором упали все возможности, кроме CAP_NET_BIND_SERVICE сразу после запуска, поэтому даже некоторые потенциальные дыры в безопасности будут менее опасными. Обычно вам может не понадобиться этот патч, но если у вас есть эта болезнь, называемая паранойей безопасности, и ваша передача файлов происходит между некоторыми темными уголками Интернета, а не вашей удобной офисной локальной сетью, исправление может быть хорошей идеей.
Чтобы узнать, работает ли ftp-proxy с полными привилегиями root, проверьте, есть ли getpcaps возвращает что-то вроде этого:
yourserver root# getpcaps `pidof ftp-proxy`
Capabilities for `16982': =eip cap_setpcap-eip
Исправленная версия должна возвращаться следующим образом:
yourserver root# getpcaps `pidof ftp-proxy`
Capabilities for `9522': = cap_net_bind_service+ep
И, наконец, вот патч, который я написал миллионы лун назад, надеюсь, его все еще можно применить.
--- common/com-misc.c.orig 2006-11-20 13:54:59.000000000 +0200
+++ common/com-misc.c 2006-11-20 14:40:47.000000000 +0200
@@ -36,0 +37 @@
+#include <sys/capability.h>
@@ -748,0 +750,18 @@
+ /*
+ * If running as root, drop all the privileges except CAP_NET_BIND
+ */
+ if (geteuid() == 0) {
+ cap_t caps = cap_init();
+ static cap_value_t capv[] = {CAP_NET_BIND_SERVICE};
+ const int numcaps = sizeof(capv) / sizeof(capv[0]);
+ if (caps == NULL)
+ syslog_error("cap_init() failed; errno = %d", errno);
+ if (cap_set_flag(caps, CAP_PERMITTED, numcaps, capv, CAP_SET) < 0)
+ syslog_error("Could not set permitted capabilities;
errno = %d", errno);
+ if (cap_set_flag(caps, CAP_EFFECTIVE, numcaps, capv, CAP_SET) < 0)
+ syslog_error("Could not set effective capabilities;
errno = %d", errno);
+ if (cap_set_proc(caps) < 0)
+ syslog_error("Could not apply capability set; errno =
%d", errno);
+ cap_free(caps);
+ }
+