Вот моя ситуация: Я выполняю Google Compute Engine по умолчанию изображение Ubuntu 16.04 на GCE. Все - в основном установка по умолчанию, и я позволяю соединения с SSH, HTTP и HTTPS. Все работает, пока перезагрузки не происходит, в которой точке сеть прекращает работать. Это произошло во второй раз теперь, в первый раз, когда я только что запустил с нуля, но я хотел бы узнать то, что продолжается теперь.
Настолько лучше всего, как я могу сказать, это происходит после необслуживаемых обновлений или ручных обновлений, когда ядро обновлено, но я не на 100% уверен. Все смотрит совершенно нормальные, но ни входящие ни исходящие работы сетевого трафика. Я не могу проверить с помощью ping-запросов машину или SSH в нее. Я могу зарегистрировать на пути последовательный терминал через Консоль Google Cloud. Здесь, когда я пытаюсь проверить с помощью 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;
}
Таким образом, кажется, что пакет добирается до VM, но это думает, что это - марсианский пакет по некоторым причинам и игнорирует/отклоняет его?
Вчера были обновлены эти пакеты:
Я уже попытался возобновить арендный договор DHCP, и удалить новое ядро и загрузить предыдущее ядро напрасно.
Что может быть сделано для разрешения этого?
Таким образом, оказывается, что проблема была с ddclient. Та же проблема произошла для меня на Azure также, но никогда не происходила на AWS.
Я использовал ddclient для обновления моих доменных записей для этого сервера. Кажется, что, возможно, GCE и Azure используют ddclient во время облачной-init установки для экземпляра, но AWS не делает. Я предполагаю, что это требуется позволить шлюзу знать, что экземпляр произошел, и т.д. Когда я установил и сделал свою собственную конфигурацию для ddclient, это, кажется, переопределяет то, что происходит во время запуска экземпляра, таким образом заставляя сеть не работать правильно. Удаление ddclient и удаление/etc/ddclient.conf решили проблему.