Automatisches Setup eines Netzwerklabors

vorhergehende Artikel in: Linux Docker Virtualisierung
01.12.2019

Ich hatte hier schon über Möglichkeiten geschrieben, Komponenten eines Netzwerklabors automatisch als LXC-Container aufzusetzen. Nachdem ich neulich mit einem Kollegen über Testszenarien für GlusterFS philosophiert habe, habe ich nunmehr versucht, diese Fragmente zu konsolidieren...

Anforderungen

Das Skript soll vollautomatisch ein Setup mit diversen getrennten Subnetzen so erstellen, dass Rechner in jedem der Subnetze automatisch Zugriff auf das Internet haben, jedoch von den anderen Subnetzen aus nicht erreicht werden können.

Die Subnetze untereinander sind durch spezielle Appliances zu verbinden, mit denen die QoS auf den Verbindungen zwischen den Subnetzen gesteuert werden kann

Idealerweise wird anschließend eine Dokumentation generiert, die die Informationen zu den Subnetzen enthält, ebenso wie Informationen darüber, wie die einzelnen Appliances erreicht und gesteuert werden können.

Bauteile

Es existiert bereits ein Skript zur Einrichtung eines Routers und damit implizit zur Einrichtung eines Subnetzes. Damit kann eine der Anforderungen bereits umgesetzt werden.

Weiterhin existiert ein Skript zur Einrichtung eines "intelligenten" steuerbaren Netzwerkkabels (steuerbar, was QoS angeht). Damit ist eine weitere der genannten Anforderungen umsetzbar.

Beide Skripte müssen mehrfach aufgerufen werden, um die skizzierte Laborumgebung zu realisieren.

Skizze der Umgebung ohne QoS

Es werden drei Subnetze eingerichtet - Diese werden in einer Hierarchie organisiert: Eines der Subnetze wird direkt mit dem Internet verbunden, die anderen beiden werden mit diesem zentralen Subnetz verbunden. Damit müssen Verbungen aus einem dieser beiden Subnetze heraus ins Internet über zwei Router-Appliances laufen.

In einer späteren Ausbaustufe wird in dem Subnetz, das in der Hierarchie am weitesten oben angesiedelt ist ein dedizierter Nameserver eingerichtet. Dieser ist dazu da, das Internet zu simulieren: Hier können später zentrale Dienste wie zum Beispiel EMail registriert werden.

Ohne diesen dedizierten Nameservice kann die Erstellung der drei Subnetze durch den dreimaligen Aufruf des Skripts setup_router.sh aus diesem Repository erfolgen.

Dabei ist zu beachten, dass die Interfaces beim Aufruf jeweils Bridges sein müssen - existieren sie nicht, werden sie eingerichtet. Das Subnetz, welches in der Hierarchie ganz oben sein soll, muss als externes Interface eine Bridge zugeordnet bekommen, an der ebenfalls ein physisches Interface konfiguriert ist, über das eine Verbindung ins Internet möglich ist.

Die externen Interfaces der beiden anderen Subnetze müssen die gleichen Bridges sein, wie das interne Interface des obersten Subnetzes der Hierarchie.

Damit besteht das Netzwerklabor zu diesem Zeitpunkt aus vier Bridges und drei Containern (drei Router).

QoS Überlegungen

Sollen jetzt noch die QOS Appliances hinzugefügt werden, ist es wichtig, zu entscheiden, wie und wo die schlechten Netzwerkverbindungen simuliert werden sollen: Man könnte die QOS für einzelne Server im oberen Subnetz einrichten oder die Verbindungen zwischen den jeweils untergeordneten Subnetzen und dem übergeordneten Subnetz pauschal über eine solche Appliance laufen lassen. Dieser Fall würde bedeuten, dass alle Rechner innerhalb desselben Subnetzes eine ungestörte, segr schnelle verbindung untereinander haben und nur bei Kommunikation über Subnetzgrenzen hinweg Störungen (je nach Konfiguration der Appliances) auftreten können. Eine solche Konfiguration könnte man sich über ein Szenario erklären, das die zwei untergeordneten Subnetze als zwei geographisch getrennte Standorte eines Unternehmens modelliert.

Skizze der Umgebung mit QoS

Um den Aufwand so gering als möglich zu halten, werden wir dieses Szenario umsetzen - damit ändert sich das beschriebene Szenario ohne QoS wie folgt:

Es werden drei Subnetze eingerichtet - Diese werden in einer Hierarchie organisiert: Eines der Subnetze wird direkt mit dem Internet verbunden, die anderen beiden werden mit diesem zentralen Subnetz verbunden. Damit müssen Verbungen aus einem dieser beiden Subnetze heraus ins Internet über zwei Router-Appliances laufen.

In einer späteren Ausbaustufe wird in dem Subnetz, das in der Hierarchie am weitesten oben angesiedelt ist ein dedizierter Nameserver eingerichtet. Dieser ist dazu da, das Internet zu simulieren: Hier können später zentrale Dienste wie zum Beispiel EMail registriert werden.

Ohne diesen dedizierten Nameservice kann die Erstellung der drei Subnetze durch den dreimaligen Aufruf des Skripts setup_router.sh aus diesem Repository erfolgen.

Dabei ist zu beachten, dass die Interfaces beim Aufruf jeweils Bridges sein müssen - existieren sie nicht, werden sie eingerichtet. Das Subnetz, welches in der Hierarchie ganz oben sein soll, muss als externes Interface eine Bridge zugeordnet bekommen, an der ebenfalls ein physisches Interface konfiguriert ist, über das eine Verbindung ins Internet möglich ist.

Das Setup der zwei QoS-Appliances erfolgt durch den zweimaligen Aufruf des Skripts setup_schlechtesnetz.sh aus diesem Repository.

Die Server-Interfaces der beiden Appliances müssen die gleichen Bridges sein, wie das interne Interface des obersten Subnetzes der Hierarchie.

Die externen Interfaces der beiden anderen Subnetze müssen die gleichen Bridges sein, wie das Consumer-Interface jeweiligen QoS-Appliance.

Damit besteht das Netzwerklabor zu diesem Zeitpunkt aus sechs Bridges und fünf Containern (drei Router, zwei QoS-Appliances).

Beispiel

brctl addbr intnet0
ifconfig intnet0 up
./setup_router.sh router br0 intnet0 10.100.0.254 255.255.255.0 192.168.10.2 intnet0.lab
brctl addbr intnet1
ifconfig intnet1 up
brctl addbr badintnet1
ifconfig badintnet1 up
./setup_schlechtesnetz.sh badintnet1 br0 badintnet1 intnet0
./setup_router.sh router1 badintnet1 intnet1 10.100.1.254 255.255.255.0 10.100.0.254 intnet1.lab 10.100.0.1 255.255.255.0

Damit haben wir ein Subnetz geschaffen, das über eine Verbindung konfigurierbarer Qualität am übergeordneten Subnetz hängt und darüber wiederum mit dem Internet verbunden ist. (Die letzten beiden Parameter beim Aufruf von setup_router.sh hätte man auch weglassen können, dann würde die Appliance statt der angegebenen IP-Adresse für das externe Interface versuchen, eine per DHCP zu bekommen.) Man kann sich jetzt mittels lxc-attach -n badintnet1 -- mit der Appliance verbinden und entweder eines der vorgefertigten Scripte unter /scripts benutzen, um die verbindungsparameter anzupassen oder selbst neue Konfigurationen erstellen.

Weitere Subnetze können durch Wiederholung der Anweisungen erstellt werden. Ein Beispiel dafür sieht man hier:

brctl addbr intnet2
ifconfig intnet2 up
brctl addbr badintnet2
ifconfig badintnet2 up
./setup_schlechtesnetz.sh badintnet2 br0 badintnet2 intnet0
./setup_router.sh router2 badintnet2 intnet2 10.100.2.254 255.255.255.0 10.100.0.254 intnet2.lab 10.100.0.2 255.255.255.0

Auch hier wurde durch die beiden optionalen Parameter für setup_router.sh eine feste IP-Adresse für das externe Interface konfiguriert.

Zugriff auf Container in den Subnetzen

Dazu sei hier nochmals auf meine Auslassungen zum Thema Bastion-Host und die Aktualisierung zu diesem Thema hier verwiesen (ssh -Y -J ubuntu@router,ubuntu@10.100.0.2 ubuntu@xyzclient - der zweite Host in der Kette muss bei fester IP-Adresse und ohne Nameserver noch als Adresse eingegeben werden, da der Name router2 noch nicht aufgelöst werden kann).

Prinzipiell sind alle Container natürlich immer über lxc-attach -n containername -- administrierbar. Außerdem haben alle QoS-Appliances bereits einen SSH-Server installiert. Für die Router muss dieser Dienst erst noch installiert werden, sollte er benötigt werden. In allen Containern sind Nutzer mit dem Nutzernamen ubuntu angelegt. Um sie nutzen zu können, muss allerdings erst ein Passwort gesetzt werden. das kann geschehen mittels lxc-attach -n containername -- passwd ubuntu.

Ausblick

Dieses Setup ist bisher nur ein Skelett. Wir habe nun lediglich erreicht, dass in den zwei Standorten unseres Szenarios große 19'' Schränke stehen, in denen ein Switch einsam Energie verbraucht.

Von hier aus kann man nunmehr aber schnell weitere Szenarien entwickeln. Es ist zum Beispiel möglich, in den Subnetzen Docker-Hosts zu virtualisieren und die Dienste in den Docker-Containern des einen mit denen des anderen Subnetzes zu verbinden.

Damit Rechner aus dem einen mit Rechnern des anderen Subnetzes reden dürfen ist noch die Einrichtung eines Tunnels oder VPN nötig. Das soll hier nicht Teil der Veranstaltung werden.

Alternativ ist es auch immer möglich, Container innerhalb eines Subnetzes zusammenzuschalten und die Qualität der Verbindungen jedes einzelnen Containers über eine Appliance - wie oben bereits angedeutet - steuerbar zu machen.

Links

Hier noch einige weiterführende Links zum Thema Netzwerken mit verschiedenen Containertechnologien Host-übergreifend.

Artikel, die hierher verlinken

PiHole-Bug bei Installation

25.07.2021

Ich trage mich aktuell mit dem Gedanken, analog zu meinen Skripts zur Einrichtung von Kartenservern oder Netzwerkinfrastruktur einen kleinen Server komplett unattended einrichten zu können, der PiHole, DNSSEC und einen autonomen root-Resolver integriert.

Vorhaben 2020

03.01.2020

Genau wie letztes Jahr habe ich auch dieses Jahr wieder ein "Listche" verfasst, um mir all die interessanten Vorhaben zu notieren, die ich mit mittlerem zeitlichen Horizont anzugehen gedenke.

VPN im Netzwerklabor

04.12.2019

Im vorangegangenen Artikel beschrieb ich, wie man mit einigen Bash-Skripten die Grundlagen für ein relativ komplexes Netzwerklabor basierend auf LXC schaffen kann. Hier möchte ich darauf aufbauend beschreiben, wie man exemplarisch die damit erstellten Subnetze mittels VPNs verbinden kann.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Mandelbrot-Sets mittels Shadern berechnen

    17.05.2019

    Nachdem ich in den letzten verregneten Tagen auf Youtube in den Videos von Numberphile versunken bin, hat mich eines davon angestachelt, mich selbst mit dem Mandelbrotset zu beschäftigen. Als ich dann noch Code fand, der behauptete, das auf einer Graphikkarte mittels Shadern berechnen zu können, war es um mich geschehen...

    Weiterlesen...

Neueste Artikel

  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...
  • bad-certificates Version 2.1.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern hat eine Erweiterung erfahren und verfügt über ein Partnerprojekt - beide sind nunmehr in der Version 2.1.0 freigegeben

    Weiterlesen...
  • SQLite als Geodatenbank

    Wie bereits in einem früheren Artikel beschrieben treibe ich derzeit Anstrengungen voran, die sQLshell attraktiver für Nutzer zu machen, die mit Geodatenbanken arbeiten.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.