Вопрос или проблема
Я пытаюсь сделать ping на свой новый сервер Ubuntu 18 (работающий как VPS у какого-то хостинг-провайдера) из командной строки после подключения по ssh к машине. И при использовании публичного IP-адреса (196.189.91.144), и зарегистрированного доменного имени (swapme.et), ping просто истекает по времени.
Так как я не очень разбираюсь в конфигурации серверов, я растерян и удивлён, что это не работает, особенно потому, что у меня не было такой проблемы на предыдущих VPS-серверах, с которыми я экспериментировал.
Необходимо ли делать какую-то дополнительную ручную настройку, чтобы получить работу обратной связи? Я думал, что можно сделать ping на себя, используя публичный IP или доменное имя, из коробки(?)
Вот что у меня есть на данный момент, и что я могу предложить в качестве релевантной информации для решения проблемы:
/etc/hostname
etisp
/etc/hosts
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
# Следующие строки желательны для хостов, поддерживающих IPv6
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
$ ifconfig -a
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.180.53.144 netmask 255.255.255.0 broadcast 10.180.53.255
inet6 fe80::f816:3eff:fe43:32d6 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:43:32:d6 txqueuelen 1000 (Ethernet)
RX packets 4478573 bytes 324094022 (324.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 279023 bytes 41316618 (41.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 730566 bytes 43043266 (43.0 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 730566 bytes 43043266 (43.0 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Правила межсетевого экрана
Статус: активен
Логирование: включено (низкое)
По умолчанию: запрещено (входящие), разрешено (исходящие), отключено (маршрутизируемые)
Новые профили: пропуск
Куда Действие Откуда
-- ------ ----
22/tcp (OpenSSH) РАЗРЕШИТЬ В Куда угодно
80/tcp РАЗРЕШИТЬ В Куда угодно
443/tcp РАЗРЕШИТЬ В Куда угодно
80,443/tcp (Nginx Full) РАЗРЕШИТЬ В Куда угодно
22/tcp (OpenSSH (v6)) РАЗРЕШИТЬ В Куда угодно (v6)
80/tcp (v6) РАЗРЕШИТЬ В Куда угодно (v6)
443/tcp (v6) РАЗРЕШИТЬ В Куда угодно (v6)
80,443/tcp (Nginx Full (v6)) РАЗРЕШИТЬ В Куда угодно (v6)
Обратите внимание, что ping других серверов работает, а ping на публичный IP-адрес и доменное имя с другой машины также работает.
Спасибо!
Основываясь на том, что мы знаем до сих пор, я попробую первое решение.
- Есть сервер, который отправляет ping на внешний адрес
196.189.91.144 - Есть маршрутизатор, который знает сеть
10.180.53.0/24, включая10.180.53.144, и внешний IP196.189.91.144 - Есть Интернет, который знает внешний IP
196.189.91.144
Если кто-то из Интернета сделает ping на внешний IP, возможно, маршрутизатор ответит или в случае продвинутой настройки ICMP будет перенаправлен, и сервер ответит. Мы пока не знаем.
Но в любом случае маршрутизатор нуждается в информации, чтобы ответить на запросы с внешнего адреса и на внутреннем интерфейсе тоже.
Каждый маршрут, который не определён, будет проходить через стандартный шлюз, в данном случае через маршрутизатор. Но у маршрутизатора также есть шлюз по умолчанию (чаще всего это провайдер). И если маршрутизатор отправит ping провайдеру, почему провайдер должен на это ответить?
Варианты решения зависят от точной настройки. Но в любом случае, почему я должен проверять ответ ICMP системы за NAT из-за NAT? Внутренняя сеть здесь более важна.
Ответ или решение
Когда вы настраиваете VPS (виртуальный выделенный сервер) и не можете пинговать его собственный внешний IP-адрес или зарегистрированное доменное имя, это может быть вызвано несколькими факторами, которые стоит рассмотреть. Давайте детально разберем ситуацию, используя предоставленные вами данные.
1. Сетевой интерфейс и адресация
Из вашего вывода команды ifconfig -a видно, что ваш сервер имеет внутренний IP-адрес 10.180.53.144 и внешний IP-адрес 196.189.91.144. В VPS среде часто используется NAT (сеть с преобразованием адресов) для разделения внутренней и внешней адресации.
Проблема с пингом:
- Пинг через внешний IP: Когда вы пытаетесь пинговать свой сервер через внешний IP, запрос проходит через интернет к вашему провайдеру, а затем обратно к вашему серверу. Однако, если сервер не настроен для обработки ICMP-запросов (протокол для ping), вы не получите ответа.
- Пинг через доменное имя: Здесь ситуация аналогична. Хотя доменное имя может разрешаться в правильный IP-адрес, сервер все равно требует соответствующих настроек.
2. Фаервол и конфигурация сервера
Из вывода ваших правил фаервола видно, что только порты 22 (SSH), 80 (HTTP) и 443 (HTTPS) открыты для входящих соединений. Это значит, что ICMP-запросы (которые используются для ping) могут быть заблокированы по умолчанию.
Решение:
- Проверьте настройки вашего фаервола. Некоторые фаерволы фактически блокируют ICMP-запросы. Чтобы разрешить пинг, вам нужно добавить правило для ICMP:
sudo ufw allow proto icmp- Также проверьте, не установлен ли здесь другой механизм фильтрации, который мог бы блокировать ICMP-запросы.
3. Маршрутизация и NAT
Проблема также может заключаться в маршрутизации. Если ваш сервер находится за NAT, необходимо убедиться, что маршрутизация настроена корректно, и что ваш сервер может получать ICMP-запросы от внешних IP-адресов.
Рекомендации:
- Убедитесь, что маршрутизатор (или провайдер) настроен так, чтобы перенаправлять ICMP-запросы на внутренний IP-адрес вашего VPS. Если ваш провайдер предоставляет NAT, важно, чтобы он разрешал обратные ICMP-запросы.
- Проверьте документацию вашего провайдера на предмет возможных ограничений.
4. Локальная конфигурация
Вы также упомянули, что конфигурация /etc/hosts и /etc/hostname настроена корректно. Однако, эти файлы не влияют на ICMP, но могут быть полезны для локального разрешения имен.
5. Дополнительные шаги
Если после всех вышеперечисленных шагов проблема сохраняется:
- Запустите диагностику маршрутизации на вашем сервере:
traceroute 196.189.91.144-
Это поможет вам пройтись по каждому узлу в маршруте и выявить, где именно теряются пакеты.
-
Проверяйте также логирование на вашем сервере и фаерволе на предмет ошибок или блокировок ICMP.
Заключение
Таким образом, проблема с невозможностью пинга своего VPS-сервера по внешнему IP-адресу или доменному имени может быть вызвана рядом факторов, включая настройки фаервола, маршрутизацию и NAT. Прошаговое решение с учетом всех этих аспектов должно помочь вам успешно настроить ваше серверное окружение. Если вам потребуется дополнительная помощь, всегда можно обратиться в техподдержку вашего провайдера или к специалисту по сетям.