Сеть, недостижимая после обновлений

Вот моя ситуация: Я выполняю 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, но это думает, что это - марсианский пакет по некоторым причинам и игнорирует/отклоняет его?

Вчера были обновлены эти пакеты:

  • libgnutls-openssl27:amd64
  • linux-headers-4.10.0-38-generic:amd64
  • linux-headers-virtual-hwe-16.04:amd64

Я уже попытался возобновить арендный договор DHCP, и удалить новое ядро и загрузить предыдущее ядро напрасно.

Что может быть сделано для разрешения этого?

0
задан 1 November 2017 в 09:51

1 ответ

Таким образом, оказывается, что проблема была с ddclient. Та же проблема произошла для меня на Azure также, но никогда не происходила на AWS.

Я использовал ddclient для обновления моих доменных записей для этого сервера. Кажется, что, возможно, GCE и Azure используют ddclient во время облачной-init установки для экземпляра, но AWS не делает. Я предполагаю, что это требуется позволить шлюзу знать, что экземпляр произошел, и т.д. Когда я установил и сделал свою собственную конфигурацию для ddclient, это, кажется, переопределяет то, что происходит во время запуска экземпляра, таким образом заставляя сеть не работать правильно. Удаление ddclient и удаление/etc/ddclient.conf решили проблему.

0
ответ дан 2 November 2019 в 00:06

Другие вопросы по тегам:

Похожие вопросы: