Вопрос или проблема
У нас есть несколько KVM виртуальных серверов в Hetzner, и вот что-то странное с ними.
ping -c 4 172.31.1.1
PING 172.31.1.1 (172.31.1.1) 56(84) байт данных.
От 49.13.XX.XX icmp_seq=1 Порт назначения недоступен
ping: sendmsg: Операция не разрешена
От 49.13.XX.XX icmp_seq=2 Порт назначения недоступен
ping: sendmsg: Операция не разрешена
От 49.13.XX.XX icmp_seq=3 Порт назначения недоступен
ping: sendmsg: Операция не разрешена
От 49.13.XX.XX icmp_seq=4 Порт назначения недоступен
ping: sendmsg: Операция не разрешена
--- статистика ping для 172.31.1.1 ---
4 пакета отправлено, 0 получено, +4 ошибок, 100% потеря пакетов, время 3051мс
Это под root. Это Ubuntu. Очевидно, что SeLinux отсутствует, только AppArmor, и он не ограничивает сетевые функции.
IP принадлежит шлюзу по умолчанию. iptables/nft не работает. Я совершенно сбит с толку.
Все остальные серверы доступны для ping. В чем причина этого? Это выглядит крайне запутано и даже глупо.
Ответ или решение
Вопрос о непинговании шлюза по умолчанию в виртуальных серверах KVM — это довольно распространенная ситуация, с которой могут столкнуться системные администраторы и пользователи, работая с облачными сервисами. Если вы пытаетесь пинговать адрес 172.31.1.1 и получаете сообщение "Destination Port Unreachable" с указанием "Operation not permitted", это может указывать на несколько различных причин, которые стоит исследовать.
1. Проверка сетевой конфигурации
Первое, что стоит сделать — проверить сетевые настройки вашего виртуального сервера. Убедитесь, что:
- IP-адрес вашего сервера и IP-адрес шлюза находятся в одной сети. В данном случае, необходимо удостовериться, что подсеть для 172.31.1.1 и вашего IP-адреса совпадают. Если адреса находятся в разных подсетях, вы не сможете получить доступ к шлюзу.
- Маска подсети настроена правильно. Неправильная маска может приводить к тому, что пакеты не будут направляться на шлюз.
ip addr show
ip route show2. Отсутствие ответов от шлюза
Если другие виртуальные сервера могут пинговать шлюз, а ваш — нет, это может указывать на следующие моменты:
- Фильтрация трафика на уровне шлюза. Администратор сети или провайдер облака может настроить правила безопасности, запрещающие ICMP-ответы от определенных IP-адресов для предотвращения DDoS-атак. Попробуйте проверить, существуют ли какие-либо ограничения на уровне сети.
- Правила брандмауэра. Хотя вы упомянули, что iptables или nft не запущены, стоит также проверить настройки bpf или других программ, которые могут блокировать трафик.
3. Аппаратные или программные ограничения
Несмотря на то, что ваше окружение на базе Ubuntu, вы также можете проверить следующее:
- Сетевые драйверы и инструменты управления. Убедитесь, что используемые драйвера актуальны и корректно работают с вашим гипервизором KVM.
- Наличие проблем на уровне виртуализации. Если ваш сервер работает в виртуальной среде KVM, возможно, существуют ограничения, наложенные гипервизором, которые препятствуют нормальному взаимодействию с сетью.
4. Проблемы с маршрутизацией
Хотя шлюз по умолчанию должен быть доступен, всегда следует удостовериться, что нет проблем с маршрутизацией:
traceroute 172.31.1.1Этот инструмент может помочь диагностировать, на каком этапе теряются пакеты.
5. Анализ журналов
Проверьте системные и сетевые журналы на наличие ошибок, которые могут указать на источник проблемы:
journalctl -xe
dmesg | grep -i errorЗаключение
Эта ситуация может показаться запутанной, но тщательное обследование сетевой конфигурации, правил маршрутизации и доступных сетевых ресурсов может помочь выявить причину непингования шлюза. Не стоит исключать возможность настроек на уровнях провайдера или гипервизора. Если вопросы сохраняются, рассмотрите возможность обращения в службу поддержки вашего провайдера облака для дальнейшей диагностики.