IPA 2021
12.05.2021 - 31.05.2021
Kandidat: Sabareeshan Nadeswaran
Kandidat Nadeswaran Sabareeshan Betrieb (=Durchführungsort) Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 T 079 860 02 49 (am besten erreichbar) G 044 533 36 53 M <sabareeshan.n@gmail.com | |
---|---|
Verantwortliche Fachkraft Rüefli Egil Rafisa Informatik GmbH Bernstrasse 88, 8049 / Dietikon T 078 767 84 04 (am besten erreichbar) G 044 533 36 50 M <e.rueefli@rafisa.ch | BerufsbildnerIn/ Lehrfirma Ryser Rolf Stiftung WISS Hohlstrasse 535, 8048 / Zürich T 058 404 42 69 (am besten erreichbar) G 058 404 42 69 M <rolf.rys<er@wiss.ch |
Hauptexperte Spahn Adrian T 078 688 51 52 G 044 744 27 57 M <adi@adi-net.ch | Nebenexperte Gajanthan Vasantharuban T 079 397 64 81 M <gajanthan.vasantharuban@gmail.com |
Detaillierte Aufgabenstellung Titel der Arbeit
Konzipierung, Aufbau und Anbindung des Netzwerkes für einen externen Firmenstandort Ausgangslage
In der Rafisa Informatik GmbH werden zurzeit 50 Lernende der Fachrichtungen Applikationsentwicklung, ICT-Fachmann/Fachfrau, Systemtechnik und Betriebsinformatik zu InformatikerInnen EFZ ausgebildet. Neben dem regulären Ausbildungsbetrieb bietet die Rafisa auch Eignungsabklärungen, Arbeitstrainings, Vorbereitungen für eine Informatik-Ausbildung sowie Bewerbungs- und Job-Coachings an.
Die Firma befindet sich in einer Wachstumsphase, neben dem Hauptort Dietikon kamen als Standorte Bern, Fribourg und Zug hinzu. Die Standorte sind bisher weitgehend autonom, alle verfügen über eine nach eigenen Vorgaben erstellte IT-Infrastruktur. Die Geschäftsleitung hat nun beschlossen, die Netzwerk-Infrastruktur zu vereinheitlichen. Der in Dietikon entwickelte Firmenstandard soll auf die anderen Standorte übertragen werden. Zudem sollen die Standorte über ein Site-to-Site-VPN angebunden werden. Am Beispiel der Rafisa Fribourg wird in dieser IPA die Anbindung vorbereitet.
Detaillierte Aufgabenstellung
In einer Testumgebung soll eine Lösung für die Netzwerk-Infrastruktur des Standortes Fribourg erarbeitet werden. In Vorarbeiten wurden die Bedürfnisse von Fribourg abgeklärt, sie liegen in einem SOLL-Netzplan vor. Firewall und Switches sind so zu konfigurieren, dass sie zum einen dem Firmenstandard genügen und zum anderen den SOLL-Vorgaben aus Fribourg genügen. Es ist zu Überprüfen, ob der Firmenstandard Dietikon einfach übernommen werden kann, oder wo allenfalls Anpassungen nötig sind. Des weiteren soll die Site-To-Site-Anbindung mit einer zweiten Firewall realisiert und getestet werden. Als weitere Aufgaben sind ein WLAN-Netzwerk einzurichten und eine Backuplösung zu realisieren.
Zur Verfügung stehende Hardware und Services
Hardware
1x Dedizierter Rack-Server
1x PC mit BackupPC (Vorarbeit)
2x Firewall pfSense auf APU-Hardware (Die FW-Zürich wird als Vorarbeit mit VLANs gemäss Firmenstandard aufgesetzt)
2x Managed Switch 24-Port 1x Managed Switch 48-Port 1x Managed Switch 8-Port
2x Arbeitsplatzrechner für Doku und Testing (Installation als Vorarbeit) 1x Unify-AP
Services
Proxmox-VE Virtualisierungsplattform (Installation als Vorarbeit) 2x VLAN für den Aufbau der Testumgebung
Folgende Unteraufgaben sind zu lösen (Verweise auf die individuellen Beurteilungskriterien sind mit den Kürzeln I1-I7 gekennzeichnet):
Eine gute Planung setzt voraus, dass der Auftrag zunächst geklärt wird. Dazu sollen Informationen zu mindestens folgenden Bereichen eingeholt werden:
Aufzeigen von Lösungsvarianten
Bei IT-Projekten gibt es oft verschiedene Lösungen zur Erreichung der Projektvorgaben. Zu folgenden Vorgaben sollen Lösungsvarianten gesucht werden:
Entscheidung für Lösungsvariante (I3)
Nachdem Lösungsvarianten erarbeitet worden sind, müssen nun in untenstehenden Bereichen begründete Entscheidungen getroffen werden. Zudem soll ein SOLL-Netzplan der Testumgebung erstellt werden:
SOLL-Planung, welche auf begründeten Entscheidungen über die Lösungsvarianten beruht (s. Aufgabe 2)
SOLL-Netzplan der Testumgebung mit allen beteiligten Systemen (Server, Switches, Arbeitsplatzrechner, Firewalls, WLAN-AP)
Einrichten der Switches (I4)
Die Vorgaben für die Einrichtung der Switches sind:
Einrichten der Firewall (I5)
Die Vorgaben für die Einrichtung der Firewall sind:
Die Vorgaben für die Wireless-Lösung sind:
Backup und Restore (I7)
Als Vorarbeit wird ein PC mit der Backup-Lösung BackupPC eingerichtet. Mit Hilfe von BackupPC sollen die Konfigurationsdateien der Switches und der Firewall gesichert werden.
Dokumentationen
Layer3-Netzplan der Rafisa Netzplan der Testumgebung
Dokumentation der VLANs auf den Switches im Rafisa Wiki (Markdown-Quellcode im Anhang) Dokumentation der VLANs auf der Firewall im Rafisa Wiki (Markdown-Quellcode im Anhang)
Testing
Vorgaben für die Einrichtung der Switches sind erfüllt Vorgaben für die Einrichtung der Firewall sind erfüllt
Vorgaben für die Einrichtung des WLAN-Netzwerkes sind erfüllt Mittel und Methoden
Zyxel Switches pfSense Firewall Linux
BSD
Vorkenntnisse
Zyxel Switches pfSense Firewall Linux
OpenVPN Vorarbeiten
Installation Proxmox VE auf Server Installation der beiden Arbeitsplatz-PCs Kurzberschreibung BackupPC Konfiguration FW Zürich
Neue Lerninhalte
Backup von Config-Dateien realisieren Arbeiten in den letzten 6 Monaten
Mitarbeit im Network-Team Konfiguration von Switches und Firewalls
Installation und Konfiguration von Samba-Servern Konfiguration BackupPC
IPA-Block 10, KW13: | 10.05.2021 – 14.05.2021 |
---|---|
IPA-Durchführung: | 10.05.2021 – 11.06.2021 |
Einreichung bis: | 12.04.2021 |
Die Prüfungsexperten bilden zusammen mit dem Fachverantwortlichen der Ausbildung und dem Kunden den Auftraggeber. Zusammen sind sie für die Formulierung der Aufgabenstellung und Benotung der Projektarbeit zuständig.
Ausbildner: Rolf Ryser
Lernende: Sabareeshan Nadeswaran
Projektleiter: Sabareeshan Nadeswaran Auftraggeber, Kunde: Egil Rüefli
Der Projektleiter ist für die komplette Realisierung und Dokumentation der IPA zuständig Der Auftraggeber ist für die Formulierung des Auftrages zuständig.
Die Realisierung der IPA liegt allein in der Verantwortung von Sabareeshan Nadeswaran.
Abbildung 1: Projektorganigramm
Dieses Projekt wird nach der Projektmethode IPERKA realisiert. Dabei repräsentiert jeder dieser Buchstaben einen Meilenstein. I steht für Informieren. Dort werden alle notwendigen Informationen zusammengetragen. P ist Planen. Dort werden Informationen ausgewertet und mögliche Lösungen vorgeschlagen für das Erreichen des Projektziels. Beim E, also dem Entscheiden werden von den Vergleichen, die sinnvollste Lösung gewählt. Am besten kann diese Lösung auch begründet werden. R steht für Realisieren. Dort werden die Lösungen in die Tat umgesetzt. Zur Realisation gehört auch das Dokumentieren der Umsetzung. Im Meilenstein K, welche für Kontrollieren steht, wird die Realisation getestet in verschiedenen Ebenen. Der letzte Meilenstein ist das Auswerten, daher der Buchstabe bei Iperka. Dort werden die Tests ausgewertet, aber auch das ganze Projekt reflektiert. [1]
Die Arbeitsergebnisse und alle relevanten Dokumente werden in One Drive gespeichert. Die Ordner sind nach Arbeitstagen sortiert. Die Konfigurationsfiles der Switches und der Firewall werden am Ende des Tages in den entsprechenden Ordner abgelegt. Der Ubuntu Server wird auf einer externen Festplatte gesichert. Die Festplatte wird nach der Sicherung des jeweiligen Tages bei der VF abgelegt.
Backup der VM für den Unify Controller auf dem Proxmox-Server: externe Festplatte wird auf dem Proxmoxserver /usbmnt gemountet. In der Weboberfläche wird /usbmnt als Backuptorage hinzugefügt. Ab dem Tag der Realisierung wird das Backup manuell durchgeführt.
Zeitplan Projekt: IPA Standortanbindung Kandidat: Sabareeshan Nadeswaran Zeitraum: 12.05.21 - 31.05.21 Soll-Zeit: Ist-Zeit: Meilenstein: | 12.05.21 | 14.05.21 | 17.05.21 | 19.05.21 | 20.05.21 | 21.05.21 | 26.05.21 | 27.05.21 | 28.05.21 | 31.05.21 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
10:00-14:00 | 15:00-19:00 | 09:00-14:00 | 15:00-18:00 | 10:00-14:00 | 13:00-19:00 | 10:00-14:00 | 15:00-19:00 | 10:00-14:00 | 15:00-19:00 | 09:00-14:00 | 15:00-18:00 | 10:00-14:00 | 15:00-19:00 | 10:00-14:00 | 15:00-19:00 | 10:00-14:00 | 15:00-19:00 | 10:00-14:00 | 15:00-19:00 | |
Vorbereitung und Dokumentation | ||||||||||||||||||||
Zeitplan aufgrund der Aufgabenstellung erstellen | ||||||||||||||||||||
Dokumentieren | ||||||||||||||||||||
Informieren | ||||||||||||||||||||
Erfassung der zur Verfügung gestellten Hardware | ||||||||||||||||||||
Erfassung der zur Verfügung gestellten Services | ||||||||||||||||||||
Beschreibung der aufzusetzenden Services | ||||||||||||||||||||
Beschreibung der Firmenstandards und Namenskonzept | ||||||||||||||||||||
Darstellung und Analyse des zugesendeten Planes aus Fribourg | ||||||||||||||||||||
Einbettung der Testumgebung in L3-Netzplan des Rafisa Netzwerkes | ||||||||||||||||||||
Planen | ||||||||||||||||||||
Lösungsvariante für das Einrichten der VLANs | ||||||||||||||||||||
Lösungsvariante für das Einrichten der FW | ||||||||||||||||||||
Lösungsvariante für das Einrichten der Switches | ||||||||||||||||||||
Lösungsvariante für das Einrichten der WLAN-Netzwerke | ||||||||||||||||||||
Lösungsvariante für Backup und Restore | ||||||||||||||||||||
Netzplan Soll-Zustand Testumgebung | ||||||||||||||||||||
Entscheiden | ||||||||||||||||||||
Entscheid für das Einrichten der VLANs | ||||||||||||||||||||
Entscheid für das Einrichten der FW | ||||||||||||||||||||
Entscheid für das Einrichten der Switches | ||||||||||||||||||||
Eintscheid für das Einrichten der WLAN-Netzwerke | ||||||||||||||||||||
Entscheid für Backup und Restore | ||||||||||||||||||||
Arbeitspakete erstellen | ||||||||||||||||||||
Realisieren | ||||||||||||||||||||
Switches einrichten | ||||||||||||||||||||
Firewall einrichten | ||||||||||||||||||||
Site to Site VPN konfigurieren | ||||||||||||||||||||
Konfiguration BackupPC | ||||||||||||||||||||
Basisinstallation Ubuntu Server | ||||||||||||||||||||
Unify-Controller + Access-Point einrichten | ||||||||||||||||||||
Dokumentation Rafisa Wiki | ||||||||||||||||||||
Kontrollieren | ||||||||||||||||||||
Testkonzept erstellen | ||||||||||||||||||||
Tests durchführen | ||||||||||||||||||||
Auswerten | ||||||||||||||||||||
Testszenario Auswerten | ||||||||||||||||||||
Auswerten/Dokumentation der Ergebnisse/Reflexeion | ||||||||||||||||||||
Reserve/Ergänzen von fehlenden Dokumentationen/Versenden der Arbeit | ||||||||||||||||||||
1. Expertenbesuch | ||||||||||||||||||||
2. Expertenbesuch |
TAG 01 | |
---|---|
Datum | Mittwoch, 12.05.2021 |
Arbeitszeit | 10:00-19:00 |
Ausgeführte Aufgaben | Folgende Kapitel wurden in der Doku erfasst: Erfassung der zur Verfügung gestellten Hardware Erfassung der zur Verfügung gestellten Services Erfassung der aufzusetzenden Services Beschreibung der Firmenstandards und Namenskonzept Darstellung und Analyse des IST-Zustandes in Fribourg Vorgehensmethode beschrieben IPERKA beschrieben und in eigenen Worten erläutert. Arbeitsprotokoll Tag 01 erfasst Zeitplan und Firmenstandards an Hauptexperten und Nebenexperten via Mail gesendet. Zeitplan Tag 1 mit IST-Zeit ausgefüllt. Beide Dokumente sind hochgeladen in entsprechenden Tagesordner. |
Aufgetretene Probleme | Beim Beschreiben des BackupPCs hatte ich Probleme das Wort deduplizieren im Kontext mit dem Backupvorgang zu verstehen. |
Problemlösung | Ich habe meine verantwortliche Fachkraft ersucht und Ihn gefragt, was deduplizieren im Zusammenhang mit BackupPC ist |
Reflexion | Ich habe verstanden, wie der BackupPC seinen Vorgang durchführt und verstehe somit auch wieso er so effizient ist für einen Backup-Server. |
Wissensbeschaffung | __https:%%//%%www.digitec.ch/de/s1/product/zyxel-gs2200-24-__ __24ports-switch-233517__ __https:%%//%%icecat.biz/de/p/zyxel/gs2200-__ __48/network+switches-gs2200-48-8157611.html__ __https:%%//%%www.digitec.ch/de/s1/product/ubiquiti-unifi-ap-__ __ac-pro-1300mbits-450mbits-access-point-5620972__ __https:%%//%%www.varia-store.com/de/produkt/103302-pc-__ __engines-apu4d2-systemboard-4x-lan-2-gb-ram.html__ __https:%%//%%www.pcengines.ch/apu4d2.htm__ |
__https:%%//%%help.ui.com/hc/en-us/articles/360050130353-__ __UniFi-UniFi-Overview__ __https:%%//%%www.proxmox.com/de/proxmox-ve/funktionen__ | |
---|---|
Beanspruchte Hilfe | Die VF hat mir nähere Infos über den Begriff deduplizieren erklärt. |
Zeitplan eingehalten | Ja |
Woran arbeite ich am nächsten Tag weiter | Dokument von Tag 01 in Tag 02 verschieben und erst dann öffnen bzw. weiterarbeiten. L3-Plan Ist-Zustand Rafisa Informatik GmbH Teilnahme ersten Expertenbesuch um 09.30 via Teams |
Meilenstein | Ich konnte den Meilenstein Informieren erreichen. |
TAG 02 | |
---|---|
Datum | Freitag, 14.05.2021 |
Arbeitszeit | 09:00-18:00 |
Ausgeführte Aufgaben | 1. Epertenbesuch mit VF, Haupt- und Nebenexperte via Teams um 09:30 Befragen nach Wohlergehen Zusammenfassende Dokumentation erklärt bekommen von Hauptexperte Fragen bezüglich Anpassung Aufgabenstellung, Quellenverzeichnis, Einfügen des Firmenstandards Termin für Demo wird am 2.Besuch festgelegt Folgende Kapitel erfasst Portbelegung IST-Zustand hinzugefügt. Neuer Abschnitt im Beschreiben der zu aufzusetzenden Services Plan der VLAN Planen der WLAN-Netzwerk Planen der Switches Planen der FW Tag 02 Lernjournal erfasst |
Aufgetretene Probleme | Beim Planen der LACP ist mir nicht klar geworden wie ich die Planung gestalterisch im Bericht darstellen sollte. |
Problemlösung | Ich habe alle Infos über LACP in Bezug zu meiner Arbeit zusammengetragen und habe diese am VF gezeigt und Ihn um Rat gefragt. |
Reflexion | Als ich beim Planen der FW-Rules angekommen war, ist mir realisiert worden, dass ich die Beschreibung von FW Regeln, deren Funktionsweise auch im Kapitel 7.3.1 erfassen kann. |
Wissensbeschaffung | Wissen von VF beansprucht. __https:%%//%%docs.netgate.com/pfsense/en/latest/firewall/rule-__ __methodology.html__ |
Beanspruchte Hilfe | Besprochen mit VF was wo kommt von Planen Entscheiden |
Zeitplan eingehalten | Ja |
---|---|
Woran arbeite ich am nächsten Tag weiter | Dokumente unterschreiben von Pkorg und Mail an HEX, NEX,VF Dokumente von Tag 02 in Tag 03 kopieren Kapitel Planen Backup und Restore Kapitel Soll Zustand Testumgebung |
TAG 03 | |
---|---|
Datum | Montag, 17.05.2021 |
Arbeitszeit | 10:00-19:00 |
Ausgeführte Aufgaben | Folgende Kapitel erfasst in der Doku VLAN Konzept Zu realisierende WLAN-Ports Zu realisierende LACP Zu realisierende Switches Portbelegung sw-fr-s01-01 Portbelegung sw-fr-s02-01 Portbelegung sw-fr-s03-01 Arbeitspakete verfeinert sw-fr-s03-01 realisiert VLANs erstellt Portzuweisung gemäss Portbelegung T2 LACP Loopguard In MGMT zugewiesen gemäss PLAN Sw-fr-s02-01 realisiert Sw-fr-s01-01 realisiert Fw-fr-308-01 realisiert |
Aufgetretene Probleme | Während der Realisierung sw-fr-s01-01 fiel mir auf, dass die Portbelegung komische Lücken hat. |
Problemlösung | Portbelegung angepasst. |
Reflexion | Ich konnte einen neuen LACP entdecken und habe somit die Portbelegung ebenfalls angepasst Ich habe bemerkt dass ich lange Zeit brauchen werde beim Planen, daher habe ich meinen Fokus aufs Realisieren gelegt. |
Wissensbeschaffung | Wissen von VF beansprucht. |
Beanspruchte Hilfe | Ich habe bei der VF nachgefragt ob noch ein zusätzlicher LACP vorhanden ist bzw. wollte bestätigen lassen. |
Zeitplan eingehalten | Nein Ich habe zuhause weitergearbeitet damit ich einigermassen im Zeitplan noch bin. |
Woran arbeite am nächsten Tag weiter | Switches einrichten |
Meilenstein | Ich konnte den Meilenstein Entscheiden nicht erreichen das ich viel Zeit mit dem Planen verbrachte hatte. |
---|
TAG 04 | |
---|---|
Datum | Mittwoch, 19.05.2021 |
Arbeitszeit | 10:00-19:00 |
Ausgeführte Aufgaben | Einrichten der Switches Arbeitspakete angefangen fw-fr-s01-01 angefangen zu realisieren Dokumentation erweitert oder ergänzt. |
Aufgetretene Probleme | Ich habe nochmals die Switches überprüft und neben der neuen LACPs vom Vortrag ist mir aufgefallen, dass auf allen Switches vier Ports noch unbelegt ist. |
Problemlösung | Portbelegung nochmals angepasst |
Reflexion | Ich konnte somit alle Ports auf allen Switches noch belegen, die Realisation steht noch da ich zuerst die FW vollständig konfigurieren möchte. |
Wissensbeschaffung | Keine Quellen verwendet. |
Beanspruchte Hilfe | Die VF hat mir erklärt das die vier Ports standardmässig noch laufen, erst wenn die vier Ports mit den SFB Modulkabel angeschlossen sind werden, diese vier deaktiviert und die vier Modul-Ports aktiviert. |
Zeitplan eingehalten | Nein |
Woran arbeite am nächsten Tag weiter | Dokumentaiton überarbeiten Entscheid für Rules setzen Planen der Wlan-Netzwerke beschreiben Mail an die VF, HEX,NEX mit unterschriebene Dokumente. |
TAG 05 | |
---|---|
Datum | Donnerstag, 20.05.2021 |
Arbeitszeit | 10:00-19:00 |
Ausgeführte Aufgaben | Dokumentation ergänzt Lernjournal nachgeführt von Tag 04 und Tag 05 Entscheid für WLAN-Netzwerke Entscheid für das Setzten der Rules WAN-Interfaces anpassen und FW an sw-fr-s01-01 anschliessen. Mail an die VF,HEX,VF die Dokumente zur Unterschrift |
Aufgetretene Probleme | Ich konnte die Rahmenbedingungen nicht ganz ausfüllen für Entscheid Backup und Restore |
Problemlösung | Ich habe nochmals Input über das Planen und Entscheiden von der VF geholt. |
Reflexion | Die Transferzeiten für die Konfigurationsdateien hat die VF von den produktiven Switches geholt. |
Wissensbeschaffung | Wissen von VF beanspurcht |
Beanspruchte Hilfe | Ja, ich holte mir Inputs von der VF |
Zeitplan eingehalten | Nein. |
Woran arbeite am nächsten Tag weiter | Inhalte von Tag 05 zu Tag 06 kopieren und umbenennen 2.Expertenbesuch via Teams 09:30 |
TAG 06 | |
---|---|
Datum | Freitag, 21.05.2021 |
Arbeitszeit | 09:00-18:00 |
Ausgeführte Aufgaben | 2.Expertenbesuch via Teams ca.30min WAN statisch gesetzt von fw-zh-308-01 Site to Site eingerichtet CA erstellt Server und Client Zertifikat erstellt OpenVPN Server eingerichtet Rules auf folgende Interfaces erstellt OpenVPN WAN Client Specific Overrides angepasst Export/Import Server to Client Rules OPNVPN konfiguriert Lernjournal Tag 06 nachgeführt Zeitplan Tag 06 mit IST-Zeit eingetragen |
Aufgetretene Probleme | Für die Demo-Vorbereitung hatte WAN nicht funktioniert und kam somit ins Internet und gleichzeitig zu den Switches. |
Problemlösung | Netzwerkkabel hatte Wackelkontakt |
Reflexion | Ich konnte am Experten trotzdem noch zeigen wie ich auf die Switches komme Experte hatte mir noch einen Ratschlag mitgeteilt bei der Kurzfassung ist das Ergebnis nicht das Endresultat des Projekt sondern der letzte Stand von Tag 10 |
Wissensbeschaffung | Ich hatte einen guten Ratschlag vom Nebenexperten erhalten. Auch habe ich Input von meiner VF geholt |
Beanspruchte Hilfe | Beim Ping Test hatte mir die VF mitgeteilt das ich den Ping Test auf der FW selber durchführen sollte. |
Zeitplan eingehalten | Nein |
Woran arbeite ich am nächsten Tag weiter | Kopieren der Daten von Tag 06 auf Tag 07 BKP Server einrichten |
TAG 07 | |
---|---|
Datum | Mittwoch, 26.05.2021 |
Arbeitszeit | 10:00-19:00 |
Ausgeführte Aufgaben | Vorarbeit geleistet am 25.05.21 Ordner und Unterordner erstellt für BackupPC Backup eingerichtet für fw-fr-s01-01 und sw-fr-s01-01 VM uni-fr-205-01 erstellt und Basisinstallation Ubuntu 20.04 LTS durchgeführt. Backup eingerichtet für sw-fr-s02-01 und sw-fr- s03-01 Installation und Einrichtung Unifi-Controller Terminvorschlagformular ausgefüllt in pkorg für HEX Lernjournal Tag 7 nachgeführt. |
Aufgetretene Probleme | Als ich das Backup einrichten wollte für fw-fr-s01-01 hatte ich via SSH diesen von bkp-fr-308-01 erreichen, konnte ich diesen aber nicht erreichen. |
Problemlösung | Bei der FW wurde dieser dekativiert. PFsene deaktiviert diesen standardmässig, ich habe diesen aktiviert. |
Reflexion | Ich habe meine Arbeitspaket für die FW nochmals angepasst. |
Wissensbeschaffung | Die VF hat mir scp gezeigt für Backup von fw-fr-s01-01 Link später einfügen. |
Beanspruchte Hilfe | Die VF um Rat gefragt. |
Zeitplan eingehalten | Ja |
Woran arbeite ich am nächsten Tag weiter | Kopieren von Tag 7 in 8 und umbenennen und mit diesen dann weiterarbeiten Backup kontrollieren bzw. durchführen von uni-fr-205-01 DHCP Server wird im VLAN01_MGMT kurzfristig in Betrieb genommen um den AP einzubinden. |
TAG 08 | |
---|---|
Datum | Donnerstag, 27.05.2021 |
Arbeitszeit | 10:00-19:00 |
Ausgeführte Aufgaben | Lernjournal nachgeführt von Tag 07 Manuelles Backup von Uni-fr-205-01 Konfiguration von uni-fr-205-01 inkl. Einrichten der WLAN-Netzwerke Testsznarios erstellt inkl. Testkonzept Testfall 1 bis 3 durchgeführt und dabei diese ausgewertet. |
Aufgetretene Probleme | Client vom VLAN21 konnte keine anderen VLANs erreichen siehe Testfall Nr.1 |
Problemlösung | Folgende Rule ergänzt bei VLAN21_CLEMPLE-Interface: VLAN21_CLEMPLE any pass to any |
Reflexion | Dadurch wurde mir die Funktionsweise der Rules nochmals von meiner VF erklärt vor allem mit Inbound Outbound. Durch diesen Testfall aber durch meine VF wurde mir klar, dass ich alle VLANs in der Berechtigungsmatrix durchtesten muss. |
Wissensbeschaffung | Wissen von VF beansprucht |
Beanspruchte Hilfe | Die VF um Rat gefragt |
Zeitplan eingehalten | Ja |
Woran arbeite ich am nächsten Tag weiter | Dokumente in Tag 08 OneDrive hochladen Lernjournal vollständig nachführen Manulles Backup von Uni-fr-205-01 Testfälle von 3 bis 5 |
TAG 09 | |
---|---|
Datum | Freitag, 28.05.2021 |
Arbeitszeit | 10:00-19:00 |
Ausgeführte Aufgaben | Lernjournal vollständig nachgeführt von Tag 08 Manuelles backup von Uni-fr-205 Testfälle abgearbeitet von 4 bis 6 Ausformulierung der Realisierungsschritte Tag 10 vorbereitet. |
Aufgetretene Probleme | Ich habe das Manuelle Backup vergessen für Uni-fr-205- 01 |
Problemlösung | Outlook Termin als Erinnerung setzen |
Reflexion | Bei der nächsten Arbeite ziehe auch Planungstool mit ein. Der Meilenstein Auswerten am Tag 9 konnte eingehalten werden. |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Keine Hilfe eingeholte, habe aber privat noch zwei Stunden am Bericht gearbeitet. |
Zeitplan eingehalten | Ja |
Woran arbeite ich am nächsten Tag weiter | Bericht egänzen |
TAG 10 | |
---|---|
Datum | Montag, 31.05.2021 |
Arbeitszeit | 09:00-18:00 |
Ausgeführte Aufgaben | Glossar ergänzt Kurzfassung geschrieben Auswertung geschrieben Formatierungen überprüft und durchgelesen der Dokumentation |
Aufgetretene Probleme | Zeit für das Kapitel Auswertung wurde sehr knapp. |
Problemlösung | Kapitel Auswertung wurde abgekürzt geschrieben |
Reflexion | Für Kurzfassung konnte auf die Tipps des Experten zurückgegriffen werden. |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Hilfe beim Kürzen der Auswertung und beim Abschliessen des Berichts. |
Zeitplan eingehalten | Ja |
Ausgangspunkt der vorliegenden Arbeit war ein SOLL-Plan des Netzwerkes für den Rafisa-Standort Fribourg. Dieser SOLL-Plan wurde zunächst analysiert, verfeinert und danach mit den Standardanforderungen für Netzwerk der Rafisa verglichen und wo nötig angepasst. Die vorgeschlagene Lösung für Fribourg umfasste die Einrichtung von Standard-VLANs auf drei Switches und auf der Firewall. Zusätzlich sollte ein WLAN-Netzwerk und eine Site-to-Site-VPN-Lösung eingerichtet werden. Für das Backup der Konfigurationsfiles der Netzwerkgeräte waren Scripts zu schreiben.
Die VLANs konnten alle entsprechend den Vorgaben eingerichtet werden. Mit Firewall-Rules wurden die Zugriffsrechte für die VLANs festgelegt. Das Site-to-Site VPN zwischen der Firewall Fribourg und der als Vorarbeit eingerichteten Firewall Zürich wurde mit dem pfSense-Modul OpenVPN realisiert. Auf dem WLAN-Controller wurden drei WLAN-Netzwerke mit separaten VLAN-Zugängen eingerichtet. Für das Backup wurden zwei Bash-Prebackup-Scripts geschrieben, die danach in die installierte Backup-Lösung BackupPC eingebunden wurden.
Als Abschluss wurde die gesamte Lösung getestet. Die Tests verliefen bis auf einen alle wie erwartet. Beim Testen der Zugriffsmatrix für die VLANs zeigte sich, dass auf der Firewall eine Allow-Rule vergessen worden war. Nach dem Anlegen dieser Rule konnte auch der letzte Test erfolgreich abgeschlossen werden.
Die Hardwareinformationen wurden mit dmidecode, lspci und fdisk gefunden. In Windows wurden die HW-Informationen mit Hilfe der Systeminformation gelesen.
Gerät | Modellbezeichnung | CPU | Memory | HD | NW- Adapter |
---|---|---|---|---|---|
Proxmox-Server | Dell Power Edge R520 | 2x Intel Xeon E5- 2407 2.2 GHz | 64 GB DDR3 | 1 TB Sata Raid 5 | 2 BCM5720 Gigabit Ethernet |
Backup-Server | HP ProDesk 600 | i5-4570 3.2 GHz | 6GB DDR3 | sda:500 GB SSD sdb: 2TB Sata | Intel I217- LM Gigabit Ethernet |
Arbeitsplatzrechner 1 pc-zh-308-01 | Dell XPS | i5-2500 3.30 GHz | 12 GB DDR3 | Hitachi Satadisk 512 GB | Intel 82579V Gigabit Network Adapter |
nb-zh-308-01 Arbeitsplatzrechner 2 | Lenovo T410 | i5-M540 2.5 Ghz | 4GB DDR3 | Samsung SSD 250 GB | Intel 82577LM Gigabit Network Adapter |
---|
Tabelle 1: Hardware Server und PCs
Gerät | Modellbezeichnung | Übertragungsrate | Anzahl Ports | Firmware |
---|---|---|---|---|
Switch 01 | GS2200-24 | 1000 Mbit/s | 24 | 4.00 |
Switch 02 | GS2200-24 | 1000 Mbit/s | 24 | 4.00 |
Switch 03 | GS2200-48 | 1000 Mbit/s | 48 | 3.80 |
Switch 04 | GS2210-10 | 1000 Mbit/s | 10 | 4.00 |
Tabelle 2: Hardware Switches
Bei den Switches handelt sich um fully-managebare Zyxel-Switches. Sie sind sowohl über CLI als auch über ein Webinterface managebar. Zusätzlich zu den geforderten Informationen findet sich in der Spalte Firmware die aktuelle Firmwareversion der Switches. Die Informationen zu den Switches wurden auf Internetseiten gefunden [2] [3]
Die Informationen zur Hardware von dem Access-Point wurden auf Internetseiten gefunden. [4]
Gerät | Modellbezeichnung | Anzahl Ports | WLAN- Standards | Frequenzbänder | Verschlüsselungsmöglichkeiten |
---|---|---|---|---|---|
Access- Point | UniFI AP AC-PRO | 2 | Wi-Fi 2 /802.11a, Wi-Fi 5/802.11ac, Wi-Fi 3/ 802.11g, Wi-FI 4/802.11n | 2.4 GHZ , 5.0 GHZ | WPA-PSK, WPA2-PSK, WPA- EAP, WPA-EAP, WPA2- Enterprise |
Tabelle 3: Hardware Access Point
Gerät | Input | Output |
---|---|---|
Powerline POE Adapter | 100 – 240V | 48V |
Die Informationen zu den HW-Spezifikationen der Firewall wurden im Internet gefunden [5] [6]
Gerät | Modellbezeichnung | CPU | Memory | Festplatte | Netzwerk- Interfaces | Übertragungsrate |
---|---|---|---|---|---|---|
Firewall | apu4d2 | AMD Emmbed G Series | 2 GB DDR3- 1333 DRAM | 16 GB SSD | igb0 igb1 igb2 igb3 | 1000Mbit/s |
Tabelle 4: Hardware Firewall
Proxmox VE ist eine Virtualisierungsplattform, welche auf Debian basiert. Die Software ist ein Open- Source Produkt. Die Virtualisierung kann auf zwei Technologien umgesetzt werden. Zu einem sind das KVM und zum anderen LXC. Proxmox lässt sich via Webinterface verwalten. Eines der Vorteile von Proxmox ist die Live Migration. Somit ist es möglich bei Proxmox während der Produktion die VM von einer Platte zur anderen Platte zu migrieren. Ein weiterer Pluspunkt ist die Backupfunktion beim Proxmox. Es ist möglich diverse Speichermediums als Storage einzubinden. [7]
In der Rafisa kommt die Backuplösung BackupPC zum Einsatz. Dabei handelt es sich um eine freie Disk-zu-Disk Backup-Suite. Als Übertragungsarten stehen smb für das Backup von Windows-Shares, sowie für die Sicherung der Daten das rsync-Protokoll. Zusätzlich lassen sich die Funktionalitäten mit Pre- und Post-Backupscripts ausführen. Zu den Main Features gehören
Auf Anfrage wurde vom Team SRB ein BackupPCServer zur Verfügung gestellt und mit der Basisinstallation BackupPC. Gemäss der SLA#001 Backup und Restore v.01 [8] ist ersichtlich, dass folgende Backuparten zur Verfügung stehen:
In der Planung müssen folgende Punkte berücksichtigt werden: Festlegen von Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten
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.
Folgende Mainfeatures sind vorhanden:
In der Planung soll eine Lösung für die Konfiguration des Rules und die Möglichkeiten zur Realisierung der VPN-Site-to-Site-Anbindung erarbeitet werden.
Der UniFi Network Controller ist eine Java-Software, welche erlaubt, die Unifi Geräte über ein Webinterface zu verwalten. Der Controller kann auf dem Unifi Cloud Key gehostet oder auch als Server in Linux, Windows, macOS eingerichtet werden. [9]
Es handelt sich um einen passiven Controller: Die Access-Points werden durch den Controller konfiguriert, danach laufen sie selbständig. Der Controller kann auch abgeschaltet werden, ausser man nutzt die Guest-Portal-Funktion.
Der Vorteil eines passiven Controllers besteht darin, dass die AP's weiterlaufen, selbst wenn der Controller ausgeschaltet wird (kein Single Point of Failure). Als Nachteil kann erwähnt werden, dass
z.B. Informationen über die Funkeigenschaften der Accesspoints und der verbundenen Clients nicht zur Steuerung genutzt werden können. So sucht der AP beim Start z.B. einen geeigneten Funkkanal und bleibt auf diesem. So ist keine Optimierung durch den Controller möglich.
Hauptfeatures des Controllers sind:
In diesem Kapitel werden die firmenspezifischen Vorgaben über das Netzwerkkonzept und Namenskonzept der Firma beschrieben. Diese Vorgaben sind ebenfalls im Anhang enthalten.
Alle Standorte erhalten ein /24 Netz aus dem grösseren privaten Netz 172.16/12, dh. 172.16.0.0/16 bis 172.31.0.0/16. Die VLANs werden dann in die jeweiligen /24-Subnetze unterteilt, also z.B.
172.16.1.0/24, 172.16.2.0/24 usw.
Netzadressbereich | CIDR-Notation | Verkürzte CIDR- Notation | Anzahl Adressen | Anzahl Netze gemäß Netzklasse (historisch) |
---|---|---|---|---|
172.16.0.0 bis 172.31.255.255 | 172.16.0.0/12 | 172.16/12 | 220 = 1.048.576 | Klasse B: 16 private Netze mit jeweils 65.536 Adressen; 172.16.0.0/16 bis 172.31.0.0/16 |
7.4.2.1 zh.rafisa.org - 172.16.0.0/12
VLAN Name | Kürzel | Funktion | VID | IP-Adresse | FW-Interface-Name | DHCP- Server |
---|---|---|---|---|---|---|
VLAN Management | 01 | |||||
VLAN01 | MGMT | Management | 01 | 172.16.1.0/24 | VLAN01_MGMT | ❌ |
VLAN Server | 10-19 | |||||
VLAN10 | SRVAUTH | Server Authentifizier ung | 10 | 172.16.10.0/24 | VLAN10_SRVAUTH | ❌ |
VLAN14 | SRVEMPL | Server Ausbildner | 14 | 172.16.14.0/24 | VLAN14_SRVEMPL | ❌ |
VLAN15 | SRVLEARN | Server Lernende | 15 | 172.16.15.0/24 | VLAN15_SRVLEARN | ❌ |
VLAN Clients | 20-29 | |||||
VLAN21 | CLEMPL | Clients Ausbildner | 21 | 172.16.21.0/24 | VLAN21_CLEMPL | ✔️ |
VLAN22 | CLLEARN | Clients Lernende | 22 | 172.16.22.0/24 | VLAN22_CLLEARN | ✔️ |
VLAN23 | CLGUEST | Clients Guest (WLAN) | 23 | 172.16.23.0/24 | VLAN23_CLGUEST | ✔️ |
VLAN Drucker | 40 | |||||
VLAN40 | LP | Drucker | 40 | 172.16.40.0/24 | VLAN40_LP | ❌ |
VLAN Labor | 50-59 | |||||
VLAN51 | LAB01 | Labor 01 | 51 | 172.16.51.0/24 | VLAN51_LAB01 | ✔️ |
VLAN52 | LAB02 | Labor 02 | 52 | 172.16.52.0/24 | VLAN52_LAB02 | ✔️ |
VLAN53 | LAB03 | Labor 03 | 53 | 172.16.53.0/24 | VLAN53_LAB03 | ✔️ |
VLAN54 | LAB04 | Labor 04 | 54 | 172.16.54.0/24 | VLAN54_LAB04 | ✔️ |
VLAN55 | LAB05 | Labor 05 | 55 | 172.16.55.0/24 | VLAN55_LAB05 | ✔️ |
In der Tabelle oben sind alle VLAN’s aufgelistet, welche das Netzwerk-Team immer auf der FW und auf den Switches standardmässig konfiguriert. Der Interface-Name bildet sich aus dem VLAN Namen und dem Kürzel. Im VLAN01_MGMT sind die Switches oder die FW selber enthalten. Auch der unifiController und der Backup-Server sind dort inbegriffen. Wie der Name schon sagt ist im VLAN Server alle virtuellen Server enthalten. VLAN Clients ist selbsterklärend. Alle Drucker sind im VLAN40_LP vorhanden. Alle Labors sind im VLAN Labor. Es werden alle Geräte ausser welche im VLAN Clients und VLAN Labor sind, mit einer statischen IPv4 Adresse vergeben. Der Rest erhält seine Netzwerkkonfigurationen via DHCP-Server von der FW. Dieser Firmenstandard ist vom September 2020. Auf diesem baut sich meine IPA auf, selbst wenn sich die Norm sich laufend ändert.
Die Matrix wird Zeile nach Spalte gelesen (Zugriff von Zeile nach Spalte erlaubt/nicht erlaubt)
VLAN | 01 | 10 | 14 | 15 | 21 | 22 | 23 | 40 | 51 | 52 | 53 | 54 | 55 | WAN | VPN- EXT |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
01 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
10 | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ |
14 | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
15 | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
21 | ❌ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
22 | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
23 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
40 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
51 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
52 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ✔️ | ❌ |
53 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ✔️ | ❌ |
54 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ✔️ | ❌ |
55 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ | ❌ |
WAN | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
VPN- EXT | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ |
Das VLAN01_MGMT hat überall Zugriff. VLAN10_SRVAUTH darf nach draussen und zu den VPN- Server der externen Standorte. Die Ausbildner haben Zugang zu allen anderen VLANs ausser VLAN01_MGMT. Die Lernende haben Zugang nach draussen, in VLAN10_SRVAUTH, VLAN15_SRVLEARN und dem VLAN40_LP.
Die folgende Tabelle zeigt die IP-Zuteilung der Geräte am Standort Dietikon. Sie dient als Ausgangspunkt für das Erstellen des L3-Plans im Kapitel 7.6.
VLAN | Kürzel/Hostname | IP-Adresse | Funktion | Ort |
---|---|---|---|---|
VLAN Management | ||||
VLAN01 | MGMT | 172.16.1.0/24 | Management | |
fw-zh-ruga-01 | 172.16.1.1 | Firewall | ||
prox-zh-ruga-01 | 172.16.1.21 | Proxmox VE Node | ||
prox-zh-ruga-02 | 172.16.1.22 | Proxmox VE Node | ||
uni-zh-ruga-01 | 172.16.1.30 | Unifi Controller | ||
ap-zh-01 | 172.16.1.31 | Unifi Accesspoint | ||
ap-zh-02 | 172.16.1.32 | Unifi Accesspoint | ||
ap-zh-03 | 172.16.1.33 | Unifi Accesspoint | ||
ap-zh-04 | 172.16.1.34 | Unifi Accesspoint | ||
ap-zh-05 | 172.16.1.35 | Unifi Accesspoint | ||
bkp-zh-r02b-01 | 172.16.1.100 | Backup-Server zh.rafisa.org | ||
VLAN Authentifizierung | ||||
VLAN10 | AUTH | 172.16.10.0/24 | ||
dc-zh-ruga-02 | 172.16.10.22 | DC1 zh.rafisa.org | ||
dc-zh-ruga-04 | 172.16.10.24 | DC2 zh.rafisa.org | ||
VLAN Server Ausbildner | ||||
VLAN14 | SRVEMPL | 172.16.14.0/24 | ||
fs-zh-ruga-01 | 172.16.14.21 | Fileserver zh.rafisa.org | ||
VLAN Server Lernende | ||||
VLAN15 | SRVLEARN | 172.16.15.0/24 | ||
fs-zh-ruga-01 | 172.16.15.21 | Fileserver zh.rafisa.org |
Benutzernamen setzen sich zusammen aus dem ersten Buchstaben des Vornamens plus dem Nachnamen. Sollten sich bei neuen Nutzern gleichlautende Benutzernamen ergeben, wird die Anzahl Buchstaben des Vornamenkürzels um 1 erhöht. Bei identischen Vor- und Nachnamen wird das Benutzerkürzel um eine fortlaufende Nummer, beginnend bei 01 ergänzt.
Beispiele:
Geräte
Der Gerätename setzt sich zusammen aus einem Kürzel für die Funktion, dem Kürzel für den physikalischen Standort sowie einer fortlaufenden Nummer, beginnend bei 01.
Beispiele:
Kürzel für die Funktionsbezeichnungen
Kürzel | Funktion |
---|---|
bkp | Backup Server |
dc | Domain Controller |
ds | Deployment Server |
fw | Firewall |
nb | Notebook |
pc | PC |
prox | Proxmox VE Server |
sw | Switch |
Physikalische Standorte
Der physikalische Standort setzt sich zusammen aus dem Kürzel für den Standort sowie einer internen Raumangabe. Bei Geräten, welche in einem Rack stehen, werden anstelle der Raumangabe das Kürzel für das Rack angegeben.
Beispiele:
Kürzel für die Standorte
Kürzel | Standortbezeichnung |
---|---|
be | Bern |
fr | Fribourg |
zg | Zug |
zh | Zürich |
Kürzel für die internen Räume
Kürzel | Ort |
---|---|
200 | Raum 200 im 2. Stock |
201 | Raum 201 im 2. Stock |
Kürzel für Racks
Zürich | |
---|---|
Kürzel | Racknummer |
ruga | Rack A im Untergeschoss |
rugb | Rack B im Untergeschoss |
r02a | Rack A im 2. Stock |
r02b | Rack B im 2. Stock |
r03a | Rack A im 3. Stock |
r03b | Rack B im 3. Stock |
r03c | Rack C im 3. Stock |
r03d | Rack D im 3. Stock |
r04a | Rack A im 4. Stock |
Der Plan ist vom Standortleiter in Fribourg gesendet wurden. Die Realisierung findet in den Betriebsferien im Sommer 2021 statt.
Abbildung 2:IST-Zustand Fribourg
Das Netzwerk in Fribourg besteht zurzeit aus den zwei 24-Port Switches sw-fr-s00-10 und sw-fr-s00- 12, die über je 2×2 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 2×4 im Teaming-Modus LACP gekoppelten Trunks zwei Server angeschlossen. Im Soll-Zustand werden alle VLANs beim Teaming- Trunk aufgeschaltet. 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 einem ersten Schritt sollen die alten Switches mit allen verbundenen Geräten ans VLAN22_CLLEARN 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 Subnetz, die Netzwerkdienste DHCP und DNS sowie der Gateway. Auf Nachfrage teilte 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)
Bei den nicht angegebenen Ports in untenstehender Tabelle handelt es sich um ungetaggte Standardports.
Ports | VLAN | LACP |
---|---|---|
23-24 | Keine VLANs | LACP-Trunk nach sw-fr-s00-12, Ports 01-02 |
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 |
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.54.1/24 und 172.16.55.1/24. Der bereits dargestellten 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 und sind einem Services Team zugewiesen. Der Owner ist der zuständige Teamleiter. Die erfassten Geräte findet man im Kapitel «IP-Zuteilung der Geräte der Rafisa Standort Dietikon». Die Domain für Dietikon ist «zh.rafisa.org». Der FQDN der Firewall wäre also «fw-zh-ruga-01.zh.rafisa.org».
Die untenstehende Tabelle zeigt die Geräte und Funktionen der Geräte.
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 | Backup Server | 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 |
In der linken Spalte finden sich die aktuellen Namenskonzeptionen von Fribourg. Die Racks sind noch nicht benannt, als Standortkürzel haben sie S00. Es wird vorgeschlagen, der Namenskonvention von Zürich zu folgen und die Racks mit s01 – s03 zu bezeichnen.
Vorschlag von SF | Vorschlag von Dietikon | |
---|---|---|
Firewall | FW-FR-S00-01 | fw-fr-s01-01 |
Switch 1 | SW-FR-S00-01 | sw-fr-s01-01 |
Switch 2 | SW-FR-S00-02 | sw-fr-s02-01 |
Switch 3 | SW-FR-S00-03 | sw-fr-s03-01 |
Main Rack | Nicht vorhanden | s01 |
Server Rack | Nicht vorhanden | s02 |
Workshop Room | Nicht vorhanden | s03 |
In Fribourg wird aktuell noch im Subnetz 172.21.22.0/24 gearbeitet. Damit sich Fribourg die Vorgaben erfüllen, welche die Norm vorgibt, muss sich das Subnetz zwischen 172.21.0.0/16 und 172.31.0.0/16 befinden.
Gemäss SF sollen mindestens fünf VLANs vorhanden sein. In der rechten Spalte sind die Vorgaben ersichtlich gemäss Firmenstandard.
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) |
Es werden zu den drei Switches Varianten aufgelistet
Beim Switch sw-fr-s00-01 gibt es keine Varianten. Die LACPs können so realisiert werden.
Trunk | Ports | Tagged/Untagged | Beschreibung |
---|---|---|---|
T1 | 01 – 04 | T | LACP-Trunk auf Switch sw-fr-s00-02 |
T2 | 05 – 06 | T | LACP-Trunk auf Switch sw-fr-s00-03 |
T3 | 41 – 42 | U | LACP-Trunk auf Switch sw-fr-s00-10 |
Beim Switch sw-fr-s00-02 wurden im von Fribourg angegebenen SOLL-Zustande die LACPs für die Windows-Teamings vergessen. Variante 1 zeigt den Vorschlag von Fribourg, Variante 2 zeigt die ergänzte Variante.
Variante 1
Trunk | Ports | Tagged/Untagged | Beschreibung |
---|
T1 | 05 – 08 | T | LACP-Trunk auf Switch sw-fr-s01-01 |
---|---|---|---|
T4 | 23 -24 | U | LACP-Trunk auf Switch sw-fr-s00-012 |
Variante 2 (vorgeschlagen)
Trunk | Ports | Tagged/Untagged | Beschreibung |
---|---|---|---|
T1 | 05 – 08 | T | LACP-Trunk auf Switch sw-fr-s00-01 |
T4 | 23 -24 | U | LACP-Trunk auf Switch sw-fr-s00-012 |
T5 | 05 – 08 | T | LACP-Teaming-Trunk auf srv-fr-s00-01 |
T6 | 19 – 22 | T | LACP-Teaming-Trunk auf srv-fr-s00-02 |
Beim Switch sw-fr-s00-03 gibt es keine Varianten. Die LACPs können so realisiert werden.
Trunk | Ports | Tagged/Untagged | Beschreibung |
---|---|---|---|
T1 | 03 – 04 | T | LACP-Trunk auf Switch sw-fr-s00-01 |
Da in der Rafisa für den Remote-Access bereits OpenVPN verwendet wird, wurde mit dem VF beschlossen, auch für die Site-to-Site-VPNs OpenVPN einzusetzen. OpenVPN ist eine freie Software zum Aufbau eines Virtuellen Privaten Netzwerkes (VPN) über eine verschlüsselte TLS- Verbindung. Zur Verschlüsselung kann OpenSSL oder TLS benutzt werden. OpenVPN verwendet wahlweise UDP oder TCP zum Transport.
Es gibt zwei Arten von Schlüsseln, die für einen VPN-Tunnel mit OpenVPN eingesetzt werden können: PSK und Zertifikate.
Um zu entscheiden, welche Schlüssel verwendet werden sollen, werden die Varianten bezüglich 4 Kriterien verglichen:
Die Kriterien wurden von mir auch einer Gewichtung von 1 (unwichtig) bis 5 (sehr wichtig) unterzogen. Diese wurde dem VF vorgelegt und sein Einverständnis eingeholt.
Im folgenden Abschnitt werden zwei Varianten verglichen. Die Variante 1 zeigt eine Umsetzung ohne Aliase. Die Variante 2 zeigt eine Umsetzung mit Aliasen. Die Umsetzung wird bei beiden Varianten an das VLAN21_CLLEARN angewendet.
Variante 1
Source | Action | Destination |
---|---|---|
22 | allow | 22 |
22 | allow | 10 |
22 | allow | 15 |
22 | allow | 40 |
22 | block | 1 |
22 | block | 14 |
22 | block | 21 |
22 | block | 23 |
22 | block | 51 |
22 | block | 52 |
22 | block | 53 |
22 | block | 54 |
22 | allow | any |
Bei dieser Umsetzung werden die Rules einzeln erstellt für jedes VLAN. Es sind fünf Allow Rules zu setzen und 8 Block Rules zusetzen. Die letzte Rule erlaubt den Zugang ins Web.
Variante 2
Source | Action | Destination |
---|---|---|
22 | allow | 22 |
22 | allow | 10 |
22 | allow | 15 |
22 | allow | 40 |
22 | allow | ! ANY_VLAN |
Bei dieser Umsetzung wird man Aliasen gearbeitet. Oberhalb der Aliase wird der Zugang zu den entsprechenden VLANs gewährt. Bei der Regel mit den Aliasen erlauben wir dem VLAN22 keinen Zugang zu allen VLANs ausser dem Web. Anstatt 13 Regeln werden nur 5 benötigt.
Funktion | WPA-Personal | WPA-Enterprise |
---|---|---|
Verschlüsselung | AES-CCMP | AES-CCMP |
Authentifizierung | Preshared Key(PSK) | Radius + Zertifikate |
VLAN | keine dynamische Zuteilung | dynamische Zuteilung nach Login |
Eine Umsetzung WPA-Enterprise hat viele Vorteile:
realisiert. Das zweite WLAN wird mit Passwort für Gäste realisiert. Bei dieser Umsetzung sind also technische Anforderungen vorgegeben.
Wenn das WLAN mit dieser Technologie realisiert wird, sind drei WLAN-Netzwerke mit statischer VLAN Zuordnung notwendig. Die Authentifizierung wird mit PSK durchgeführt.
Die Aufgabe besteht darin, die Configs via BackupPC im PULL-Verfahren automatisch zu sichern. Es gibt 2 Möglichkeiten der Realisierung. Über ein Prebackup-Script können die Config-Files per FTP oder per SSH auf den BackupPC kopiert und dann in den BackupPC-Pool gesichert werden. Folgende Tabelle zeigen die Vor- und Nachteile der beiden Lösungen:
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-Tar: Tar- Archivierung 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-Tar: Tar- Archivierung 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 |
Bei der Firewall ist der Zugang nur über SSH möglich. Das Konfig-File ist auf der pfSense in der Datei
/conf/config.xml gespeichert. Im Prebackup-Script kann die Konfig-Datei zunächst mit scp auf den BackupPC kopiert und dann von dort in den Backup-Pool gesichert werden.
Backupart | Vorgehen | Vorteile | Nachteile |
---|---|---|---|
SSH-Copy | Prebackup-Script: Mit dem Befehl scp das Konfig-File in ein lokales Verzeichnis auf BackupPC kopieren BackupPC-Tar: Tar-Archivierung dieses Verzeichnisses durch BackupPC. | Backup ist verschlüsselt | keine |
Aktuell hält sich die Namenskonventionen sich an die Firmenstandards. Aber die Racks sind nicht vorhanden bzw. nicht nummeriert. Da ist auch ersichtlich an den Vorschlag von SF, welche für die neuen Switches die Namen sw-fr-s00-01, sw-fr-s00-02, sw-fr-s00-03 vorschlägt. Möchte man sich an
die Firmennorm halten, so werden die Racks nummeriert. Dann ergibt sich folgende Hostnamen oder Gerätebezeichnung
Racks | |
---|---|
Gerätebezeichnung | physischer Standort |
s01 | Main Rack |
s02 | Server Rack |
s03 | Workshop Room |
VLAN | Kürzel/Hostname | IP-Adresse | Funktion | Ort |
---|---|---|---|---|
VLAN Management | ||||
VLAN01 | MGMT | 172.21.1.0/24 | Management | |
fw-fr-s01-01 | 172.21.1.1 | Firewall | Main Rack FR | |
sw-fr-s01-01 | 172.21.1.4 | Switch | Main Rack FR | |
sw-fr-s02-01 | 172.21.1.5 | Switch | Server Rack FR | |
sw-fr-s03-01 | 172.21.1.6 | Switch | Workshop Room FR | |
prox-fr-205-01 | 172.21.1.10 | Proxmox VE Node | Server Raum 205 | |
uni-fr-205-01 | 172.21.1.20 | Unifi Controller | Server Raum 205 | |
ap-fr-308-01 | 172.21.1.21 | Unifi Accesspoint | Raum 308 IPA Arbeitsplatz |
|
bkp-fr-308-01 | 172.21.1.30 | Backup-Server fr.rafisa.org | Raum 308 IPA Arbeitsplatz |
|
pc-fr-308-01 | DHCP | Arbeitsplatzrechner | Raum 308 IPA Arbeitsplatz |
|
VLAN Authentifizierung | ||||
VLAN10 | AUTH | 172.21.10.0/24 |
In Fribourg wird aktuell mit folgendem Subnetz gearbeitet: 172.21.22.0/24. Dank diesem Subnetz ist eine vereinfachte Anbindung bzw. Konzepterarbeitung möglich, da es dem Firmenstandard entgegenkommt.
VLAN Name | Kürzel | Funktion | VID | IP-Adresse | FW-Interface-Name | DHCP- |
---|
Server | ||||||
---|---|---|---|---|---|---|
VLAN Management | 01 | |||||
VLAN01 | MGMT | Management | 01 | 172.21.1.0/24 | VLAN01_MGMT | ❌ |
VLAN Server | 10-19 | |||||
VLAN10 | SRVAUTH | Server Authentifizierung | 10 | 172.21.10.0/24 | VLAN10_SRVAUTH | ❌ |
VLAN14 | SRVEMPL | Server Ausbildner | 14 | 172.21.14.0/24 | VLAN14_SRVEMPL | ❌ |
VLAN15 | SRVLEARN | Server Lernende | 15 | 172.21.15.0/24 | VLAN15_SRVLEARN | ❌ |
VLAN Clients | 20-29 | |||||
VLAN21 | CLEMPL | Clients Ausbildner | 21 | 172.21.21.0/24 | VLAN21_CLEMPL | ✔️ |
VLAN22 | CLLEARN | Clients Lernende | 22 | 172.21.22.0/24 | VLAN22_CLLEARN | ✔️ |
VLAN23 | CLGUEST | Clients Guest (WLAN) | 23 | 172.21.23.0/24 | VLAN23_CLGUEST | ✔️ |
VLAN Drucker | 40 | |||||
VLAN40 | LP | Drucker | 40 | 172.21.40.0/24 | VLAN40_LP | ❌ |
VLAN Labor | 50-59 | |||||
VLAN51 | LAB01 | Labor 01 | 51 | 172.21.51.0/24 | VLAN51_LAB01 | ✔️ |
VLAN52 | LAB02 | Labor 02 | 52 | 172.21.52.0/24 | VLAN52_LAB02 | ✔️ |
VLAN53 | LAB03 | Labor 03 | 53 | 172.21.53.0/24 | VLAN53_LAB03 | ✔️ |
VLAN54 | LAB04 | Labor 04 | 54 | 172.21.54.0/24 | VLAN54_LAB04 | ✔️ |
VLAN55 | LAB05 | Labor 05 | 55 | 172.21.55.0/24 | VLAN55_LAB05 | ✔️ |
Die beiden vergessenen LACP-Trunks für das Teaming werden nach Rücksprache mit dem Stellenleiter Fribourg wie folgt realisiert:
Trunk | Host 1 | Port1 | Host 2 | Port |
---|---|---|---|---|
T1 | sw-fr-s01-01 | 01 – 04 | sw-fr-s02-01 | 01 –04 |
T2 | sw-fr-s01-01 | 05 – 06 | sw-fr-s03-01 | 01 – 02 |
T3 | sw-fr-s01-01 | 29 – 30 | sw-fr-s00-10 | 01 – 02 |
T4 | sw-fr-s02-01 | 23 – 24 | sw-fr-s00-12 | 01 – 02 |
T5 | sw-fr-s02-01 | 05 – 08 | srv-fr-s00-01 | |
T6 | sw-fr-s02-01 | 09 – 12 | srv-fr-s00-02 |
Für die WLAN-Anmeldung wird WPA Personal gewählt. WLAN-Enterprise wäre zwar wegen der vielen Vorteile zu bevorzugen. Da Fribourg aktuell über keinen AD verfügt, wird in dieser IPA die Lösung über das Shared Key-Verfahren realisiert. Die Sicherheit kann mit einem Radius Profil erweitert werden und somit Authentifizierung mit Zertifikaten ermöglichen. Es werden also drei WLAN- Netzwerke realisiert:
WLAN | VLAN | Netzwerknamen | PW |
---|---|---|---|
Rafisa_Employees | VLAN21_CLEMPL | Rafisa_Employees | |
Rafisa_Learners | VLAN22_CLLEARN | Rafisa_Learners | |
Rafisa_ Guests | VLAN23_CLGUEST | Rafisa_Guests |
Folgende Ports sind für die WLANs zu realisieren:
Hostname | Ports | Untagged | Tagged |
---|---|---|---|
sw-fr-s01-01 | 09 – 14 | VLAN01_MGMT | VLAN21_CLEMPL |
VLAN22_CLLEARN | |||
VLAN23_CLGUEST |
Für den Switch sw-fr-s01-01 ergibt sich unter Berücksichtigung aller Entscheidungen folgende Portbelegung:
Ports | VLAN | LACP |
---|---|---|
01 – 04 | Tagged VLANs | LACP – Trunk nach sw-fr-s02 – 02, Ports 01 – 04 |
05 – 06 | Tagged VLANs | LACP – Trunk nach sw-fr-s03 – 03, Ports 01 – 02 |
07 | VLAN01_MGMT | |
08 | VLAN – Uplink FW – FR -01 | |
09 – 14 | Uplink zu AP-FR-01 | |
15 – 18 | VLAN40_LP | |
19 – 28 | VLAN21_CLEMPL | |
29 – 46 | VLAN22_CLLEARN | |
47 – 48 | VLAN 21_CLEMPL |
Für den Switch sw-fr-s02-01 ergibt sich unter Berücksichtigung aller Entscheidungen folgende Portbelegung:
Ports | VLAN | LACP | |
---|---|---|---|
01 – 04 | Tagged VLANs | LACP – Trunk nach sw-fr-s01 – 01, Ports 01 – 04 | |
05 – 08 | Tagged VLANs | Teaming für srv-fr-s00-01 | |
09 – 12 | Tagged VLANs | Teaming für srv-fr-s00-02 | |
13 | VLAN01_MGMT | ILO Port für srv-fr-s00-01 | |
14 | VLAN01_MGMT | ILO Port für srv-fr-s00-02 | |
15 – 18 | VLAN01_MGMT | ||
19 – 20 | VLAN40_LP | ||
21 – 22 | VLAN 21_CLEMPL | ||
23 – 24 | VLAN22_CLLEARN | ||
25 – 28 | Tagged VLANs | Trunk |
Für den Switch sw-fr-s03-01 ergibt sich unter Berücksichtigung aller Entscheidungen folgende Portbelegung:
Ports | VLAN | LACP |
---|---|---|
01 – 02 | Tagged VLANs | LACP – Trunk nach sw-fr-s01 – 01, Ports 01 – 02 |
03 – 04 | Tagged VLANs | Trunk |
05 | VLAN01_MGMT | |
06 – 10 | VLAN21_CLEMPL | |
11 – 28 | VLAN22_CLLEARN |
Das Site to Site VPN wird mit OpenVPN realisiert. Mit der untenstehenden Entscheidungsmatrix wurden die zwei möglichen Verschlüsselungsverfahren gemäss den in der Planung festgelegten Kriterien verglichen.
Kriterium/Technologie | Gewichtung | PSK | SSL/TLS | Gewichtung PSK | Gewichtung SSL/TLS |
---|---|---|---|---|---|
Einfache Konfiguration | 3 | 5 | 3 | 15 | 9 |
Sicherer Public Key | 5 | 2 | 5 | 10 | 25 |
Bessere Erweiterung | 5 | 2 | 5 | 10 | 25 |
Bessere Netzwerksicherheit | 5 | 2 | 5 | 10 | 25 |
Total | 45 | 84 |
Einfachere Konfiguration: Bei PSK ist die Konfiguration für die Bereitstellung der Site to Site VPN viel einfacher und somit weniger zeitaufwändig.
Sicherer Publik Key: Beide Technologien benötigen einen Public Key für die Verschlüsselung. Während dieser Key beim PSK unsicher ist, ist er bei der CA um einiges sicher, da er um einiges längerer ist.
Bessere Erweiterung: Während im PSK auf allen Systemen (VPN Server /VPN Client) bei einer Änderung des Systems, die Keys angepasst werden müssen, ist die Änderung nur auf dem OpenVPN- Server anzupassen.
Bessere Netzwerksicherheit: Während beim PSK für jeden Standort bei Anbindung ein zusätzlicher Port beim zentralen Server offen ist, benötigt man bei der Zertifikatstechnologie nur einen Port.
Die Berechtigungsmatrix wurde vollständig übernommen gemäss Firmenstandard übernommen.
VLAN | 01 | 10 | 14 | 15 | 21 | 22 | 23 | 40 | 51 | 52 | 53 | 54 | 55 | WAN | VPN- ZH |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
01 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ❌ |
10 | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ |
14 | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
15 | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
21 | ❌ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
22 | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
23 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
40 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | |
51 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
52 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ✔️ | ❌ |
53 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ✔️ | ❌ |
54 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ✔️ | ❌ |
55 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ | ❌ |
WAN | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
VPN- ZH | ✔️ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ |
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 gravierend, 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 in ein lokales Verzeichnis auf dem BackupPC kopiert wird. 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 ein lokales Verzeichnis kopiert und danach ebenfalls mit BackupPC-Rsync in ein BackupPC-Archiv verschoben.
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 |
Für die Meilensteine werden die fünf Phasen von IPERKA gewählt.
Konfigurationsübersicht fw-zh-308-01 | |
---|---|
Beschreibung | Tätigkeiten |
OpenVPN-Server konfigurieren | Interne Zertifizierungsstelle einrichten CA RAFISA ZH Server Zertifikat fw-zh-308-01 User Zertifikat fr.rafisa.org (Zertifikatsname und CN) OpenVPN – Server einrichten OpenVPN FR ← ZH Rules anpassen WAN-Interface OpenVPN-Interface Client Specific Overrides konfigurieren TLS Key OpenVPN-Server kopieren und in ein Notepad eintragen und speichern |
Konfigurationsübersicht sw-fr-s01, sw-fr-s02-01, sw-fr-s03-01 | |
---|---|
Beschreibung | Tätigkeiten |
Einrichten vom Switch | Hostname ändern Static IPv4 Adresse ändern VLAN Interfaces erstellen VLAN - Portzuweisung Trunks setzen LACP konfigurieren Zeitserver einrichten Anschliessen der Netzwerkkomponente |
Konfigurationsübersicht fw-fr-s01-01 | |
Beschreibung | Tätigkeiten |
Basiseinrichtung | Hostname ändern WAN Interfaces anpassen VLAN-Interfaces erstellen Zeitserver einrichten DHCP-Server einrichten Aliase erstellen Rules erstellen gemäss Berechtigungsmatrix SSH aktivieren |
OpenVPN-Client konfigurieren | Import folgender Daten Zertifikat von CA RAFISA ZH Zertifikat von fr.rafisa.org TLS Key (Einrichten des OpenVPN Clients) Einrichten des OpenVPN Clients TLS Key einfügen 172.16.55.2 als Serverhost eintragen Zertifizierungsstelle und Client Zertifikat angeben CA Rafisa ZH fr.rafisa.org Rule auf OpenVPN Interface anpassen |
Konfigurationsübersicht uni-fr-205-01 | |
Beschreibung | Tätigkeiten |
Server in Betrieb nehmen | Basisinstallation Ubuntu 20.04 LTS Zeitserver einrichten Installation UnifiController Erstkonfiguration UnifiController Webinterface Einbinden vom ap-fr-308-01 Netzwerk erstellen WLAN – Netzwerke erstellen inkl. Netzwerk-Zuweisung Testdurchlauf Testfall Nr.2 Backup vorbereiten/durchführen |
Die Einrichtung eines VLAN-Interface wird bei der Realisierung für den Switch sw-fr-s03-01 als Vorzeigebeispiel verwendet. Daher wird der nb-zh-308-01 an Port 5 angeschlossen. Die Default IP des Switches ist 192.168.1.1, daher wird die IPv4 -Adresse statisch gesetzt welche im Range von 192.168.1.2 bis 192.168.1.254 befinden sollte. Zyxel verwendet folgende Default Logindaten:
Username | admin |
---|---|
Passwort | 1234 |
Zur Basiseinrichtung gehören folgende Konfigurationen:
Auf der Registerkarte General Setup der Switches wird zunächst der Hostname festgelegt. Danach wird als Zeitserver die IP der Firewall angegeben.
Der Administrative Zugang stellt den Switch ins VLAN01_MGMT, mit der man auch die Switch via Web-Interface verwalten kann. Dies kann unter IP-Setup eingestellt werden
Abbildung 3: Administrativer Zugang für Switches
Erstellen eines neuen VLAN-Interfaces oder schon vorhandenem VLAN-Interface VLAN ID 1 ist standartmässig immer vorhanden. Daher muss dieses VLAN nicht neu erstellt werden, sondern nur angepasst werden. Unter VLAN bei Advanced Application sind zwei Konfigurationen notwendig. Unter Static VLAN werden die Interfaces erstellt und gleichzeitig können untaggede oder Taggede Portzuweisungen zu den VLANs konfiguriert werden. Unter VLAN-Port-Setup werden die Ports welche Untagged sind, werden mit den entsprechenden VID also PVID bestätigt. Folgende Konfigurationen werden bei Static VLAN für das Anpassen oder Erstellen eines VLAN-Interfaces vorgenommen.
Active | Wenn ein Häkchen gesetzt wurde, wird das VLAN aktiviert, beim Nichtsetzen wird das VLAN deaktiviert |
Name | VLAN-Interface |
VLAN Group ID | VLAN Tag-ID (1 bis 4096 ) |
Fixed | Dieser Port wird dem VLAN permanent zugewiesen |
Forbidden | Dieser Port wird dem VLAN die Zuweisung verweigert. |
Tx Tagging | Alle ausgehenden Ethernet Frames werden an diesem Port mit dem VLAN-ID-Tag versehen. Diese Einstellung ist wichtig, wenn der Port als Trunk eingerichtet werden soll. |
Auch ist eine Übersicht von allen VLANs vorhanden.
Abbildung 4: Übersicht aller VLANs
Bei VLAN Port Setting ist nur entscheidet das nur die PVID mit übereinstimmt dem VLAN-Tag, wenn der Port fixed und keine Tx-Tagging gesetzt bekommen bei den VLAN-Interfaces bzw. deren Portzuweisungen.
Abbildung 5: Ausschnitt der VLAN Port Setting für die Ports 18 bis 21 bei sw-fr-s03
Die Vorgehensweise für die Konfiguration eines LAG wird am sw-fr-s02 erläutert. Gemäss Kapitel 9.1.7 werden die Ports 1 bis 4 zu dem LACP Trunk(T1) gebildet. Die nachfolgenden Konfigurationen müssen bei beiden Hosts, welche mit einem LAG verbunden werden,identisch sein.
Abbildung 6:Konfiguration LACP-T1 beim sw-fr-s02-01
Unter Link Aggregation Setting wird in der oberen Hälfte der LACP Trunk eingerichtet. Group ID «T1»wird aktiviert. Criteria wird die Option auf «dst-mac» gesetzt. In der unteren Hälfte werden die Ports den jeweiligen LACP-Trunk zugeordnet. Nun muss noch das LACP-Protokoll aktiviert werden. Dabei ist so dass bei Zyxel der LACP allgemein und für den LACP-Trunk aktiv sein. Dafür muss man bei LAGLACP folgende Einstellung vornehmen:
Abbildung 7: Aktivieren des LACP-Protokolls auf sw-fr-s02-01
Die letzte Einstellung die für LAG relevant ist, ist das Deaktivieren des LoopGuard auf den LACP-Trunk Ports. Für das Aktivieren/Deaktivieren eines LoopGuard wird unter der gleichnamigen Konfigurationsseite bei Advanced Application der LoopGuard aktiviert oder deaktiviert.
Abbildung 8: LoopGuard-Einstellung für sw-fr-s02-01
Für den Switch sw-fr-s01-01 wird die LAG-Konfiguration und das Setzen der Management-IP im CLI vorgenommen, da es im Web-Interface die LAG Einrichtung nicht vollständig umgesetzt werden kann. Dafür wird mit Putty ein SSH-Verbindung zu sw-fr-s01-01 aufgebaut.
Trunk T2 <cr dst-mac
In diesem Kapitel sind Vorgehensweisen zu folgenden Konfigurationen, welche in Kapitel 9.4.2 aufgelistet sind, beschrieben. Pfsense hat dieselbe Default IP wie Zyxel bei seinen Switches. somit ist der Vorgang für den Zugriff aufs Websinterface gleich. Nur das Passwort ist anders als bei Zyxel.
Username | admin |
---|---|
Passwort | pfsense |
Bei General Setup unter System, lässt sich der Hostname und die lokale Domäne eintragen
Abbildung 9:Basiseinrichtung 1
Unter Localization lässt sich die Zeitzone, Zeitserver und die Sprache einstellen.
Abbildung 10:Basiseinrichtung 2
Ein Admin-User ist standardmässig schon bei Pfsense eingerichtet. Nun wird noch sein Passwort geändert um nicht die Login Daten der Pfsense zu verwenden. Das neue Passwort wird auf der Seite System/User Manager/ admin angepasst.
Um ein VLAN-Interface zu hinzufügen, navigiert man zu InterfacesVLAN. Nun werden für das VLAN01_MGMT die Konfigurationen wie folgt eingetragen:
Abbildung 11: Basiseinrichtung 3 VLAN-Interface
In der Rafisa wird das Parent Interface für die VLANs stets igb1 ausgewählt. Ansonsten kann man sich auch an die Beschriftung orientieren. VLAN Tag muss identisch sein mit dem VLAN Tag welche für das Erstellen des gleichnamigen VLAN-Interface auf den Switches verwendet wurden. Description ist nur eine Hilfestellung für die Mitglieder des Networks- Team. Zum Schluss wird dieses VLAN noch zu den
Interfaces permanent zugewiesen.
Abbildung 12: Basiseinrichtung 4 VLAN-Interface 2
Aktuell ist dieses Interfaces noch Opt1 benannt, dieses wird noch zum VLAN-Interfacenamen umbenannt. Zeitgleich kann der GW vom VLAN statisch gesetzt werden, da die Konfigurationen auf derselben Seite vorgenommen werden.Die Konfiguration zum Einrichten des GW vom VLAN01_MGMT ist im Abbild 13 Basiseinrichtung 6 VLAN-Interface 4 ersichtlich.
Abbildung 13:Basiseinrichtung 5 VLAN-Interface 3
Der Upstream-GW ist die Verbindung zwischen dem GW des Interfaces und dem GW der WAN Seite. Ich benötige aber diese Option in meiner Arbeit nur sobald ich für Site to Site VPN die WAN-Adresse statisch setzte. In der Testumgebung werden die Optionen in Reserved Networks deaktiviert. In der produktiven Umgebung muss dann aber die Option aktiviert sein.
Abbildung 14:Basiseinrichtung 6 VLAN-Interface 4
Jetzt wird noch erläutert wie man einen DHCP-Server für ein VLAN-Interface einrichtet. Um einen DHCP-Server einzurichten, navigiert man zu Services/DHCP Services/ und wählt dann das entsprechende VLAN-Interface aus. Sobald man das Häkchen auf Enable setzt, wird dieser aktiviert. Nun muss noch der Range für das Verteilen der IPv4 Adresse angegeben werden.
Abbildung 15: Basiseinrichtung 7 DHCP-Server
Wenn alle VLANs vollständig eingerichtet wurden, kann man mit dem Erstellen eines Aliasen fortfahren. In Pfsense konfiguriert man Aliase im Bereich Firewall. Bei den Eingaben sind die nachfolgenden Optionen vorzunehmen.
Proberties | |||
---|---|---|---|
Name | VLAN_ANY | ||
Description | VLAN_ANY | ||
Type | Network(s) | ||
Network(s) | |||
Subnetz des VLANs | Netzmaske | VLAN-Interfacenamen |
Tabelle 5:Eingabemaske Aliase
Bevor mit der VPN Konfiguration auf der Server Side also Standort Dietikon begonnen werden. wird eine statische IPv4 auf dem WAN-Interface und der Upstream-GW benötigt, das gleiche gilt auch für den Standort in Dietikon.
Option | Eingabe | |
---|---|---|
IPv4 Configuration Type | Static IPv4 | |
IPv4 Adresss | 172.16.54.2 | /24 |
IPv4 Upstream gateway | WANGW_LAB04 – 172.16.54.1 |
Bevor die Vorgehensweise zu den Rules erläutert wird, wird das Site to Site VPN mit OpenVPN beschrieben. Dafür werden die nachfolgenden Konfigurationen zum VPN-Server und den Zertifikaten in fw-zh-308-01 vorgenommen. Beim Arbeiten mit Zertifikaten werden die Konfigurationen in pfsense in «Certificate Manger» und beim Arbeiten mit VPN wird diese in OpenVPN eingestellt.
Zuerst wie die Zertifizierungsstelle CA-RAFISA-ZH eingerichtet. Das kann unter System/Certificate Manager/CAs erstellt werden. Folgende Optionen müssen wie folgt eingeben werden:
Option | Eingabe |
---|---|
Descriptive Name | CA-RAFISA-ZH |
Method | Create an internal Certficate Authority |
Common Name | ca-rafisa-zh |
Tabelle 6:Eingaben CA-RAFISA-ZH Abbild 1
Zusatzinformationen für Interne Zwecke
Option | Eingabe |
---|---|
Country Code | CH |
State or Province | Zürich |
City | Dietikon |
Organization | Rafisa Informatik GmbH |
Organizational Unit | Network Services Team |
Tabelle 7:Eingaben CA-RAFISA-ZH Abbild 2
Jetzt kann je ein Server-Zertifikat und je ein Client-Zertifikat erstellt. Beide Zertifikate werden von CA- RAFISA-ZH ausgestellt und werden für die Authentifizierung zwischen den Systemen fw-fr-s01-01 und fw-zh-308-01 benötigt.
Die Eingaben werden wie folgt ausgeführt:
Option | Eingabe |
---|---|
Descriptive Name | fw-zh-308-01 |
Method | Create internal Certficate |
Common Name | fw-zh-308-01.zh.rafisa.org |
Certificate Authority | CA-RAFISA-ZH |
Certificate Type | Server Certificate |
Tabelle 8: Eingaben Server-Zertifikat fw-zh-308-01
Option | Eingabe |
---|---|
Descriptive Name | fr.rafisa.org |
Method | Create internal Certficate |
Common Name | fr.rafisa.org |
Certificate Authority | CA-RAFISA-ZH |
Certificate Type | User Certificate |
Tabelle 9:Eingaben User-Zertifikat fr.rafisa.org
Somit sind alle notwendigen Zertifikate erstellt und sollten mitsamt Informationen über die Konfigurationen auf der Übersicht erscheinen.
Abbildung 16: Übersicht der Zertifikate
Folgende Eingabeoptionen werden wie folgt getätigt.
General Information | |
---|---|
Option | Eingabe |
Server Mode | Peer to Peer SSL/TLS |
Interface | WAN |
Local Port | 1194 |
Description | OpenVPN FR ← ZH |
Cryptographic Settings | |
Option | Eingabe |
TLS Configuration | Use TLS Key aktivieren |
Automatically generate a TLS Key aktivieren | |
Peer Certificate Autohriy | CA Rafisa ZH |
Server certificate | fw-zh-308-01 auswählen im Dropdownmenü |
Tunnel Settings | |
IPv4 Tunnel Network | 10.0.21.0/24 |
IPv4 Local Network | Subnetze werden eingefügt |
IPv4 Remote Network | 172.21.1.0/24,172.21.10.0/24 |
Somit ist der OpenVPN Server eingerichtet konfiguriert. Später wird der Server aber noch benötigt damit der TLS Key kopiert und für den Export vorbereitet werden kann. Jetzt können Rules eingerichtet werden.
Mit dieser Regel wird auf der WAN Seite der Port 1194 OpenVPN geöffnet und erlauben das der Datenverkehr von WAN auf 1194 Port gelangen kann. Auf dem OpenVPN Interface wird auch noch eine Rule eingestellt. welche die Erlaubnis hat den Verkehr von VLAN10_SRVAUTH in Fribourg nach Zürich durchzulassen.
Abbildung 17:Rule auf dem WAN-Interface any-OpenVPN
Abbildung 18: Rule auf dem OpenVPN-Interface VLAN10_SRVAUTH_FR - VLAN10_SRVAUTH
Das ist notwendig um den Verkehr zwischen den beiden Standorten einzugrenzen
General Information | |
---|---|
Option | Eingabe |
Server List | OpenVPN Server 1: OpenVPN FR ← ZH |
Common Name | fr.rafisa.org |
Description | OpenVPN FR ← ZH |
Tunnel Settings | |
IPv4 Tunnel Network | 10.0.21.0/24 |
IPv4 Local Network | Subnetze werden eingefügt |
IPv4 Remote Network | 172.21.1.0/24,172.21.10.0/24 |
Nun werden drei Komponenten für die Konfiguration auf der Client-Side vom OpenVPN exportiert, siehe Abbildungen unten.
Nun werden im Certificate Manager die exportierten Daten importiert. Am besten öffnet man mit dem Editor alle Daten um dann später die einzelnen Daten einzufügen. Nun wird der Client eingerichtet.
General Information | |
---|---|
Option | Eingabe |
Server Mode | Peer to Peer SSL/TLS |
Interface | WAN |
Server Port | 1194 |
Server host or address | 172.16.55.2 |
Description | OpenVPN FR ← ZH |
Cryptographic Settings | |
Option | Eingabe |
TLS Configuration | Use TLS Key aktivieren |
Einfügen des TLS Keys vom OpenVPN Server | |
Peer Certificate Autohriy | CA Rafisa ZH |
Client Certificate | fr.rafisa.org auswählen im Dropdownmenü |
Tunnel Settings | |
IPv4 Tunnel Network | 10.0.21.0/24 |
IPv4 Remote Network | 172.31.10.0/24, 172.31.14.0/24, 172.31.21.0/24, 172.31.1.0/24 |
Zum Schluss müssen noch Rules auf dem OpenVPN-Interface vorgenommen werden
Abbildung 19: Rules auf dem OpenVPN Interface
Als erstes werden auf BackupPC unter /home/rafisa-backup/backup die temporären Verzeichnisse für die zu sichernden Konfigurationsdateien angelegt. Die Verzeichnisse werden nach den Hostnames der zu sichernden Geräte benannt:
Abbildung 20:Backup Verzeichnis
Da die Backups als User backuppc gemacht werden, wird das Verzeichnis backup mit dem Befehl
«chown –R backuppc:backuppc /home/rafisa-backup/backup» dem User und der Gruppe backuppc zugeordnet.
Für die Prebackup-Scripts wird das Verzeichnis /home/rafisa-backup/bin angelegt. Danach werden für die Prebackup-Scripts mit dem Befehl touch vier Dateien angelegt:
Abbildung 21:Prebackup-Scripts Verzeichnis
Für die Switches wird folgendes Script (Beispiel ist für sw-fr-s01-01) angelegt:
#!/bin/bash
cd /home/rafisa-backup/backup/sw-fr-s01-01 ftp -n 172.21.1.4 «EOF
quote USER admin quote PASS 1234 get config
quit EOF
mv /home/rafisa-backup/backup/sw-fr-s01-01/config /home/rafisa-backup/backup/sw-fr-s01-01/sw-fr-s01-01.conf
In der ersten Zeile wird festgelegt, dass das Programm mit dem Befehl «bash» ausgeführt wird. In der nächsten Zeile wird mit «cd» ins temporäre Backupverzeichnis gewechselt. Danach loggt sich BackupPC mittels ftp auf dem Switch 172.21.1.4 ein und führt interaktiv die Kommandos aus, die sich zwischen der Markierung «EOF und EOF befinden. Mit «get config» wird das gewünschte Konfigfile ins temporäre Backupverzeichnis kopiert und danach mit «mv» umbenannt.
Für die Firewall wird folgendes Script angelegt:
#!/bin/bash
/usr/bin/sshpass -p 1234 scp -oStrictHostKeyChecking=no admin@172.21.1.1:/conf/config.xml /home/rafisa-backup/backup/fw- fr-s01-01/fw-fr-s01-01.conf
In der ersten Zeile wird festgelegt, dass das Programm mit dem Kommando «bash» ausgeführt wird. In der zweiten Zeile wird mit «sshpass» das Passwort übergeben und danach mit «scp» das File config.xml auf der Firewall nach /home/rafisa-backup/backup/fw-fr-s01-01/fw-fr-s01-01.conf kopiert.
Im Web-Interface von BackupPC werden zunächst alle benötigten Hosts angelegt:
Nach der Auswahl des Hosts kann unter «Edit config» die Backupkonfiguration für die Hosts eingerichtet werden. Unter der Registerkarte «Backup Settings» wird der Pfad zum entsprechenden Prebackup-Script angegeben. Also z.B. «/home/rafisa-backup/backup/fw-fr-s01-01». Beim Start wird dieses Script vor dem eigentlichen Backup ausgeführt und damit das Konfig-File des entsprechenden Netzwerkgeräts ins Verzeichnis «/home/rafisa-backup/backup/gerätename» kopiert.
Unter der Registerkarte «Xfer» wird die eigentliche Backup-Methode festgelegt. Für die lokale Kopie der Dateien wird die Methode «tar» ausgewählt. Tar wird von BackupPC dazu verwendet, den Inhalt des in der Einstellung «TarShareName» angegebenen Verzeichnisses in den Backup-Pool zu kopieren.
Die Einstellungen unter «Schedule» können so belassen werden. Dies führt dazu, dass einmal in der Woche zwischen 19:30 und 07:00 ein Full-Backup und danach jeden Tag ein Incremental-Backup durchgeführt wird, was für die Dauer der IPA mehr als genug ist.
Als Vorarbeit wurde der prox-fr-205-01 geliefert, so dass wenn man diesen am sw-fr-s02-01 angeschlossen hat, in Betrieb genommen wurde. Zuerst wird mit Create VM, die virtuelle Maschine mit den nachfolgenden Konfigurationen erstellt.
General | |
---|---|
Option | Eingabe |
Node | ozelot |
VM ID | 105(Proxmox passt die ID automatisch) |
Name | uni-fr-308-01. Wurde später nachträglich angepasst in: uni-fr-205- 01 |
OS | |
Option | Eingabe |
Use CD/DVD disc image file (iso) | wird ausgewählt |
Storage | local |
ISO image | ubuntu-20.04-live-server-amd64 im Dropdownmenü ausgewählt |
Guest OS: | |
Type | Linux |
Version | 4.X/3.X/2.6 Kernel |
Harddisk | |
Option | Eingabe |
Storage | local-lvm |
Disk size (GiB) | 50 GB |
CPU | |
Option | Eingabe |
Sockets | 1 |
Cores | 2 |
Memory | |
Option | Eingabe |
Memory (MiB) | 4096 |
Network | |
Option | Eingabe |
Bridge | vmbr0 |
VLAN Tag | 1 |
Tabelle 10: Konfigurationsübersicht uni-fr-308-01
Am Schluss werden die ganzen vorgenommen Einstellungen aufgelistet und bestätigen das Erstellen der VM.
Abbildung 22: Bestätigen der technischen Spezifikationen der VM: uni-fr-308-01
Nun kann mit der Basisinstallation von Ubuntu 20.04 LTS begonnen werden:
Übersicht der Konfiguration Basisinstallation Ubuntu 20.04 LTS | |
---|---|
Option | Eingabe |
Sprache | Deutsch |
Tastatur | Switzerland |
Netzwerkkonfiguration | |
IPv4 Methode | Manual |
Subnet | 172.21.1.0/24 |
Address | 172.21.1.20 |
Gateway | 172.21.1.1 |
Name servers | 172.21.1.1 |
Begleitete Speicherplatzkonfiguration | Use an entire disk wählen |
Speicherplatzkonfiguration | Vorgeschlagene Methode wählen und bestätigen |
Profileinrichtung | |
Your name | Sabareeshan Nadeswaran |
Your server’s name | uni-fr-205-01 |
Pick a username | sysadmin |
Choose a password | ********* |
Confirm your password | ********* |
OpenSSH einrichten | Install OpenSSH-Server wählen |
Tabelle 11:Übersicht der Konfiguration Basisinstallation Ubuntu 20.04 LTS
Dann wird eine Systemaktualisierung durchgeführt, welche abgewartet werden muss. Sobald die Option erscheint für einen Neustart, kann dieser durchgeführt. Vor dem Neustart muss aber die ISO- Datei entfernt werden.
Nachdem das System wieder hochgefahren wurde und man sich erfolgreich eingeloggt hat kann ein Snapshot erstellt werden.
Nach der Basisinstallation von Ubuntu kann die Controller-Software installiert werden. Dazu verbindet man sich zuerst über SSH mit dem Ubuntu-Server.
Mit dem Befehl «sudo apt install openjdk-8-jdk -y» wird Java in der benötigten Version installiert. Danach werden für das Funktionieren von apt die Pakete ca-certificates und apt-transport-https installiert.
Mit folgenden Befehlen werden die benötigten Repositories hinzugefügt:
/etc/apt/sources.list.d/100-ubnt-unifi.list
Danach kann der Unifi-Controller mit folgenden Befehlen installiert werden: sudo apt-get update && sudo apt-get install unifi
Mit folgendem Befehlt wird der Service gestartet:
sudo service unifi start
n Chrome folgende URL: https://172.21.1.20:8443 aufrufen
Übersicht der Konfiguration Ersteinrichtung uni-fr-205-01 | |
---|---|
Option | Eingabe |
Controller Name | uni-fr-205-01 und Einverständniserklärung als gelesen markieren |
Enable Remote Access | deaktivieren |
User your Ubiquiti account for local access | deaktvieren |
Local Administrator Username | sysadmin |
Local Administrator Password | ********* |
Confirm password | ********* |
Local Administrator Email | <s.nadeswaran@rafisa.ch |
Automatically optimize my network | deaktivieren |
Enable Auto Backup | deaktivieren |
Devices Setup | Skip |
WiFi Setup | Skip |
Country or territory | Switzerland |
Timezone | UTC+02.00 Europe/Zurich |
Tabelle 12:Übersicht der Konfiguration Ersteinrichtung uni-fr-205-01
Nach Login erscheint ein Info Fenster mit der man zum Classic dashboard wechseln kann. Diese Einstellung wird akzeptiert. Dann wird die Option New User Interface deaktiviert und bestätigen diese Änderung.
Nach diesen Schritten kann ein Snapshot erstellt werden, mit der Bezeichnung Snapshot 2.Nachdem
dieser Vorgang beendet wurde, kann man sich dem Erstellen eines Netzwerks widmen. Mit Create Network, in den Network Settings werden diese erstellt. Nachdem dieser erstellt wurde, kann ein WLAN einrichten und diesem WLAN wird dann das gleichnamige Netzwerk zugewiesen. WLAN wird ebenfalls in den Settings erstellt. Die Beschreibung des Realisierungsvorgang wird anhand des WLAN
«Rafisa_Employees» erläutert.
Übersicht in der Eingabemaske «CREATE NEW NETWORK» | |
---|---|
Option | Eingabe |
Name | Rafisa_Employees |
Purpose | VLAN Only |
VLAN | 21 |
Übersicht in der Eingabemaske «CREATE NEW WIRELESS NETWORK» | |
Option | Eingabe |
Name/SSID | Rafisa_Employees |
Enabled | Enable this wireless network aktiv setzen |
Security | WPA Personal |
Security Key | ********* |
Network | Rafisa_Employees auswählen |
Tabelle 13: Vorgenommen Konfigurationen im uni-fr-205-01
Nachdem der AP auf die Werkeinstellungen zurückgesetzt wurde, kann man diesen mit Hilfe eines Powerline POE Adapter anschliessen.
Sobald der AP im Web-Gui des Controllers erscheint, kann unter den Devices-Settings die Netzwerkkonfiguration statischen setzen. Dem AP wird die IP 172.21.1.21 gegeben.
Ziel ist, die gesamte Lösung zu testen. Da IT-Systeme so komplex sind, kann natürlich nicht alles getestet werden. Es ist deshalb auch wichtig auszuführen, was nicht getestet wird. Die Testsysteme und die Umgebung sieht man im untenstehenden Netzplan.
Abbildung 23: Testumgebung und Testsysteme
Wichtige Begriffe, die beim Testing verwendet werden, sind: Testobjekt, Testmittel, Testmethode, Testfall. Testobjekt ist der zu testende Gegenstand (z. B. eine Softwarefunktion, ein Softwaremodul oder ein Softwaresystem). Testmittel sind die eingesetzte Soft- und Hardware. Bei der Testmethode wird gesagt, um welche Art von Test es sich handelt, z.B. Komponententest (einzelne Komponente der Lösung), Integrationstest (Komponenten im Zusammenspiel), Systemtest (gesamtes System) oder Abnahmetest (Test durch Kunden).
Die Funktionen folgender Objekte werden getestet:
In der folgenden Tabelle findet sich eine Auflistung der Testfälle mit einer Beschreibung, was getestet werden soll.
Nr. | Name | Beschreibung |
---|---|---|
1 | VLANs | Test der statischen VLANs und der VLAN-Trunks |
2 | Firewall-Rules für die Internen VLANs | Die Regeln der FW in Standort Fribourg testen. Vergleich mit der Berechtigungsmatrix. |
3 | Access-Point | WLAN-Netzwerke auf die Zuweisung ins korrekte VLAN testen. |
4 | LACP-Trunks auf den Switches | Es wird auf die Funktionalität des LAG getestet. |
5 | Firewall-Rules für das VPN | Es wird getestet, ob die Regeln für den Zugriff von ZH nach FR richtig eingerichtet sind. Vergleich mit der Berechtigungsmatrix. |
6 | Backup-Scripts und Restore | Es wird getestet ob die Arbeitsergebnisse darunter auch die Konfigurationsdateien der Switch und der FW mithilfe des BackupPC-Servers gesichert werden können und ob gesicherten Dateien für den Restore funktionieren. |
In der folgenden Tabelle wir für jeden Testfall angegeben, was nicht getestet wird.
Nr. | Name | Was nicht getestet wird |
---|---|---|
1 | VLANs | Da das Austesten aller 96 Switch-Ports zu viel Zeit brauchen würde, wird ein Stichprobentest durchgeführt. Es werden am sw-fr-s02-01 4 Ports mit den aktiven VLANs sowie die Uplinks auf den Switch sw-fr-s01-01 und die Firewall fw-fr- s01-01 getestet. |
2 | Firewall-Rules für die Internen VLANs | Es werden nicht alle Protokolle getestet, sondern nur ICMP mit Ping-Tests. Auch hier wird, wie bei Test #1, nur ein Stichprobentest auf Switch sw-fr-s02-01 durchgeführt. |
3 | Access-Point | |
4 | LACP-Trunks auf den Switches | Aus Zeitgründen wird kein Performance-Test gemacht, sondern nur auf die Switch-Information vertraut. |
5 | Firewall-Rules für das VPN | Es werden nicht alle Protokolle getestet, sondern nur ICMP mit Ping-Tests. Es wird nur der Zugang von Zürich nach Fribourg getestet, da das Absichern von Zürich eine Vorarbeit war. Sollten die Ping-Tests erfolgreich verlaufen, gilt dieser Test auch als erfolgreich verlaufener Test für die VPN-Site-to-Site-Verbindung. |
6 | Backup-Scripts und Restore | Der automatische Restore wird nicht getestet, da er noch nicht implementiert worden ist. |
In der folgenden Tabelle sind die Testmittel und Testmethoden pro Testfall aufgeführt.
Nr. | Name | Testmittel | Testmethode |
---|---|---|---|
1 | VLANs | nb-fr-308-01 (Win10 Pro, cmd, ping command) sw-fr-s02-01 (Zyxel Firmware v3.80) LACP-Trunk 1 sw-fr-s01-01 (Zyxel Firmware v4.0) fw-fr-s01-01 (pfSense v2.5.1) | Systemtest, Stichprobentest |
2 | Firewall-Rules für die Internen VLANs | nb-fr-308-01 (Win10 Pro, cmd, ping command) sw-fr-s02-01 (Zyxel Firmware v3.80) LACP-Trunk 1 sw-fr-s01-01 (Zyxel Firmware v4.0) | Systemtest |
3 | WLAN Access-Point | nb-fr-308-01 (Win10 Pro, cmd, ping command) | Systemtest |
ap-fr-308-01 ( | |||
---|---|---|---|
4 | LACP-Trunks auf den Switches | sw-fr-s01-01 (Zyxel Firmware v4.0) sw-fr-s02-01 (Zyxel Firmware v3.8) sw-fr-s03-01 (Zyxel Firmware v3.8) | Komponententest |
5 | Firewall-Rules für das VPN | fw-fr-s01-01 (pfSense v2.5.1) fw-zh-308-01 (pfSense v2.5.1) | Systemtest |
6 | Backup-Scripts und Restore | bkp-fr-308-01 (Ubuntu 20.04 LTS + BackupPC v 3.3.2-3) Pre-Backupscripts in bash v5.0-6 fw-fr-s01-01 (pfSense v2.5.1) sw-fr-s01-01 (Zyxel Firmware v4.0) sw-fr-s02-01 (Zyxel Firmware v3.8) sw-fr-s03-01 (Zyxel Firmware v3.8) | Integrationstest, Systemtest |
In diesem Kapitel finden sich die Testprotokolle für die Testfälle.
Testfall Nr. | #1 |
---|---|
Beschreibung | Test der statischen VLANs und der VLAN-Trunks |
Testperson | Projektleiter |
Testzeitpunkt | Tag 08 15:45 |
Vorgehen | Auf dem Switch sw-fr-s02-01 werden je ein statisch zugeordneter VLAN-Port in jedem aktiven VLAN getestet. Aktiv sind VLAN01_MGMT, VLAN21_CLLEARN VLAN22_CLLEARN und VLAN40_LP. In den VLANs 21 und 22 ist ein DHCP-Server aktiv, es sollte automatisch eine gültige Adresse verteilt werden. Im VLAN 01 und 40 müssen die Adressen statisch vergeben werden. Das Notebook wird nacheinander an 4 zugeordneten Ports angeschlossen und das jeweilige VLAN-Interface auf der Firewall gepingt (cmd - ping Befehl). Wenn der ICMP-Request erfolgreich beantwortet wird, heisst das, das auch der benutzte Trunk funktioniert. |
Voraussetzungen | VLAN’s sind erstellt worden auf den Switches und auf der Firewall. Auf den Switchen sind die VLAN’s Ports zugewiesen worden. Sowohl auf den Switches und auf der FW sind Trunks eingerichtet. Auf diesen Trunks sind alle VLAN’s getaggt worden. Es besteht eine physische Verbindung zwischen den Trunkports mit dem Switch und der FW. |
Erwartetes Resultat | Die Ping-Tests von allen Ports werden erfolgreich beantwortet. |
OK / nicht OK | Ok (s. untenstehende Tabelle mit den Testresultaten) |
Aufgetretene Fehler / Bemerkungen | |
Auswertung | Alle Tests wurden erfolgreich durchlaufen. |
sw-fr-02-01 | ||||
---|---|---|---|---|
Port | VLAN | Quelladresse nb-fr-308-01 | Zieladresse FW- Interface | ICMP- Anwort |
15 | VLAN01_MGMT | 172.21.1.100 (statisch) | 172.20.1.1 | ✔️ |
19 | VLAN40_LP | 172.21.40.100 (statisch) | 172.40.1.1 | ✔️ |
21 | VLAN21_CLEMPL | 172.21.21.100 (dhcp) | 172.21.21.1 | ✔️ |
25 | VLAN22_CLLEARN | 172.21.22.100 (dhcp) | 172.21.22.1 | ✔️ |
Firewall-Rules für die internen VLANs
Testfall Nr. | #2 |
---|---|
Beschreibung | Die Regeln der FW in Standort Fribourg testen. Vergleich mit der Berechtigungsmatrix. |
Testperson | Projektleiter |
Testzeitpunkt | Tag 08 16:00 |
Vorgehen | Auf dem Switch sw-fr-s02-01 werden je ein statisch zugeordneter VLAN-Port in jedem aktiven VLAN getestet. Aktiv sind VLAN01_MGMT, VLAN21_CLLEARN VLAN22_CLLEARN und VLAN40_LP. In den VLANs 21 und 22 ist ein DHCP-Server aktiv, es sollte automatisch eine gültige Adresse verteilt werden. Im VLAN 01 und 40 müssen die Adressen statisch vergeben werden. |
Das Notebook wird nacheinander an 4 zugeordneten Ports angeschlossen und die jeweiligen VLAN-Interfaces auf der Firewall gepingt (cmd - ping Befehl). Die Firewall-Interfaces sollten gemäss Berechtigungsmatrix Anwort geben. |
|
---|---|
Voraussetzungen | VLAN’s sind erstellt worden auf den Switches und auf der Firewall. Auf den Switches sind die VLAN’s Ports zugewiesen worden. Sowohl auf den Switches und auf der FW sind Trunks eingerichtet. Auf diesen Trunks sind alle VLAN’s getaggt worden. Es besteht eine physische Verbindung zwischen den beiden Trunkports mit dem Switch und der FW. Die Regeln sind gmäss Berechtigungsmatrix auf der FW konfiguriert. Für diesen Testfall benötigt man einen Client im VLAN22_CLLEARN und die GW-Adresse von VLAN21_CLEMPL |
Erwartetes Resultat | Die Ping-Tests verlaufen gemäss Berechtigungsmatrix. |
OK / nicht OK | Tests für VLAN01, 22 und 40 ok. Von VLAN 21 waren keine anderen VLANs erreichbar. |
Aufgetretene Fehler / Bemerkungen | Von VLAN21_CLEMPL waren keine anderen VLANs erreichbar. Die Kontrolle ergab, dass auf der FW für dieses Interface eine Allow-Rule fehlte. Nach Hinzufügen der Rule verlief der Test erfolgreich. |
Auswertung | Das Beispiel zeigt, dass immer wieder kleine Fehler passieren können. Für die produktive Umgebung wird deshalb empfohlen, jeden Port zu testen und nicht nur auf Stichproben zu vertrauen. |
Die Tabelle zeigt der Port und die IP-Quelladresse des Testsystems nb-fr-308-01 sowie die Zieladressen die FW-Interfaces:
sw-fr-02-01 | |||
---|---|---|---|
Port | VLAN | Quelladresse nb-fr-308-01 | Zieladresse FW-Interface |
15 | VLAN01_MGMT | 172.21.1.100 (statisch) | 172.21.1(10, 14, 15, 21-23,40, 51-53).1 |
19 | VLAN40_LP | 172.21.40.100 (statisch) | 172.21.1(10, 14, 15, 21-23,40, 51-53).1 |
21 | VLAN21_CLEMPL | 172.21.21.100 (dhcp) | 172.21.1(10, 14, 15, 21-23,40, 51-53).1 |
25 | VLAN22_CLLEARN | 172.21.22.100 (dhcp) | 172.21.1(10, 14, 15, 21-23,40, 51-53).1 |
Die Tabelle zeigt die Erwartungen (E) und die tatsächlichen Resultate (R) der Ping-Tests.
VLAN | 01 E R | 10 E R | 14 E R | 15 E R | 21 E R | 22 E R | 23 E R | 40 E R | 51 E R | 52 E R | 53 E R | 54 E R | 55 E R | WAN E R | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
01 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
21 | ❌ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ✔️ | ❌ |
22 | ❌ | ❌ | ✔️ | ✔️ | ❌ | ❌ | ✔️ | ✔️ | ❌ | ❌ | ✔️ | ✔️ | ❌ | ❌ | ✔️ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ |
40 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ |
Testfall Nr. | #5 |
---|---|
Beschreibung | Es wird getestet, ob die Regeln für den Zugriff von ZH nach FR richtig eingerichtet sind. Vergleich mit der Berechtigungsmatrix. |
Testperson | Projektleiter |
Testzeitpunkt | Tag 09 11:30 |
Vorgehen | Im Webinterface von fw-zh-308-01 unter Diagnostics den Ping- Test auswählen. Dann als Quelle das gewünschte Interface wählen, als Ziel-IP die IP-Adresse des gewünschten VLAN- Interfaces auf der Firewall fw-fr-s01-01 wählen. |
Voraussetzungen | Switch und FW die beiden Standorte sind korrekt eingerichtet. In Standort Dietikon sind die notwendigen Zertifikate und der Zertifizierung Stelle, der OpenVPN Server und der Client Overrides konfiguriert. In Standort Fribourg ist der OpenVPN Client eingerichtet und die Zertifikate und Keys importiert worden von Zürich. Zusätzlich sind zu notwendigen Regeln noch eine zusätzliche Regel auf dem VLAN01_MGMT Interface die Rule erstellt, welche den Verkehr mit der als Source VLAN21_CLEMPL von Zürich die Destination VLAN01_MGMT blockiert. Gleichzeitig wird die Rule getestet ob man von VLAN01_MGMT_ZH - VLAN01_MGMT_FR erreichen kann. So wird die Site to Site Vpn |
Erwartetes Resultat | Die Ping-Tests verlaufen gemäss Berechtigungsmatrix. |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | Alle Testresultate entsprechen den Erwartungen. |
Die Tabelle zeigt das Quell-VLAN in ZH (IP-Adresse 172.31.x.1) sowie das Ziel-VLAN (IP-Adresse 172.21.x.1) in FR sowie die erwarteten (E) sowie die tatsächlichen Resultate (R):
VLAN FR VLAN ZH
01 ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️
10 ❌❌ ✔️✔️ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌
14 ❌❌ ❌❌ ✔️✔️ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌
15 ❌❌ ❌❌ ❌❌ ✔️✔️ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌
21 ❌❌ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️ ✔️✔️
22 ❌❌ ✔️✔️ ❌❌ ✔️✔️ ❌❌ ✔️✔️ ❌❌ ✔️✔️ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌
23 ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ✔️✔️ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌
40 ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ✔️✔️ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌
51 ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ✔️✔️ ❌❌ ❌❌ ❌❌ ❌❌
52 ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ✔️✔️ ❌❌ ❌❌ ❌❌
53 ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ✔️✔️ ❌❌ ❌❌
54 ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ✔️✔️ ❌❌
55 ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ❌❌ ✔️✔️
Testfall Nr. | #6 |
---|
Beschreibung | Es wird getestet ob die Arbeitsergebnisse darunter auch die Konfigurationsdateien der Switch und der FW mithilfe des BackupPC-Servers gesichert werden können und ob gesicherten Dateien für den Restore funktionieren. |
---|---|
Testperson | Projektleiter |
Testzeitpunkt | Tag 09 13:00 |
Vorgehen | Ausführhen des Skripts auf dem BackupPC, notwendige Änderungen der Konfigurationsdateien vornehmen, (FW- Config), Restore testen. |
Voraussetzungen | BackupPC befindet sich wie beim Zustand wie der SBR-Team das vorbereitet hat Der BackupPC ist gemäss Kapitel |
Erwartetes Resultat | Die Konfigurationsdateien der Switch und der FW sind im vorerstellen Ordner vorhanden und können manuell auf den Netzwerkgeräten wieder eingespielt werden. |
OK / nicht OK | ok |
Aufgetretene Fehler / Bemerkungen | Alle Geräte funktionieren nach dem Restore wie gewünscht. |
Am Tag 1 wurde von meiner VF vorgeschlagen. die FA 2021 nochmals durchzulesen. Dadurch konnte ich am Tag 2, an dem auch der erste Expertenbesuch war, Fragen notieren. Die wichtigste Frage für mich war das Abklären bezüglich des Setzens der Firmenstandards. Im FA 2021 wurde verlangt, dass die Firmenstandards im Teil 1 des Berichts enthalten sein sollen. Dasselbe hat der HEX vorgeschlagen. Im Bericht ist aber der Firmenstandard im Teil 2 bzw. im Informieren und ebenfalls im Anhang. Auch gab der HEX eine Zusammenfassung in seinen Worten, welche kurze Schwerpunkte dieser IPA nochmals zusammenfasst. Die Analyse des Soll-Plans aus Fribourg war in der Phase Informieren die grösste Herausforderung.
Beim 1. Expertenbesuch hat der Experte die wohl grösste Herausforderung erwähnt. Nämlich die Phase Planen und Entscheiden. Diese Anmerkung habe ich zwar wahrgenommen, aber erst später wurde mir die Schwierigkeit klar. Vor allem für die Planung der Backup und Restore oder die Planung des Soll-Zustands holte ich mir die Hilfe von meiner VF. Für die Darstellung im Bericht von den beiden Meilensteinen würde ich trotzdem wahrscheinlich wieder um Hilfe bitten. Diese Meilensteine haben mich kurz aus der Bahn gebracht. Da sonst die Gliederung nicht logisch wäre, wenn man von Entscheiden zu Planen arbeitet. Dafür gab mir VF den Tipp, dass ich die Phase Entscheiden vorziehen bzw. nur für das Einrichten der Switches und der FW. Dafür soll ich aber auch gleichzeitig mit der Realisation von diesen Netzwerkkomponenten beginnen. Auch wurde mir immer klar wie wichtig Selbstdisziplin. Ich habe am Anfang vom Projekt das manuelle Backup der Konfigurationsdateien von den Switchen und der Firewall, konnte aber aufgrund Zeitdrucks dies nicht konsequent durchziehen.
Während der Phase Realisieren ist mir aufgefallen, dass ich immer wieder zurückkehren musste zu anderen IPERKA Phasen. Es wurde mir auch klar, dass man selbst wenn man dieses Projekt nach den Phasen gliedert, diese nicht einfach linear abarbeiten kann.
Zum Kontrollieren kann ich sagen, dass mir dadurch, dass ein Testkonzept verlangt und dieses auch im Planen miteinfliesst.
Ich kann sagen das dieses Projekt am Ende alles in allem gut gelungen ist. Der Stress wurde nach Tag 2 bemerkbar, dennoch konnte ich den Rückstand auf den Zeitplan immer wieder reduzieren.
Das nächste Mal würde ich das Planen noch methodischer planen. Da ich die manuelle Sicherung nicht jeden Tag durchführen konnte. würde ich mit Outlook mir einen Termin als Erinnerung am Morgen und Abend des jeweiligen Tages erstellen. Ich konnte viele Erkenntnisse aus den einzelnen Phasen mitnehmen. Die grösste ist wohl, dass selbst wenn man die Aufgabe nach Iperka gliedert, diese dennoch nicht abgearbeitet werden kann.
[1] | jacob, «iperka?,» [Online]. [Zugriff am 12 5 2021]. |
---|---|
[2] | Digitec, «Digitec,» [Online]. Available: https://www.digitec.ch/de/s1/product/zyxel-gs2200-24- 24ports-switch-233517. [Zugriff am 12 05 2021]. |
[3] | icecat. [Online]. Available: https://icecat.biz/de/p/zyxel/gs2200-48/network+switches-gs2200- 48-8157611.html. [Zugriff am 12 05 2021]. |
[4] | Digitec, «Digitec,» [Online]. Available: https://www.digitec.ch/de/s1/product/ubiquiti-unifi-ap- ac-pro-1300mbits-450mbits-access-point-5620972. [Zugriff am 12 05 2021]. |
[5] | Varia-Store, «Varia-Store,» [Online]. Available: https://www.varia- store.com/de/produkt/103302-pc-engines-apu4d2-systemboard-4x-lan-2-gb-ram.html. [Zugriff am 12 05 2021]. |
[6] | pcengines, «pcengines,» [Online]. Available: https://www.pcengines.ch/apu4d2.htm. [Zugriff am 12 05 2021]. |
[7] | P. VE, «Proxmox VE,» [Online]. Available: https://www.proxmox.com/de/proxmox- ve/funktionen. [Zugriff am 12 05 2021]. |
[8] | pfsense, «pfsense,» [Online]. Available: https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html. [Zugriff am 14 05 2021]. |
[9] | UniFI, «UniFI,» [Online]. Available: https://help.ui.com/hc/en-us/articles/360050130353-UniFi- UniFi-Overview. [Zugriff am 12 05 2021]. |
Begriff | Definition |
---|---|
Common Name | Name des Objekts ,welche validiert wird mit einem Zertifikat. |
Datendeduplikation | Ist ein Prozess, der redundante Daten identifiziert (Duplikaterkennung) und eliminiert. Wird in einem Backup-Pool beispielsweise ein Fileduplikat erkannt, wird die Datei nur einmal gespeichert und dann via Hardlinks verknüpft. |
Debian Linux | Ist ein ein Comunity gestütztes freies Betriebssystem. Debian ist eine der ältesten und weitest verbreitetsten Linux-Distributionen. Unter anderem bildet Debian die Basis der Linux-Distribution Ubuntu. |
IDS | Intrusion Detection System, ein System zur automatisierten Erkennung von Angriffen auf Computernetzwerke. Häufig ist das System Teil einer UTM- Lösung. |
Interne Zertifizierungsstelle | Zuständig für die Validierung von SSL-Zertifikaten im Web. In jedem Browser gibt es eine Datenbank mit Einträgen von verschiedenen Zertifizierungsstellen. |
KVM | KVM steht für Kernel-based Virtual Machine. KVM besteht aus einer Reihe von Kernelmodulen, welche eine Infrastruktur des Linux-Kernels zur Virtualisierung zur Verfügung stellen. Sie ist auf mit den Hardware-Virtualisierungstechniken von Intel (VT) oder AMD (AMD-V) ausgestatteten x86-Prozessoren sowie auf der System-z-Architektur lauffähig. |
LACP | Link Aggregation (kurz: LA) bedeutet die Bündelung mehrerer physischer LAN- Schnittstellen zu einem logischen Kanal. Damit kann der Datendurchsatz erhöht oder die Ausfallsicherheit verbessert werden. |
Linux Container | LXC (Linux Containers) ist ein Verfahren zur Virtualisierung auf Betriebssystemebene. LXC realisiert die Virtualisierung nicht über virtuelle Maschinen, sondern über eine virtuelle Umgebung, die zwar über eigene Prozesse verfügt, aber den Kernel des Hostsystems nutzt. |
LVM | Der Logical Volume Manager (LVM) ist ein Partitionsschema, das eine Abstraktionsebene zwischen Festplatten, Partitionen und Dateisystemen bietet. Logical Volumes können sich so auch über mehrere Festplatten erstrecken. |
Proxmox VE | Proxmox VE ist eine auf Debian basierende Open-Source- Virtualisierungsplattform. Über eine Weboberfläche können virtuelle Maschinen verwaltet und gesteuert werden. |
rsync | Rsync ist sowohl ein Programm als auch ein Netzwerkprotokoll zur Synchronisation von Daten über ein Netzwerk. Rsync erkennt auch Veränderungen innerhalb von Dateien und synchronisiert nur die veränderten Teile. |
SSL/TLS | SSL ausgeschrieben Secure Sockets Layer, ist notwendig wenn verschlüsselte Daten zwischen zwei Systemen ausgetauscht werden. TLS, Transport Secure Layer ist der Nachfolger von SSL und somit auch sicherer. |
UTM | Unified Threat Management ist ein Bündel von Sicherheitstechnologien, die auf einer einzigen Plattform vereint sind. Ziel des UTM ist es, an einem zentralen Punkt Sicherheit für das gesamte Netzwerk bereitzustellen. |
VLAN | Ein Virtual Local Area Network (VLAN) ist ein logisches Teilnetz auf einem Switch oder in einem physischen Netzwerk. Ein VLAN trennt physische Netze in Teilnetze auf, indem es dafür sorgt, dass VLAN-fähige Switches Frames (Datenpakete) nicht in ein anderes VLAN weiterleiten (obwohl die Teilnetze an gemeinsamen Switches angeschlossen sein können). |
VPN | VPN (virtual private network) bezeichnet ein privates Kommunikationsnetz. Dabei wird ein bestehendes Kommunikationsnetz, z.B. das Internet, als Transportmedium verwendet. Über verschlüsselte Verbindungen können Mitglieder eines öffentlichen Kommunikationsnetzwerkes an das bestehende Firmennetzwerk angebunden werden. |
Version | Status | Datum | Author | URL |
---|---|---|---|---|
0.1 | Erster Entwurf | 08.08.2019 | Egil Rüefli | |
0.2 | Ergänzungen | 08.09.2019 | Richi Stammherr, Tim de Vries, Silvan Dux, Egil Rüefli | |
1.0 | Review und Freigabe | 08.09.2020 | Richi Stammherr, Egil Rüefli |
VLAN Name | Kürzel | Funktion | VID | IP-Adresse | FW-Interface-Name | DHCP- Server |
---|---|---|---|---|---|---|
VLAN Management | 01 | |||||
VLAN01 | MGMT | Management | 01 | 172.16.1.0/24 | VLAN01_MGMT | ❌ |
VLAN Server | 10- 19 | |||||
VLAN10 | SRVAUTH | Server Authentifizierung | 10 | 172.16.10.0/24 | VLAN10_SRVAUTH | ❌ |
VLAN14 | SRVEMPL | Server Ausbildner | 14 | 172.16.14.0/24 | VLAN14_SRVEMPL | ❌ |
VLAN15 | SRVLEARN | Server Lernende | 15 | 172.16.15.0/24 | VLAN15_SRVLEARN | ❌ |
VLAN Clients | 20- 29 | |||||
VLAN21 | CLEMPL | Clients Ausbildner | 21 | 172.16.21.0/24 | VLAN21_CLEMPL | ✔️ |
VLAN22 | CLLEARN | Clients Lernende | 22 | 172.16.22.0/24 | VLAN22_CLLEARN | ✔️ |
VLAN23 | CLGUEST | Clients Guest (WLAN) | 23 | 172.16.23.0/24 | VLAN23_CLGUEST | ✔️ |
VLAN Drucker | 40 | |||||
VLAN40 | LP | Drucker | 40 | 172.16.40.0/24 | VLAN40_LP | ❌ |
VLAN Labor | 50- 59 | |||||
VLAN51 | LAB01 | Labor 01 | 51 | 172.16.51.0/24 | VLAN51_LAB01 | ✔️ |
VLAN52 | LAB02 | Labor 02 | 52 | 172.16.52.0/24 | VLAN52_LAB02 | ✔️ |
VLAN53 | LAB03 | Labor 03 | 53 | 172.16.53.0/24 | VLAN53_LAB03 | ✔️ |
VLAN54 | LAB04 | Labor 04 | 54 | 172.16.54.0/24 | VLAN54_LAB04 | ✔️ |
VLAN55 | LAB05 | Labor 05 | 55 | 172.16.55.0/24 | VLAN55_LAB05 | ✔️ |
Die Matrix wird Zeile nach Spalte gelesen (Zugriff von Zeile nach Spalte erlaubt/nicht erlaubt)
VLAN | 01 | 10 | 14 | 15 | 21 | 22 | 23 | 40 | 51 | 52 | 53 | 54 | 55 | WAN | OVPN-FR |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
01 | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
10 | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ |
14 | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
15 | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
21 | ❌ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ |
22 | ❌ | ✔️ | ❌ | ❌ | ❌ | ✔️ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
23 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
40 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
51 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
52 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ❌ | ✔️ | ❌ |
53 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ❌ | ✔️ | ❌ |
54 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ | ✔️ | ❌ |
55 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ✔️ | ❌ |
WAN | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ | ❌ |
OVPN-FR | ❌ | ✔️ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔️ |