Моя проблема в том, что я пытаюсь настроить tftp на сервере, все, что нужно, чтобы работать правильно, кроме случаев, когда я пытаюсь загрузить файл из tftp, он никогда не отвечает, нет никаких ошибок, которые я вижу, просто тишина, когда я нюхаю трафик с сервера, который должен отвечать, я вижу запрос, но сервер никогда не отвечает файлом
Я использую компьютер с Fedora 17
(Я знаю, что это конец жизни, но в настоящее время это невозможно изменить)
Я пытаюсь получить tftp
на нем я установил tftp (yum install -y tftp-server
) и установите для запуска, открыл UDP
порт 69
, и установите разрешения для папки, но она ни на что не отвечает. Вот несколько выходных данных и файлы конфигурации
Когда я запускаю tftp [ip of server] получить тест
Любая помощь будет принята с благодарностью
SELinux
:
# setenforce 0
setenforce: SELinux is disabled
tftp config
:
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 = -s /copos/tftp -vvv
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}
The Directory
:
# ls -lah /copos/tftp/
total 48K
drwxrwxrwx 4 root root 4.0K Feb 3 14:42 .
drwxr-xr-x. 31 coposuser coposuser 4.0K Feb 3 14:46 ..
drwxrwxrwx 3 root root 4.0K Feb 3 14:42 clonezilla
-rwxrwxrwx 1 root root 27K Feb 3 14:42 pxelinux.0
drwxrwxrwx 2 root root 4.0K Feb 3 14:42 pxelinux.cfg
-rwxrwxrwx 1 root root 9 Feb 3 14:42 test
The Port is opened
:
# netstat -anp|grep 69|grep xinet
udp 0 0 0.0.0.0:69 0.0.0.0:* 3533/xinetd
У вас может быть правило брандмауэра, блокирующее доступ
или
Ваш каталог / copos не имеет полных разрешений.
Вы сможете понять это, выполнив:
tail -f /var/log/messages
пока вы пытаетесь загрузить файл. Если вы не получаете никаких записей, это проблема с брандмауэром, если вы получаете что-то вроде:
Feb 3 18:50:48 host1 in.tftpd[10298]: RRQ from 192.168.4.190 filename test.xml
Feb 3 18:50:48 host1 in.tftpd[10298]: sending NAK (0, Permission denied) to 192.168.4.190
тогда это проблема с разрешениями.
Также имейте в виду, что захват только порта 69 не покажет вам всю трассировку. Сервер tftp будет использовать для передачи порт источника, отличный от порта 69. Вот почему tftp обычно не работает, если задействован NAT.
Таким образом, полный обмен обычно выглядит так, например:
client requests file via tftp (source port random_client -> dest port 69)
server send back tftp file (source port random_server -> dest port random_client)
Как вы можете видеть, захват tcpdump на порту 69 не покажет вам весь диалог. Также, если у вас есть NAT, после того, как сервер попытается отправить файл с исходного порта, отличного от 69, большинство реализаций NAT не смогут перенаправить пакет (будет работать только NAT с полным конусом или с ограниченным конусом, но с ограничением порта или симметричным NAT будет не).