Я запускаю Ubuntu 18.10 на VPS.
С момента обновления (я почти уверен) с 16.04 мой вторичный IP-адрес просто перестает получать трафик после нескольких часов работы.
У меня будет два запущенных эхо-запроса, на мой основной IP и мой дополнительный IP, а вторичный просто спонтанно отключится примерно через 3-4 часа.
Когда это происходит, его интерфейс, eth0
, по-прежнему будет отображаться как <UP>
в ifconfig -a
. An mtr
доберется до своего шлюза.
Перезагрузка восстанавливает IP-адрес и делает его доступным. Ничего больше. Не ifdown eth0 --force && ifup eth0
не service networking restart
.
Соответствующие интерфейсы:
$ ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 149.210.175.202 netmask 255.255.255.0 broadcast 149.210.175.255
ether 52:54:00:35:97:95 txqueuelen 1000 (Ethernet)
RX packets 703 bytes 65063 (65.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 146 bytes 19511 (19.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Не уверен, почему второй IP не отображается в ifconfig -a
, как это происходит в ip a
:
$ ip a
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:35:97:95 brd ff:ff:ff:ff:ff:ff
inet 149.210.175.202/24 brd 149.210.175.255 scope global eth0
valid_lft forever preferred_lft forever
inet 149.210.176.154/24 brd 149.210.176.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a01:7c8:aab3:44f:5054:ff:fe35:9795/64 scope global dynamic mngtmpaddr
valid_lft 2591978sec preferred_lft 604778sec
inet6 fe80::5054:ff:fe35:9795/64 scope link
valid_lft forever preferred_lft forever
Я не использую netplan.io, потому что какой-то блог опубликовал о том, что он глючит, что заставило меня принять это за причину. Однако с netplan.io существует точно такая же проблема. у меня было ufw
отключен на время, не имело значения.
Хостинговая компания была достаточно любезна, чтобы помочь мне устранить неполадки, но безрезультатно. Они даже перенесли VPS на другой гипервизор, что не имело никакого значения. В крайнем случае, я полностью обновил ядро до 5.1.8-050108-generic
.
Что я могу сделать, чтобы узнать больше о причинах периодических отключений?
Лучшее время для устранения неполадок - это время возникновения проблемы.
dmesg
или journalctl -k
команда.ip monitor
команда, чтобы увидеть, какие события и изменения происходят.ip n ls
). Адрес шлюза должен быть REACHABLE
.nstat -az
вывод тоже может быть очень полезным, но только после шагов, описанных выше.