Назад | Перейти на главную страницу

Невозможно пинговать, но можно загружать пакеты

Я установил Debian Squeeze на сервер Dell PowerEdge. Однако у меня возникла проблема с настройкой сети. Хотя я могу пинговать машины внутри своей сети, я не могу выполнить d0 за пределами сети (google.com). Самое странное, что я могу обновлять пакеты из репозиториев Debian и устанавливать их!

Разрешение DNS работает нормально - проверено с помощью host google.com.

Я понимаю, что это должна быть проблема, связанная с настройками сети и / или брандмауэром. Однако я не могу понять проблему. Буду очень признателен за любую помощь.

Содержание / и т.д. / сеть / интерфейсы

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
#iface eth0 inet dhcp
iface eth0 inet static
    address 10.14.85.244  
    netmask 255.255.0.0
    network 10.14.0.0
    gateway 10.14.1.2

Содержание /etc/resolv.conf

domain sit.iitkgp
search sit.iitkgp
nameserver 10.14.0.2

Содержание /etc/apt/apt.conf

Acquire::http::proxy "http://IP:PORT/";    # Values are actually used here
Acquire::ftp::proxy "ftp://IP:PORT/";
Acquire::https::proxy "https://IP:PORT/";

iptables

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

Маршруты

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.14.0.0       0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         10.14.1.2       0.0.0.0         UG    0      0        0 eth0

Ближе к концу этого ping strace что-то вроде EAGAIN (Resource temporarily unavailable) можно рассматривать. Это сообщение не появляется, когда я пингую (успешно) внутренний IP-адрес. Будьте уверены, что это новый сервер и на нем более чем достаточно места на диске и в памяти.

Обновить

Только что заметил что tcptraceroute работает нормально:

# tcptraceroute -i eth0 google.com
Selected device eth0, address 10.14.85.244, port 53532 for outgoing packets
Tracing the path to google.com (74.125.236.80) on TCP port 80 (www), 30 hops max
 1  10.14.1.2  0.310 ms  0.283 ms  0.281 ms
 2  10.151.1.2  0.274 ms  0.253 ms  0.281 ms
 3  maa03s05-in-f16.1e100.net (74.125.236.80) [closed]  0.141 ms  0.172 ms  0.227 ms

Обновление и разрешение

Я считаю, что сообщения ICMP блокируются брандмауэром. Кроме того, у соответствующего сервера нет общедоступного IP-адреса. Я думаю, это тоже как-то связано. Другая машина, с которой я мог пинговать google.com, имеет публичный IP-адрес.

Однако меня больше всего беспокоило то, что apt-get действительно сработало, но не lynx или wget. Проблема заключалась в переменных окружения прокси. Они были установлены в .bashrc файл, но не export-ед. Я не заметил этого. Как только я их экспортировал, все идет гладко.

Спасибо всем за понимание!

Для тебя - А ХайкуХокку.

См. Ваш брандмауэр.
Он блокирует ICMP.
Сделайте так, чтобы этого не было.

Или, точнее:

Пинг - это ICMP. DNS - это UDP. Загрузки идут по TCP.
Проблема, с которой вы столкнулись, заключается в том, что ping не работает, что означает, что ваш брандмауэр (или другой в сети), вероятно, блокирует ICMP.

Исправьте это или попросите ответственного netadmin исправить это, и ping будет работать.

Дважды проверьте свой шлюз на соответствие настройкам машины, которая может пинговать за пределами вашей сети.

Обычные соглашения (по большей части) используют в качестве шлюза либо первый, либо последний доступный IP в данном блоке. Итак, 10.14.0.1 или 10.14.255.254. Ваш (хотя он может быть правильным) на первый взгляд выглядит немного странно.

Вы пробовали использовать такой инструмент, как curl / wget, чтобы попытаться получить что-нибудь из реального внешнего мира? Найденные вами пакеты могут быть не на исходном установочном носителе.