Вопросы Теги

TFTP: тайм-аут передачи на сервере RHEL 6

Я врезаюсь в стену, пытаясь заставить tftp работать с использованием RHEL 6 в качестве сервера. Ошибка со стороны клиента просто "

1) Использование tcp вместо udp = FAIL

2) Перемещение корневого каталога tftp = FAIL

3) И, как вы можете видеть, у меня уже включено подробное ведение журнала для tftp

4) Изменение пользователь в config = FAIL

Я сейчас в растерянности. Кто-нибудь сталкивался с этой проблемой раньше?

ОБНОВЛЕНИЕ: Вот моя полная конфигурация iptables: 

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1:136]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 69 -m state --state NEW,ESTABLISHED -  j ACCEPT
-A INPUT -j DROP
COMMIT

Кроме того, я отключил iptables и по-прежнему получаю такое же сообщение об истечении времени ожидания передачи.

ОБНОВЛЕНИЕ №2 - Я также добавил следующее в iptables, но iptables недоволен. 

-A INPUT --sport 1024: --dport 1024: -m state --state ESTABLISHED -j   ACCEPT
-A OUTPUT --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

Ошибка: 

iptables: Applying firewall rules: iptables-restore v1.4.7: unknown option `--sport'

ОБНОВЛЕНИЕ # 3

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

Перед началом передачи: 

 5      245 ACCEPT     udp  --  *      *       192.168.10.11         0.0.0.0/0           udp dpt:69 state NEW,ESTABLISHED 
   0        0 ACCEPT     udp  --  *      *       192.168.10.11         0.0.0.0/0           udp spts:1024:65535 dpts:1024:65535 state   ESTABLISHED 
--
   0        0 ACCEPT     udp  --  *      *       0.0.0.0/0             192.168.10.11      udp spt:69 state ESTABLISHED 
  30      960 ACCEPT     udp  --  *      *       0.0.0.0/0             192.168.10.11      udp spts:1024:65535 dpts:1024:65535 state  RELATED,ESTABLISHED

После попытки передачи: 

   10      490 ACCEPT     udp  --  *      *       192.168.10.11        0.0.0.0/0           udp dpt:69 state NEW,ESTABLISHED 
    0        0 ACCEPT     udp  --  *      *       192.168.10.11            0.0.0.0/0           udp spts:1024:65535 dpts:1024:65535 state      ESTABLISHED 
 --
   0        0 ACCEPT     udp  --  *      *       0.0.0.0/0             192.168.10.11      udp spt:69 state ESTABLISHED 
   58     1856 ACCEPT     udp  --  *      *       0.0.0.0/0             192.168.10.11      udp spts:1024:65535 dpts:1024:65535 state  RELATED,ESTABLISHED

Таким образом, это говорит мне, что это не брандмауэр, и если я не вижу пакетов возврата с tcpdump, это что-то среднее, возможно, само приложение.

3
задан 28 July 2016 в 21:40
1 ответ

Поскольку вы используете модуль state в конфигурации iptables, чтобы разрешить только НОВЫЕ соединения через порт tftp, и вы разместили только выдержку из конфигурации вашего брандмауэра:

1 ПРИНЯТЬ udp - в любом месте состояние НОВОЕ udp dpt: tftp

является тем правилом в цепочке INPUT, а также существует общее -A INPUT -m состояние --state RELATED, УСТАНОВЛЕНО -j ПРИНЯТЬ правило? (Если это так, то это правило, вероятно, должно быть первым правилом в вашей цепочке INPUT.)

Поскольку, хотя сам протокол UDP не имеет состояния, модули conntrack по-прежнему сохраняют некоторую информацию о состоянии для UDP, и у вас может быть случай, когда первый Пакет UDP принимается, и каждый последующий пакет рассматривается как часть «установленного» или «связанного» сеанса , а не как «новый» и отклоняется.

3
ответ дан 3 December 2019 в 06:29

Теги

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