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

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

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 @ ipxe tmp] # 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 и повторил процесс, самое большее, что я могу получить из 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 в нее, и, похоже, нет никаких проблем с сетью, которые я могу видеть.

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

2 ответа

Решение

Оказывается, что при тестировании TFTP вы должны пробить дыру как в сервере, так и в брандмауэре клиента. Это не имеет большого смысла, так как большинство статей в Интернете будут рассказывать о selinux, а также об отключении брандмауэра на сервере tftp. Сервер работал нормально, и хотя я попробовал его для разных типов операционных систем, от windows до linux и mac, все 3 из этих разных клиентов tftp должны иметь правило, вставленное в их брандмауэр, чтобы разрешить доступ к tftp. Обычно это сопровождается сообщением на сервере tftp, в котором что-то говорится на мелодию "No route to host", но этот шаг по какой-то причине был пропущен. Если вы были как я и не уверены, что делать, даже если вы следовали всем указаниям. Удостоверьтесь, что вы пробиваете отверстие и в противопожарной стене клиента.

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

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

server_args = -R 9990:9999 [rest of your parameters]

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

Другие вопросы по тегам