< Startseite >

 

Unterschiedliche Variationen zum Einrichten und Aktivieren einer Netzwerkverbindung nach unterschiedlichen Anfordungen.

Dieses Tutorial richtet sich an erfahrene Linux-Anwender und an engagierte und neugierige Beginner, die die Zusammenhänge in ihrem Netzwerk unter Linux besser verstehen möchten! Für mich ist dieser Artikel keine „wissenschaftlich fundierte Arbeit“, ich befasse mich hierbei eher mit der Intention zu einem Essay mit diesem Thema und gestatte mir dabei einige Freiheiten. Ein wichtiger Hinweis gleich zu Beginn: Die hier besprochenen Lösungen sind nicht selektiv oder alleine für sich anwendbar. Das bedeutet, eine einzelne Lösung ist ohne Berücksichtigung des Kontextes in den hier besprochenen Rahmenbedingungen nicht konfliktfrei einsetzbar.

Inhaltsübersicht über die Kapitel dieses Artikels:

> Einleitung

> Netzwerk-Überblick

> Feststellen der vorhandenen Netzwerkinterfaces

> Feststellen der für die aktuelle Netzwerkverbindung verwendeten Programme

> Deaktivieren des Default-Setups für Netzwerkverbindungen

Einrichten eines über ...

> ... ETH verbundenen Anwender-PCs via DHCP

> ... ETH verbundenen dedizierten Server-Systems mit Static-IP

> ... WLAN verbundenen stationär genutzten Laptops

> ... ETH verbundenen Anwender-PCs mit lokalen VMs         

Virtuelle Maschinen (libvirt/KVM) für den Ad-Hoc-Gebrauch isolierter Anwendungen, z.B. Online- Banking. Die VMs sind reguläre LAN-Clients, sind via Bridge mit dem LAN verbunden und sowohl der Host-PC als auch die VMs beziehen via DHCP eine IP-Adresse vom DSL-Router.

> ... WLAN verbundenen Anwender-PCs mit lokalen Vms

Wie zuvor, nur via WLAN.

> ... WLAN/ETH verbundenen Anwender-PCs mit lokalen Vms

Virtuelle Maschinen (libvirt/KVM) für den Ad-Hoc-Gebrauch isolierter Anwendungen, z.B. Online- Banking. Die VMs laufen in einem vom LAN isolierten Subnet, sind via Bridge verbunden , erfahren aber ein NAT auf dem Host-PC.

> ... ETH verbundenen Servers mit lokalen VMs als dedizierte Systeme

Virtuelle Maschinen (libvirt/KVM) für isolierte Anwendungen, z.B. FTP-Server, Pihole, VPN-Server, oder ähnliches. Die VMs sind reguläre LAN-Clients, sie sind via Bridge mit dem LAN verbunden und sowohl der Host-PC als auch die VMs sind mit im LAN gültigen IP-Adressen eingerichtet. Sowohl Server als auch VMs sind Headless-Systeme, also ohne unmittelbare Interaktion durch User. Der Zugriff auf Server und VMs erfolgt remote. Die VMs werden headless via SSH und VNC eingerichtet.

 

Einleitung

Immer wieder liest man in den verschiedenen Linux-Foren besondere Fragen, die sich mit den scheinbar unlösbaren Problemen bei der Einrichtung einer Netzwerkverbindung befassen. In Wirklichkeit sind die Probleme meistens eher trivialer Natur und wenn man weiß wie, sind sie oft in Sekunden zu beheben. Nur ist gerade bei diesem Sachverhalt ein bestimmter Umstand die Ursache dafür, dass die Probleme tatsächlich scheinbar unlösbar sind, wenn man nicht gerade selber ein Linux-Profi ist.

Selbst bei so harmlosen Problemen, wie

» fehlende Firmware für eine WLAN-Karte

» Netzwerkinterface heißt auf einmal nicht mehr wie erwartet eth0 oder wlan0, sondern hat neuerdings einen kryptischen Namen

» bei multiplen Interfaces gleichen Typs (z.B. wlan0 und wlan1), die den Namen zufällig nach einem Reboot wechseln

» beim Einrichten von statischen IP-Adressen, wofür es 101 unterschiedliche Methoden gibt, die je nach Umfeld falsch oder richtig oder einfach nur wirkungslos sein können

» beim gleichzeitigen Aktivieren mehrerer Interfaces wie eth+wlan, eth+eth, wlan+wlan, virtuelle Inferfaces zusammen mit physischen NICs in verschiedenen Kombinationen, etc.

» bei der grundsätzlich notwendigen Antwort auf die Frage, wie das Netzwerk überhaupt gestartet wird

ist man als Linux-Anfänger mangels Erfahrung und Sachkenntnis schnell hoffnungslos überfordert, dieses Problem zu lösen. Die Ursachen für die scheinbare Unlösbarkeit sind vielfältig.

Zum einen ist es die digitale Evolution, das bedeutet, die Linux-Betriebssysteme entwickeln sich permanent über die Jahre immer weiter, sie werden kontinuierlich an moderne Anforderungen angepasst, das was gestern noch galt, was richtig und gut war, ist heute hoffnungslos veraltet. So liest man heute immer noch wieder Ratschläge mit relativ aktuellem Datum, die sich mit der Verwendung der Kommandos aus dem Paket ‚net-tools‘ befassen. Dabei ist dieses Paket bereits 2009 durch die damaligen Maintainer/Entwickler als deprecated angekündigt worden, mittlerweile ist es sogar auf Debian-Seiten so deklariert. Die vorhandenen Funktionen dieses alten Pakets unterstützen aktuelle technische Hardware-Anforderungen nur noch, wenn die Kommandos auf die Programme des derzeit aktuellen Pakets ‚iproute2‘ gelinkt werden konnten. Ohne diese Symlinks fehlt also teilweise die Unterstützung der Möglichkeiten moderner Hardware, weil es diese Möglichkeiten vor Jahren noch nicht gab… und dennoch werden die alten Programme immer noch empfohlen. Und wer das nicht weiß, fällt darauf rein und verschafft sich nur wegen der Verwendung alter Tutorials möglicherweise völlig unnötig neue Probleme. Und diesen Umstand begleitend korreliert die Tatsache, dass das Internet nichts vergisst… leider also auch nicht jene Tutorials und Lösungsbeschreibungen, die vor einem Jahrzehnt mal aktuell für die damalige Einrichtung eines Linux-Systems waren, es heute aber nicht mehr sind.
 
Das hat wiederum zur Folge, dass man heute beim Suchen nach diesem Thema sehr viele Tutorials im Internet findet, die alle zusammen eine unüberschaubare Vielzahl von vermeintlichen Problemlösungen für das eigene Problem anbieten. Am Ende fällt es einem Laien regelmäßig und fast vorhersagbar ziemlich schwer einzuschätzen, ob eine oder mehrere der gefundenen Lösungen tatsächlich passend zum eigenen Problem sind, ob sie vielleicht hoffnungslos veraltet oder immer noch aktuell sind. Und es ist auch nicht ungewöhnlich, wenn Lösungen deshalb, weil sie eben nicht so gut passen, teilweise oder unvollständig oder sogar einfach nur falsch angewandt wurden, so das sie das ursprüngliche Problem nicht nur unverändert ungelöst lassen, sondern das es nun sogar noch verschlimmert wurde. Und es werden nicht selten auch Lösungen gefunden, die insgesamt betrachtet heute allenfalls als suboptimal gelten können… wenn nicht sogar die Gefahr besteht, dass sie mitunter auch schädlich für die Integrität resp. die Sicherheit des Systems sind. Das kann passieren, wenn eine Dokumentation (um mal 2 Beispiele zu nennen) für die Netzwerkkommunikation veraltete Verschlüsselungstechniken verwendet oder darauf verzichtet, das die Sicherheit verbessernde ‚Application Layer Gateway‘ bei FTP zur Reduzierung offener Ports in der Firewall zu verwenden.
 
Als weitere meiner Meinung nach ernsthafte Ursache für die scheinbare Unlösbarkeit erweist sich die Tatsache, dass es bei den wichtigen bekannten Linux-Distributionen keine eindeutige Regel, keine allgemeingültige gemeinsame Vorgehensweise für den Start einer Netzwerkverbindung gibt. Die unterschiedlich ausgestatteten grafischen Oberflächen mit jeweils eigener Zielsetzung bei der Ausstattung bieten eingebettet in das jeweils eigene Desktop-Konzept zwar meistens eine grundsätzliche Unterstützung durch Dialog-Anwendungen an, die aber wiederum von Desktop zu Desktop unterschiedlich in der Handhabung der Dialoge oder hinsichtlich der im Hintergrund gestarteten Services sein kann. Dabei ist diese jeweilige Unterstützung meistens jedoch nur auf die mehr oder weniger übliche Standard-Anforderung beschränkt: ein Home-PC wird via Patchkabel verbunden oder ein mobiles Gerät wird als WLAN-Client verbunden. Darüber hinausgehende spezielle Anforderungen sind dann oft nicht mehr über die GUI-Dialoge zu lösen, sondern können erst nach langem Suchen im Internet über manuelle Einträge in einem Terminal-Fenster in der Konfigurationsdatei eines Programms gelöst werdenwobei natürlich zuerst festgestellt werden musss, welche von der Distribution vorgesehene Programme überhaupt in dieser Installation welche Aufgabe wahrnehmen. Das bedeutet, die für die Netzwerkverbindungen installierten Programme der eigenen grafischen Benutzeroberfläche, die ja letztendlich notwendigerweise konfiguriert werden müssen, können bei einem anderen Desktop völlig andere sein.
 

Tja, solche Randbedingungen verkomplizieren leider durchaus so manches Bemühen bei der Problembeseitigung. Ich möchte diesen Absatz trotzdem keinesfalls als Kritik verstanden wissen, denn das ist es wirklich nicht. Gerade diese unglaubliche Variabilität, gerade diese vielen Möglichkeiten machen aus Linux ein faszinierendes Betriebssystem ohne Grenzen und unnötige Beschränkungen. Wer allerdings ein uniformes Linux will und als Konsequenz diese Variabilität als Hindernis oder sogar als Schlecht empfindet, der hat Linux nicht verstanden – ein solcher User ist definitiv mit Windows besser bedient.

Eine weitere wichtige Einflussgröße auf die Schwierigkeiten beim Erkennen, an welcher Stelle genau ein Problem gelöst werden muss, liegt teilweise auch in der primären Intention einer Distribution durch die Ausrichtung auf eine besondere Zielgruppe. So betrachte ich Linux Mint eher als klassisches grafisch unterstütztes Desktop-System für den Endanwender, ebenso wie z.B. Ubuntu oder auch die Varianten der Debian-Desktops. Wobei insbesondere Linux Mint versucht, die technischen Anforderungen an einen Laien, um dieses Linux betreiben, sehr gering zu halten. Im direkten Vergleich dazu sind Debian und noch mehr ArchLinux deutlich anspruchsvoller ausgerichtet und erfordern eine höhere Einsatzbereitschaft des Users, sich mit den technischen Grundlagen des Systems zu befassen. ArchLinux wendet sich eindeutig an den engagierten und versierten Linuxer, der kein fertiges Betriebssystem von der Stange verwenden möchte und sich mit viel Sachkenntnis ein Betriebssystem von Grund auf nach eigenen Vorstellungen einrichtet. Von den klassischen für den Mainstream-Anwender konzipierten Desktop-Distributionen unterscheiden sich z.B. Debian, Raspbian oder Fedora allerdings insofern, dass sie auch ohne jegliche grafische Unterstützung installiert werden können, womit sie natürlich auch echte Server-Qualitäten anbieten können. Gleichzeitig werden dabei aber auch wieder eigene Wege bei der Netzwerkverbindung beschritten. Ja, klar, selbstverständlich kann man auch mit Linux Mint einen multifunktionalen LAN-Server hinzaubern…. aber ‘ne wirklich gute Idee ist das ganz sicher nicht…. Linux Mint hat eben andere Stärken und bedient eine andere Zielgruppe. Gutgemeinte Ratschläge, Linux Mint als Server-System zu verwenden, erachte ich also mindestens als fahrlässig.
 
Als Fazit fragt man sich nun, ein wenig nachdenklich geworden, ob nicht bei so enormer Variabilität gleichzeitig auch ein großes Potential an Fehleinschätzungen besteht, wenn Laien-Anwender anderen Laien-Anwendern helfen wollen ...?…  ja, genau das passiert meiner Meinung nach ohne jeden Zweifel ständig. Es hat also durchaus einen guten Grund, dass bei ganz vielen Fragestellungen in den Internetforen häufig die erste Antwort eines erfahrenen Linux‘ers ist „Welchen Desktop hast Du installiert?“ Und wie gesagt, nicht nur Debian überlässt zusätzlich auch im vollen Umfang dem Anwender die freie Entscheidung, wie und womit die Aufgaben zur Erstellung einer Netzwerkverbindung letztlich überhaupt erledigt werden sollen. Das heißt, man kann die vorgeschlagenen Wege auch vollständig außer acht lassen und komplett eigene Lösungen einrichten. Wobei das natürlich unweigerlich zur Folge hat, dass man bei Problemen dann unbedingt auf einen erfahrenen Linux-Anwender angewiesen ist.
 

Hier nun mal ein kurzer Überblick über die möglichen und alternativ nutzbaren Wege zur Einrichtung von Netzwerkverbindungen, aus dem man durchaus auch eine Ursache für so manche Irritation und der scheinbaren Unlösbarkeit bei diesem Thema erahnen kann.

Das Netzwerk kann gestartet werden, mithilfe

- systemd-networkd

- des häufig installierten Networkmanagers

- eines von verschiedenen grafischen Networkmanagement-Tools, wie connman, wicd, etc.

- des traditionellem Scripts /etc/init.d/networking, was über den Umweg der historischen runlevels gestartet wird

- der systemd-Unit ifup@service und Einträgen in /etc/networking/interfacess

- manueller CLI-Kommandos aus dem Paket iproute2

- manueller CLI-Kommandos aus dem Paket net-tools, was (trotz Status deprecated) immer noch installiert werden kann

- eigener Scripte

- wpa_supplicant bei WLAN-Verbindungen

Darüber hinaus sind dann oft auch noch unterschiedliche Zusatztools für den Netzwerkbetrieb installiert, völlig unberücksichtigt davon, ob die bei dieser Installation überhaupt sinnvoll sind oder eher nur als verkomplizierende Bloatware betrachtet werden müssen, wie z.B.

- dnsmasq, als schmaler DNS und DHCP-Server, oder

- das mächtige Tool ‚dhcpcd5‘ oder

- die einzeln installierbaren schmaleren Pakete ‚isc-dhcp-client‘ oder ‚isc-dhcp-server‘

Bei der Betrachtung von Abhängigkeiten bestimmter Prozesse zum Netzwerk gibt es ebenfalls völlig unterschiedliche Interpretationen, wie der Umstand „Netzwerk OK definiert werden kann, zum Beispiel:

- Netzwerk-Interfaces sind vorhanden, wurden vom Kernel erkannt, Firmware ist OK und sind via systemd-UDEV mit Symlinks versehen.

- Die Interfaces wurde gestartet und deren Status ist von DOWN auf UP gewechselt, z.B. von ifup@service.

- Ein Programm zur Herstellung von Netzwerkverbindungen wurde gestartet, z.B. der Networkmanager.

- Ein solches Programm zur Herstellung von Netzwerkverbindungen hat für ein NIC erfolgreich eine Verbindung hergestellt.

- Was ist mit einem zweiten Netzwerk, wenn z.B. ein WLAN-Interface einen Accesspoint mit Bridge zum ersten NIC herstellen soll?

- Eine IPv4-Adresse wurde für ein NIC vom DHCP-Client angefordert, z.b. von isc-dhcp-client.

- Eine IPv4-Adresse wurde für ein NIC via DHCP erhalten und dem Interface zugewiesen.

- Gibt es ein zweites Interface? Müssen beide NICs für die Feststellung „Netzwerk OK“ verbunden sein?

- Das IPv6-Netzwerk für das Interface ist mit einer Link-Local-Adresse konfiguriert.

- Via Prefix-Delegation wurde ein IPv6-ISP-Prefix empfangen.

- Mithilfe der ‚Stateless Address Autoconfiguration“ (SLAAC) wurde vom Kernel eine IPV6-Adresse generiert.

- Über die eingerichteten IP-Adressen ist ein Default-Gateway erreichbar, IPv4? IPv6? Beide?

- Über die eingerichteten IP-Adressen ist ein bestimmter Server im LAN erreichbar, IPv4? IPv6? Beide?

Jeder einzelne dieser Zustände kann geprüft werden. Jeder einzelne Aspekt kann entsprechend seiner Anforderung das Ergebnis haben „Netzwerk OK“. Und wie man selber den Zustand „Netzwerk OK“ definiert, ist fast willkürlich und allein abhängig von den eigenen Anforderungen oder dem Ziel eines bestimmten Jobs.

Für die meisten Anwender, die gar nicht so sehr in die Tiefe schauen wollen, ist das Netzwerk dann verfügbar und als OK deklariert, wenn z.B. bestimmte Ziele erreichbar sind, egal ob es eine Web-Site im Internet oder der eigene Server im LAN ist. Aber alles auf dem Weg dahin wird oft erst dann wichtig, wenn diese Ziele zum gewünschten Zeitpunkt auf einmal nicht mehr erreicht werden können. Ein häufig auftretendes Problem ist beispielsweise fehlende Firmware für WLAN-NICs oder beim Mount-Befehl auf einen Netzwerk-Share, wenn der Mount-Versuch bereits erfolgt, bevor das eigentliche Ziel (Server) über die fertige und erfolgreich hergestellte Netzwerk-Verbindung erreichbar ist. Das passiert gerne bei langsamen Netzwerk-Starts, bei einer schlechten WLAN-Verbindung oder bei einer vielleicht älteren und insgesamt langsameren Hardware, bei der das Netzwerk einfach seine Zeit braucht.

 

Einige bekannte und beliebte Distributionen installieren Software manchmal leider nicht nach dem Prinzip von der Effektivität des notwendigen (plus opt-in für zusätzliches, individuelles) oder mit Sparsamkeit nach der Idee, je geringer die installierte Software-Basis ist, umso geringer ist auch die Menge potentiell angreifbarer Schwachstellen. Stattdessen wird eher aus dem Vollen installiert, Festplattenspeicher ist billig, also wird von vornherein alles installiert, was der eine oder andere User vielleicht irgendwann mal anwenden können will … losgelöst von der Frage, ob das wirklich mal passiert. Zudem werden diverse Dienste auch gleich noch als Daemon aktiviert, unberücksichtigt davon, ob diese Funktionalität überhaupt genutzt wird. Das ist sicherlich für manchen Anwender sehr komfortabel, aber es genügt eben nicht meinem Anspruch an einem wartungsarmen, stabilen Computersystem mit möglichst klein gehaltener angreifbarer Oberfläche. Ich mag es lieber auf das Notwendige begrenzt, ohne jedoch dabei beim Arbeiten Komfort-Verlust hinnehmen zu müssen. Ich betone erneut ausdrücklich, dass meine Meinung hier in diesem Artikel auch an diesem Punkt keine Kritik an irgendwas sein soll. Ich wiederhole mich, die fast grenzenlose individuelle Gestaltungsfreiheit eines Linux-Betriebssystems ist einer der größten Vorteile von Linux. Es sind genau die Möglichkeiten, mit denen ich ja selber meine eher ausgefallenen Anforderungen erfüllen kann. Ich befasse mich zwar hier mit den Aspekten, die die Inbetriebnahme teilweise erschweren und natürlich damit, auf einfachen Wegen eigene Lösungen zu finden ... aber ich tue das, ohne diese Aspekte zu bewerten.
 

Alle hier oberhalb aufgeführten Programme haben jeweils irgendwo im Verzeichnis /etc ihre eigenen Konfigurationsdateien, für deren Inhalt mit Parameternamen und jeweiligem Wert bezogen auf die individuelle Interpretation/Auswirkung durch das Programm wiederum keine allgemeingültige Bedeutung besteht … jedes Programm fragt völlig individuell seine Konfigurationsparameter ab und handelt individuell danach, obwohl andere Programme mit ähnlichen Parametern auf anderen Wegen ein absolut gleiches Ergebnis erreichen könnten. Und zu guter Letzt erfordern bestimmte Netzwerk-Schnittstellen bzw. -Anforderungen auch noch spezielle Paketfilterregeln, wenn z.B. virtuelle TUN-Devices bei VPN-Verbindungen via NAT durch das physische Device eines als Server arbeitenden Systems geleitet geleitet werden müssen. Das gleiche gilt, wenn virtuellen Maschinen innerhalb eines ansonsten isolierten Netzwerks via NAT eine Verbindung zum DSL-Router ermöglicht werden soll.

Da fragt man sich doch ernsthaft „wer soll das alles noch überblicken und verstehen?“ Ganz klar ist hierbei zu erkennen, dass man vor dieser Vielfalt an potentiellen Problemquellen als Laie nur noch kapitulieren kann und sich letztlich dann doch immer um Hilfe bemühen muss. Ich habe mir deshalb hier in diesem Artikel vorgenommen, die Basics für Netzwerkverbindungen mal ein wenig zu beleuchten – mit der Hoffnung, dass der eine oder andere danach seine Probleme auf der Grundlage besseren Verstehens selber lösen kann. Dabei beschreite ich allerdings nicht unbedingt den durch die Default-Vorgaben der Distributionen eingeschlagenen üblichen Weg, sondern ich verlasse die eingetretenen Pfade. Ich verlasse sogar sehr konsequent diese Pfade und ich habe dafür eine eigene konkrete Begründung. Meine oberste Prämisse ist: Einfach, Robust und Reproduzierbar! Alles drei reduziert meinen Wartungsaufwand und die Notwendigkeit, sich bei jedem Eingriff erst mal wieder neu in die Materie einlesen zu müssen. Also ist meine persönliche Devise: tue nichts komplizierter, als es unbedingt sein muss… so einfach wie möglich, so kompliziert wie nötig… verwende keine anderen Programme als genau die, die für diese Aufgabe zwingend notwendig sind… wenn man das gleiche mit vorhandenen Board-Mitteln ohne ein zusätzliches Programm erreichen kann, entferne das überflüssige Programm zur Reduzierung der Menge installierter Programme. Das bedeutet, mein allererster Lösungsansatz ist es nicht, Probleme zu lösen, sondern zuerst potentielle Problemquellen zu beseitigen. Sind die beseitigt, befasse ich mich mit einer effizienten, stabilen und störungsarmen Lösung. Ich bitte darum, dass jetzt hier nicht als Empfehlung aufzufassen, es genau so zu tun, ich beschreibe hier lediglich, wie ich diese technischen Probleme gelöst habe und mit welchen Absichten ich das getan habe.

Gerade für die letzte Anforderung (also bezogen auf unnötige Zusatz-Prozesse) findet man sehr schnell eine einleuchtende Erklärung, warum es bei bestimmten Anforderungen durchaus sinnvoll sein kann, auf solche Prozesse zu verzichten und diese unnötigen Programme sogar komplett zu deinstallieren: Ein Samba-Server im lokalen Netzwerk muss für die Clients natürlich immer unter der gleichen IP-Adresse erreichbar sein, dafür verwendet man auf diesem System idealerweise eine statische IP-Adresse. Das kann man sehr leicht mit einem einzeiligen Befehl erreichen, der beim Start des Systems ausgeführt wird. Für diese Mini-Aufgabe hat Debian bereits alles an Board, es ist nicht notwendig, irgendwas hinzu zu installieren… auch nicht einen als Daemon laufenden dhcp-client, damit man die gewünschte statische IP in dessen Konfiguration eintragen kann, damit das Programm dann am Ende diesen einzeiligen Befehl ausführt. Die Kernfrage ist, wozu benötigt man überhaupt einen dhcp-Daemon als dhcp-Client, wenn das Netzwerkinterface doch sowieso eine statische IP-Adresse erhalten soll? Oder welchen sinnvollen Zweck erfüllt überhaupt avahi, wenn der Rechner patchkabelverbunden als stationärer dedizierter Server mit Static-IP betrieben werden soll… ?… die Antworten lauten: braucht man nicht! gar keinen! Also ist besser gefragt: welche Anforderungen an bestimmte Netzwerkeigenschaften erfordern besondere zusätzliche Programme, welche meist obligatorisch installierten Programme sind vor dem beabsichtigten Einsatzzweck hingegen vollkommen überflüssig?

 
Ich habe hier wiederholt die Beseitigung von Problemen und Störungsursachen angesprochen. Das ist auch die eigentliche Intention dieses Artikels, Ursachen verstehen, Probleme lösen, restriktiven Erfordernissen genügen, besondere Anforderungen realisieren. Wenn allerdings ein normaler Desktop-PC nach erfolgreich abgeschlossener Installation hinsichtlich der Netzwerkverbindungen sofort fehlerfrei funktioniert, gibt es eigentlich keinen Grund, daran mit unnötiger Bastelei etwas zu verändern…. ja, klar, man kann es tun, aber man muss es nicht. Das Ziel dieses Artikels ist Troubleshooting, Probleme beseitigen, ein Versuch die Grundlagen dafür zu schaffen, die eigene Netzwerk-Umgebung hinsichtlich der Hardware- und Software-Komponenten besser zu verstehen, eindeutig identifizieren und darauf basierend dann besser und zielgerichteter nach den passenden Informationen im Internet suchen zu können, wenn echte Probleme gelöst werden sollen. Als maßgebliche Unterstützung bei der Umsetzung meiner eigenen Vorstellungen von Sicherheit und Stabilität hat sich erwiesen, dass ich für all unsere Systeme basierend auf Debian ein eigenes Custom-Desktop-Environment einsetze. Diese spezielle grafische Oberfläche enthält effektiv genau das, was unser Umgang mit der IT erfordert, ohne unnützen Ballast vorzuhalten und ohne Einschränkungen im Bedienkomfort hinnehmen zu müssen.
 

Und als wichtigster Aspekt ist noch einmal festzustellen, dieser Artikel spiegelt nur meine Meinung darüber, warum ich auf welchen Wegen die Probleme löse, es ist auf keinen Fall eine Empfehlung, alles andere über Bord zu werfen und es genau so zu tun. Das Ziel dieses Artikels ist es, Zusammenhänge zu verstehen, Lösungsalternativen bewerten und einschätzen zu können und am Ende darüber die eigenen Probleme erfolgreich zu beseitigen.

 

Netzwerk-Überblick

Schauen wir uns nun das folgende Bild an, um etwas besser zu verstehen, welche möglichen Zielsetzungen für welche Geräte innerhalb eines privaten Netzwerks gelten könnten:

 

Wir sehen hier oberhalb eine Netzwerk-Darstellung, die vermutlich in den wesentlichen Bestandteilen den weitaus größten Anteil aller privaten Netzwerke relativ übereinstimmend abbildet, unabhängig davon, ob im Einzelfall vielleicht mehr/andere Geräte verwendet werden, im anderen Fall weniger. Nicht die Anzahl der Geräte definiert, was ein Netzwerk ist, sondern die Art und Weise der Verbindung und der Kommunikation untereinander – hinsichtlich der Netzwerk-Topologie wird das also  weitestgehend passen. Zum einen sind es also ein oder mehrere mobile Geräte, die sich via WLAN mit einem handelsüblichen DSL-Router verbinden, zum zweiten sind es ein bzw. mehrere stationäre PCs, die via Patchkabel mit dem Router verbunden sind. Es ist zusätzlich ein zentraler File-Server zur Speicherung von Dateien (SAMBA oder NFS) eingerichtet, weiterhin vielleicht ein VPN-Server für den Zugang ins heimische Netzwerk über das Internet, vielleicht auch noch ein VM-Server, der virtuelle Maschinen für unterschiedliche isolierte Aufgaben betreibt, oder ein Print-Server für den angeschlossenen Drucker. Das können jeder für sich durchaus physisch vorhandene, separate echte Maschinen sein, die als dedizierte Server aktiv sind, oder es sind nur virtuelle Maschinen, die innerhalb eines physischen PCs eingerichtet sind. Ebenso können die verschiedenen Server-Funktionalitäten durchaus auch alle von einer einzelnen Maschine geleistet werden – sofern sie ausreichend leistungsfähig ausgestattet ist. Die mit roter Bezeichnung versehenen Systeme sind die, die als Geräte mit Service-Funktion von den Client-Systemen gezielt und reproduzierbar angesprochen werden müssen/sollen, die wir also immer unter der gleichen IP-Adresse finden wollen.

Rein technisch betrachtet sind alle dargestellten Geräte, egal welche Aufgabe sie unseren Wünschen entsprechend zu erfüllen haben, letztlich dennoch nur gleichwertige Clients unseres zentralen DSL-Routers. Der Router ist das Gerät, welches die lokale Netzdomain repräsentiert und der als Standard-Gateway das Tor ins Internet darstellt – für den Router gibt es kein niederwertig oder höherwertig, client ist client. Aber durch die Tatsache, dass gleich trotzdem noch lange nicht gleich bedeutet und wir die Geräte mit besonderen Aufgaben priorisieren, existieren schließlich durch unsere Anforderungen und durch unsere Vorstellung über die Geräte doch noch konkrete Unterschiede – aber man muss verstehen, dass diese Unterschiede primär nur in unserem Denken über diese Hardware existieren.

Einer der wichtigsten Unterschiede ist: Bestimmte Systeme sind von uns als End-User-Geräte vorgesehen, mit Bildschirm, Tastatur und Maus und bestimmte andere Systeme arbeiten als headless eingerichtete Server-Systeme, die weder über Eingabegeräte noch über einen Bildschirm verfügen. An diesen Headless-Systemen melden sich üblicherweise (und sinnvollerweise) auch keine User zur Erledigung normaler Desktop-Aufgaben an, die Zugriffe auf diese Systeme erfolgen nicht durch physische Interaktion und im Dialog vor Ort, sondern nur auf digitalen Wegen über die Netzwerkkommunikation. Und gerade deshalb müssen diese Headless-Systeme innerhalb des lokalen Netzwerks immer auf die gleiche Weise ansprechbar oder erreichbar sein. Das betrifft also alle als Server im LAN arbeitenden Systeme. Wenn ich z.B. beim Start meines Arbeitsplatz-PCs die Netzwerklaufwerke meines Files-Servers via Mount-Units automatisch verbunden haben möchte, so muss der Server natürlich konsequent immer unter der gleichen IP-Adresse im Netzwerk erreichbar sein. Das gleiche gilt ebenso für alle anderen als digitale Dienstleister arbeitenden Systeme, die von anderen Maschinen im LAN via IP-Adresse erreichbar sein müssen, z.B. bei SSH-Zugriffen zur Fernwartung an Headless-Systemen, bei Remote-Desktop-Zugriffen, bei lokalen Mail-Servern, bei einem Print-Server, beim Blick auf den Camera-View.

Die Notwendigkeit, dass einzelne Systeme eine statische IP im lokalen Netzwerk benötigen, ist allerdings im Default-Verhalten eines handelsüblichen DSL-Routers oft nicht automatisch berücksichtigt. Korrekterweise arbeitet der Router meistens zunächst einmal als DHCP-Server. Das bedeutet, wenn sich ein Client-Gerät im Netzwerk anmeldet, vergibt der Router automatisch eine freie IP-Adresse und beachtet dabei, dass diese IP-Adresse momentan einmalig im Netzwerk vergeben ist, um einen konfliktfreien Datenverkehr zu gewährleisten. Das bedeutet aber manchmal auch, dass die vom Router vergebene IP-Adresse für ein Client-Gerät an einem Tag anders sein kann, als sie am Vortag war. Normalerweise kann man in der Web-Oberfläche des Router eine Einstellung vornehmen, womit für ein bestimmtes Client-Gerät immer die gleiche IP-Adresse reserviert wird - dann würde das Gerät immer die gleiche IPAdresse erhalten. Aber manchmal möchte man auch IP-Adressen zur leichteren Erinnerung manuell fest vorgeben und nicht die pseudostatischen verwenden, die der Router nach seinem Ermessen vergeben hat. Aus der Sicht eines Client-Gerätes wären das nämlich trotzdem keine echten statischen IPs, sondern weiterhin eine vom Router per DHCP-Server zugewiesene – nur wird die aller Voraussicht nach immer gleich bleiben.

Gleichbleibend zu meinen anderen Artikeln verwende ich auch hier wieder das Lokale Netzwerk 10.0.1.0/24 als Test-Umgebung. Der Test-PC, den ich nacheinander mit unterschiedlichen Variationen malträtiere, hat kontinuierlich die u.g. IP-Adresse.

IP-Range des lokalen Heimnetzwerks:              10.0.1.0/24

Default-Gateway:                                 10.0.1.1

IP-Adresse lokaler Test-PC:                      10.0.1.56

$ date

Mi 17. Jun 14:27:54 CEST 2020

$ lsb_release -a

Distributor ID: Debian

Description   : Debian GNU/Linux 10 (buster)

Release       : 10

Codename      : buster

$ ip r s | grep default

default via 10.0.1.1 dev eth0

Manchmal hat man also eigene Vorstellungen, nach welcher Logik feste IP-Adressen verwendet werden sollen. Zum Beispiel sollen die dafür relevanten Geräte im 4. Segment der IP eine konstante, unserer eigenen Vorstellung der Netzwerk-Logik entsprechende Ziffer erhalten:

10.0.1.1

für den DSL-Router

10.0.1.2

für den Fileserver

10.0.1.3

für den Druck-Server

10.0.1.4

für den lokalen DNS mit Pihole

10.0.1.10 und 10.0.1.11

für zwei IP-Cams

10.0.1.20, 10.0.1.21 und 10.0.1.22

für drei headless auf dem Server betriebene virtuelle Maschinen

10.0.1.50 bis 10.0.1.99

für alle normalen Client-Geräte eine flexibel zugeteilte IP-Adresse via DHCP

Ich persönlich halte es jedenfalls nicht für sinnvoll, ausnahmslos für alle Geräte statische IP-Adressen vorzusehen. Das würde mir viel zu viel sinnlose Wartungsarbeit bereiten. Aus technischer Sicht hat das auch überhaupt keine Vorteile, und auch sicherheitstechnisch ist das m.M.n. völlig irrelevant. Die tatsächlichen Vorteile statischer IP-Adressen bei einigen ausgewählten Geräten sind rein subjektiver, menschlicher Natur … man erinnert sich halt leichter, die Handhabung wird für mich als Anwender und Chef-Betreuer im Heimnetzwerk leichter. Aber weil ich z.B. unsere Smartphones überhaupt nicht über das Netzwerk erreichen muss und die selber meistens nur Internet-Clients sind, ist mir letztlich völlig egal, welche IP-Adresse der Router denen bei Aktivierung des Handy-WLANs vergibt. Das gleiche betrifft beispielsweise meinen eigenen PC … welche lokale IP-Adresse der im LAN hat, ist doch wirklich so unwichtig, wie nur irgendwas. Ich will nur alle Systeme mit Server-Funktionen immer unter konstant gleicher IP-Adresse erreichbar haben, alles andere ist mir dabei relativ egal.

An dieser Stelle nun noch ein gewohnter Hinweis: Ich rate von der Verwendung des sudo-Kommandos bei der alltäglichen normalen Administration eines Desktop-PCs aufgrund signifikant sicherheitsrelevanter Bedenken konsequent ab. sudo ist in der Default-Konfiguration meiner Einschätzung nach ein offenes und quasi unkontrollierbares Sicherheitsrisiko, was die Sicherheit eines Systems hochgradig infrage stellt. Die mit einer Standard-Konfiguration von sudo einhergehenden Risiken habe ich in meinem Artikel < security > relativ umfassend beschrieben. Das heißt, bei allen in diesem Artikel besprochenen Tätigkeiten setze ich eine als root legitimierte, mit dem root-Pwd authentifizierte Terminal-Sitzung und somit das passende Shell-Environment (login als root) voraus.
 

 

Feststellen der vorhandenen Netzwerkinterfaces

Bei der erstmaligen Einrichtung einer Netzwerkverbindung auf einem Linux-System, ebenso beim Untersuchen von Problemen oder beim Beseitigen von Störungen, ist ausnahmslos und grundsätzlich und wirklich immer die erste Maßnahme, den Ist-Zustand der Netzwerkinterfaces (NIC) festzustellen. Die Kenntnis über die Namen der Interfaces, deren Verbindungsstatus und ggf. auch die MAC-Adressen sind meiner Meinung nach zwingend notwendig.

 
 

Selbstverständlich kann man auch vieles über die im Desktop-Environment implementierten grafischen Dialoge ermitteln, aber leider führt die Vielfalt solcher Benutzerschnittstellen in den Distributionen häufig viel schneller zur Verwirrung, als das sie wirklich hilfreich bei einer Diagnose sind. Darüber hinaus vertrete ich die Meinung, dass das Tun und Ergebnis eines GUI-Dialogs für mich als Anwender häufig sehr intransparent ist… weil ich meistens nicht erkennen kann, welcher Parameter (wie heißt der?), mit welchem Inhalt (ist tatsächlicher Value und Anzeige im Dialog identisch?), in welcher Konfigurationsdatei (wo ist sie gespeichert?), mit welchen Auswirkungen (gibt‘s auch andere Möglichkeiten?) geändert wird.

Und wie ich schon sagte, sehr oft unterstützen solche Dialoge entweder nur die Anforderungen an simple Basic-Funktionen oder sie erschlagen mich mit einer unübersichtlichen bunten Vielfalt und Möglichkeiten, wobei ich mich doch eigentlich viel mehr auf die Lösung eines bestimmten Problems fokussieren möchte. Für mich ist das Grund genug, auf solche Dialoge zu verzichten und die Probleme an der Wurzel anzugehen… also direkt im Betriebssystem. Diese Prämisse gilt übrigens grundsätzlich und ist meine bevorzugte Vorgehensweise… ich will wissen, welches Programm was tut, wie ich das beeinflussen kann, was ich an welchen Stellen dafür tun muss und ob so ein Programm am Ende vielleicht auch nur ein eigentlich überflüssiges Komfort-Tool ist. Gerade bei den reinen Komfort-Tools bin ich der Meinung, dass man bei günstigen Bedingungen besser damit bedient ist, wenn man genau darauf verzichtet. Das ist letztlich dann auch die Vorgehensweise, die mir im Laufe der Zeit in gewissen Grenzen ermöglicht hat, das Betriebssystem meines PC deutlich besser zu verstehen und ihn deswegen insgesamt auf sicherere und sehr störungsarme Weise zu betreiben.

Die folgende Liste zeigt die zwei gefundenen und für Netzwerkverbindungen geeigneten Interfaces auf meinem Test-PC. Die Bezeichnungen eth0 und wlan0 sind i.ü.S. nicht mehr als nur die aktuellen bezeichnenden Eigenschaften bestimmter Hardware auf diesen PCs. Auf einem anderen PC können andere Bezeichnungen angezeigt werden. Das ist aber unproblematisch, es handelt sich hierbei nur um symbolische Namen, mit denen wir eine bestimmte Hardware ansprechen können.

$ ip link show | grep -i broadcast

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000

Ein Beispiel ohne aktive Netzwerkverbindungen:

$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000

    link/ether d0:3g:ff:9a:xy:zz brd ff:ff:ff:ff:ff:ff

3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000

    link/ether dd:1e:ca:ae:08:6b brd ff:ff:ff:ff:ff:ff

Ein Beispiel mit aktiver WLAN-Verbindung in einem IPv4-LAN:

$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000

    link/ether d0:3g:ff:9a:xy:zz brd ff:ff:ff:ff:ff:ff

3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

    link/ether 08:0766b:bb:kk:ae brd ff:ff:ff:ff:ff:ff

    inet 10.0.1.38/24 brd 10.0.1.255 scope global dynamic wlan0

       valid_lft 863977sec preferred_lft 863977sec

Ein Beispiel mit aktiver kabelgebundener Netzwerkverbindung mit IPv4 und IPv6:

$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether d0:3g:ff:9a:xy:zz brd ff:ff:ff:ff:ff:ff

    inet 10.0.1.56/24 brd 10.0.1.255 scope global dynamic eth0

       valid_lft 863991sec preferred_lft 863991sec

    inet6 2022:1687:6219:h500:15a8:622:3040:c8db/64 scope global temporary dynamic

       valid_lft 7187sec preferred_lft 3587sec

    inet6 2022:1687:6219:h500:d23g:ffff:fe9a:xyzz/64 scope global dynamic mngtmpaddr

       valid_lft 7187sec preferred_lft 3587sec

    inet6 fe80::d23g:ffff:fe9a:xyzz/64 scope link

       valid_lft forever preferred_lft forever

3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000

    link/ether dd:1e:ca:ae:08:6b brd ff:ff:ff:ff:ff:ff

Betrachten wir kurz, welche Informationen im letzten Beispiel enthalten sind:

- Es werden 3 Netzwerkinterfaces gelistet:

1: lo      – das loopback-Interface zur systeminternen Kommunikation

2: eth0    – ein kabelgebundenes Netzwerkinterface zur externen Kommunikation

3: wlan0   – ein mit Funk arbeitendes Netzwerkinterface zur externen Kommunikation

- Das via Patchkabel mit einem Netzwerk verbundene Interface eth0 zeigt an zwei Stellen den Status ‚UP‘. Das erste bezieht sich auf den physischen Status des Interfaces, es ist also grundsätzlich betriebsbereit. Die aktuelle Eigenschaft state UP‘ bezieht sich auf den Status einer Netzverbindung, UP=verbunden, DOWN=nicht verbunden

- Beim aktiv verbundenen Interface eth0 lautet die

- MAC-Adresse:                                         d0:3g:ff:9a:xy:zz

- lokal gültige IPv4:                                  10.0.1.56

- global gültige temporäre IPv6 (privacy extensions):  2022:1687:6219:h500:15a8:622:3040:c8db

- global gültige reguläre IPv6 (MAC-Related):          2022:1687:6219:h500:d23g:ffff:fe9a:xyzz

- lokal gültige Link-Local-Adresse:                    fe80::d23g:ffff:fe9a:xyzz

- Das Interface wlan0 ist derzeit nicht mit einem Netzwerk verbunden

Das bei den IP-Adressen angezeigte Attribut ‚global‘ ist leider ein wenig irritierend. Denn hinsichtlich der IPv4-Adresse, die oberhalb auch mit „global“ bezeichnet ist, besteht die Besonderheit, dass diese eben nicht global gültig ist. Von der IANA wurden bereits 1994 drei private IP-Adressbereiche festgelegt, die bis heute noch gültig sind. Jeder der drei Bereiche liegt in einer anderen Klasse des historischen (!) Netzklassen-Konzepts. Mittels Subnetmasks unter der Prämisse „Classless Inter-Domain Routing (CIDR)“ besteht heute allerdings höchste Flexibilität darin, beliebig verkleinerte Netze im gesamten reservierten Adressraum zu definieren. In der folgenden Tabelle wird jetzt deutlich, dass die oberhalb festgestellte IPv4-Adresse 10.0.1.56/24 nur eine im privaten Netzwerk nutzbare IP-Adresse ist, die keinen Zugang zum Internet ermöglicht.

Reservierte Adressbereiche für IPv4. Beispiele:

Netzadressbereich

CIDR-Notation

Historische Netzklasse

Zweck

10.0.0.0    bis  10.255.255.255

172.16.0.0  bis  172.31.255.255

192.168.0.0 bis  192.168.255.255

10.0.0.0/8    

172.16.0.0/12  

192.168.0.0/16

A

B

C

Private Adressen für lokale Netzwerke ohne Zugang zum öffentlichen Adressraum (Internet)

169.254.0.0 bis  169.254.255.255

169.254.0.0/16

 

Link-Local-Addresses haben nur Gültigkeit innerhalb abgeschlossener Netzwerksegmente

127.0.0.0   bis  127.255.255.255

127.0.0.0/8

 

Loopback-Addresses = localhost, die Selbst-Adresse eines Hosts/NICs

224.0.0.0   bis  239.255.255.255

nicht definiert (Leading-Bits 1110)

 

Multicast-Adressen

Lokal bedeutet also, diese IPv4-Adresse ist immer nur im lokalen Netzwerk gültig und wird nicht ins Internet geroutet. Global bedeutet hingegen, diese Adresse ist sowohl im lokalen Netzwerk gültig und sie wird auch ins Internet geroutet. Globale IP-Adressen sind deshalb im Moment der Verwendung weltweit gültig und in diesem Moment definitiv immer exklusive und einmalige Unikate. Lokale Adressen hingegen müssen zum Zeitpunkt der Verwendung nur im lokalen Netzwerk einmalig und exklusiv für ein einzelnes Netzwerkinterface sein. Aus globaler Perspektive betrachtet, also mit Blick auf die restliche Welt, könnte diese gleiche lokale IP-Adresse noch tausende Male zur gleichen Zeit in anderen privaten Netzen existieren.

Bei Anfragen durch unseren PC an Empfänger im Internet (z.B. Web-Seiten über Firefox oder zum Mailhoster mit Thunderbird, etc.) werden solcherart private Absender-IPv4-Adressen durch den DSL-Router mit der öffentlichen IP-Adresse des DSL-Routers im Rahmen der Network-Address-Translation (NAT) ersetzt. Die Empfänger im Internet sehen also nicht die lokale/private IP des PCs, sondern nur die öffentliche, exklusive, einmalige IP des DSL-Routers. Im Gegensatz dazu ist bei Anfragen ins Internet über IPv6-Global-Unicast-Addresses der Kontakt zwischen den Geräten quasi End-to-End. Beide Seiten sehen die jeweils öffentliche IP der Gegenseite. Wobei es uns nicht möglich ist festzustellen, ob für das eigentliche Zielsystem der Gegenseite nicht trotzdem auch NAT durchgeführt wird.

Ein paar ergänzende Information mit bildlicher Darstellung über das Thema NAT sind weiter < unten > im Artikel und auch in meinem Artikel < security > enthalten.

Ganz allgemein wird gesagt, das NAT in Verbindung mit der bei IPv4-DSL-Accounts täglich üblichen Zwangstrennung eine gewisse Datenschutzfunktion innehat. Dieser Gedanke setzt allerdings voraus, dass es keine andere Möglichkeiten der Wiedererkennung und des Trackings geben würde. Die gibt es aber leider. Und vermutlich hat NAT gegen das Tracking deswegen wohl eine eher untergeordnete Relevanz. Wer sich beispielsweise nicht über die Möglichkeiten des Browser-Fingerprints bewusst ist, oder die Gefahr durch Cookies, oder durch eindeutig identifizierbare Surface-Daten, oder der Meldung „ich bins“ durch verwendete und ggf. gesendete Werbe-ID-Kennziffern (in einem den Datenschutz missachtenden Programm/PlugIn/AddOn), der braucht sich über die Sicherheit durch NAT wahrscheinlich auch keine weiteren Gedanken zu machen. Nichtsdestotrotz kann man natürlich auch die Wiedererkennung durch eine quasi-statisch gleichbleibende IPv6-Adresse (Interface-ID), die gebunden an die MAC-Adresse maschinell durch SLAAC erzeugt wurde, durchaus mit der Verwendung der Privacy Extensions erschweren. Aber auch das eliminiert nicht die anderen real existierenden Tracking-Risiken. Speziell zum Thema IP-Adressen sind  < hier > noch ein paar weitere Informationen enthalten.

Wie zuvor gibt es auch für IPv6-Adressen reservierte Bereiche. Beispiele:

Netzadressbereich

Zweck

fe80::/64

LLA

Link-Local-Adresses haben nur Gültigkeit innerhalb abgeschlossener Netzwerksegmente

fc00::/7    (fc00... bis fdff...)

ULA

Unique Local Addresses für lokale Netzwerke bzw. über Tunnel verbundene lokale Netze ohne Zugang zum öffentlichen Adressraum (Internet)

2000::/3    (2000... bis 3fff...)

GUA

Global Unicast Addresses für die Verwendung im öffentlichen Adressraum (Internet)

::1/128

lo

Loopback = localhost, die Selbst-Adresse eines Hosts/NICs

ff00::/8    (ff...)

 

Multicast-Adressen

Unter Debian und den durch systemd vorgegebenen Spielregeln für „Predictable Network Interface Names“, mit denen der Name eines Interfaces reproduzierbar vorhergesagt werden kann, ist es durchaus normal, dass im Gegensatz zu früher die Interfaces nicht mehr eth0 oder wlan0 heißen, sondern einen von der Hardware abhängigen Namen verwenden. Das bedeutet, der früher vom Kernel ermittelte Name des Netzwerkinterfaces lautet nicht mehr in zählweise aufsteigend eth* oder wlan*, sondern ist Firmware-, Topologie-, Ortsinformationsabhängig. Das hat durchaus einige Vorteile, es kann aber in Einzelfällen geradezu kryptische Ausmaße annehmen:

$ ip link show | grep -i broadcast

2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

3: wlp2s87554345532ac0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000

$ ip a s dev wlp2s87554345532ac0 | grep 'link/ether'

    link/ether dd:1e:ca:km:08:xy brd ff:ff:ff:ff:ff:ff

Denn wie hier im oberen Beispiel benannt ist der Name wlp2s87554345532ac0 des WLAN-Interfaces in keinster Weise von Vorteil. Im Gegenteil, so ein Namens-Unglück ist denkbar anwenderunfreundlich, man kann ihn sich kaum merken, jegliche Handhabung, also auch die Administration des Netzwerks, wird damit erschwert. Wenn ein NIC maschinell so unmöglich bezeichnet wurde, ist es angebracht, dass auf eine leichtere Bezeichnung zu ändern.

Die Umbenennung des NICs auf einen freundlicheren Namen ist schnell passiert. Dazu wird die folgende Datei angelegt und der neue Name wird an die MAC-Adresse des Interfaces gebunden. Weil MAC-Adressen weltweit einmalig sind, kann es später bei der Identifikation des Interfaces auch nicht mehr zu Verwechselungen kommen, falls im Rechner gelegentlich noch ein zweites WLAN-Interface verwendet wird.

$ su -

# nano /etc/systemd/network/10-wlan0.link

 

[Match]

MACAddress=dd:1e:ca:km:08:xy

Type=wlan

 

[Link]

Name=wlan0

Nach dem reboot des System sollte das Netzwerkinterface dann diesen manuell vorgegebenen Namen innehaben, was man wiederum mit dem obigen ip-Kommando bestätigen kann. Hier ist unbedingt zu beachten, das an den vorherigen Name gebundene alte Verbindungen jetzt nicht mehr funktionieren.

Achtung: Ist tatsächlich ein zweites WLAN-NIC angeschlossen, ist es sogar unbedingt ratsam, beiden NICs auf diesem Wege eine eindeutige Bezeichnung explizit zuzuweisen, um vorn vornherein Konflikte auszuschließen. In solchen besonderen Fällen mit mehreren vorhandenen Interfaces gleichen Typs ist es nämlich nicht ungewöhnlich, dass die Reihenfolge, in der die NICs vom Kernel erkannt und benannt werden, nicht konstant ist. Das bedeutet, es ist nicht sicher vorhersagbar, welches NIC nach einem Neustart des Systems die Kernel-Bezeichnung wlan0 oder wlan1 erhalten wird. Wenn nun z.B. nur eines der NICs über eine AccessPoint-Funktionalität verfügt, hätte das möglicherweise zur Folge, dass auf einmal und scheinbar völlig unerklärlich der mit ‚hostapd“ eingerichtete AccessPoint nicht mehr funktioniert. Ich empfehle deshalb, den Dateinamen dem Namen des NIC anzugleichen und eine fortlaufende Prioritäts-Nr. voranzustellen, z.b. wenn das zweite NIC als künftiger Accesspoint den Name wlanap bekommen soll, lautet der Dateiname der Konfiguration 11-wlanap.lnk.
 

 

Feststellen der für die aktuelle Netzwerkverbindung verwendeten Programme

Neben dem zuvor erworbenen Wissen über die vorhandene Hardware (und bevor auch nur an irgendeiner Stelle irgendetwas verändert wird), ist es eben so unerlässlich, unbedingt den Istzustand der verwendeten Software festzustellen. Zuerst haben wir uns also angesehen, welche Netzwerkinterfaces vorhanden sind und mit welchem symbolischem Namen wir mit einem bestimmten Interface umgehen müssen, als nächstes befassen wir uns mit der dafür notwendigen bzw. bisher verwendeten Software. Dabei ist der wichtigste Aspekt die Firmware, oder -mit anderen Worten gesagt- die Hardware-Treiber. Ohne die entsprechende Firmware ist es nicht möglich, ein Netzwerkinterface in Betrieb zu nehmen.

Es ist als Folge der „Debian Free Software Guideline“ durchaus nicht ungewöhnlich, dass bei einem neu installierten Debian-Betriebssystem die Netzwerk-Hardware nicht sofort funktioniert. Das passiert möglicherweise dann, wenn aufgrund einer proprietären Nutzungslizenz und der Closed-Source-Eigenschaft der benötigten Firmware dieser Treiber nicht automatisch vom offiziellen Debian-Installer installiert wurde. Dieses Verhalten ist sowohl  korrekt als auch wünschenswert und entspricht vollständig den Regeln des Debian-Gesellschaftsvertrages, im Default-Verhalten des Installers zunächst nur freie Software zu installieren. Um auch unfreie Software zu installieren, muss während des Setups durch Opt-In ausdrücklich „non-free“ erlaubt werden. Im Regelfall kann man dieses Problem aber auch noch einfach nach Beendigung der Installation lösen, indem dem in der Sources-List vorhandenen „main“ die Debian-Repository-Eigenschaften „contrib non-free“ hinzugefügt werden.
 

$ su -

# nano /etc/apt/sources.list

deb http://deb.debian.org/debian/ buster main contrib non-free

deb http://security.debian.org/debian-security buster/updates main contrib non-free

deb http://deb.debian.org/debian/ buster-updates main contrib non-free

# apt update

# apt full-upgrade

Im folgenden als Beispiel konstruierten Journalauszug erkennen wir, dass die Netzwerkverbindung weder Kabelgebunden noch via Funk möglich wäre, weil die entsprechenden Hardware-Treiber (Firmware) fehlt. Weiterhin sehen wir, dass hier der Networkmanager erfolglos versucht hat, eine Verbindung herzustellen.  

# journalctl -b | grep -i "firmware"

Jul 07 14:19:55 tomspc dhclient[466]: Failed to get interface index: No such device

Jul 07 14:19:56 tomspc kernel: r8169 0000:03:00.0: firmware: failed to load rtl_nic/rtl8168e-3.fw

Jul 07 14:19:56 tomspc kernel: iwlwifi 0000:05:00.0: firmware: failed to load iwlwifi.ucode (-2)

Jul 07 14:19:56 tomspc kernel: iwlwifi 0000:05:00.0: Direct firmware load for iwlwifi.ucode failed with error -2

Jul 07 14:19:56 tomspc NetworkManager[380]: <warn>  device (wlan0): firmware may be missing.

 

Das weitere Vorgehen ist einfach, wie nehmen einen Text-Teil der Fehlermeldung und suchen damit im Debian-Repo nach einem passenden Paket. Ist ein Paket verfügbar, wird es kurzerhand installiert. Danach ein Reboot und bei der anschließenden Kontrolle sollten die Fehlermeldungen aus dem Journal verschwunden sein.
 

# apt search  rtl_nic/rtl8168e

firmware-realtek/stable,now 20190114-2            Binary firmware for Realtek wired/wifi/BT adapters

# apt search  iwlwifi

firmware-iwlwifi/stable 20190114-2                Binary firmware for Intel Wireless cards

# apt install firmware-realtek firmware-iwlwifi

# systemctl reboot

Im nächsten Schritt versuchen wir festzustellen, welche Programme bisher entweder eine Netzwerkverbindung erfolgreich herstellen können oder welche Programme es zumindest versuchen und aufgrund von Fehlern scheitern.

Für eine erste Diagnose zur Feststellung des Istzustands empfehle ich ‚systemctl‘ zur Abfrage der von systemd automatisch in der Bootphase gestarteten Dienste zu verwenden. Es handelt sich hier um die jeweiligen Ausgaben auf verschiedenen PCs.

# systemctl -l | egrep -i "network|connect"

1. Auf meinem Laptop wurde zum Beispiel der im Bash-Foreground laufende Network-Manager selnic gestartet:

selnic.service                          loaded active exited    Connect to Network (Wired or WLAN-SSID)

2. Auf diesem System wurde das sysv-Script /etc/init.d/networking gestartet:

networking.service                      loaded active exited    Raise network interfaces

3. Auf  diesem PC wird das Netzwerk durch systemd-networkd.service gestartet.

systemd-networkd.service                loaded active running   Network Service

4. Auf  diesem PC wurde der Network-Manager und das sysv-Script /etc/init.d/networking gestartet:

networking.service                      loaded active exited    Raise network interfaces

NetworkManager.service                  loaded active running   Network Manager

5. Auf  diesem PC wird das Netzwerk durch eine Custom-Service-Unit gestartet:

network.service                         loaded active exited    thlu: Start network connectivity                      

6. Auf  diesem PC wurde der Network-Manager ‚connman‘ und das sysv-Script /etc/init.d/networking gestartet:

connman.service                         loaded active running   Connection service

networking.service                      loaded active exited    Raise network interfaces

 

Stellvertretend für alle obigen Varianten schauen wir uns nur den Status der Service-Units des letzten Systems an. Die Vorgehensweise ist bei allen anderen immer gleich.

# systemctl status connman.service

    connman.service - Connection service

     Loaded: loaded (/lib/systemd/system/connman.service; enabled; vendor preset: enabled)

     Active: active (running) since Wed 2020-07-08 18:50:41 CEST; 52s ago

     Main PID: 414 (connmand)

     CGroup: /system.slice/connman.service

             └─414 /usr/sbin/connmand -n

 

   Jul 08 18:50:42 lxqt connmand[414]: enp1s0 {add} route fe80:: gw :: scope 0 <UNIVERSE>

   Jul 08 18:50:44 lxqt connmand[414]: enp1s0 {add} route 2022:1687:6219:h500:: gw :: scope 0 <UNIVERSE>

   Jul 08 18:50:46 lxqt connmand[414]: enp1s0 {add} address 2022:1687:6219:h500:d23g:ffff:fe9a:xyzz/64 label (null)

 

# systemctl status networking.service

   ● networking.service - Raise network interfaces

     Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)

     Active: active (exited) since Wed 2020-07-08 18:50:41 CEST; 8min ago

     Process: 333 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0/SUCCESS)

     Main PID: 333 (code=exited, status=0/SUCCESS)

 

   Jul 08 18:50:41 lxqt systemd[1]: Starting Raise network interfaces...

   Jul 08 18:50:41 lxqt systemd[1]: Started Raise network interfaces.

 

Zusätzlich empfehle ich, auch einen Blick ins Journal zu werfen. Um einen Eindruck von den möglichen Ergebnissen bei der Suche im Journal zu vermitteln, beschreibe ich hier im folgenden die Log-Auszüge von verschiedenen Systemen, welches jedes für sich das Netzwerk auf eine eigene Art startet.  

# journalctl -b | egrep -i "network|connection"

1. Der folgende Journal-Auszug deutet auf das alte sysv-Script /etc/init.d/networking in Verbindung mit ifup@.service hin:

Jun 23 14:10:57 pc1 systemd[1]: Started Raise network interfaces.

Jun 23 14:10:57 pc1 systemd[1]: Reached target Network.

 

2. Auf diesem PC wird das Netzwerk durch systemd-networkd gestartet:

Jun 23 14:49:04 pc2 systemd[1]: Started Network Service.

Jun 23 14:49:04 pc2 systemd[1]: Reached target Network.

 

3. Auf diesem PC wird das Netzwerk durch den Netzwerk-Manager ‚connman‘ gestartet:

Jun 23 14:17:30 lxqt systemd[1]: Started Connection service.

Jun 23 14:17:30 lxqt systemd[1]: Reached target Network.

Jun 23 14:17:30 lxqt connmand[448]: Connection Manager version 1.36

 

5. Auf diesem Laptop wird das Netzwerk durch den Bash-Netzwerk-Manager ‚selnic‘ gestartet:

Jun 23 14:06:55 lappi systemd[1]: Started thlu:selnic.service:   Connect to Network (Wired or WLAN-SSID).

Jun 23 14:06:55 lappi systemd[1]: Reached target Network.

 

4. Auf meinem PC wird das Netzwerk aufgrund besonderer Anforderungen durch eine spezielle Service-Unit gestartet:

Jun 23 14:17:00 thomaspc systemd[1]: Started thlu:network.service    Start network connectivity.

Jun 23 14:17:00 thomaspc systemd[1]: Reached target Network.

Weil man nun anhand der überall sehr ähnlichen Log-Texte kaum unterscheiden kann, welcher Prozess letztlich für den Start des Netzwerks verantwortlich ist, kann sich diese spezielle Diagnose durchaus ein wenig anspruchsvoll gestalten. Aber die Kombination aus Journaleinträgen und der Liste gestarteter Service-Units  sollte allemal ausreichen, um sich ausreichend Klarheit zu verschaffen. Wir sollten an diesem Punkt angekommen nun eindeutig wissen, welche Netzwerk-Hardware installiert ist und welche Programme sich bisher um die Herstellung einer Netzwerksverbindung gekümmert haben. Mit den nun folgenden nächsten Schritten werden die Voraussetzungen geschaffen, das Netzwerk erstmalig unmittelbar und direkt zu starten, um dann anschließend die in dieser Distribution als Default-Programme installierten Mechanismen zu deaktivieren.

 

Einrichten eines über ETH verbundenen Anwender-PCs via DHCP

 
Weil ich mich ja nun für ein eher unkonventionelles Vorgehen für die stationär betriebene Systeme entschieden habe und dort gewisse eigentlich unnötige Komfort-Tools entfernen will, muss ich allerdings unbedingt vorher sicherstellen, dass ich mich nicht gleich zu Anfang selber aussperre. Für alle weiteren Tätigkeiten bei der Netzwerk-Konfiguration ist es deshalb zwingend notwendig, als allererstes eine Service-Unit einzurichten, mit der sich der PC nach einem Reboot auch wieder automatisch mit dem Netzwerk verbindet, wenn wir (wie im nächsten Kapitel beschrieben) vorhaben, das Default-Setup der Netzwerk-Konfiguration zu deaktivieren. Tun wir das nicht, so kann es schlimmstenfalls wirklich passieren, dass wir uns bei einem Headless einzurichtenden PC ausgesperrt haben, wenn die alten per Default-Setup vorgesehenen Prozesse deaktiviert wurden. Das bedeutet, wenn ich einen Raspberry Pi ohne angeschlossene Tastatur und ohne Bildschirm durch Fernwartung via SSH einrichten will, muss ich absolut sicher sein, dass ich den Pi nach einem Reboot auch wieder im Netz wiederfinde. Dazu benötigen wir die folgende Service-Unit… bitte beachten, dass hier ggf. der Names des NIC angepasst werden muss … aber den haben wir ja oberhalb im vorherigen Teilkapitel festgestellt. Und bitte auch beachten, dass ich hier ausdrücklich von einem via Patchkabel verbundenen PC spreche.
 

Sitzen wir allerdings gerade an einem normalen Desktop-PC, mit Bildschirm, Tastatur und Maus, kann eigentlich nicht viel passieren, wir können ganz entspannt alle Arbeiten ausführen, ohne dabei ein großes Risiko einzugehen, irgendwas unwiderruflich kaputtzumachen. Wenn jetzt hierbei wirklich ein Fehler passiert, alles kein Problem, wir können ja jederzeit alle Änderungen wieder rückgängig machen und darüber dann erreichen, dass nach einem Restart des Rechners wieder der Default-Zustand besteht – einschließlich entweder der aktiven Netzwerkverbindung oder auch der zuvor bestehenden Probleme. Also gilt folgende Devise: Sehr, sehr sorgfältig bei einer Headless-Einrichtung arbeiten.  Und trotzdem auch sehr sorgfältig bei jeder anderen Einrichtung arbeiten, auch wenn wir diese direkt an Tastatur und Bildschirm wieder reparieren könnten.

Die folgende Service-Unit verwendet das oben festgestellte Interface für eine zuverlässig hergestellte kabelgebundene Netzwerkverbindung und ist anschließend als fertige Lösung besonders gut für normale stationäre Desktop-PCs geeignet. Ein solcher PC benötigt eigentlich keine Static-IP, er wird als Workstation eingeschaltet, meldet sich beim Router, bekommt eine IP via DHCP-Server und kann ungehindert im Netz und im Internet agieren, irgendwann wird er ausgeschaltet. Diese Service-Unit kann beispielsweise deswegen an solchen stationären und patchkabelgebundenen PCs als endgültige Lösung betrachtet werden. Für headless betriebene Server-Systeme mit besonderer Netzfunktionalität (z.B. mit Bridgedevices) oder für mobile Laptops ist diese Unit allerdings nur ein Zwischenschritt, die Unit wird auf solchen Systemen nach Abschluss der Arbeiten wieder deaktiviert.
 

Achtung!  Sowohl diese als auch alle weiteren folgenden Service-Units sind nicht konfliktfrei mit anderen das Netzwerk startenden Programmen. Das bedeutet als Voraussetzung, wenn diese oder eine der folgenden Service-Units aktiviert werden sollen, müssen vorher ggf. konkurrierende Programme oder Dienste deaktiviert werden. Die dazu notwendigen Maßnahmen sind im nächsten Kapitel beschrieben.

Zielvorstellung bzw. beabsichtigter Verwendungszweck für diese Service-Unit:

Stationäre kabelverbundene PCs, die eine lokale IPv4-Adresse bzw. einen IPv6-Prefix vom DHCP-Server (DSL-Router) beziehen.

$ su -

# nano /etc/systemd/system/network.service

[Unit]

Description=thlu:network.service:     Start network connectivity

After=basic.target

Before=network.target shutdown.target

Wants=network.target

 

[Service]

Environment="PATH=/bin:/usr/sbin:/usr/bin"

Type=oneshot

RemainAfterExit=yes

 

ExecStartPre=ip link set dev eth0 up

ExecStart=dhclient -4 eth0

 

ExecStop=dhclient -r eth0

ExecStopPost=ip link set dev eth0 down

 

[Install]

WantedBy=multi-user.target

 

 

# cd /etc/systemd/system

# systemctl start network.service

Neue Netzwerkverbindung aktivieren

Teststart, um auf Fehler zu prüfen

# systemctl status network.service

● network.service - thlu:network.service:     Start network connectivity

   Loaded: loaded (/etc/systemd/system/network.service; enabled; vendor preset: enabled)

   Active: active (exited) since Wed 2020-03-25 16:55:12 CET; 4s ago

  Process: 521 ExecStartPre=/sbin/ip link set dev eth0 up (code=exited, status=0/SUCCESS)

  Process: 522 ExecStart=/sbin/dhclient -4 eth0 (code=exited, status=0/SUCCESS)

 Main PID: 522 (code=exited, status=0/SUCCESS)

    Tasks: 1 (limit: 2200)

   Memory: 3.5M

   CGroup: /system.slice/network.service

           └─523 /sbin/dhclient -4 eth0

 

Mär 25 16:55:11 tomsvpngw systemd[1]: Starting thlu:network.service:     Start network connectivity...

Mär 25 16:55:11 tomsvpngw dhclient[523]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6

Mär 25 16:55:11 tomsvpngw dhclient[523]: DHCPOFFER of 10.0.1.56 from 10.0.1.1

Mär 25 16:55:11 tomsvpngw dhclient[523]: DHCPREQUEST for 10.0.1.56 on eth0 to 255.255.255.255 port 67

Mär 25 16:55:11 tomsvpngw dhclient[523]: DHCPACK of 10.0.1.56 from 10.0.1.1

Mär 25 16:55:11 tomsvpngw dhclient[522]: RTNETLINK answers: File exists

Mär 25 16:55:12 tomsvpngw dhclient[523]: bound to 10.0.1.56 -- renewal in 429397 seconds.

Mär 25 16:55:12 tomsvpngw systemd[1]: Started thlu:network.service:     Start network connectivity.

# systemctl enable network.service

Created symlink /etc/systemd/system/multi-user.target.wants/network.service → /etc/systemd/system/network.service.

Die vorstehende Service-Unit verwendet im ExecStart-Statement zur Abfrage einer IP-Adresse beim DHCP-Server (üblicherweise ist das DSL-Router) natürlich einen lokalen DHCP-Client. Es muss also unbedingt sichergestellt sein, dass auch ein lokaler DHCP-Client verfügbar ist, denn ohne dieses Programm würde die Unit unweigerlich fehlschlagen. An dieser Stelle ist das Verständnis wichtig, dass bei der Anforderung „nomaler Client-PC“  nur eine DHCP-Client-Instanz benötigt wird. Bei diesem PC handelt es sich also nicht um ein System, was als DHCP-Server oder gar Router verwendet werden soll. Ein zusätzlich installierter DHCP-Server wie dnsmasq‘ oder oder ‚isc-dhcp-server‘ oder wie die meiner Meinung nach sehr überladene Client-SW ‚dhcpcd5‘ ist somit völlig überflüssig und wären diese Pakete installiert, so würde ich sie wie im nächsten Kapitel beschrieben entfernen.

# dpkg -l | grep isc-dhcp

ii  isc-dhcp-client         4.4.1-2   amd64    DHCP client for automatically obtaining an IP address

ii  isc-dhcp-common         4.4.1-2   amd64    common manpages relevant to all of the isc-dhcp packages

Fehlen diese beiden Pakete, werden sie installiert:

# apt install isc-dhcp-client isc-dhcp-common

 

 
An dieser Stelle möchte ich das noch einmal ausdrücklich betonen: Ich befasse mich hier in diesem Artikel immer nur mit Linux-Setups, bei denen es NICHT um eine generelle Router-Funktionalität geht oder darum, mit einem eigenen DHCP-Server die gleiche in handelsüblichen DSL-Routern immer vorhandene Funktion vollständig zu ersetzen. Ich sehe gerade beim letzten Aspekt keinerlei sinnvollen Nutzen oder einen Mehrwert enthalten, sondern nur unnötige und vermeidbare Mehrarbeit für mich in der Netzwerk-Administration. Man kann einen eigenen DCHP-Server einrichten, man muss aber nicht. Für mich ist so etwas konsequent ausgeschlossen.
 

 

Deaktivieren des Default-Setups für Netzwerkverbindungen

Die Deaktivierung des Default-Setups zur Verhinderung potentieller Störungsquellen sowie die Entfernung eigentlich unnötiger Software sollte uns nun, nachdem wir uns erfolgreich Klarheit über die Hardware (Interfaces) und Software (Firmware und Network-Tools) verschafft haben, nicht mehr weiter schwer fallen. Für die hier folgend beschriebenen Services, die auf dem eigenen System nicht aktiv sind oder die möglicherweise gar nicht installiert sind, werden die betroffenen Maßnahmen deshalb natürlich übersprungen.

Dieses Tutorial funktioniert unter Debian, Raspbian und aller Wahrscheinlichkeit gleichermaßen auch unter Arch Linux, Ubuntu oder Mint. Weil aber die möglichen Beispiele zu den folgenden Services erwartungsgemäß völlig unterschiedlich auf den Systemen oder durch die Ziele einer Distribution eingerichtet und aktiviert sind, ist nicht vorhersagbar, welche Schritte ausgeschlossen sind und welche durchgeführt werden müssen. Ich habe hier versucht, etliche unterschiedliche Situationen abzubilden, die aber niemals alle zusammen auf einem System  installiert sein können. Deshalb bitte sehr aufmerksam arbeiten und jeden Service anhand seines Status prüfen. Ist ein Service nicht active‘, so wird an dieser Stelle auch nichts unternommen oder verändert. Im Idealfall besteht am Anschluss an die vorherigen Kapitel jetzt aber eine genaue Kenntnis darüber, welche Services außer Betrieb genommen werden sollen.

# cd /

# find /etc -iname "*networking" -print

/etc/rc0.d/K01networking

/etc/rc6.d/K01networking

/etc/rcS.d/S01networking

/etc/default/networking

/etc/init.d/networking

 

 

 

Hier wurde eine Verbindung nach altem Standard gefunden:

sysv = obsolet => ausplanen

 

 

 

# systemctl status ifup@eth0.service

● ifup@eth0.service - ifup for eth0

Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset: enabled)

Active: active (exited) since Sat 2019-06-08

# systemctl mask ifup@eth0.service

Created symlink /etc/systemd/system/ifup@eth0 .service → /dev/null.

# update-rc.d networking remove

# systemctl status networking.service

● networking.service - Raise network interfaces

Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)

Active: active (exited) since Thu 2020-03-05 14:37:31 CET; 21s ago

# systemctl mask networking.service

Created symlink /etc/systemd/system/networking.service → /dev/null.

# find /etc -iname "*networking" -print

/etc/default/networking

/etc/init.d/networking

 

Für die folgenden Beispiele entweder die Service-Units einzeln auf active und  enabled prüfen oder explizit nur die ansprechen, die zuvor (s.o.) ermittelt wurden!

# systemctl status NetworkManager.service

● NetworkManager.service - Network Manager

Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)

Active: active (running) since Sat 2019-06-08

# systemctl mask NetworkManager.service

Created symlink /etc/systemd/system/NetworkManager.service → /dev/null.

# systemctl status connman.service

● connman.service - Connection service

   Loaded: loaded (/lib/systemd/system/connman.service; enabled; vendor preset: enabled)

   Active: active  (running) since Mon 2020-06-22 21:26:06 CEST; 18s ago

# systemctl mask connman.service

Created symlink /etc/systemd/system/connman.service → /dev/null.

# systemctl status systemd-networkd

● systemd-networkd.service - Network Service

Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)

Active: active (running) since Sat 2019-06-08

# systemctl mask systemd-networkd

Created symlink /etc/systemd/system/systemd-networkd.service → /dev/null.

# systemctl status wpa_supplicant.service

● wpa_supplicant.service - WPA supplicant

Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; enabled; vendor preset: enabled)

Active: active (running) since Thu 2020-03-05 15:01:35 CET; 9min ago)

# systemctl mask wpa_supplicant.service

Created symlink /etc/systemd/system/wpa_supplicant.service → /dev/null.

# systemctl status dhcpcd.service

● dhcpcd.service - LSB: IPv4 DHCP client with IPv4LL support

Loaded: loaded (/etc/init.d/dhcpcd; generated)

Active: active (running) since Thu 2020-03-05 15:01:35 CET; 9min ago

# systemctl mask dhcpcd.service

Created symlink /etc/systemd/system/dhcpcd.service → /dev/null.

# systemctl status isc-dhcp-server.service

● isc-dhcp-server.service - LSB: DHCP server

Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)

Active: active (running) since Thu 2020-03-06 14:02:25 CET; 6min ago

# systemctl mask isc-dhcp-server.service

Created symlink /etc/systemd/system/isc-dhcp-server.service → /dev/null.

# systemctl -l | grep avahi

  avahi-daemon.service                 loaded active running   Avahi mDNS/DNS-SD Stack

  avahi-daemon.socket                  loaded active running   Avahi mDNS/DNS-SD Stack Activation Socket

# systemctl mask avahi-daemon.service avahi-daemon.socket

  Created symlink /etc/systemd/system/avahi-daemon.service → /dev/null.

  Created symlink /etc/systemd/system/avahi-daemon.socket → /dev/null.

# systemctl reboot

Nach dem Reboot wird eine Erfolgskontrolle durchgeführt. Natürlich fragen wir auch hier wieder nur die Services ab, die wir zuvor manuell deaktiviert haben:

# systemctl status ifup@eth0 networking NetworkManager systemd-networkd wpa_supplicant dhcpcd isc-dhcp-server

● ifup@eth0.service

   Loaded: masked (Reason: Unit ifup@eth0.service is masked.)

   Active: inactive (dead)

 

● networking.service

   Loaded: masked (Reason: Unit networking.service is masked.)

   Active: inactive (dead)

 

● NetworkManager.service

   Loaded: masked (Reason: Unit NetworkManager.service is masked.)

   Active: inactive (dead)

 

● systemd-networkd.service

   Loaded: masked (Reason: Unit systemd-networkd.service is masked.)

   Active: inactive (dead)

 

● wpa_supplicant.service

   Loaded: masked (Reason: Unit wpa_supplicant.service is masked.)

   Active: inactive (dead)

 

● dhcpcd.service

   Loaded: masked (Reason: Unit dhcpcd.service is masked.)

   Active: inactive (dead)

 

isc-dhcp-server.service

   Loaded: masked (Reason: Unit isc-dhcp-server.service is masked.)

   Active: inactive (dead)

 

# systemctl status avahi-daemon.service avahi-daemon.socket

● avahi-daemon.service

   Loaded: masked (Reason: Unit avahi-daemon.service is masked.)

   Active: inactive (dead)

 

● avahi-daemon.socket

   Loaded: masked (Reason: Unit avahi-daemon.socket is masked.)

   Active: inactive (dead)

 

Jetzt ist der Moment der Wahrheit gekommen :-) Haben wir nach dem Reboot immer noch eine aktive Netzwerkverbindung, obwohl alle relevanten und zuvor dafür zuständigen Service-Units außer Betrieb genommen wurden? War die erstellte Service-Unit  /etc/systemd/system/network.service erfolgreich? Wenn die oben beschriebene Service-Unit korrekt eingerichtet wurde, sollte sie erfolgreich die patchkabelverbundene Netzwerkverbindung hergestellt haben.
 

Die folgende Abfrage zeigt uns den Zustand des Interfaces (UP?), den Verbindungsstatus (state UP?) und ob via DHCP erfolgreich eine IP bezogen werden konnte:

$ ip a

$ systemctl status network.service

 

 

Einrichten eines über ETH verbundenen dedizierten Server-Systems mit Static-IP

Weil im bisherigen Verlauf dieses Artikels bereits alle relevanten Vorarbeiten und Voraussetzungen relativ umfassend besprochen wurden, beschränke ich mich jetzt hier und auch bei den noch folgenden Service-Units primär auf auf die eigentliche Einrichtung der Netzverbindung eines einzelnen Systems mit besonderen Anforderungen.

Zielvorstellung bzw. beabsichtigter Verwendungszweck für diese Service-Unit:

Ein stationärer kabelverbundener PC,  der z.B. als Samba-Server die statische IPv4-Adresse 10.0.1.2 zugewiesen bekommen soll. IPv6-Global-Unicast-Adressen sind davon nicht betroffen und werden unabhängig davon via RA-Prefix-Delegation und SLAAC erstellt.

$ su -

# nano /etc/systemd/system/network.service

[Unit]

Description=thlu:network.service:     Start network connectivity

After=basic.target

Before=network.target shutdown.target

Wants=network.target

 

[Service]

Environment="PATH=/bin:/usr/sbin:/usr/bin"

Type=oneshot

RemainAfterExit=yes

 

ExecStartPre=ip addr add 10.0.1.2/24 dev eth0

ExecStartPre=ip link set eth0 up

ExecStartPre=ip route add default via 10.0.1.1

ExecStart   =true

 

ExecStop=ip link set eth0 down

ExecStopPost=ip addr flush dev eth0

ExecStopPost=ip route del default via 10.0.1.1

 

[Install]

WantedBy=multi-user.target

= Zugewiesene Static-IP-Adresse

= Verwendete Interface

= Default-Gateway

 

 

# cd /etc/systemd/system

# systemctl start network.service

Teststart, um auf Fehler zu prüfen. Wenn Fehlerfrei, dann neue Netzwerkverbindung aktivieren

# ip a

1: lo: *snip*

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether d0:3g:ff:9a:xy:zz brd ff:ff:ff:ff:ff:ff

    inet 10.0.1.2/24 scope global eth0

    valid_lft forever preferred_lft forever

# systemctl status network.service

network.service - thlu:network.service:     Start network connectivity

  Loaded: loaded (/etc/systemd/system/network.service; disabled; vendor preset: enabled)

  Active: active (exited) since Wed 2020-07-15 14:37:35 CEST; 37s ago

  Process: 7101 ExecStartPre=/usr/sbin/ip addr add 10.0.1.2/24 dev eth0 (code=exited, status=0/SUCCESS)

  Process: 7102 ExecStartPre=/usr/sbin/ip link set eth0 up (code=exited, status=0/SUCCESS)

  Process: 7103 ExecStartPre=/usr/sbin/ip route add default via 10.0.1.1 (code=exited, status=0/SUCCESS)

  Process: 7104 ExecStart=/usr/bin/true (code=exited, status=0/SUCCESS)

  Main PID: 7104 (code=exited, status=0/SUCCESS)

 

Jul 15 14:37:35 thomaspc systemd[1]: Starting thlu:network.service:    Start network connectivity...

Jul 15 14:37:35 thomaspc systemd[1]: Started thlu:network.service:     Start network connectivity.

# systemctl enable network.service

Created symlink /etc/systemd/system/multi-user.target.wants/network.service → /etc/systemd/system/network.service.

 

 

 

Einrichten eines über WLAN verbundenen stationär genutzten Laptops

Manchmal trifft es zu, dass ein Laptop oder Notebook ausschließlich stationär genutzt wird. Wir nutzen selber mehrere mobile Linux-Geräte, aber einige von denen verlassen trotzdem nie das Haus, obwohl sie durchaus komfortabel tragbar und mobil sind. Bei diesen Systemen bietet es sich natürlich an, auch hier einfach eine statische Verbindung herzustellen – nur eben über WLAN. Wozu benötige ich einen WLAN-Network-Manager, wenn doch das Gerät sowieso nie bewegt wird und nie einen anderen Accesspoint verwendet. Auch für solche Systeme sind schnell die Verbindungseinstellungen hergestellt, mit denen sich das Gerät direkt nach dem Einschalten zuverlässig mit dem DSL/WLAN-Router verbindet.

Generell gilt derzeit für alle WLAN-Verbindungen auf einem Linux-System, dass wpa_supplicant installiert sein muss. Dieses Programm stellt die Funkverbindung zwischen zwei WLAN-Geräten her. Damit ist also noch nicht die logische Netzwerkverbindung selber gemeint, sondern i.ü.S. trifft eher der Vergleich zum Patchkabel zu. Auch das Patchkabel zwischen zwei Geräten stellt noch nicht die logische Netzwerkverbindung auf TCP/IP-Ebene des Netzwerk-Stacks her, hier ist es erst mal nur eine physische Verbindung, beim WLAN ist es erst mal nur eine Funkverbindung. Bitte überprüfen, ob die Pakete installiert sind:

# dpkg -l wpasupplicant iw

||/ Name           Version       Architektur  Beschreibung

+++-==============-=============-============-==============================================

ii  iw             5.0.1-1       amd64        tool for configuring Linux wireless devices

ii  wpasupplicant  2:2.7+git     amd64        client support for WPA and WPA2 (IEEE 802.11i)

Wenn diese beiden Pakete noch nicht vorhanden sind, müssen sie jetzt installiert werden:

# apt install wpasupplicant iw

Sofern die Pakete bereits vorhanden waren oder direkt nach dem wir sie installiert haben, können wir sofort testen, ob unsere WLAN-Hardware funktioniert. Ich weise jetzt natürlich nicht mehr darauf hin, dass die Firmware für die WLAN-Hardware auch wirklich installiert ist… denn das hatten wir ja schon weiter oben sichergestellt. Bitte daran denken, wenn das WLAN-Interface eine andere Bezeichnung als wlan0 hat, muss natürlich diese andere Bezeichnung hier verwendet werden. Und wie erfreulich, mein eigener Test-Accesspoint wurde beim Scan natürlich auch sofort gefunden:

# ip link set wlan0 up

# iw wlan0 scan | grep -i ssid

SSID: Toms_AP  

SSID: FRITZ!Box 7430 IS

SSID: Vodafone Hotspot

SSID: FRITZ!Box 7412

SSID: DIRECT-06-HP DeskJet 2600 series

SSID: Vodafone-30AB

SSID: UschisNetz

SSID: KalleKloppersFritte

usw...

# ip link set wlan0 down

Mit den nächsten Schritten legen wir manuell eine Datei mit den aktuellen und für diese Aufgabe notwendigen Verbindungseinstellungen für unseren Accesspoint/unsere SSID an. Der Name dieser Datei ist nicht vorgegeben, wie können sie nennen, wie wir wollen. Ich halte es nur für günstig und auch sinnvoll, wenn sie einfach den Namen der SSID übernimmt, dann gibt es nie Irritationen darüber, wofür diese Datei gedacht ist. Mit der erste Maßnahmen legen wir quasi ein Basic-Format an, welches bereits das verschlüsselte WLAN-Password enthält:

                 SSID    WLAN-Password                     

# wpa_passphrase Toms_AP mein_geheimes_wlan_password >/etc/wpa_supplicant/toms_ap.conf

# cat /etc/wpa_supplicant/toms_ap.conf

network={

    ssid="Toms_AP"

    #psk="mein_geheimes_wlan_password"

    psk=7425aa1c7133ea8f5b412a99c51fc6f32371719c03f3550f5d5cb780accbd8c3

}

Nun wird der vorgegebene Inhalt noch um einige weitere notwendige Angaben ergänzt … zum Beispiel mit den unterstützten Verschlüsselungsmethoden. Und wir entfernen natürlich die Klar-Text-Darstellung unseres WLAN-Passwortes. Hier noch ein wichtiger Hinweis: Andere Verschlüsselungen als RSN oder WPA sollten aus Sicherheitsüberlegungen nicht mehr verwendet werden, denn eine schwache Verschlüsselung kann heute durchaus schon gehackt und mitgehört werden.

# nano /etc/wpa_supplicant/toms_ap.conf

 ctrl_interface=/var/run/wpa_supplicant

 ap_scan=1

 

 network={

    scan_ssid=1

    priority=20

    id_str="Guest"

 

    ssid="Toms_AP"

    psk=7425aa1c7133ea8f5b412a99c51fc6f32371719c03f3550f5d5cb780accbd8c3

 

    proto=WPA RSN

    group=CCMP TKIP

    pairwise=CCMP TKIP

    key_mgmt=WPA-PSK

}

Wenn die Datei eingerichtet ist und abschließend noch einmal sorgfältig kontrolliert wurde, dass keine Tipp- oder Übertragungsfehler enthalten sind, kann  sofort getestet werden, ob sie funktioniert:

# ip link set dev wlan0 up

# wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/toms_ap.conf

# dhclient wlan0

Interface und Verbindung öffnen, eine IP-Adresse anfordern

# ip a

Wenn eine IP-Adresse aus dem lokalen Netzwerk angezeigt wird, sollte es jetzt möglich sein, mit einem Browser Web-Seiten im Internet zu öffnen-

# pkill -f /etc/wpa_supplicant/toms_ap.conf

# ip link set dev wlan0 down

# ip addr flush dev wlan0

Zum Schluss den laufenden Prozess beenden und aufräumen

Wenn alle Tests erfolgreich verlaufen sind, spricht nun überhaupt nichts mehr dagegen, diese Einstellungen auch beim Start des Gerätes zu verwenden und die Netzwerkverbindung via WLAN automatisch herzustellen.

An diesem aktuellen Punkt zur Erstellung einer WLAN-Netzwerkverbindung angekommen ist festzustellen, dass alle diese bisherigen Maßnahmen im Grunde genommen nur dem Basic-Handwerk für die erfolgreiche Einrichtung einer solchen Funk-Verbindung entsprechen. Normalerweise haben wir selber allerdings eher wenig damit zu tun, weil diese Schritte zumeist verborgen vor unseren Augen im Hintergrund durch irgendeinen installierten Netzwerk-Manager erfolgen. Nur hat dieses verborgene Tun leider nicht nur einen komfortablen Aspekt, es enthält auch den für mich unangenehmen Nebeneffekt, dass es mir das Verstehen meines Betriebssystems vorenthält. Nun ja, ich bin halt der Meinung, wenn ich die Kontrolle über meine Hardware behalten will, sollte ich auch ein Mindestmaß von dem verstehen, was darauf im Verborgenen abläuft. Das verhilft mir nicht nur zu deutlichen besseren Möglichkeiten bei der Fehlerdiagnose bestehender Probleme, es dient auch noch definitiv dem Datenschutz und somit dem Schutz meiner digitalen Privatsphäre. Denn da, wo ich gar nichts kontrollieren oder beeinflussen kann, habe ich auch keine Kontrolle über den Datenschutz und darüber, wie meine Hardware verwendet wird.
 

Wie zuvor wird dafür wieder eine systemd-Service-Unit verwendet. Hier besteht allerdings eine kleine Besonderheit. Um dem Kernel meines Testsystems die Zeit zu geben, den externen USB-Wlan-Stick zu erkennen und mit dem Symlink als wlan0 zu bezeichnen, habe ich ihm 3 Wartesekunden gegönnt.  Ohne diese 3 Sekunden konnte es in seltenen Fällen passieren, dass die Service-Unit gestartet wurde, bevor der Stick korrekt erkannt wurde… und natürlich muss die Unit dann infolgedessen und verständlicherweise fehlschlagen.

Zielvorstellung bzw. beabsichtigter Verwendungszweck für diese Service-Unit:

Stationär verwendete via WLAN verbundene PCs/Laptops/Notbooks, die eine lokale IPv4-Adresse bzw. einen IPv6-Prefix vom DHCP-Server (DSL-Router) beziehen.

$ su -

# nano /etc/systemd/system/network.service

[Unit]

Description=thlu:network.service:     Start wireless network connectivity

After=basic.target

Before=network.target

Wants=network.target

 

[Service]

Environment="PATH=/bin:/usr/sbin:/usr/bin"

Type=oneshot

RemainAfterExit=yes

 

ExecStartPre=sleep 3

ExecStartPre=ip link set dev wlan0 up

ExecStartPre=wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/toms_ap.conf

ExecStart   =dhclient wlan0

 

ExecStop    =pkill -f /etc/wpa_supplicant/toms_ap.conf

ExecStopPost=dhclient -r wlan0

ExecStopPost=ip link set dev wlan0 down

ExecStopPost=ip addr flush dev wlan0

 

[Install]

WantedBy=multi-user.target

 

# cd /etc/systemd/system

# systemctl start network.service

Teststart, um auf Fehler zu prüfen. Wenn fehlerfrei, dann wie zuvor neue Netzwerkverbindung aktivieren

# ip a

# systemctl status network.service

# systemctl enable network.service

Created symlink /etc/systemd/system/multi-user.target.wants/network.service → /etc/systemd/system/network.service.

 

Die jetzt hier in diesem Kapitel besprochene Vorgehensweise ist wirklich nur dann empfehlenswert, wenn Geräte, die eigentlich für den mobilen Einsatz gedacht sind, tatsächlich nur stationär benutzt werden. Wenn sie allerdings ihrer eigenen Zweckbestimmung entsprechend regelmäßig mitgenommen werden und sich unterwegs des öfteren an fremden offenen Gasteber-Netzen anmelden, ist diese Lösung denkbar ungeeignet.
 

Ich verwende für solche Fälle bei unsere mobilen Geräten selbstverständlich auch ein Programm zur Unterstützung bei ad hoc hergestellten WLAN-Verbindungen an fremden Access-Points. Dafür nutze ich selnic, meinen eigenen kleinen Netzwerk-Manager, der menügeführt und komfortabel exakt das gleiche tut, wie hier zuvor beschrieben wurde.

 

 

Einrichten eines über ETH verbundenen PCs mit lokalen VMs (libvirt/KVM, Bridge, LAN-Client, DHCP)

Auf meinem eigenen PC nutze ich zusätzlich zu den normalen Desktop-Anwendungen mehrere virtuelle Maschinen für unterschiedliche Zwecke. Der Hintergrund ist einfach, es sollen gewisse Prozesse von meiner persönlichen Desktop-Oberfläche und von meinem persönlichen Datenbereich nicht nur ausgeschlossen werden, sie sollen sogar konsequent von allen möglicherweise erreichbaren privaten Daten isoliert werden und tatsächlich nur wie unter Quarantäne-Bedingungen laufen. Das betrifft zum Beispiel meinen Browser, mit dem ich im Internet surfe, oder eine zweite VM, die ausdrücklich nur für Online-Banking verwendet wird. Die VMs sind so eingerichtet, dass sie über ihren beabsichtigten Zweck hinaus keinerlei andere Funktionen oder Programme beinhalten oder Zugriff auf irgendwelche Daten oder Ressourcen unseres Netzwerks haben. Im Endeffekt hat das die Auswirkung, dass mein persönliches Home-Dir, also mein eigener Linux-User-Account auf dem PC, niemals einen direkten Kontakt mit irgendwelchen Web-Sites des Internets hat. Für die nun folgenden Lösungsvorschläge mit jeweils sehr anspruchsvollen Zielen halte ich es für obligatorisch, das vom Installer eingerichtete oder in der Distribution implementierte Default-Setup der Netzwerkverbindung wie beschrieben zu deaktivieren. Konflikte hierbei durch konkurrierende oder ähnliche Prozesse sind wirklich völlig unnötige Problemursachen.

Einschränkungen hinsichtlich des Bedienungskomforts habe ich durch die VMs nicht. Ich habe ein Browser-Icon auf dem Desktop, das klicke ich völlig unspektakulär an und der Browser öffnet sich. Das einzige auffällige ist eine kurze Verzögerung von 4-5 Sekunden. Solange braucht es vorher die VM von der SSD zu starten. Die VM (ein Debian-System) verlangt natürlich keine extra Anmeldung, der Browser startet dort von alleine. Also ist die Bedienung bis auf die Wartezeit eigentlich die gleiche, wie ohne VM. Meine VMs sind alle mit einem Debian ohne Standard-Desktop-Environment eingerichtet. Zu einem anfangs ‚leeren‘ Debian wurden dann manuell nur der X-Server und Openbox dazu installiert, laufende Dienste gibt es keine.  Mehr ist nicht notwendig, ein Mehr an Desktop-Environment würde möglicherweise nur die Startzeit unnötigerweise verlängern. Für meinen Browser (FF ESR) verwende ich eine eigene user.js, die, so hoffe ich, meine Ansprüche an den Schutz der Privatsphäre ebenfalls unterstützt.

Warum mach ich das? Weil ich das als eine der sehr wenigen tatsächlich vorhandenen Möglichkeiten betrachte, der digitalen Entmündigung bezogen auf das Recht der exklusiven Verfügungshoheit meiner digitalen Privatsphäre und all meiner privaten Daten entgegenzutreten. Das mag für eine Sichtweise „Ich habe keine Geheimnisse, ich habe nichts zu verbergen und jeder kann alles sehen.“ befremdlich sein.  Tja, auf solcherart Unkenntnis über die digitale Realität einzugehen ist hier aber leider nicht möglich, das würde den Rahmen sprengen. Nur soviel dazu, die Annahme dass das nicht existiert, von dem man nichts weiß und was man selber auch nicht unmittelbar schmerzhaft spürt, ist letztlich die Grundlage dafür, dass die Menschen tatsächlich digital entmündigt werden. Das passiert quasi hinterhältig über die Zugänge zum Internet, kontinuierlich, verborgen im für die meisten Anwender undurchschaubaren digitalen Labyrinth der Netzwerke, und zwar ohne das die Anwender das bemerken oder dem bewusst zugestimmt haben.

Ein nachdenkenswertes Zitat von Edward Snowden:

"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say.“

Sinngemäß übersetzt:

""Zu argumentieren, dass Ihnen das Recht auf Privatsphäre egal ist, weil Sie nichts zu verbergen haben, ist nichts anderes als zu sagen, dass Ihnen Redefreiheit egal ist, weil Sie nichts zu sagen haben."“

Ohne die ‚bridge-utils‘ ist es grundsätzlich nicht möglich, die VM als eigenständigen LAN-Client einzurichten. In dem Fall bleibt nur das Masquerading durch den Host-PC. Für die Einrichtung einer solchen VM über ein Bridge-Device sind also als zwingende Voraussetzung  zuerst die entsprechenden Pakete zu installieren, falls sie im Moment noch fehlen:

# dpkg -l qemu-system-x86 virt-manager virt-viewer

dpkg-query: Kein Paket gefunden: qemu-system-x86

dpkg-query: Kein Paket gefunden: virt-manager

dpkg-query: Kein Paket gefunden: virt-viewer

 

# apt install qemu-system-x86 virt-manager virt-viewer

 

# dpkg -l bridge-utils

dpkg-query: Kein Paket gefunden: bridge-utils

 

# apt install bridge-utils

Prüfen, ob notwendige Pakete installiert sind.

 

 

 

 

Nur fehlende Pakete installieren!

 

Eine Service-Unit zum Start des Bridge-Netzwerks zwischen Host und VM.

Zielvorstellung bzw. beabsichtigter Verwendungszweck für diese Service-Unit:

Ein stationärer kabelverbundener Desktop-PC, der zusätzlich lokale ad hoc vom Anwender zu startende VMs beinhaltet. Die VMs treten im lokalen Netz als eigenständige Clients mit einer eigenen IP-Adresse im LAN auf. Und weil die VMs eigenständige LAN-Clients sind, ist dadurch verhindert, dass die Datenpakete einer VM im LAN nicht als scheinbar ursprünglich vom physischen Host kommend erkannt werden, was der Falle bei Host-NAT via Masquerading wäre. Die Netzwerkanbindung der VM erfolgt über ein virtuelles Bridge-Device.

$ ip a s dev eth0 | grep 'link/ether'

  link/ether d0:3g:ff:9a:xy:zz brd ff:ff:ff:ff:ff:ff

$ su -

# nano /etc/systemd/system/network.service

[Unit]

Description=thlu:network.service    Start network connectivity

After=basic.target

Before=network.target shutdown.target

Wants=network.target

Conflicts=shutdown.target

 

[Service]

Environment="PATH=/bin:/usr/sbin:/usr/bin"

Type=oneshot

RemainAfterExit=yes

 

ExecStartPre=ip link add br0 type bridge

ExecStartPre=ip link set br0 type bridge stp_state 0

ExecStartPre=ip link set br0 type bridge forward_delay 0

ExecStartPre=ip link set br0 address d0:3g:ff:9a:xy:zz

ExecStartPre=sysctl -w net.ipv6.conf.br0.forwarding=1

ExecStartPre=sysctl -w net.ipv6.conf.br0.disable_ipv6=0

ExecStartPre=sysctl -w net.ipv6.conf.br0.autoconf=1

ExecStartPre=sysctl -w net.ipv6.conf.br0.use_tempaddr=2

ExecStartPre=sysctl -w net.ipv6.conf.br0.accept_ra=2

ExecStartPre=ip link set eth0 master br0

ExecStartPre=ip link set eth0 up

ExecStartPre=ip link set br0 up

ExecStartPre=dhclient -v br0

ExecStart   =true

 

 

 

 

 

 

 

 

 

= MAC-Adresse entspricht der von eth0

= Interface-Konfiguration für IPv6 via sysctl

= ipv6 erlauben

= Autokonfiguration via SLAAC erlauben

= Privacy Extensions erlauben

= Router-Advertisement trotz forwarding erlauben

ExecStop    =ip link set eth0 nomaster

ExecStopPost=ip link set eth0 down

ExecStopPost=ip addr flush dev eth0

ExecStopPost=ip link set br0 down

ExecStopPost=ip addr flush dev br0

ExecStopPost=ip link del br0 type bridge

 

[Install]

WantedBy=multi-user.target

Bei Shutdown aufräumen

Diese Service-Unit darf natürlich jetzt noch nicht in Betrieb genommen werden, es sind zuerst noch weitere Voraussetzungen zu schaffen. Die wichtigste Maßnahme ist, IPv6 dann zu konfigurieren, wenn der heimische DSL-Vertrag entweder auf Dual-Stack oder DS Lite beruht. In beiden Fällen wird vom DSL-Provider IPv6 unterstützt und ein ISP-Prefix wird vermutlich über das Router-Advertisement und dem Neighbor Discovery Protocol auf die Client-Geräte verteilt.

Mit den Einstellungen der Kernel-Parameter für IPv6 wird folgendes erreicht:

# nano /etc/sysctl.d/sysctl_ipv6_tpc.conf

net.ipv6.conf.all.forwarding=1

 

net.ipv6.conf.default.disable_ipv6=0

net.ipv6.conf.default.forwarding=1

net.ipv6.conf.default.autoconf=0

net.ipv6.conf.default.use_tempaddr=0

net.ipv6.conf.default.accept_ra=0

 

net.ipv6.conf.eth0.disable_ipv6=1

net.ipv6.conf.eth0.forwarding=0

net.ipv6.conf.eth0.autoconf=0

net.ipv6.conf.eth0.use_tempaddr=0

net.ipv6.conf.eth0.accept_ra=0

 

# sysctl --system

 

forwarding für alle Interfaces erlauben

 

für neue NICs ipv6 erlauben (für dynam.-gener. br0)

  - forwarding erlauben

  - keine Autokonfiguration (SLAAC) durchführen

  - Privacy Extensions (Temp-Adressen) nicht erlauben

  - RA nicht erlauben

 

für das bestehende NIC eth0 IPv6 verbieten

  - forwarding verbieten

  - keine Autokonfiguration durchführen

  - Privacy Extensions (Temp-Adressen) nicht erlauben

  - kein Router Advertisement erlauben

 

Einstellung on-the-fly aktivieren

Der Zweck dieser Einstellungen und der Service-Unit ist es, das physische Interfaces eth0 in einen promiskuitiven Modus zu versetzen und das virtuelle Bridge-Interface br0 als primäres Interface zu deklarieren. Im Normalfall leitet eth0 als alleiniges Interface nur IP-Pakete (TCP/UDP im Netzwerk-Stack) an den Kernel weiter, deren Ziel die IP-Adresse dieses System ist. Im promiskuitiven Modus werden auch IP-Pakete weitergeleitet, die eine andere IP-Adresse als Ziel habe… hier wird also das Bridge-Device zum maßgeblichen Interface und die VMs mit eigener IP zu Empfängern der an sie addressierten IP-Pakete. Zusätzlich wird verhindert, dass das physische Interface eth0 über IP-Adressen überhaupt als regulärer Client mit dem Netzwerk verbunden ist. Damit im Netzwerk-Datenverkehr über gleichzeitig vorhandene physische und virtuelle Interfaces nicht miteinander konkurrierende aktive IP-Adressen für Konflikte sorgen, muss außerdem verhindert werden, dass der Kernel via SLAAC automatisch IPv6-Adressen für eth0 generiert.

Mit IPv6 wird das systemisch etwas anders gehandhabt, als man das von IPv4 kennt. Bei IPv4 gibt es lediglich zwei Möglichkeiten, entweder es wird eine IP-Adresse vom DHCP-Server angefordert oder man vergibt eine manuelle IP-Adresse. Bei IPv6 wird im Regelfall keine Adresse vom DHCP-Server angefordert und es wird auch keine Global-Unicast-Adresse manuell angelegt. Der Kernel selber erstellt dynamisch eine MAC-basierte globale IPv6-Adresse, sobald er vom DSL-Router über das Neighbor Discovery Protocol einen Netzwerk-Prefix erhält. Und genau das wird hier mit diesen ausdrücklichen Einstellungen für das physische Interface eth0 unterbunden.

Und ja, wenn man ein reines und eher traditionelles IPv4-Netzwerk hat, kann  man diese Schritte zum Setzen der Kernel-Parameter selbstverständlich überspringen. In dem Fall müssen natürlich auch die sysctl-Statements aus der Service-Unit entfernt werden, die werden dann einfach nicht benötigt:

ExecStartPre=sysctl -w net.ipv6.conf.br0.forwarding=1

ExecStartPre=sysctl -w net.ipv6.conf.br0.disable_ipv6=0

ExecStartPre=sysctl -w net.ipv6.conf.br0.autoconf=1

ExecStartPre=sysctl -w net.ipv6.conf.br0.use_tempaddr=2

ExecStartPre=sysctl -w net.ipv6.conf.br0.accept_ra=2