Ablauf¶

Das Verfahren soll nur gestartet werde, wenn der Rechner zwar eine betriebsfähige Netzwerkschnittstelle, aber noch keine IPv4-Adresse besitzt:

• Der Rechner wählt eine beliebige IP-Adresse aus einem Pool von 65024 Adressen. Der Pool besteht aus den Adressen im Bereich 169.254/16 ohne die Bereiche 169.254.0/24 und 169.254.255/24. Der Rechner benutzt zur Wahl einen Pseudozufallsgenerator mit einem aus individuellen Hardware-Eigenschaften (z.B. der permanenten MAC-Adresse des Ethernet-Adapters) abgeleiteten Startwert. Es ist durchaus erwünscht, wenn der Rechner jedes Mal dieselbe IP-Adresse nutzt. Eine einmal genutzte IP-Adresse darf der Rechner auch permanent speichern.

• Die gewürfelte Adresse wird geprüft, ob sie bereits einem anderen Rechner gehört. Hierfür schickt der Rechner per ARP Anfragen ins Netzwerk.

• Wenn jemand per ARP antwortet, dann verwirft der Rechner die gewählte IP-Adresse und startet das Verfahren erneut.

• Wenn niemand antwortet, dann reklamiert der Rechner mit Ankündigungen per ARP die gewählte IP-Adresse für sich und benutzt sie auch für seine Zwecke.

Eine APIPA-IP-Adresse (oder auch "Link Local IPv4 Address") ist interoperabel mit anderen IP-Adressen, darf aber nur sehr eingeschränkt geroutet werden, genauer:

• Nur Pakete von APIPA nach APIPA dürfen geroutet werden.

• Damit gilt: Mit einer APIPA-Adresse kommt man nicht ins Internet.

Installation¶

Zur Benutzung von APIPA bei Ubuntu kann man (mindestens) 3 verschiedene Wege wählen: Entweder über das Paket avahi-autoipd 🇬🇧 oder über die in zur Konfiguration von Netzwerken gängigen Programmen NetworkManager und systemd-networkd bereits eingebauten Funktionalitäten.

1. Paket installieren^[1][2][3][4]:

   • avahi-autoipd ('Avahi IPv4LL Daemon zur Netzwerkadresskonfiguration', aus universe)

   Befehl zum Installieren der Pakete:

   sudo apt-get install avahi-autoipd 

2. Für den Weg über NetworkManager und

3. den Weg über systemd ist nichts weiteres zu installieren.

Konfiguration¶

1. Für die Nutzung des Pakets avahi-autoipd ist nach der Installation nichts zu konfigurieren. Man muss allerdings den Daemon starten; dies kann testweise mit diesem Befehl erfolgen:
   

   sudo avahi-autoipd --check LAN 

   Der hier beispielhaft verwendete Schnittstellenname LAN ist anzupassen. Wer dies dauerhaft verwenden möchte, kann eine Unit für den automatischen Start per systemd beim Systemstart erstellen, die Manpage von avahi-autoip enthält die dafür benötigten Informationen.

2. Ohne Installation des Pakets avahi-autoipd kann man sich, z.B. mittels nm-connection-editor^[2][3] ein Verbindungsprofil für den NetworkManager anlegen.
   

   nmcli connection add type ethernet con-name Link
   nmcli connection modify Link ipv6.method disabled
   nmcli connection modify Link ipv4.method link-local
   nmcli connection modify Link connection.autoconnect-priority -1 

   Wichtig ist hierbei für autoconnect-priority einen kleineren Wert als für alle anderen Verbindungsprofile des Typs ethernet zu wählen.

3. Alternativ kann man als Root^[4] auch eine Konfigurationsdatei für systemd-networkd mit folgendem Inhalt anlegen:
   

   # /etc/systemd/network/99-APIPA.network
   [Match]
   Type =      ether
   
   [Network]
   Description =   APIPA
   # LinkLocalAddressing = yes | no | ipv4 | ipv6
   LinkLocalAddressing =   ipv4
   IPv4LLStartAddress =    169.254.128.0
   #IPv4LLRoute =           yes
   # MulticastDNS = yes | resolve | no
   #MulticastDNS =          yes

   Auch hier ist wichtig, über den mit 99 beginnenden Dateinamen die Anwendung erst dann zuzulassen, wenn alle anderen Konfigurationen nicht anwendbar sind.

Test¶

Zum Test der Namensauflösung per mDNS benötigt man neben dem eigenen Rechner (hier beispielhaft: Maria) einen weiteren Rechner (hier beispielhaft: Lieselotte) im Netzwerk, und dieser weitere Rechner muss seinen Namen und seine IP-Adresse per nDNS veröffentlichen.

• Testbefehle^[2][3], wenn man auf dem eigenen Rechner Avahi verwendet:

  • avahi-resolve-host-name lieselotte.local 

    Beispielausgabe:
    

    Lieselotte.local	169.254.6.219 

  • resolvectl -p mdns query lieselotte.local 

    Beispielausgabe:
    

    lieselotte.local: resolve call failed: No appropriate name servers or networks for name found 

• Testbefehle^[2][3], wenn man auf dem eigenen Rechner systemd-resolved mit mDNS verwendet:

  • avahi-resolve-host-name lieselotte.local 

    Beispielausgabe:
    

    Klientobjekterstellung ist fehlgeschlagen: Dienst läuft nicht 

  • resolvectl -p mdns query lieselotte.local 

    Beispielausgabe:
    

    lieselotte.local: 169.254.6.219                -- link: LAN
                      (Lieselotte.local)
    
    -- Information acquired via protocol mDNS/IPv4 in 9.9ms.
    -- Data is authenticated: no; Data was acquired via local or encrypted transport: no
    -- Data from: network

• In beiden Fällen sollte …

  • die direkte Abfrage beim DNS-Namensserver per Unicast-DNS eine Fehlermeldung ergeben:

    host lieselotte.local 

    Beispielausgabe:

    Host lieselotte.local not found: 2(SERVFAIL) 

  • und die direkte Abfrage über Glib funktionieren:

    getent hosts lieselotte.local 

    Beispielausgabe:

    169.254.6.219   lieselotte.local 

  • und schließlich sollte auch die mDNS-Namensauflösung aus Programmen (über Glib) funktionieren, beispielsweise:

    ping -4 -c1 lieselotte.local 

Namensauflösung über Glib¶

Für die Namensauflösung aus Programmen werden üblicherweise Funktionen aus der Bibliothek Glib benutzt. Die dafür verwendeten Methoden werden mit der Datei /etc/nsswitch konfiguriert.

Bei einem Ubuntu-Desktop-System findet man üblicherweise^[2][3]:

grep hosts /etc/nsswitch.conf 

Beispielausgabe:

hosts:          files mdns4_minimal [NOTFOUND=return] dns 

Hier sind drei Methoden konfiguriert, die nacheinander aktiviert werden, bis ein Ergebnis erzielt wurde:

1. files steht für Nachschlagen in der Datei: /etc/hosts

2. mdns4_minimal [NOTFOUND=return] befragt avahi-daemon, der versucht, per mDNS eine Antwort zu finden.

3. dns steht für normales Unicast-DNS, d.h. Befragung der in der Datei /etc/resolv.conf konfigurierten Namensserver (nameserver). Bei Ubuntu ist das immer 127.0.0.53, worunter man den Dienst systemd-resolved erreicht, der die Ergebnisse von Anfragen zwischenspeichert und die Forwarder befragt, welche der Befehl^[2][3]

   resolvectl 

   anzeigt.

Wenn man Avahi deaktiviert und ggf. mDNS über systemd-resolved aktiviert, muss keine Anpassung in der Datei /etc/nsswitch erfolgen, denn, wenn der Avahi-DAEMON nicht läuft, macht mdns4_minimal gar nichts außer ein wenig Zeit zu verschwenden.

Alternativ kann man den 2. Eintrag ersatzlos entfernen, wenn man Avahi nicht benutzt.

Alternativ kann man mit Avahi einen anderen Modul verwenden. Näheres dazu liest man in der Dokumentation:

zless /usr/share/doc/libnss-mdns/README.md.gz 

Alternativ kann man ein vom Projekt Systemd geliefertes NSS-Modul einsetzen. Davon wird abgeraten, weil in Experimenten damit kein befriedigendes Zeitverhalten erreicht wurde.

Avahi: Aktivierung und Deaktivierung¶

Das wird im Artikel Avahi^[5] beschrieben.

systemd-resolved: mDNS aktivieren¶

Standardmäßig ist nDNS mit systemd-resolved deaktiviert. Man aktiviert es global mit einer Konfigurationsdatei:

# /etc/systemd/resolved.conf.d/mDNS.conf
[Resolve]
MulticastDNS =          yes

Nach Neustart von systemd-resolved^[6] oder des Systems aktiviert dies mDNS für die Veröffentlichung und die Auflösung von Rechnernamen und IP-Adressen auf globaler Ebene, systemd-resolved wird dies auf jede geeignete Schnittstelle übertragen, sofern man das nicht explizit mit systemd-networkd oder NetworkManager anders steuert.

Alternativ zum Wert yes kann man auch resolve angeben, was dann nur die Namensauflösung aktiviert.

systemd-resolved: mDNS deaktivieren¶

Man entfernt alle Zeilen MulticastDNS=yes und MulticastDNS=resolve aus der Konfiguration, fügt optional MulticastDNS=no hinzu und startet neu.

Unicast-DNS-Domäne local¶

Manche Reuter für den privaten Gebrauch, darunter die Fritzboxen, verteilen per DHCP die Unicast-DNS-Domäne local. Leider ist keine Methode bekannt, dies beim DHCP-Server der Fritzbox abzustellen. Ersatzweise kann man auf jedem Client die Annahme der DHCP-Option verweigern und muss dann ggf. DNS-Server und DNS-Domäne selbst einstellen.

Bei Verwendung von NetworkManager sind dafür in jedem Verbindungsprofil, getrennt für IPv4 und IPv6, Einstellungen ignore-auto-dns= zuständig, die nicht per GUI zugänglich sind. Eine Einstellung gelingt aber per nmcli:

nmcli connection modify PROFIL ipv6.ignore-auto-dns yes
nmcli connection modify PROFIL ipv4.ignore-auto-dns yes 

Möglicherweise (z.B. bei FB7490) reicht bereits die Einstellung für IPv6 aus.

Multicast¶

Die Veröffentlichung von Rechnername und Adresse, die Ankündigung von Diensten und die Auflösung von Rechnername zu IP-Adresse erfordern Multicast auf beiden beteiligten Rechnern:

• Normalerweise sollte Multicast bei einem aktuellen Netzwerk- bzw. WLAN-Adapter problemlos funktionieren.

• Bei manchen sehr alten Netzwerkkarten muss Multicast explizit eingeschaftet werden. Der Befehl

  ip -br link | grep -v MULTICAST 

  zeigt die Schnittstellen mit fehlendem Multicast an, beispielsweise:

  lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
  radio            DOWN           48:51:b7:40:66:bd <BROADCAST> 

  Die Schnittstelle lo ist hier nicht relevant, aber wenn man radio für Avahi benutzen möchte, sollte man versuchen, Multicast einzuschalten:

  sudo ip link set multicast on radio 

• Für Multicast müssen die jeweiligen Adressen auf beiden Rechnern verfügbar sein. Die existierenden Multicast-Adressen zeigt der Befehl

  ip maddress 

  sortiert nach Schnittstelle. Für jede von Avahi benutzen Schnittstelle benötigt man mindestens:

  • link 01:00:5e:00:00:fb für Ethernet bzw. Wifi (Layer 2)

  • inet 224.0.0.251 für das Protokoll IPv4 bzw. ff02::fb für IPv6

• Wenn sich Multicast nicht einschalten lässt oder die vorstehend genannten Multicast-Adressen fehlen, hilft vielleicht, für die IP-Multicast-Adresen einen Unicast-Leitweg einzurichten:

  sudo ip route add 224/4 dev radio 

  Der hier beispielhaft verwendete Schnittstellenname radio ist anzupassen. NetworkManager richtet diese Route automatisch ein, wenn man als Methode link-local angibt, aber die Route scheint völlig nutzlos zu sein. Vielleicht ist sie aber doch in bestimmten Situationen erforderlich.

Netzwerkport¶

Damit der nDNS-DAEMON andere Rechner findet und der eigene Rechner gefunden werden kann, öffnet der DAEMON den Netzwerk-Port 5353/udp. Dies kann man so überprüfen:

ss -ulpen 'sport = 5353'  

Beispielausgabe:

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process                                                                  
UNCONN 0      0            0.0.0.0:5353       0.0.0.0:*     uid:108 ino:57433 sk:1001 cgroup:/system.slice/avahi-daemon.service <-> 
UNCONN 0      0            0.0.0.0:5353       0.0.0.0:*     uid:991 ino:8056 sk:1 cgroup:/system.slice/systemd-resolved.service <-> 
UNCONN 0      0               [::]:5353          [::]:*     uid:991 ino:8063 sk:2 cgroup:/system.slice/systemd-resolved.service v6only:1 <->

Im Beispiel sieht man 2 aktive mDNS-DAEMONen avahi-daemon und systemd-resolved auf Port 5353 lauschend. Das ist so nur für Testzwecke zulässig; da sich die beiden gegenseitig stören können, sollte es im produktiven Betrieb nur einen geben.

Fehlerhafte Namensauflösung¶

Zerokonf beruht letztlich auf der Zuweisung eines weiteren Namens und der Verknüpfung dieses Namens mit einer IP-Adresse des Rechners. Dies ist normalerweise unkritisch, denn ein Rechner darf theoretisch beliebig viele Namen und auch beliebig viele IP-Adressen besitzen, wenn man dabei folgende Regeln beachtet:

• Unterschiedliche Rechner sollten nicht denselben Namen verwenden.

• Unterschiedliche Rechner dürfen nicht dieselbe IP-Adresse verwenden.

In vorstehenden Sätzen kann das Wort „Rechner“ sowohl ein reales Hardware-Gerät oder eine in Software realisierte virtuelle Maschine bedeuten.

Die Verwendung von NAT (Network Address Translation) bedeutet immer eine Missachtung vorstehender Regeln, und wenn man dann noch auf beiden Seiten des Routers einen mDNS-DAEMON verwendet, kommt es zu Fehlfunktionen. Beim Einsatz virtueller Maschinen läuft man z.B. schnell in diese Falle, wenn man Host und Gast per NAT koppelt.

Zur Vermeidung von Fehlfunktionen im Netzwerk sollte man generell beachten.

• NAT nach Möglichkeit gar nicht einsetzen. Bei virtuellen Maschinen kann man z.B. Brücken bzw. "bridged networking" verwenden.

• Oder: Wenn NAT unvermeidlich, dann jedenfalls nicht MASQUERADE, sondern SNAT verwenden, d.h. die Zieladresse, auf die NAT übersetzt, darf nicht die Adresse des Routers und auch nicht die Adresse des Host sein.

• Oder: nDNS nicht auf beiden Seiten eines NAT-Routers verwenden.

• Oder: Nicht auf beiden Seiten des NAT-Routers dieselbe mDNS-Domäne verwenden. Man könnte z.B. auf der Seite des Host local und auf Seite des Gastes die Subdomäne VM.local verwenden.

Logdateien werden zugemüllt¶

Die im vorstehenden Abschnitt genannte Falle führt neben den Fehlfunktionen bei der Namensauflösung auch zum Zumüllen der Log-Dateien des Gastes und des Hosts und aller (!) weiteren Rechner im Netzwerk mit Einträgen dieser Art:

pp avahi-daemon[1963]: Invalid legacy unicast query packet.
...
pp avahi-daemon[1963]: Received response from host 192.168.xxx.yyy with invalid source port 39506 on interface 'eth0.0'
...