Проблема: я столкнулся с проблемой с TFTP-сервером и IP-телефонами Cisco 79XX. В локальной сети все работает нормально, но когда TFTP-сервер находится на общедоступном сервере (и телефоны внутри частной сети - за NAT / брандмауэром), телефоны могут связываться с TFTP по UDP 69, но не могут получить какой-либо файл / данные (тайм-аут).
Причина: «Согласно RFC 1350, сервер отправляет клиенту (со случайного порта) DATA TFTP-пакет. Однако брандмауэр отклоняет этот пакет, потому что он не может найти существующее соединение между выбранным портом сервера и портом клиента в таблице перевод."
Возможное решение: мне нужно, чтобы сервер TFTP использовал порт 69 не только для приема запросов, но и для отправки ответов клиентам. «В этом случае межсетевой экран правильно передает ответы клиенту согласно записи из таблицы перевода». Кроме того, некоторые провайдеры VoIP решили проблему, написав собственный сервер TFTP.
Вопрос: Я не могу найти какой-либо конкретный параметр / конфигурацию на сервере linux atftp, который определяет порт (-ы), используемый для ответов клиентам. Есть ли такой вариант или другой бесплатный TFTP-сервер Linux с открытым исходным кодом, который может справиться с этим?
Спасибо, CL
Ваше решение должно быть найдено в конфигурации вашего брандмауэра, а не на сервере TFTP.
Любой достойный брандмауэр должен уметь распознавать ответ на начальный запрос TFTP и может быть настроен для динамического отслеживания и временного разрешения обратного соединения TFTP.
Т.е. Сетевой фильтр Linux имеет вспомогательные модули nf_conntrack_tftp и nf_nat_tftp, которые, подобно вспомогательному модулю FTP, после загрузки позволяют отслеживать возвращаемые соединения TFTP.
Например, Cisco PIX может сделать то же самое (возможно, дефолт четный).