Des Öfteren erinnere ich Kollegen daran, doch bitte bei Upgrades in einer Remoteshell mit einem terminal mutliplexer zu arbeiten. Falls doch einmal die Verbindung abbricht, nicht ein halb installiertes, oder konfiguriertes Paket vorliegt. Das kann viel und sehr unangenehme Arbeit auslösen.
Man glaubt es kaum, den Fakt habe ich bei meiner Firewall in meinem Homeoffice die letzten Jahre ignoriert.
Bei dem Upgrade von opnSense via SSH hatte ich leider die aktive Terminalverbindung zur Firewall geschlossen und mir somit die Installation meiner Firewall im laufenden Betrieb zerstört. An sich wäre die Situation ja noch via Shell rettbar gewesen, aber just hatte ich in dem Moment die Verbindung gekappt, welche die libSSL löschte. Ein Zugang via SSH ist nicht somit mehr möglich gewesen. Die Abhängigkeit der libcrypto machte mir nun ein Strich durch die Rechnung.
kex_exchange_identification: Connection closed by remote host, lautet die Fehlermeldung bei einem Versuch der Wiederaufnahme der Remoteverbindung via SSH. Aber ich konnte mich ja noch via Weboberfläche verbinden und von dort aus die Installation fortsetzen. Glänzende Idee. Ein schlechter Ausgang. Ich kann das Paket libSSL nicht mehr reinstallieren, da die heruntergeladenen Pakete ohne das Paket libSSL nicht validieren kann. Ich stecke in der Mitte des Upgrades fest.
Im gekonnten Unixstil läuft die Firewall selbst aus dem RAM noch weiter. Ich konnte erst einmal weiterarbeiten, um am Wochenende via seriellen Anschluss opnSense neu zu installieren. Da ich tägliche Backups der Konfigurationsdateien automatisch vornehmen lasse, XML-Dateien via API, könnte ich opnSense neu installieren und rekonfigurieren.
Ich sah dies aber Startschuss mir neue Hardware zu bestellen und somit auf eine potentere Hardware inklusive 2.5 GBs Netzwerkkarten anstelle der 1 GBs Netzwerkkarten umzusteigen.
Hohe Verlässlichkeit der PCEngines APU1D4
Seit 2016 lief die Hardware von PCEngines dauerhaft und schützte unsere Infrastruktur. Am Anfang mit pfSense (hinter dem internen Link findet sich auch die Auflistung der Hardwarekomponenten), ab September 2018 mit opnSense. Geschenkt bekommen habe ich die Hardware von David D. aus der Schweiz. Ein toller Mensch und der Patenonkel meines Sohnes.
Wir besitzen eine Leitung mit einer Geschwindigkeit von 500MBit/s und einer festen IP. Das Internetgrundrauschen und den von uns erzeugten Verkehr durch ein zwei Personen Homeoffice, inklusive 13-Jährigen Sohn, etc., kommt es zu einem großen Datendurchsatz.
Der Wechsel auf einen Produktnachfolger aus dem Hause PCEngines war schon länger eine beschlossene Sache, vor allem die 4 GB RAM und die 1 GB/s NICS, sowie die CPU, kamen langsam in das Schwitzen.
In Zukunft wollte ich ein Upgrade der Leitung in unsere Wohnung auf 1 Gbit/s vornehmen. Ich warte hier aber noch darauf, dass der Upstream auf Minimum 100 MB/s erfolgt. Also begann ich eine Suche nach einer Alternative bei PCEngines. Bedauerlicherweise habe ich festgestellt, dass diese Firma inzwischen die Herstellung aufgegeben hat.
Der Nachfolger HUNSN RJ03
Nach einer längerer Suche habe ich mich dann für eine HUNSN RJ03 mit folgenden Spezifikationen entschieden:
Modellnummer: HUNSN RJ03
Gehäuse: Aluminium, mit Knockout-Loch, Verdrahtung der Kabel an den externen
CPU: Intel Celeron Prozessor N5105 (4M Cache, bis zu 2,90 GHz)
Unterstützt AES-NI: Ja
Speicher: 2 x sodimm ddr4 2933 MHz, max.32gb
Speicher: 2 x m.2 2280 PCIE3.0 1x nvme SSD und 1 x 2,5 Zoll sata SSD/HDD
Netzwerkkarte: Intel 2.5GbE I226-V, UDE eingebauter Filteranschluss
E/A-Schnittstelle: Power ON/OFF, CLR CMOS, 2 x USB3.0, Typ-C für Display/USB, TF, 2 x USB2.0, HDMI, DP, 4 x LAN, DC_IN
Erweiterung: M.2 WiFi 6 (kontaktieren Sie HUNSN, um es anzupassen)
Stromversorgung: Dc100-240v ac/50-60hz, 12v/3a
Betriebstemperatur: 0°c~70°c
Lagertemperatur: -20°c~80°c
Relative Luftfeuchtigkeit: 10 %~90 % (nicht kondensierend)
TDP: 10w
Kühlsystem: Lüfterlos, 80 x 80 mm Löcher, Unterstützung für 12v 4 pin 8010 Lüfter
Größe: 178 x 126 x 55 mm
Gewicht: 1.5 kg
Packliste: HUNSN RJ03 Firewall-Gerät, Netzteil, Netzkabel, Garantiekarte
Funktion: Unterstützt automatisches Einschalten der Hardware (standardmäßig aktiviert), WoL, System-Energiemanagement, Temperaturmanagement
Bei der Bestellung (Externer Link zu Amazon, ohne Affiliate) wählte ich eine Konfiguration mit 16 GB RAM und eine 512 GB SSD 4 x 2.5 GbE für 361,99 €
Um Auskunft über die von mir angegebenen Komponenten zu erhalten, wurden folgende Befehle in der Shell genutzt:
root@FIREWALL:~ # grep -E 'nvd0' /var/run/dmesg.boot
nvd0: <INTEL SSDPEKNU512GZ> NVMe namespace
nvd0: 488386MB (1000215216 512 byte sectors)
nvd0: <INTEL SSDPEKNU512GZ> NVMe namespace
nvd0: 488386MB (1000215216 512 byte sectors)
nvd0: <INTEL SSDPEKNU512GZ> NVMe namespace
nvd0: 488386MB (1000215216 512 byte sectors)
nvd0: <INTEL SSDPEKNU512GZ> NVMe namespace
nvd0: 488386MB (1000215216 512 byte sectors)
root@FIREWALL:~ # dmidecode | grep -10 'Size: 8 GB'|grep Manufacturer
Manufacturer: SK Hynix
Module Manufacturer ID: Bank 1, Hex 0xAD
Memory Subsystem Controller Manufacturer ID: Unknown
Manufacturer: SK Hynix
Module Manufacturer ID: Bank 1, Hex 0xAD
Memory Subsystem Controller Manufacturer ID: Unknown
root@FIREWALL:~ # dmidecode | grep -12 'Size: 8 GB' | grep Speed
Speed: 2400 MT/s
Configured Memory Speed: 2400 MT/s
Speed: 2400 MT/s
Configured Memory Speed: 2400 MT/s
root@FIREWALL:~ # dmidecode | grep -12 'SK Hynix'|grep 'Part Number'
Part Number: HMA81GS6AFR8N-UH
Part Number: HMA81GS6AFR8N-UHVerbaut wurden hier die SSD 670p SSDPEKNU512GZ von Intel, sowie zwei 8 GB Speicherriegel von SK Hynix mit der Teilenummer HMA81GS6AFR8N-UH. Der Hersteller benötigte für die Lieferung 8 Tage.
Inbetriebnahme und Betrieb mit opnSense
Das Leben kann auch einmal schön sein, vor allem wenn ich meine Firewall nicht mehr mit einem seriellen Kabel installieren muss.
Ich konnte opnSense sehr einfach via dem VGA Image auf einem USB-Stick, einer Tastatur und einem via HDMI verbundenen Monitor installieren. Da die PCEngines APU noch lief, habe ich hier ein frisches Backup der Konfiguration inkl. der Daten der Graphen gemacht und wollte dieses dann auch gleich einspielen.
Welches natürlich nicht funktionieren kann. Die PCEngines APU unterliegt einer anderen Benamung der Netzwerkkarten und somit kann das Pendant von HUNSN mit dieser nichts anfangen und meldete diese als absent. Mit Ruhm habe ich mich in dem Moment nicht bekleckert, aber es ist immer wieder schön, wenn man auch über sich selbst einmal lachen kann.
Als Lösung habe ich WAN von re0 in igc0 und LAN re2 von in igc1 in der Konfigurationsdatei geändert. Somit wurden die alten Einstellungen übernommen. Alles lief OOTB. Später stellte ich noch fest, dass der ACME-Client nicht wirklich seine Arbeit wie zuvor erledigte, hier löste aber eine nochmalige Abspeicherung der Einstellungen das Problem.
Fazit
Der Industrierechner von HUNSN erledigt seine Arbeit seit mehr als 94 Tagen zu meiner Zufriedenheit und bietet mir die gleichen Eigenschaften wie die PCEngines APU. Passiv gekühlt, die Betriebstemperaturen und die Robustheit eines Industrie-PCs. Dies waren für mich neben der Geschwindigkeit der Hardware, sowie der Herstellerkomponenten, der Grund für meine Wahl. Die PCEngines APU selbst wird nochmals mit opnSense konfiguriert und als Ersatz für einen Ausfall der neuen Hardware vorbereitet. Wer mitrechnete, PCEngines APU lief 9 Tage nur aus dem RAM.