Сервер 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]
Однако это частичное решение, поскольку для него нельзя установить то же значение, что и для порта прослушивания, и это будет порт источника, а не порт назначения. Поэтому вам, скорее всего, понадобится определенное правило брандмауэра на клиенте.