Вопросы Теги

Сервер Centos 6/7 tftp не отправляет ответ

Я пытаюсь запустить и запустить действительно простой TFTP-сервер с целью работы в качестве загрузочного сервера IPXE. Однако все, что я делаю, похоже, не работает, чтобы сервер мог общаться с удаленным клиентом. Я могу заставить клиента обмениваться данными через локальный хост, что, кажется, отлично работает. 

tftp $TFTP_SERVER -c get README

Хотя это отлично работает на локальном хосте, это противоречит цели наличия сервера, который может общаться удаленно. Файл конфигурации tftp выглядит следующим образом: 

[root@ipxe tmp]# cat /etc/xinetd.d/tftp
# default: off
# description: The tftp server serves files using the trivial file transfer \
#       protocol.  The tftp protocol is often used to boot diskless \
#       workstations, download configuration files to network-aware printers, \
#       and to start the installation process for some operating systems.
service tftp
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -vvvvv -c -s /ipxe/
        disable                 = no
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

ПРИМЕЧАНИЕ. ДЛЯ ОТЛАДКИ Я ВЫПОЛНЯЛ СЛЕДУЮЩИЕ: Я отключил брандмауэр: 

[root@ipxe ~]# service iptables stop
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Unloading modules:                               [  OK  ]
[root@ipxe ~]# chkconfig iptables off

Я отключил SELinux, потому что он отстой.

[ root @ ipxetmp] # cat / etc / selinux / config 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Я также перезагружал большое количество раз.

Независимо от того, что я, кажется, пытался, даже меняя версию CentOS на 7 и повторяя процесс, все, что я могу получить from tftp: 

Jan 30 22:52:01 ipxe xinetd[2013]: START: tftp pid=2265 from=192.168.10.186
Jan 30 22:52:01 ipxe in.tftpd[2266]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:06 ipxe in.tftpd[2267]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:11 ipxe in.tftpd[2268]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:20 ipxe in.tftpd[2269]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:25 ipxe in.tftpd[2270]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:30 ipxe in.tftpd[2271]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:35 ipxe in.tftpd[2272]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:40 ipxe in.tftpd[2275]: RRQ from 192.168.10.186 filename README

Я, очевидно, могу пропинговать систему и использовать ssh, и, похоже, я не вижу никаких проблем с сетью.

Что, черт возьми, мне здесь не хватает? Какая следующая логическая линия в диагностике проблемы? Я почти готов сообщить об ошибке по этой проблеме.

-1
задан 31 January 2018 в 08:19
2 ответа

Оказывается, при тестировании TFTPвам нужно пробить дыру как в сервере, так и в брандмауэре клиента. Это не имеет особого смысла, поскольку в большинстве статей в Интернете рассказывается о selinux, а также об отключении брандмауэра на сервере tftp. Сервер работал нормально, и даже несмотря на то, что я пробовал его в нескольких разных типах операционных систем, от Windows до Linux и Mac, всем трем этим различным клиентам tftp необходимо установить правило в их брандмауэр, чтобы разрешить доступ к tftp. Обычно это сопровождается сообщением на tftp-сервере, которое говорит что-то вроде «Нет маршрута к хосту», но этот шаг по какой-то причине был пропущен. Если бы вы были похожи на меня и не уверены, что делать, даже если следовали всем направлениям. Убедитесь, что вы пробили дыру и в брандмауэре клиента.

1
ответ дан 5 December 2019 в 19:41

Причина этого в том, что по умолчанию tftp слушает порт 69, но начинает передачу файлов на совершенно случайных портах, не обработанных правилом conntrack и поэтому блокируется брандмауэром.

Вы можете указать диапазон портов с помощью параметра -R xxxx:xxxx в server_args в /etc/xinet.d/tftp:

server_args = -R 9990:9999 [остальные параметры]

Однако это частичное решение, поскольку для него нельзя установить то же значение, что и для прослушивающего порта, и это будет исходный порт, а не порт назначения. Поэтому вам, скорее всего, потребуется специальное правило брандмауэра на клиенте.

1
ответ дан 2 February 2021 в 21:04

Теги

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