Сеть недоступна после обновлений
Вот моя ситуация: я запускаю изображение Google Compute Engine Ubuntu 16.04 по умолчанию на GCE. В основном это настройка по умолчанию, и я разрешаю подключения к SSH, HTTP и HTTPS. Все работает до перезагрузки, после чего сеть перестает работать.
Насколько я могу судить, это происходит после автоматических обновлений, или обновление вручную, когда ядро обновлено, но я не уверен на 100%. Все выглядит совершенно нормально, но ни входящий, ни исходящий сетевой трафик не работают. Я не могу пинговать машину или SSH. Я могу войти через последовательный терминал через Google Cloud Console. Здесь, когда я пытаюсь выполнить ping-машину снаружи, я получаю следующее сообщение в консоли:
Nov 1 11:40:17 instance-2 kernel: [ 409.306083] IPv4: martian source 10.128.0.2 from *x.x.x.x (my ip)*, on dev ens4
Nov 1 11:40:17 instance-2 kernel: [ 409.306100] ll header: 00000000: 42 01 0a 80 00 02 42 01 0a 80 00 01 08 00 B.....B.......
Я также вижу некоторые ошибки при загрузке облака-init, например:
[ 26.780358] cloud-init[1177]: 2017-11-01 11:24:42,023 - util.py[WARNING]: No instance datasource found! Likely bad things to come!
[FAILED] Failed to start Initial cloud-init job (metadata service crawler).
Но это, вероятно, связано с отсутствием какой-либо сетевой связи?
Я ничего не могу достичь, включая шлюз по умолчанию 10.128.0.1
Выходной сигнал ifconfig
ens4 Link encap:Ethernet HWaddr 42:01:0a:80:00:02
inet addr:10.128.0.2 Bcast:10.128.0.2 Mask:255.255.255.255
inet6 addr: fe80::4001:aff:fe80:2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:11 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2186 (2.1 KB) TX bytes:2980 (2.9 KB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Содержание /var/lib/dhcp/dhclient.ens4.leases
lease {
interface "ens4";
fixed-address 10.128.0.2;
option subnet-mask 255.255.255.255;
option routers 10.128.0.1;
option dhcp-lease-time 86400;
option dhcp-message-type 5;
option domain-name-servers 169.254.169.254;
option dhcp-server-identifier 169.254.169.254;
option interface-mtu 1460;
option domain-search "c.green-torus-124415.internal.", "google.internal.";
option ntp-servers 169.254.169.254;
option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
option host-name "instance-5.c.green-torus-124415.internal";
option domain-name "c.green-torus-124415.internal";
renew 3 2017/11/01 16:33:45;
rebind 3 2017/11/01 16:33:45;
expire 3 2017/11/01 16:33:45;
}
lease {
interface "ens4";
fixed-address 10.128.0.2;
option subnet-mask 255.255.255.255;
option routers 10.128.0.1;
option dhcp-lease-time 86400;
option dhcp-message-type 5;
option domain-name-servers 169.254.169.254;
option dhcp-server-identifier 169.254.169.254;
option interface-mtu 1460;
option domain-search "c.green-torus-124415.internal.", "google.internal.";
option ntp-servers 169.254.169.254;
option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
option host-name "instance-5.c.green-torus-124415.internal";
option domain-name "c.green-torus-124415.internal";
renew 4 2017/11/02 01:52:41;
rebind 4 2017/11/02 13:33:46;
expire 4 2017/11/02 16:33:46;
}
Итак, кажется, что пакет попадает на виртуальную машину, но он считает, что это маркерный пакет по какой-то причине и игнорирует / отклоняет его?
Эти пакеты были обновлены вчера:
libgnutls-openssl27: amd64 linux-headers-4.10.0-38-generic: amd64 linux -headers-virtual-hwe-16.04: amd64Я уже пробовал возобновить аренду DHCP и удалить новое ядро и загрузить предыдущее ядро безрезультатно.
Что можно сделать разрешить это?
2 ответа
Таким образом, выясняется, что проблема связана с ddclient. Эта же проблема произошла и для меня на Azure, но никогда не было на AWS.
Я использовал ddclient для обновления записей своего домена для этого сервера. Похоже, что, возможно, GCE и Azure используют ddclient во время установки cloud-init для экземпляра, но AWS этого не делает. Я предполагаю, что это требуется, чтобы шлюз знал, что экземпляр встал и т. Д. Когда я установил и создал собственную конфигурацию для ddclient, это, похоже, переопределяет то, что происходит во время запуска экземпляра, что приводит к тому, что сеть не работает должным образом. Удаление ddclient и удаление /etc/ddclient.conf решили проблему.
Таким образом, выясняется, что проблема связана с ddclient. Эта же проблема произошла и для меня на Azure, но никогда не было на AWS.
Я использовал ddclient для обновления записей своего домена для этого сервера. Похоже, что, возможно, GCE и Azure используют ddclient во время установки cloud-init для экземпляра, но AWS этого не делает. Я предполагаю, что это требуется, чтобы шлюз знал, что экземпляр встал и т. Д. Когда я установил и создал собственную конфигурацию для ddclient, это, похоже, переопределяет то, что происходит во время запуска экземпляра, что приводит к тому, что сеть не работает должным образом. Удаление ddclient и удаление /etc/ddclient.conf решили проблему.