Назад | Перейти на главную страницу

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

Я пытаюсь запустить и запустить действительно простой 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, потому что это отстой.

[корень @ 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, и, похоже, нет никаких проблем с сетью, которые я вижу.

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

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