Вопросы Теги

Wget, Завихрение, Вкусный Сбой, но работы Ping - CentOS 5

Это походит об этом... Насколько я знаю, другие ресурсы (как почтовые шпульки и crontabs) все создаются по требованию. Корневой каталог (скопированный с/etc/skel) и passwd/group/shadow файлы является всем, что должно быть изменено на создании использования.

7
задан 2 September 2010 в 20:15
7 ответов

У Вас есть правила брандмауэра на месте, которые являются блокирующим портом 80 исходящих, или отказ от взаимного входящего ответа. Они могут быть правилами программного брандмауэра, которые могут быть блокирующим портом 80 конкретно, или весь TCP (PING является ICMP), сверьтесь:
iptables -L поскольку ErikA указал выше.
Это могла также быть проблема аппаратного брандмауэра - сервер позади брандмауэра Cisco? Консультируйтесь с Вашим определять местоположение системного администратора. Если можно завихриться от других машин, у них есть:80 открытых. Это также возможно, но вряд ли, который они блокируют, Вы - их сторона, но если Вы ничто не можете завихриться (даже Google), это - Ваша сторона.

3
ответ дан 2 December 2019 в 23:39
  • 1
    , я ничто не могу завихриться, даже Google. Серверы находятся в Китае - но я проверил это curl http://google.com работы над другими серверами. –  Michael Robinson 2 September 2010 в 19:42
  • 2
    Так как это Китай, это добавляет другую ссылку в, "кто мог блокировать Вас" цепочка. Действительно завихряется работа google.cn? Можно ли соединиться с другими портами (например, telnet к 443?) –  James L 2 September 2010 в 20:08
  • 3
    Не Может curl http://google.cn/ на сервере проблемы, может на других. –  Michael Robinson 2 September 2010 в 20:11
  • 4
    telnet для портирования 443, 80 зависают. –  Michael Robinson 2 September 2010 в 20:13
  • 5
    то, что telnet для портирования 443 работ, или они оба зависают? –  James L 2 September 2010 в 20:45

Как я проверил бы, что что-то слушает на порте 80, и что нет никаких правил брандмауэра, которые заблокировали бы трафик к oprt 80 от IP, от которого я тестирую?

  • netstat-anp
  • iptables-vL
1
ответ дан 2 December 2019 в 23:39

Ну, ping использует ICMP, тогда как все те клиенты HTTP используют порт TCP 80. Это могло быть заблокировано между Вашим источником и местом назначения?

2
ответ дан 2 December 2019 в 23:39
  • 1
    , Мог быть, но другие два сервера не зависают ни в одном из моих примеров –  Michael Robinson 2 September 2010 в 19:41
  • 2
    Так, чтобы мог быть заблокирован для сервера, это перестало работать. –  mfinni 2 September 2010 в 20:06
  • 3
    Это могло быть... там так или иначе, чтобы я определил ли дело обстоит так? –  Michael Robinson 2 September 2010 в 20:10
  • 4
    Если Вы не можете даже telnet для портирования 80, то он заблокирован где-нибудь. Это могло быть заблокировано на Вашем сервере, с которого Вы запускаете соединение. Это могло быть заблокировано на веб-сайте, с которым Вы пытаетесь соединиться. Это могло быть заблокировано в любом промежуточном сетевом устройстве. Необходимо работать со сторонами, ответственными за каждого/всего из тех для определения, где блок. завихрение –  mfinni 2 September 2010 в 20:30
  • 5
    к незаконному серверу из работ LAN, они, должно быть, заблокировали IP –  Michael Robinson 2 September 2010 в 20:36

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

Чтобы проверить, слушает ли что-то на порте 80, выполняет следование из самого веб-сервера:

$ netstat -lan | egrep LISTEN

В выводе, если Вы видите строку как это, затем что-то слушает на порте 80.

tcp        0      0 0.0.0.0:80            0.0.0.0:*               LISTEN

Если что-то действительно слушает на порте 80, то вероятно, что правило брандмауэра блокирует трафик. Можно проверить правила брандмауэра путем выполнения $ iptables --list на веб-сервере.

0
ответ дан 2 December 2019 в 23:39
  • 1
    Спасибо за Ваш ответ. Как я проверил бы, что что-то слушает на порте 80, и что нет никаких правил брандмауэра, которые заблокировали бы трафик к oprt 80 от IP, от которого я тестирую? Я проверил на обоих наших других веб-серверах что примеры выше работы. –  Michael Robinson 2 September 2010 в 19:22
  • 2
    , я отредактировал свой ответ для отражения дополнительных вопросов. –  EEAA 2 September 2010 в 19:31
  • 3
    Спасибо, я добавил вывод двух команд к моему вопросу –  Michael Robinson 2 September 2010 в 19:36
  • 4
    Ну, от Вашего вывода netstat ничто не слушает на порте 80. Вы уверены, что Ваш процесс веб-сервера работает? –  EEAA 2 September 2010 в 20:12
  • 5
    Просто установленный httpd, посмотрите обновленный вывод. –  Michael Robinson 2 September 2010 в 20:15

Я не полностью понимаю, как Вы пытаетесь протестировать это, но действительно ли это - экземпляр EC2? Если так, удостоверьтесь, что это находится в той же "группе безопасности" как другие серверы или что политики в группе позволяют порт 80 и такой.

0
ответ дан 2 December 2019 в 23:39

Что-то между Вашим неправильно себя ведущим сервером и rpm.pbone.net блокирует соединения TCP, инициируемые Вашим неправильно себя ведущим сервером с rpm.pbone.net порт 80 как место назначения. Преступник мог быть Вашим сервером самим, rpm.pbone.net самостоятельно, или любой промежуточный маршрутизатор/брандмауэр. И то, что заблокировано, могло быть пакетом установления соединения или его ответом.

Первый шаг в расследовании должен выяснить, кто блокирует трафик. tcptraceroute rpm.pbone.net 80 должен сказать Вам, как далеко пакеты могут пойти.

Это может или не может помочь работать tcpdump и посмотрите, получаете ли Вы некоторый ответ (ACK, ICMP или что-то более странное) к Вашему пакету SYN при запуске исходящего соединения с портом 80.

0
ответ дан 2 December 2019 в 23:39

В моем случае проблема была вызвана устаревшим кешем DNS. Помогло следующее: 

# service nscd restart
1
ответ дан 2 December 2019 в 23:39

Теги

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