Ubuntu 18.04’te DHCP istemcisinden yanlış IP adresi


3

Ubuntu 18.04 (sunucu) kutumun DHCP sunucusundan önyükleme sırasında yanlış bir IP adresi vermesiyle ilgili garip bir sorun yaşıyorum. Arayüzde önyüklemeden sonra dhclient çalıştırmak, arayüze doğru IP eklenmesine neden olur.

DHCP Sunucusu, gösterilen MAC adresini kullanarak bir rezervasyonun elle yapılandırıldığı bir Windows kutusudur. ip addr Ubuntu'da (iki nokta üst üste olmadan):

5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:26:b9:82:44:27 brd ff:ff:ff:ff:ff:ff
    inet 10.10.11.162/23 brd 10.10.11.255 scope global dynamic eno4
       valid_lft 689861sec preferred_lft 689861sec
    inet6 fe80::226:b9ff:fe82:4427/64 scope link
       valid_lft forever preferred_lft forever

Benim 50-courtin-networking.cfg (cloud-init cfg)

network:
  version: 2
  ethernets:

    bcm:
      match:
        name: eno*
      dhcp4: true
      dhcp6: false

DHCP için Journalctl girişleri:

#journalctl | grep -Ei 'dhcp'`
Jul 12 10:10:56 skprov2 systemd-networkd[1160]: eno1: DHCP lease lost
Jul 12 10:10:57 skprov2 systemd-networkd[1160]: eno4: DHCP lease lost
Jul 12 10:11:00 skprov2 systemd-networkd[1160]: eno1: DHCPv4 address 10.10.11.157/23 via 10.10.10.254
Jul 12 10:11:02 skprov2 systemd-networkd[1160]: eno4: DHCPv4 address 10.10.11.162/23 via 10.10.10.254

Oturum açtıktan sonra dhclient'i elle arama (ayrıntılı):

# dhclient -v eno4
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eno4/00:26:b9:82:44:27
Sending on   LPF/eno4/00:26:b9:82:44:27
Sending on   Socket/fallback
DHCPREQUEST of 10.10.10.40 on eno4 to 255.255.255.255 port 67 (xid=0x4cb8a62d)
DHCPACK of 10.10.10.40 from 10.10.10.10
bound to 10.10.10.40 -- renewal in 294538 seconds.

10.10.10.10 doğru DHCP sunucusudur ve 10.10.10.40 üzerinde yapılandırılmış olan IP'dir. Windows DHCP'de, yanlış kiralama (.162) ubuntu kutusunda mevcut herhangi bir MAC adresini içermeyen uzun bir "Benzersiz Kimlik" gösterir: 032e827c00020000ab11d0fc617dced58a43

Bundan kaçınmanın doğru yolu nedir? Uzun UID için kiraları reddetmek? Bu UID ilk olarak nereden geliyor? NIC, Dell PowerEdge R710 sunucusunda yerleşiktir.

Yanıtlar:


4

Sorunun nedeni, Ubuntu 18.04'teki yerleşik ağ yapılandırmasının artık NIC Mac adresini DHCP istekleri için varsayılan kimlik olarak kullanmamasıdır.

Geleneksel (ve "mantıklı") davranışı, dhcp-identifier: mac /etc/netplan/xxx.yaml (cloud-init) dosyasındaki konfigürasyona şu şekilde:

network:
    renderer: networkd
    version: 2
    ethernets:
        nicdevicename:
            dhcp4: true
            dhcp-identifier: mac

"Nicdevicename", ağ cihazınızın adıdır.

kullanım

sudo netplan apply

yeni yapılandırmayı denemek için. Hata alırsanız, lütfen .yaml dosyalarında tam girintinin çok önemli olduğunu unutmayın.


Güzel. BTW resmi netplan belgelerinde / referans belgesinde belgelenmiştir: netplan.io/reference
NoMad

3

Kira reddetmek işe yaramaz. Ağın neden reddedildiğini bilmesi mümkün değil, o yüzden alışkanlık bunu yaparsanız sadece sihirli bir şekilde farklı bir kimlik türüne geçin. Bunu elle yapmak zorundasın.

Sistem sürümünüz yeterince yeni ise ve cloud-init tarafından yazılan yapılandırma dosyaları üzerinde doğrudan denetime sahipseniz, systemd-networkd cihazına MAC adresi tabanlı bir istemci kimliği göndererek *.network dosya:

[DHCP]
ClientIdentifier=mac

Fakat eğer systemd-networkd’ün her zaman Kullanılabilir, müşteri kimliğine doğru kira atayabilirsiniz 032e827c00020000ab11d0fc617dced58a43çünkü systemd-networkd her zaman bu makine için gönderir. (Kimliğe dayalı kimlik oluşturur /etc/machine-id.)


DHclient dahil olmak üzere Mos DHCP istemcileri, '01' (MAC tabanlı) türünde bir müşteri kimliği alanı sağlar. Diğer bir yaygın tür '00' (etki alanı adı) 'dır. Bununla birlikte, varsayılan olarak, systemd-networkd / etc / machine-id içeriğinden oluşturulan bir "opak" istemci kimliği sağlar.

DHCP protokolüne göre, kiralamalar müşteri kimliği tarafından seçilir ilk (müşteri MAC tabanlı olabilir veya olmayabilir "müşteri kimliği" seçeneğini sağladığı sürece), ardından MAC adresi Yalnızca müşteri kimlik göndermedi.

Böylece bir rezervasyon yapılandırırken, tüm iyi DHCP sunucuları, müşteri kimliğini girmenize izin verecektir veya MAC adresi. Yalnızca MAC adresini girerseniz, o zaman '01 '(MAC tabanlı) istemci kimliğinin otomatik olarak ima edildiğini varsayalım. Sizin için uygun olan ancak DHCP spesifikasyonunu teknik olarak ihlal eden "Müşteri Kimliğini Yoksay" adlı bir onay kutusu olabilir.

(Örneğin, farklı MAC'lere sahip iki Wi-Fi adaptörüm var, ancak hangi adaptörün bağlı olduğu farketmeksizin işletim sistemini aynı müşteri kimliğini göndermesi için yapılandırdım. Bu şekilde her ikisi ile de aynı adresi alıyorum.)


2
Sonuçta ağd oldu ... Ağd'ın varsayılan olarak MAC adresini kullanmadığını bilmiyordum ve bunun belki de sistem yönetimi (ya da başka bir şey için) önyüklemeden önce bazı Dell Firmware tarafından üretilen bir kimlik olduğunu düşündüm. Şu anda bu GUID için bir rezervasyonu test etme sürecindeyim.
NoMad

1
Bu notta, Dell iDRAC kesinlikle DHCP yapıyor olabilir, ancak gerçek sunucudan ayrı bir MAC adresi var. (Ayrıca, tüm sunucu kapatılsa bile, gücü bağladığınız anda açılır.)
grawity

iDRAC şu anda devre dışı (ve idi). UBuntu kutusu şimdi bu GUID için rezervasyon ile doğru IP alır, ancak systemctl restart systemd-networkd Arayüzlerin hiçbirine ping ile erişilemiyor. ağ rotaları bozuyor gibi görünüyor ...
NoMad

Ağın arkasındaki insanlar neden MAC adresini varsayılan kimlik olarak kullanmaya karar veriyorlar? / Etc / machine-id kullanmak, birden fazla NIC'ye sahip makineler ve klonlanmış örnekler için kötü bir fikir gibi görünüyor? Birisi bu kararın arkasındaki mantığı gösterebilir mi?
anneb

@ anneb: Mantığı bilmiyorum. Ancak klonlanmış örnekler için, aynı / etc / ssh / ssh_keys klondan sonra sıfırlanacak gibi, makine kimliği de öyle. (Afaik, systemd sanal makine kimliğini KVM / HyperV / etc'den bile alabilir.) Networkd'ün DHCPv4 müşteri kimliği DHCPv6 DUID'lere benzer şekilde üretildi ve arabirim kimliğinin çok arabirimli sistemler için buna sahip olması.
grawity
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.