====== Konzipierung, Aufbau und Anbindung des Netzwerkes für einen externen Firmenstandort - IPA Saba ===== ====== Glossar ====== ^ Begriff ^ Erklärung ^ | KVM | | | Linux Container | | | Debian Linux | | | Proxmox VE | | | Datendeduplikation | | | LVM | | | rsync | | | VPN-Server | | | Captive Portal | | | UTM | | | Transparent Proxy | | | IDS | | | VLAN | Unterscheidung Port basiert vs. Tagged((https://www.thomas-krenn.com/de/wiki/VLAN_Grundlagen)) | | LACP | | ====== Dokumentation ====== * Ordner 01 - 10 auf OneDrive, für Ausbildner freigegeben (Printscreen der Ordnerstruktur und Freigabe) * Backups der Konfigs der Switches und der Firewall in entsprechenden Tagesordner * Backup des Ubuntu-Servers ab Einrichtung auf externe Festplatte ====== Informieren ====== ===== Erfassung der zur Verfügung gestellten Hardware ===== ==== Hardware Server und PCs ==== * Mit welchen Mitteln wurde Hardware erfasst, Programme, Befehle, Internetseite des Herstellers ^ Gerät ^ Modellbezeichnung ^ CPU ^ Memory ^ HD ^ NW-Adapter ^ | Proxmox-Server | | | | | | Backup-Server | | | | | | Arbeitsplatzrechner 1 | | | | | | Arbeitsplatzrechner 2 | | | | | ==== Hardware Switches ==== * Mit welchen Mitteln wurde Hardware erfasst, Programme, Befehle, Internetseite des Herstellers ^ Gerät ^ Modellbezeichnung ^ Übertragungsrate ^ Anzahl Ports ^ | Switch 01 | | | | | Switch 02 | | | | | Switch 03 | | | | | Switch 04 | | | | ==== Hardware Access-Point ==== * Mit welchen Mitteln wurde Hardware erfasst, Programme, Befehle, Internetseite des Herstellers ^ Gerät ^ Modellbezeichnung ^ Anzahl Ports ^ WLAN-Standards ^ Frequenzbänder ^ Verschlüsselungsmöglichkeiten ^ | Access-Point | | | | | | ==== Hardware Firewall ==== * Mit welchen Mitteln wurde Hardware erfasst, Programme, Befehle, Internetseite des Herstellers ^ Gerät ^ Modellbezeichnung ^ CPU ^ Memory ^ Festplatte ^ Netzwerk-Interfaces ^ Übertragungsrate ^ | Firewall | | | | | | | ===== Erfassung der zur Verfügung gestellten Services ===== ==== Die Virtualisierungsplattform Proxmox VE ==== * Zusammenfassung((https://www.proxmox.com/de/proxmox-ve)) * Features(((https://www.proxmox.com/de/proxmox-ve/funktionen)) * KVM & Container * Webmanagement * HA-Cluster * Virtuelle Netzwerke * Storages * Backup * Firewall ==== Der Backup-Server BackuPC ==== In der Rafisa kommt die Backuplösung BackupPC((https://backuppc.github.io/backuppc/)) zum Einsatz. Dabei handelt es sich um eine freie Disk-zu-Disk Backup-Suite, die in PHP geschrieben ist. Als Übertragungsarten stehen ''smb'' für das Backup von Windows-Shares, sowie ''rsync'' für die Sicherung der Daten mit Hilfe des rync-Protokolls zur Verfügung. Zusätzlich lassen sich die Funktionalitäten mit Pre- und Post-Backupscripts erweitern. Die Hauptfeatures der Lösung sind: * Webbasiertes Administrationsinterface: Konfiguration von Backups, Analyse der Logfiles, manuelles Starten und Stoppen von Backups, Browse und Restore von Backupdaten * Datendeduplikation: Identische Files von mehreren Backups des selben Clients oder von verschiedenen Clients werden nur einmal gespeichert. Das erlaubt Einsparungen im Bereich der benötigten Kapazitäten sowie des Disk I/Os. * Kompression: Da nur neue Files komprimiert werden müssen, werden die CPUs nur moderat beansprucht * Open-Source: BackupPC wird auf Github gehostet und unter einer GPL-Lizenz verteilt * Es wird keine clientseitige Software benötigt {{:team:egil-rueefli:backuppcserversummary.png?800|}} Im Rahmen von Vorarbeiten wurde gemeinsam mit dem Team SRB (ServiceRestoreBackup) ein Backupserver auf der Basis von BackupPC installiert. Der ''SLA #001: Backup und Restore'' v.01((https://wiki.rafisa.net/doku.php?id=sla:sla-backup-and-restore)) entnimmt man, dass folgende Backuparten zur Verfügung stehen: * Backup von SMB-Shares * File-Backup von Serversystemen * Image Backup von Proxmox-VMs * Backup von Datenbank-Systemen * Backup der Konfigurationsdateien von Switches und Firewalls (im Aufbau) In der vorliegenden Arbeit soll also mit dem Backup der Konfigurationsdateien von Switches und Firewall also ein Betrag zur Erweiterung des Backup-Angebots geleistet werden. In der Planung müssen folgende Punkte berücksichtigt werden: Festlegen von Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten ===== Beschreibung der aufzusetzenden Services ===== ==== pfSense Firewall ==== pfSense ist eine auf dem Betriebssystem FreeBSD basierende Firewall-Distribution. pfSense lässt sich komplett über ein Webinterface verwalten. Zusätzlich ist der Zugriff über SSH oder über einen seriellen Port möglich. Die eingesetzten Kerntechnologien sind OpenSSL, PHP und Python. Über ein Paketsystem lassen sich die Funktionen der Firewall stark erweitern. Die Hauptfeatures von pfSense sind((https://www.netgate.com/solutions/pfsense-plus/features.html)): * VPN Server * High Availability * Load Balancing * Traffic Shaping * Captive Portal * UTM Device * Firewall / Router * DNS / DHCP Server * IDS / IPS * Transparent Caching Proxy * Web Content Filter In der Planung sollen Policies für die Konfiguration des Paketfilters und die Möglichkeiten zur Realisierung der VPN-Site-to-Site-Anbindung näher untersucht werden. ==== Ubiquiti UniFi Controller ==== * Controller entweder als Software-Lösung für Windows/Linux/Mac OXS oder als HW-Controller (Cloudkey) * Java-Paket * Zentrale Verwaltung aller Unify-Geräte über ein Web-Interface * Passiver Controller: Die Access-Points werden durch Controller konfiguriert, danach laufen sie autonom, Controller kann auch abgeschaltet werden, ausser man nutzt Guest-Portal-Funktion((https://wlanport.de/information/news-co/ubiquiti-unifi-controller-vor-und-nachteile-eines-passiven-controllers)) * Vorteile passiver Controller -> wenn Controller nicht läuft, laufen AP's weiter, kein Single Point of Failure * Nachteile passiver Controller -> Informationen über die Funkeigenschaften der Accesspoints und der verbundenen Clients nicht zur Steuerung genutzt. Z.B. sucht AP beim Start einen geeigneten Funkkanal und bleibt auf diesem -> Keine Optimierung durch Controller möglich * Version des Intstallierten Controllers erwähnen * Hauptfeatures des Controllers((https://www.bossinfo.ch/wp-content/uploads/UniFi_AP_DS.pdf)): * Integration von Grundrissen für das Monitoring der Wireless-Abdeckung * Detailliertes Reporting und Statistiken * Wireless-Uplink: Ein mit Kabel angeschlossener AP erlaubt Wireless-Uplinks auf bis zu 4 Geräte. * Guest-Portal-Support: Mit Voucher-Management * Multi-Site-Management: Verwalten mehrerer Sites mit nur einem Controller * Verwalten von WLAN-Gruppen ===== Firmenstandards für die VLANs der Rafisa Dietikon ===== ==== Standard-VLANs der Rafisa ==== * reinkopieren ==== Berechtigungsmatrix für die Standard-VLANs ==== * reinkopieren ===== Firmenstandards für das Namenskonzept ===== * reinkopieren ===== L3-Plan IST-Zustand des Projektumfelds ===== Als Gateway haben die Geräte das Firewall VLAN-Interface des entsprechenden Subnetzes, für das VLAN01-MGMT also z.B. 172.16.1.1/24. Der Gateway für die IPA-Testumgebung ist demnach 172.16.53.1/24. Der Berechtigungsmatrix kann man entnehmen, dass die Zugänge zu allen anderen VLAN's der Rafisa durch Filterrules auf der Firewall geblockt werden. Die Firewall stellt ausser dem Gateway für den Internetzugang einen DHCP-Dienst zur Verfügung, über welchen IP-Adressen aus dem entsprechenden Subnetz, die Gateway-IP sowie die IP-Adressen der DNS-Server verteilt werden. Alle im L3-Diagramm festgehaltenen System verfügen über statische IP-Adressen. ---- {{drawio>team:sabareeshan-nadeswaran:rafisa_zh_l3netzplan_01}} ---- ^ FQDN ^ IP-Adresse ^ OS ^ Services ^ Service-Team ^ Owner ^ ^ Server ^^^^^^ | prox-zh-ruga-01.zh.rafisa.org | 172.16.1.21/24 | Proxmox VE | Virtualisierungsplattform | Team Server Services | RS | | prox-zh-ruga-02.zh.rafisa.org | 172.16.1.22/24 | Proxmox VE | Virtualisierungsplattform | Team Server Services | RS | | dc-zh-ruga-02.zh.rafisa.org | 172.16.10.22/24 | Windows Server 2019 | DC/AD, DNS | Team Server Services | RS | | dc-zh-ruga-04.zh.rafisa.org | 172.16.10.24/24 | Windows Server 2019 | DC/AD, DNS | Team Server Services | RS | | fs-zh-ruga-01.zh.rafisa.org | 172.16.14.21/24 | Windows Server 2019 | Fileserver Employees | Team Server Services | RS | | fs-zh-ruga-01.zh.rafisa.org | 172.16.15.21/24 | Windows Server 2019 | Fileserver Learners | Team Server Services | RS | | bkp-zh-r02b-01.zh.rafisa.org | 172.16.1.100/24 | Ubuntu 20.04 LTS | Fileserver Learners | Team Network Services | ER | | uni-zh-ruga-01.zh.rafisa.org | 172.16.1.30/24 | Ubuntu 20.04 LTS | Ubiquiti WLAN Controller | Team Network Services | ER | | ap-zh-01-05.zh.rafisa.org | 172.16.1.31-35/24 | AirOS | AP, WPA-Enterprise Radius Auth | Team Network Services | ER | ^ Firewall ^^^^^^ | fw-zh-ruga-01.zh.rafisa.org | VLAN 172.16.1.1/24\\ WAN 46.140.45.118 | pfSense (BSD) | VLAN-Routing, Filtering, VPN Concentrator, DHCP | Team Network Services | ER | ===== Dartstellung und Analyse des zugesendeten Planes aus Fribourg ===== * Plan von wem wann erhalten (keine Namen sondern "Stellenleiter Fribourg (SF)" * Realisierungsdatum: Betriebsferien im August {{:team:egil-rueefli:03raffribourg-physview-switchvlans.png|}} ==== Analyse IST-Zustand ==== Das Netzwerk in Fribourg besteht zur Zeit aus den zwei 24-Port Switches sw-fr-s00-10 und sw-fr-s00-12, die über je 2x2 LACP-Trunks miteinander verbunden sind. sw-fr-s00-10 befindet sich im Main-Rack, sw-fr-s00-12 im Server-Rack. Am Switch sw-fr-s00-12 sind über je 2x4 im Teaming-Modus LACP gekoppelten Trunks zwei Server angeschlossen. Beide Server verfügen zudem über ein iLO-Management-System, die über einen separaten Netzwerkadapter an den Server-Switch angeschlossen sind. In der Legende wird der Netzplan als Physical Transition-Plan bezeichnet. Die beiden Switches sollen im Endzustand durch zwei neue Switches ersetzt werden. In einer Übergangsphase (Transition) sollen die alten Switches mit allen verbundenen Geräten ans Learners-VLAN der neuen Switches angeschlossen werden. Zusätzlich soll ein neuer Switch den Workshop-Room erschliessen, wodurch eine sternförmige, vom Main-Switch ausgehende Topologie entsteht. Nicht auf dem Plan ersichtlich sind das bestehende Subnet, die Netzwerkdienste DHCP und DNS sowie der Gateway. Auf Nachfrage teilt der SF die folgenden Netzwerkinformationen mit:\\ Subnetz: 172.21.22.0/24\\ Gateway: 172.21.22.1 (Swisscom Router Centro Business)\\ DHCP: 172.21.22.10 (srv-fr-s00-01)\\ DNS: 172.21.22.10 (srv-fr-s00-01) ==== Portbelegung Switch sw-fr-s00-10 ==== Bei den nicht genauer spezifizierten Ports handelt es sich um ungetaggte Standardports. ^ Ports ^ VLAN ^ LACP ^ | 23-24 | Keine VLANs | LACP-Trunk nach sw-fr-s00-12, Ports 01-02 | ==== Portbelegung Switch sw-fr-s00-12 ==== Bei den nicht genauer spezifizierten Ports handelt es sich um ungetaggte Standardports. ^ Ports ^ VLAN ^ LACP ^ | 01-02 | keine VLANs | LACP-Trunk nach sw-fr-s00-10, Ports 23-24 | | 05-08 | Keine VLANs | LACP-Trunk für Teaming-NICs auf Server srv-fr-s00-01 | | 09 | Keine VLANs | iLO | | 19-22 | keine VLANs | LACP-Trunk für Teaming-NICs auf Server srv-fr-s00-02 | | 23 | keine VLANs | iLO | ====== Planen ====== ===== Einrichten der VLANs ===== ==== Namenskonzept Racks und Switches ==== * Namenskonzept hält sich zwar an die Policy Funktion + Physischer Standort + Laufnummern, Racks sind aber nicht nummeriert. * Der Vorschlag von SF: sw-fr-s00-01, sf-fr-s00-02, sw-fr-s00-03 * Vorschlag, Rack s01, s02, s03 ==== Wahl des Subnetzes ==== * Vorhanden 172.21.22.0/24 * Integration nach Firmenstandards möglich -> 172.21.0.0/16 Standardnetz für Friourg ==== Mögliche SOLL-Zustände der VLANs ==== ^ VLANs Fribourg SOLL ^ Standard-VLANs Rafisa Dietikon ^ | Management | VLAN01_MGMT (172.16.1.0/24)| | Employees | VLAN21_CLEMPL (172.16.21.0/24) | | Learners | VLAN22_CLLEARN (172.16.22.0/24) | | WIFI | | | Printers | VLAN40_LP (172.16.40.0/24) | | | VLAN10_SRVAUTH (172.16.10.0/24) | | | VLAN14_SRVEMPL (172.16.14.0/24) | | | VLAN15_SRVLEARN (172.16.15.0/24) | | | VLAN23_CLGUEST (172.16.23.0/24) | | | VLAN51_LAB01 (172.16.51.0/24) | | | VLAN52_LAB02 (172.16.52.0/24) | | | VLAN53_LAB02 (172.16.53.0/24) | | | VLAN54_LAB02 (172.16.54.0/24) | | | VLAN55_LAB02 (172.16.55.0/24) | * Realisieren der VLANs Fribourg-SOLL vs Realisieren Standard-VLANs ==== LACP ==== === sw-fr-s01-01 === * keine Varianten ^ Trunk ^ Ports ^ Tagged/Untagged ^ Beschreibung ^ | T1 | 01 - 04 | T | LACP-Trunk auf Switch sw-fr-s02-01 | | T2 | 05 - 06 | T | LACP-Trunk auf Switch sw-fr-s03-01 | | T3 | 41 - 42 | U | LACP-Trunk auf Switch sw-fr-s00-12 | === sw-fr-s02-01 === * 2 Varianten -> Teaming-Trunks wurden vergessen == Variante 1 (bestellt) == ^ Trunk ^ Ports ^ Tagged/Untagged ^ Beschreibung ^ | T1 | 05 - 08 | T | LACP-Trunk auf Switch sw-fr-s01-01 | | T2 | 23 - 24 | U | LACP-Trunk auf Switch sw-fr-s00-01 | == Variante 2 (vorgeschlagen) == ^ Trunk ^ Ports ^ Tagged/Untagged ^ Beschreibung ^ | T1 | 05 - 08 | T | LACP-Trunk auf Switch sw-fr-s01-01 | | T2 | 23 - 24 | U | LACP-Trunk auf Switch sw-fr-s00-01 | | T3 | 05 - 08 | T | LACP-Teaming-Trunk auf srv-fr-s00-01 | | T4 | 19 - 22 | T | LACP-Teaming-Trunk auf srv-fr-s00-02 | === sw-fr-s03-01 === * keine Varianten ^ Trunk ^ Ports ^ Tagged/Untagged ^ Beschreibung ^ | T1 | 03 - 04 | T | LACP-Trunk auf Switch sw-fr-s01-01 | ==== Nicht zugeordnete Ports ==== * Zuordnung ==== WLAN: WPA2-Enterprise vs. WPA2 ==== * wie im IST-Zustand erfasst unterstützen die Unifi-AP's sowohl WPA2 als auch WPA2-Enterprise (noch bei IST-Zustand reinschreiben!) * Vergleich WPA2-Personal - WPA2-Enterprise((http://www.summitdata.com/blog/wpa2-enterprise-vs-wpa2-personal/#:~:text=What's%20the%20Difference%20Between%20WPA2%20Enterprise%20and%20WPA2%20Personal%3F&text=WPA2%20Enterprise%20uses%20IEEE%20802.1,designed%20for%20use%20in%20organizations.))((https://www.andysblog.de/ubiquiti-unifi-wlan-mit-radius-anbindung-an-active-directory-802-1x)) ^ Funktion ^ WPA2-Personal ^ WPA2-Enterprise ^ | Verschlüsselung | AES-CCMP | AES-CCMP | | Authentifizierung | Preshared Key (PSK) | Radius + Zertifikate | | VLAN | keine dynamische Zuteilung | dynamische Zuteilung nach Login | * WPA2-Enterprise bietet Vorteile: keine geteilten Passwörter, Anbindung an AD über Radius möglich, dynamische Zuordung von VLANs -> (werden nur 2 WLAN-Netzwerke benötigt: 1xFirma mit dynamischer VLAN-Zuordung, 1xGast mit WPA2-Personal und allenfalls Vouchers) * Bei einer Lösung mit WPA2-Personal werden für die automatische Zuordnung zu den VLANs 3 WLAN-Netzwerke mit PSKs benötigt * Für WPA2-Enterprise werden aber benötigt: Zertifikate (Zertifikatsstelle) + Radius-Server und AD ===== Backup und Restore ===== ==== Backupvarianten ==== Die Aufgabe besteht darin, die Configs via BackupPC im PULL-Verfahren automatisch zu sichern. === Switches === * Im Knowledge-Base Artikel von Zyxel werden 2 Möglichkeiten erwähnt((https://kb.zyxel.com/KB/searchArticle!gwsViewDetail.action?articleOid=015782&lang=EN#)): 1. die Konfig Via commandline vom Switch aus auf einen tftp Server kopieren -> Problem: geht nur manuell 2. Via snmp auf tftp-Server Problem: Geht nur bei grossen Switches von Zyxel, in der Rafisa sind auch kleine 1920er im Einsatz * In weiterem Artikel((https://community.zyxel.com/en/discussion/3496/gs1900-and-gs1920-config-backup-to-tftp-with-snmp-commands)) wird die Möglichkeit erwähnt, per SSH das Konfig-File zu sichern -> via BackupPC mit einem Prebackup-Script machbar * Es gibt auch die Möglichkeit, das Konfig-File per FTP-Zugriff zu sichern -> via BackupPC mit einem Prebackup-Script machbar. * Mit BackupPC sind also die Möglichkeiten FTP vs. SSH-Backups ^ Backupart ^ Vorgehen ^ Vorteile ^ Nachteile ^ | FTP-Backup | Prebackup-Script: 1. FTP-Login Switch 2. get config (Konfig-File wird in lokales Verzeichnis auf BackupPC gespeichert)\\ BackupPC-Rsync: Rsync dieses Verzeichnisses durch BackupPC | FTP ist stabil und erprobt, keine weiteren Kommandos benötigt | unverschlüsselte Übertragung | | SSH-Backup | Prebackup-Script: 1. SSH-Login Switch 2. show running-config -> Umleitung in ein lokales File auf BackupPC\\ BackupPC-Rsync: Rsync dieses Verzeichnisses durch BackupPC | Verschlüsselte Übertragung möglich | zusätzlicher Befehl auf Switch (show running-config) und Umleitung in ein lokales File -> kompliziert und umständlich, zusätzlicher Output muss aus Konfig-File entfernt werden | === Firewall === * manueller Backup aus dem GUI möglich -> Problem: nicht automatisch * Konfig File ist auf pfSense in der Datei /conf/config.xml gespeichert * Zugriff nur über SSH möglich -> scp (secure copy kann verwendet werden) ^ Backupart ^ Vorgehen ^ Vorteile ^ Nachteile ^ | SSH-Copy | Prebackup-Script: Mit dem Befehl ''scp'' das Konfig-File in ein lokales Verzeichnis auf BackupPC kopieren\\ BackupPC-Rsync: Rsync dieses Verzeichnisses durch BackupPC | Backup ist verschlüsselt | keine | ====== Entscheiden ====== ===== Einrichten der VLANs ===== ==== Namenskonzept Racks und Switches ==== ==== Wahl des Subnetzes ==== ==== Zu realisierende VLANs ==== ==== Zu realisierende LACPs ==== ==== Zu realisierende WLAN-Ports ==== ==== Portbelegung sw-fr-s01-01 ==== ==== Portbelegung sw-fr-s02-02 ==== ==== Portbelegung sw-fr-s03-03 ==== ===== Backup und Restore ===== ==== Backupvariante für Switches und Firewall ==== Für die Switches wird das FTP-Backup gewählt. Das Backup-File kann mit einem bewährten, stabilen Verfahren gesichert werden. Es werden zudem keine zusätzlichen Switch-Befehle oder aufwändige Umleitungen der Ausgabe auf dem Switch in ein lokales File benötigt. Der Nachteil des unverschlüsselten Transfers der Dateien ist nicht schlimm, da sich die FTP-Zugänge aller Switches im gut gesicherten Management-VLAN befinden. Das Copy via FTP wird mit Hilfe eines Prebackup-Scripts realisiert, das das in ein lokales Verzeichnis auf dem BackupPC kopiert. Danach wird es mit dem BackupPC-Rsync in ein BackupPC-Archiv abgelegt. Für die Firewall wird mit einem Prebackup-Script das Backup-File über ''scp'' in eine lokales Verzeichnis kopiert und danach ebenfalls mit BackupPC-Rsync in ein BackupPC-Archiv verschoben. ==== Rahmenbedingungen Backup und Restore ==== ^ Rahmenbedingung ^ Backup IPA ^ Vorschlag produktive Umgebung ^ | Datenmenge | sehr gering, ca. 1MB (3x Textfile für Switches, 1x Textfile für FW) || | Transferzeiten | sehr klein, bei ca. 35MB/sec (Auskunft Team Backup und Restore) || | Aufbewahrungsfrist | bis Ende IPA | 90 Tage (s. SLA Backup und Restore) | | Sicherungsperiodizitäten | jede Nacht zwischen 09:30 und 07:00 (s. SLA Backup und Restore), jede Woche ein Full-Backup, während der Woche inkrimentelle Backups || | Applikatorische Vorgaben | BackupPC mit Pre- und Postbackupscripts || ====== Realisieren ====== ====== Kontrollieren ====== ====== Auswerten ======