Сеть есть, пинги не идут.
Куда копать? Интернет раздаётся обычным бытовым роутером, dhcp-сервер на нём же.
Попробуйте пропинговать роутер по его айпи 10.0.0.1
Если и он не пингуется, под рутом посмотреть что показывает iptables-save
Обмолвлюсь, что система устанавливалась через net-install и всё было нормально. Проблема всплыла при первом старте системы, больше никаких действий с ОС не производилось.
Кстати, если бы вы привели здесь вывод неработающего пинга, это стало бы ясно сразу же.
Команда ping всегда пишет, от какого узла сети получила “от ворот поворот”, то бишь ICMP-сообшение “host unreacable”, и в данном случае мы бы увидели, что пакеты заворачивает роутер, а не ваш комп.
Что касается причин, то возможно, у роутера диапазон выдаваемых по DHCP адресов почему-то не совпадает с настройками маршрутизации. Если, конечно, другие компьютеры через него у вас успешно выходят в сеть.
$ host ya.ru
?
Я не утверждаю, что это так, но пока это единственное, что приходит в голову. Для бОльшего нужно больше информации.
P.S.
Посмотрел ваш пинг. Если он правда больше ничего не показывает, имеет смысл посмотреть, что показывает tcpdump. Если у вас он не установлен, поставьте одноимённый пакет.
Надо запустить под рутом
Что-то Arch совсем не хочет со мной дружить.
© 2006-2021, Русскоязычное сообщество Arch Linux.
Название и логотип Arch Linux ™ являются признанными торговыми марками.
Linux ® — зарегистрированная торговая марка Linus Torvalds и LMI.
Источник
Не работает ping6 !!
Разбираюсь тут с айписэкс.
Есть две убунту в двух разных ДЦ.
Хецнер не парился со стандартами, забил на нетплан. В результате, на его ВПС внешние адреса ип6 пингуются, например гугл
у него в /etc/netplan/01-netcfg.yaml почти пусто
# For more information, see netplan(5).
network:
version: 2
renderer: networkd
ethernets:
ens4:
dhcp4: yes
Они всё прописали в /etc/network/interfaces.d/50-cloud-init.cfg !
В другом ДЦ я решил делать по Ъ, прописал всё в
/etc/netplan/01-netcfg.yaml
и оно, удивительно, работает только наполовину. То есть адрес присвоился, netplan apply заработал, но не пингует ничего, тот же ип6 гугла, например. Алсо, сам хост не пингуется с других. себя по ип6 нормально пингует.
Мне кто-то объяснит, надо ли пилять базовую ип6 конфигурацию на несколько разных файлов, при использовании нетплан, или оно и так должно работать?
но не пингует ничего, тот же ип6 гугла, например
Без ip -6 ro и traceroute6 сложно понять что у тебя там и где не работает.
момент
ip -6
2a00:b700::/48 dev ens18 proto kernel metric 256 pref medium
fe80::/64 dev ens18 proto kernel metric 256 pref medium
default via 2a00:b700::5:1 dev ens18 proto static metric 1024 pref medium
traceroute6 2a00:1450:400f:80a::200e
traceroute to 2a00:1450:400f:80a::200e (2a00:1450:400f:80a::200e) from 2a00:b700::5:6f, 30 hops max, 24 byte packets
sendto: Invalid argument
1 traceroute: wrote 2a00:1450:400f:80a::200e 24 chars, ret=-1
*sendto: Invalid argument
traceroute: wrote 2a00:1450:400f:80a::200e 24 chars, ret=-1
*sendto: Invalid argument
traceroute: wrote 2a00:1450:400f:80a::200e 24 chars, ret=-1
Они всё прописали в /etc/network/interfaces.d/50-cloud-init.cfg !
уточнил, оное для dhcp
/etc/systemd/network/05-eth0.network нет, к слову говоря.
$ ping6 2a00:b700::5:1
PING 2a00:b700::5:1(2a00:b700::5:1) 56 data bytes
From 2a00:b700::5:6f icmp_seq=1 Destination unreachable: Address unreachable
sudo ip6tables -vn -L
[sudo] password for darkshvein:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
я уже пробовал пинговать шлюз, не пингуется. хз, может тоже закрыт для пинга.
From 2a00:b700::5:6f icmp_seq=1 Destination unreachable: Address unreachable
я уже пробовал пинговать шлюз, не пингуется. хз, может тоже закрыт для пинга.
Различить закрыт ли он для пинга или не доступен совсем(например из-за ошибки конфигурации) — легко
Может роутить надо через link-local адрес шлюза(если там вообще есть router advertisement конечно). Это ж ipv6, тут могут упорыши закрыть и не такое.
ip -6 neigh show
2a00:b700::220 dev ens18 lladdr 66:65:37:65:38:36 STALE
fe80::6465:37ff:fe65:3836 dev ens18 lladdr 66:65:37:65:38:36 STALE
fe80::21f:ceff:fef5:a990 dev ens18 lladdr 00:1f:ce:f5:a9:90 router STALE
2a00:b700::5:1 dev ens18 FAILED
шлюз того. не отвечает?
ну попингуй fe80::21f:ceff:fef5:a990(это link-local твоего шлюза) и посмотри что в tcpdump происходит — если адрес по-прежнему будет STALE тады ой, шлюз не отвечает.
А на такой адрес в сегменте вообще никто не откликается
ping6 fe80::21f:ceff:fef5:a990
connect: Invalid argument
ping6 fe80::21f:ceff:fef5:a990
connect: Invalid argument
Для пинга по link-local адресам нужно ОБЯЗАТЕЛЬНО указывать имя выходного интерфейса(потому что теоретически один и тот же link-local адрес может оказаться за разными физическими интерфейсами)
спасибо.
да, так пинг идёт
ping6 -I ens18 fe80::21f:ceff:fef5:a990
PING fe80::21f:ceff:fef5:a990(fe80::21f:ceff:fef5:a990) from fe80::4441:c6ff:fe6d:e383%ens18 ens18: 56 data bytes
64 bytes from fe80::21f:ceff:fef5:a990%ens18: icmp_seq=1 ttl=64 time=0.662 ms
64 bytes from fe80::21f:ceff:fef5:a990%ens18: icmp_seq=2 ttl=64 time=0.714 ms
а по остальным адресам всё равно не идёт, кстати. там тоже указывал имя интерфейса.
Попробуй указать fe80::21f:ceff:fef5:a990 в качестве адреса шлюза по умолчанию. Но вообще по идее это должно прийти через router advertisement — может у тебя отключено принятие?
Если включен роутинг IPv6(net.ipv6.conf.all.forwarding), то оно должно быть 2, а не 1
sysctl net.ipv6.conf.ens18.accept_ra
net.ipv6.conf.ens18.accept_ra = 0
фигня какая то(
сейчас перепропишу
короче.
прописал
net.ipv6.conf.ens18.accept_ra = 1
в sysctl.conf не помогло
добавил гейтвей6 в нетплане fe80::21f:ceff:fef5:a990
и всё заработало, даже пинг этой машины из хецнера прошёл.
спасибо большое!
А форвардинг-то включен? Если да — то прописывание 1 и не поможет, надо прописывать 2.
Логика в следующем — если машина объявляет себя роутером — она перестает принимать анонсы по умолчанию, если не указать этого явно
Я это к чему — если хостер сменит роутинг — то адрес через который ты маршрутизируешься сменится и будет ой. Поэтому лучше полагаться на router advertisement когда есть такая возможность
подскажи пожалуйста ещё вот что,
если команда
ip -6 neigh show
выдаёт очень много адресов, как понять,какой из них твой шлюз?
ээээ. а с каких пор шлюз определяется по NDP/ARP-записям? Начни с ip -6 route show, а потом смотри какой MAC соответствует этому адресу в ip -6 neigh show с пометкой REACHABLE
Есть две убунту в двух разных ДЦ.
Источник
Ubuntu не отвечает на ping только с одного компа. Счего начать? См. tcpdump
Есть сервер на Ubuntu, его все видят и с ним работают из разных сетей. Но есть машна, которую он «игнорирует». Точнее не машины, а ip т.к. если его поменять, то все будет нормально.
Подскажите, как начать расследование, что бы это лечить, а не переставлять ip на клиенте или сервер?
Вот, что видится на сервере от ping с «больной» машины:
Вот, что видится на сервере от ping с нормальной машины:
src host 192.168.8.110 or dst host 192.168.8.110 эквивалентно host 192.168.8.110
grep -r 192.168.8.39 /etc
Да, похоже на то, что айпишник числится в каком-то блеклисте — нужно смотреть конфиг iptables (iptables -vnL —line-numbers), а также всякие hosts.deny в /etc
из всего, что я нашел про 8.39 на сервер 3.54 есть только лог apach:
говорит, что с этой машиной работали на сервере далее он «завис» и после перезагрузки стал не доступен с этой машиной.
заработало
при очередной перезагрузки сервака, он стал виден с «больной» машины.
iptables вообще отключен, там ничего нет
В общем осталось чувство неудовлетворенности, т.к. ровно такие «залипухи» случается с этим сервером уже второй раз и временно отвергнутая машинка была из другой сети.
Спасибо, что обратили внимание на мое сообщение.
Ну, в другой раз можно провести более детальную диагностику, начать с tcpdump или iptables -j LOG, там смотреть по обстоятельствам.
снова перестало пинговаться
в общем, картина такая же: несколько минут проработало и перестало.
про то, что выдает tcpdump я писал в исходном посте а с iptables я так понял вы предлагаете сделать цепочку и прогонять по ней общение с 8.39 так?
нет в сети такого же ипа? На сервере один интерфейс?
да не обязательно цепочку, просто поставить пару правил с таргетом LOG и смотреть, где теряется
Кстати, да интересная мысль.
добавил:
смотрю iptables -nvL
после очередной перезагрузки сервер работает:
жду пока снова перестанет
Попробуй посмотреть кэш таблицы маршрутизации в момент когда машина не пингуется
вроде нет, все раздается по DHCP.
да, на сервере один интерфейс
а как лучше проверить?
наблюдаю за таблицей, есть копии: — после 12 часов работы и когда не пингуется — сразу после перезагрузки — после того как с 8.39 немного поработали с сервером.
Вроде все логично, 8.39 присутствует только в последнем случае.
Я бы посмотрел ещё на ARP таблицы и может быть ARP запросы во время отказа.
Если сервер в одном ethenet сегменте с 192.168.8.110, то, как уже посоветовали, проверьте ARP, в том числе и командой arping. Может 192.168.8.39 не отвечает на ARP-запросы сервера.
Спасибо, к сожалению они не в одной сети.
уже сутки работает нормально.
Большое спасибо всем, вроде работает уже долго и надежно.
Не понятно, что помогло, но вот, что в итоге было сделано:
1. очистил место на диске, т.к. по ходу выявилась проблема: по данным df -h места дофига, а при upload файлов происходил сбой.
2. включил FireWall, из используемых портов оставил открытыми только те, что используются.
в результате этого, закрытыми оказались 5353, это mDNS и еще какой то «блуждающий» порт (судя по команде netstat -nvl) с номером > 10000, который к java программе вел.
Источник
