Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- invis_server_wiki:installation:basesetup-160 [2026/02/16 07:55]
flacco [Netzwerk]
+++ invis_server_wiki:installation:basesetup-160 [2026/02/16 11:15] (aktuell)
flacco [Netzwerkkonfiguration]
@@ Zeile 85: / Zeile 85: @@
 <code>
 linux:~ # zypper ref
-linux:~ # zypper in invisAD-setup-14
+linux:~ # zypper in invisAD-setup-16 (vorerst noch -15)
 </code>
@@ Zeile 92: / Zeile 92: @@
 //**Hinweis:** Dass bei der Installation des invisAD-setup RPMs sehr viele weitere Software-Pakete installiert werden ist normal. ;-)//
-//**Hinweis:** Ab invis-Server Version 14.1 löst die Installation des Setup Pakets eine Reihe von Paketkonflikten aus. Genaugenommen sind das keine Konflikte sondern zyppers Weigerung automatisch zu akzeptieren, das lokal bereits installierte Pakete durch Pakete aus anderen Repositories aktualisiert werden. Erlauben Sie den Wechsel durch Auswahl von Lösungsvorschlag Nr.: **1**//
-//**Hinweis:** Beim Installieren des Setup-Paketes bemängelt **zypper** einen Paketkonflikt bezüglich unseres eigenen DHCP-Server Pakets "invisdhcp". Wählen Sie Lösungsvorschlag Nr.: **1**//
 ===== Netzwerkkonfiguration =====
+Durch den Wegfall von YaST mit Leap 16 hat sich hier einiges geändert. Auch "wicked" als Dienst zum Management der Netzwerkschnittstellen ist nicht mehr Teil von openSUSE Leap. openSUSE Leap setzt zunächst voll und ganz auf den Networkmanager. Dieser spielt seine Stärken vor allem auf Desktop-Installationen aus, da es damit normalen Usern ohne administrative Rechte gestattet ist beispielsweise einen WLAN-Zugriff zu konfigurieren. Für Server-Installationen ohne grafische Oberfläche ist er unserer Meinung nach eher nicht geeignet. Daher ersetzen wir ab invis-Server 16, den Networkmanager, respektive "wicked" durch "systemd-networkd", eine Komponente des Systemd, wie unschwer am Namen zu erkennen ist.
+Der Wechsel erfolgt automatisch mit dem Ausführen des Scripts **//netsetup//**.
+Unverändert bleibt, dass beim invis-Server die einzelnen Netzwerkschnittstellen entsprechend Ihrer Verbindung, bzw. Firewall-Zone benannt werden.
+Um die Benennung der Netzwerkschnittstellen mit den einzelnen Firewall-Zonen eines invis-Servers in Verbindung zu bringen, werden die Namen der Netzwerkschnittstellen auf Basis von udev-Regeln vergeben. Auch die Benennung der im Laufe des Setups einzurichtenden VPN-Schnittstelle wird ein entsprechender Name gegeben:
+^  Vom System vergebener Gerätename  ^  Aktueller Name  ^
+|  eth0 oder enpXsY                |  extern          |
+|  eth1 oder enpXsY                 |  intern          |
+|  //eth2 oder enpXsY//             |  //dmz//         |
+|  tun1                 |  vpn             |
+Die erste Netzwerkkarte des Systems (extern) stellt die Verbindung des Servers mit dem Internet her - entspricht somit der externen Zone Ihrer Firewall.
+Je nach dem, wie der dem invis-Server vorgeschaltete Router konfiguriert ist, müssen Sie "extern" als DHCP-Client oder gemäß den Vorgaben Ihres Providers Konfigurieren.
+Die zweite Netzwerkkarte (intern) muss mit einer festen IP-Adresse versehen werden. Selbst, wenn über den Internet-Service-Provider eine feste IP-Adresse zur Verfügung steht, ist für das interne Netz die Verwendung eines eigenen Netzes zwingend.
+Falls mehr als zwei Netzwerkschnittstellen vorhanden sind, wird die dritte Schnittstelle in **dmz** umbenannt, auch wenn das invis-Server Setup dies (derzeit) in keiner Weise nutzt.
+Die Erstellung der UDEV-Regeln wird mittels unseres Script **//netsetup//** erledigt, aufgerufen wird es ohne weitere Parameter:
+<code>
+localhost:~ # netsetup
+localhost:~ # reboot
+</code>
+Im Anschluss an dessen Ausführung muss das System neu gestartet werden. **//netsetup//** sorgt automatisch dafür, dass die externe Schnittstelle versucht sich eine IP-Adresse per DHCP zu besorgen. Wenn alles gut geht, ist der Server also nach dem Reboot per **SSH** erreichbar.
+Die Konfiguration der internen oder weiterer Schnittstellen erfolgt mittels des neuen Scripts **//netdevconf//**.
+//**Achtung: Vermeiden Sie es Ihrem lokalen Netzwerk typisch Adressbereiche gängiger Router-Modelle wie auch üblicher Docker Konfigurationen zu verpassen. Hier ein paar Beispiele von denen Sie die Finger lassen sollten:**//
+^  typische IP Netze gängiger Router und Docker-Installationen  ^
+|  192.168.0.0/24                     |
+|  192.168.1.0/24                     |
+|  192.168.2.0/24                     |
+|  192.168.50.0/24                    |
+|  192.168.100.0/24                   |
+|  192.168.177.0/24                   |
+|  192.168.178.0/24                   |
+|  192.168.188.0/24                   |
+|  172.16 - 24.0.0/16                 |
+Achtung: Bevor Sie jetzt die Netzwerkschnittstellen Ihres invis-Servers konfigurieren ein Hinweis dazu. invis-Server können lediglich mit 16 und 24 Bit breiten Netzwerkmasken also „255.255.0.0“ (/16) und „255.255.255.0“ (/24) umgehen. Idealerweise konfigurieren Sie für die interne Netzwerkschnittstelle ein privates IP-Netzwerk der Klassen „B“ (172.16.0.0 bis 172.31.255.255) oder „C“ (192.168.0.0 bis 192.168.255.255). Über die Unterstützung von Klasse „A“ Netzen denken wir noch nach, erachten dies aber nicht wirklich als notwendig für „kleine“ Netze.
+**//netdevconf//** erfordert als Aufrufparameter zunächst den Namen der Schnittstelle und dann die gewünschte IP-Adresse nebst Netzwerkmaske in Kurzschreibweise:
+<code>
+localhost:~ # netdevconf intern 172.26.0.10/16
+</code>
+Wir unterteilen die Netze der beiden unterstützten Netzwerkklassen für den DHCP-Server in verschiedene Bereiche (Damit ist **kein** Subnetting gemeint). Die nachfolgende Tabelle zeigt die verschiedenen Bereiche, angezeigt wird jeweils nur der Host-Anteil der IP-Adressen.
+^  Geräteklasse  ^  Klasse C Netz  ^  Klasse B Netz  ^
+^  Server  |  .11 - .19  |  .0.11 - .0.253  |
+^  Drucker  |  .20 - .50  |  .1.1 - .1.254  |
+^  IP-Geräte  |  .60 - .90  |  .2.1 - .3.254  |
+^  PCs  |  .120 - .199  |  .4.1 - .4.254  |
+^  dyn. Bereich  |  .200 - .220  |  .200.1 - .200.254  |