Нет пути к хосту для порта 6379

Вопрос или проблема

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

Redis определенно работает и слушает на порту 6379. Я могу подключиться к нему локально.

Сервер с Redis имеет следующую конфигурацию для iptables -S

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N FORWARD_IN_ZONES
-N FORWARD_IN_ZONES_SOURCE
-N FORWARD_OUT_ZONES
-N FORWARD_OUT_ZONES_SOURCE
-N FORWARD_direct
-N FWDI_public
-N FWDI_public_allow
-N FWDI_public_deny
-N FWDI_public_log
-N FWDO_public
-N FWDO_public_allow
-N FWDO_public_deny
-N FWDO_public_log
-N INPUT_ZONES
-N INPUT_ZONES_SOURCE
-N INPUT_direct
-N IN_public
-N IN_public_allow
-N IN_public_deny
-N IN_public_log
-N OUTPUT_direct
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES_SOURCE
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES_SOURCE
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -j OUTPUT_direct
-A FORWARD_IN_ZONES -g FWDI_public
-A FORWARD_OUT_ZONES -g FWDO_public
-A FWDI_public -j FWDI_public_log
-A FWDI_public -j FWDI_public_deny
-A FWDI_public -j FWDI_public_allow
-A FWDI_public -p icmp -j ACCEPT
-A FWDO_public -j FWDO_public_log
-A FWDO_public -j FWDO_public_deny
-A FWDO_public -j FWDO_public_allow
-A INPUT_ZONES -g IN_public
-A IN_public -j IN_public_log
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public -p icmp -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT

netstat -rn выводит:

0.0.0.0         178.xxx.xxx.1   0.0.0.0         UG        0 0          0 eth0
10.10.0.0       0.0.0.0         255.255.0.0     U         0 0          0 eth0
10.136.0.0      0.0.0.0         255.255.0.0     U         0 0          0 eth1
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
172.18.0.0      0.0.0.0         255.255.0.0     U         0 0          0 br-e071bb9e15A
178.xxx.xxx.0   0.0.0.0         255.255.240.0   U         0 0          0 eth0

Есть ли здесь что-то неправильно настроенное, и как я могу это исправить, чтобы удаленные серверы могли подключиться к порту 6379?

Судя по названиям цепочек, ваша конфигурация использует firewalld, который использует iptables в качестве заднего плана и генерирует правила iptables на основе своей собственной конфигурации. Redhat предоставляет много документации по его использованию. Для вашего случая предоставление доступа должно быть выполнено с помощью:

firewall-cmd --add-port=6379/tcp

Это, вероятно, будет отражено следующим образом в правилах iptables:

# iptables -S -t filter | grep -w 6379
-A IN_public_allow -p tcp -m tcp --dport 6379 -m conntrack --ctstate NEW -j ACCEPT

Это даст временный доступ к Redis, работающему на хосте. Если вы думаете, что сделали ошибку, вы можете отменить конфигурацию с помощью:

firewall-cmd --reload

Как только вы будете удовлетворены результатами, вы можете снова выполнить ту же команду с дополнительным параметром --permanent, чтобы записать конфигурацию, а не изменять правила, следующим образом для постоянной настройки:

firewall-cmd --permanent --add-port=6379/tcp

В дальнейшем вам всегда нужно будет выполнять две команды для изменения их на постоянной основе: одна для конфигурации, одна для работающего фаервола (после firewall-cmd --permanent ... достаточно будет выполнить firewall-cmd --reload).

Ответ или решение

Проблема "no route to host" при попытке подключения к Redis на порту 6379 может быть связана с несколькими факторами. Вы уже указали, что Redis работает локально и слушает на порту 6379, однако необходимо проверить конфигурацию сетевого окружения и брандмауэра.

  1. Проверка брандмауэра:
    Судя по вашему описанию, вы используете firewalld, который настраивает правила iptables. Убедитесь, что порт 6379 открыт для входящих соединений. Обычно это делается с помощью следующей команды:

    firewall-cmd --add-port=6379/tcp

    После выполнения этой команды, вы можете перепроверить, что правило добавлено, выполнив команду:

    iptables -S -t filter | grep -w 6379

    Вы должны увидеть строку, которая разрешает доступ к порту 6379.

  2. Постоянное изменение конфигурации:
    Если всё работает корректно, не забудьте сохранить изменения, чтобы они остались после перезагрузки сервера:

    firewall-cmd --permanent --add-port=6379/tcp
    firewall-cmd --reload
  3. Сетевые настройки:
    Убедитесь, что у вас правильные настройки сети, которые позволяют соединения от удалённых хостов. Проверьте файл конфигурации Redis (/etc/redis/redis.conf или аналогичный путь), убедитесь, что строка bind настроена правильно. По умолчанию, она может быть настроена на 127.0.0.1, что означает, что Redis доступен только локально. Измените эту строку на 0.0.0.0, чтобы Redis слушал на всех интерфейсах:

    bind 0.0.0.0

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

  4. Проверка маршрутизации:
    Используйте команду netstat -rn, чтобы убедиться, что ваш маршрутизатор настроен правильно. Убедитесь, что маршруты доступны для широковещательных адресов, если вы подключаетесь к серверу с другого сетевого сегмента.

  5. Убедитесь, что Redis работает:
    Если проблемы не устранены, проверьте состояние сервиса Redis:

    systemctl status redis

    Если служба не запущена, перезапустите её:

    systemctl restart redis

Следуя этим шагам, вы должны устранить ошибку "no route to host" и обеспечить возможность подключения к вашему Redis-серверу с удалённых машин. Если проблема все еще сохраняется, рассмотрите возможность проверок сетевого оборудования или провайдера, которые могут блокировать порты.

Оцените материал
Добавить комментарий

Капча загружается...