Top-Themen

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit

PfSense - Kopplung dreier Netze via OpenVPN

Mitglied: FA-jka

FA-jka (Level 3) - Jetzt verbinden

11.03.2016, aktualisiert 16.03.2016, 7152 Aufrufe, 3 Danke

Wer mich kennt weiß, ich lasse nicht locker

Ich habe die letzten Wochen eingehend damit verbracht, drei Netze über eine pfSense via OpenVPN zu koppeln und möchte die gewonnenen Erfahrungen zum Einen hinterfragen und zum Anderen mit euch teilen.

Dieses Tutorial soll keine reine "Nachklickanleitung" sein. Vielmehr gehe ich auch ein bisschen darauf ein, was ich gemacht habe und warum ich das genau so gemacht habe.


Zielsetzung


Mein Testnetz besteht aus drei Standorten:
  • horn ist der "Hauptstandort". Hier hänge ich mit einer öffentlichen IP-Adresse an einer Internetfestverbindung
  • farge ist mein Home-Office. Ich befindet mich hinter einer Fritz!Box
  • gamma ist der Hyper-V eines Arbeitskollegen. Hier hänge ich als DHCP-Client an einem Router

Die grundsätzliche Netzwerkkonfiguration lautet:
  • In horn habe ich das Subnetz 10.10.10.0/24. Die pfSense heißt pfHorn und läuft auf einer APU mit der LAN-IP-Adresse 10.10.10.5
  • In farge habe ich das Subnetz 10.10.20.0/24. Die pfSense heißt pfFarge und läuft auf einer APU mit der der LAN-IP-Adresse 10.10.20.5
  • In gamma habe ich das Subnetz 10.10.30./24. Die pfSense heißt pfGamma und läuft in einer Hyper-V VM mit der LAN-IP-Adresse 10.10.30.5

In den Netzen im Home-Office und auf dem Hyper-V betrachte ich mich als "Friendly User". Wichtig war mir, dieses Verhältnis nicht überzustrapazieren und möglichst wenig Abhängigkeiten zur genutzten Infrastruktur zu haben. Auch bin ich so gar kein Freund von diesem ganzen DynDNS-Geraffel und möchte offiziell ausschließlich mit der statischen IP-Adresse am Standort horn sprechen.

Aus diesem Grund habe ich mich entschieden, die Netze via OpenVPN zu koppeln.

Pragmatisch ausgedrückt: Am Hauptstandort horn läuft der VPN-Server, die anderen beiden Netze bauen eigenständig "von innen nach außen" eine Verbindung zum Server auf und koppeln die Netze. Theoretisch könnte ich einen der Domaincontroller und die dazugehörige pfSense im Mai mit nach Ibiza schlörren, an ein LAN anstöpseln und hätte ohne weitere Veränderungen eine vollständige Netzwerkverbindung.

So sieht das aus:

6551199df7a9cba854b5d1ef50adccfa - Klicke auf das Bild, um es zu vergrößern

Grundsätzliche Überlegungen


  • Wir müssen uns ein "Transportnetz" für die im VPN verschickten Daten ausdenken. 10.10.100.0/24 drängt sich nahezu auf!
  • Wir möchten Routen auf die VPN-Clients legen. Damit der Server die Clients erkennen kann, bietet es sich an, Zertifikate zu benutzen
  • Der VPN-Server muss wissen, auf welchen Client (anhand des Zertifikates) er welches Netz schicken soll
  • Der VPN-Server muss den Clients (anhand der Zertifikate) mitteilen, welche Netze auf den anderen Clients liegen
  • Am Standort gamma gibt es eine Besonderheit: Die VMs dürfen ausschließlich via Proxy mit dem Internet kommunizieren. Auch wird dort z.B. ntp auf einen eigenen Server umgeleitet, den ich nicht benutzen möchte. Der Standort gamma soll somit sämtlichen Traffic grundsätzlich durch den VPN-Tunnel schicken

Zertifikate


Ich erstelle sämtliche Zertifikate auf der Server-pfSense am Standort horn.

Grundsätzlich benötigen wir eine Stammzertifizierungsstelle sowie Server- und Userzertifikate, die von dieser Stammzertifizierungsstelle ausgestellt bzw. signiert wurden.

Der Server benötigt mindestens:

  • Das Zertifikat der Stammzertifizierungsstelle
  • Das Serverzertifikat nebst Schlüssel
  • Es bietet sich an, hier auch den Schlüssel für die Stammzertifizierungsstelle und die User-Zertifikate nebst Schlüssel vorzuhalten

Jeder Client benötigt mindestens:

  • Das Zertifikat der Stammzertifizierungsstelle
  • Sein User-Zertifikate nebst Schlüssel

Die Stammzertifizierungsstelle


Über System -> Cert Manager rufen wir den Zertifikatsmanager auf und fügen unter dem Reiter CAs eine Stammzertifizierungsstelle hinzu:

pfhorn-ca - Klicke auf das Bild, um es zu vergrößern

pfHorn.varip.de ist übrigens auch der Hostname, den die pfSense LAN-seitig hat. An dieser Stelle muss erwähnt werden, dass Zertifizierungsstellen, Zertifikate usw. ziemlich zickig sein können, wenn die darin angegebenen Hostnamen nicht den tatsächlichen Gegebenheiten im DNS entsprechen. Also - grundsätzlich einmal mehr drüber nachdenken und sorgfältig planen...

Im Anschluss exportieren wir:

  • pf-Horn-ca.crt

Server-Zertifikat


Der VPN-Server auf pfHorn benötigt ein Zertifikat und einen Schlüssel. Dieses erstellen wir ebenfalls über System -> Cert Manager, indem wir dort den Reiter "Certificates" aufrufen. Hier mal ein Beispiel:

pfhorn-servercertificate - Klicke auf das Bild, um es zu vergrößern

Bitte beachten, dass ich unter "Certificate Type" "Server Certificate" ausgewählt habe.

Im Anschluss exportieren wir:

  • nichts

User-Zertifikate


Jeder Client (auf pfFarge und pfGamma) benötigt ein eigenes Zertifikat und einen dazu passenden Schlüssel. Dieses erstellen wir, indem wir über System -> User-Manager einen neuen Benutzer anlegen. Bei mir sieht das in etwa so aus:

425883e355a904cbb9443b524609326c - Klicke auf das Bild, um es zu vergrößern
3dc3e48e841e86bc952391964dbc3bdb - Klicke auf das Bild, um es zu vergrößern

Ich habe die User der Gruppe "OpenVPN N2N" hinzugefügt. Das ist nicht erforderlich, ich habe es aber ganz gerne ein bisschen strukturierter (Monk!).

Nach dem Anlegen gehen wir noch einmal in die Benutzerverwaltung und exportieren von dort aus:

  • pfFarge.varip.de-pfFarge.varip.de.crt
  • pfFarge.varip.de-pfFarge.varip.de.key

Und weil es so schön war, wiederholen wir das Ganze noch einmal für das User-Zertifikat pfGamma und erhalten somit ebenfalls eine .crt und einen .key

Ein abschließender Blick in den Cert-Manager von pfHorn


So sieht das bei mir aus:

pfhorn-certmanager - Klicke auf das Bild, um es zu vergrößern

Wie Ihr seht, habe ich zusätzlich neben den User-Zertifikaten für die Außenstandorte pfFarge und pfGamma auch noch ein User-Zertifikat für pfHorn und jka erstellt. Man weiß ja nie, wofür man das noch einmal gebrauchen kann

Wer den Screenshot jetzt mit seinen Ergebnissen vergleicht wird bemerken, dass in der Zeile für das Serverzertifikat von pfHorn bei "in Use" nichts drin steht. Keine Panik (42!). Sobald das Zertifikat in der VPN-Konfiguration verwurstet ist, wird sich das ändern.

Import der gewonnenen Zertifikate auf den Client-Firewalls


Wie bereits mehrfach erwähnt (lehren bedeutet Wiederholung!), benötigt jede Client-Firewall:

  • Das Zertifikat der Stammzertifizierungsstelle
  • Ihr User-Zertifikat und den Schlüssel

Wir rufen also den Cert-Manager auf der Clientfirewall auf und fügen eine neue Zertifizierungsstelle hinzu. Dieses mal generieren wir keine Zertifizierungsstelle, sondern wir importieren deren Zertifikat. Sprich: Wir öffnen die pf-Horn-ca.crt mit einem Texteditor und kopieren deren Inhalt in die dazugehörige Eingabekiste:

627fc82eef769dd8b5c180fe28642476 - Klicke auf das Bild, um es zu vergrößern

Den Schlüssel tragen wir nicht ein. Ich habe mir übrigens angewöhnt, einheitliche Namen zu verwenden. Werfen wir noch einmal einen Blick in den Zertifikatsmanager von pfHorn:

pffarge-certmanager - Klicke auf das Bild, um es zu vergrößern

Das "NO" bei "Internal" bedeutet, dass wir die Zertifizierungsstelle zwar benutzen dürfen, aber keine Zertifikate ausstellen können. Und das ist auch gut so - man stelle sich nur mal vor, auf Ibiza wird meine pfSense geklaut - die daraus resultierenden "Nacharbeiten" wären nicht zu unterschätzen

Wir rufen den Cert-Manager auf der Clientfirewall auf und fügen unter dem Reiter "Certificates" ein neues Zertifikat und dessen Schlüssel hinzu. Das Zertifikat wird ebenfalls mit Copy & Paste aus der pfFarge.varip.de-pfFarge.varip.de.crt bezogen, den Schlüssel hatten wir ja in die pfFarge.varip.de-pfFarge.varip.de.key gespeichert.

85b8b67e5fb3c0501e73f20d83411ae0 - Klicke auf das Bild, um es zu vergrößern

NAT (=NAT rules!^^)


Jede pfSense hat so genannte NAT-Regeln. Salopp gesagt beschreiben die NAT-Regeln, welche Quellnetze auf welche Schnittstelle geschickt werden. Auch hier wieder ein paar Überlegungen vorab:

  • Jede Firewall schickt ihren eigenen Traffic ins Internet (also alles, was von 127.0.0.0/8 kommt)
  • Jede Firewall schickt den Traffic aus ihrem eigenen Netz ins Internet
  • Jede Firewall schickt den Traffic aus dem OpenVPN-Transportnetz (10.10.100.0/24) ins Internet
  • Da wir den gesamten Datenverkehr von pfGamma durch den Netzwerktunnel schieben, schickt die Server-Firewall pfHorn auch Datenpakete aus deren lokalen Netz ins Internet

Die NAT-Regeln finden wir unter Firewall -> NAT auf dem Reiter "Outbound". Da wir grundsätzlich alles besser wissen, setzen wir den Radioknopf "Manual Outbound NAT rule generation (AON - Advanced Outbound NAT)" und klicken einmal beherzt auf Speichern. Danach erstellen wir das Regelwerk. Hier ein Bildschirmfoto von der Server-Firewall pfHorn:

9cd580b9cde57468adcbf54057e589fa - Klicke auf das Bild, um es zu vergrößern

Ihr seht, dass es für jedes ausgehende Mapping zwei Pendants gibt (eine Regel für den statischen Port 500, eien Regel für "alles"). Kleiner Tipp: Ihr könnt eine vorhandene Regel als Vorlage benutzen, indem Ihr neben der Regel auf den Button mit dem e klickt).

Wir erinnern uns an unsere Strategie:

  • Am Server-Standort horn funktioniert die pfSense als klassiches Gateway. Also gehen wir dort erst einmal mit dem Netz von horn und dem OpenVPN-Transportnetz raus
  • Am Standort farge werden nur die Datenpakete für die Netze in horn und gamma in den VPN-Tunnel gesteuert. Diese werden innerhalb unserer eigenen Struktur terminiert und müssen daher nicht(!) genattet werden. Darum gibt es hier kein Mapping für 10.10.20.0/24
  • Am Standort gamma wird der gesamte Datenverkehr in den VPN-Tunnel geschickt. Das können auch Datenpakete für das Internet sein. Darum gibt es hier das Mapping für 10.10.30.0/24

Das ist wie gesagt der Server pfHorn. Noch einmal zur Wiederholung:

  • Der Server schickt seinen gesamten "internen" Datenverkehr (DNS-Abfragen, NTP-Abfragen usw.) ins Internet.
  • Der Server schickt alles aus seinem eigenen LAN ins Internet
  • Der Server schickt alles aus dem Netz von pfGamma (das ist das Netz, dass via VPN reinkommt komplett ins Internet geroutet werden soll) ins Internet
  • Der Server schickt alles aus dem VPN-Transportnetz (10.10.100.0/24) ins Internet

Aus Gründen der Vollständigkeit zeige ich hier die Mappings der anderen beiden Firewalls:

8603d4aebb951be04ac2dca788806b49 - Klicke auf das Bild, um es zu vergrößern
07e578975681b7b7dc04dc8e01a8413c - Klicke auf das Bild, um es zu vergrößern

Firewall-Regeln


Die Netze zu verbinden ist eine Sache. Wichtig ist natürlich auch, dass die Netze miteinander sprechen (dürfen). Unter Firewall -> Rules wird unter dem Reiter "OpenVPN" festgelegt, wer was darf. Hier meine Regel:

26d06e66c160b9433060238cf6bb248a - Klicke auf das Bild, um es zu vergrößern

Deren Bedeutung: "Alles, was über OpenVPN geht ist netzwerktechnisch vertrauenswürdig und darf alles, was die Computer im jeweiligen LAN dürfen". Eine derartige Regel gibt es natürlich auf allen drei Firewalls.

Hier noch einmal die Regel im Detail:

e3982317bf0e7a572da334abb9a6ae2d - Klicke auf das Bild, um es zu vergrößern

Der OpenVPN-Server hört auf Port 1194 (UDP) und muss von aussen erreichbar sein. Die dazugehörige Regel definieren wir unter Firewall -> Rules, dieses Mal unter dem Reiter "WAN":

b73d43546ba742870da0aeb80d376c4f - Klicke auf das Bild, um es zu vergrößern

Auch diese Regel vermag ich noch einmal detailliert aufzuzeigen:

d2c4336d3bdecff400ebc7238013f091 - Klicke auf das Bild, um es zu vergrößern

VPN-Konfiguration


VPN-Server


Im Menü VPN -> OpenVPN fügen wir unter dem Reiter "Server" einen neuen Server hinzu:

a6315bc55aac7460177b5dca8cbc6469 - Klicke auf das Bild, um es zu vergrößern
33694736bb005986dfb92f3c52542e43 - Klicke auf das Bild, um es zu vergrößern

Bitte ein paar Details beachten:
  • "Server Mode" ist "Peer to Peer (SSL/TLS)"
  • "Local Port" und "Protocol" entspricht unserer Firewall-Regel (1194 UDP)
  • "Peer Certificate Authority" zeigt auf die Stammzertifizierungsstelle
  • "Server Certificate" zeigt auf das Server-Zertifikat
  • "IPv4 Tunnel Network" beinhaltet das Tunnelnetz (siehe NAT-rules)
  • "IPv4 Remote Network/s" beinhaltet die Netze der Client-Firewalls, getrennt durch ein Komma

Nachdem wir den Tunnel hinzugefügt haben, sieht das Ganze dann so aus:

5d81e1cc82973bf52eaf2103711f8dc7 - Klicke auf das Bild, um es zu vergrößern

Wie benötigen den TLS-Key für die Clients. Also klicken wir neben dem jüngst geschaffenen VPN-Server noch einmal auf den Edit-Button.

7a91454020d66ca9feb77d36acab6f9a - Klicke auf das Bild, um es zu vergrößern

Den vollständigen Inhalt des Feldes "TLS Authentication" kopieren wir in die Zwischenablage und speichern ihn in einer Textdatei.

Damit weiß der OpenVPN-Server grundsätzlich, welche Netze er ins OpenVPN routen soll. Aber woher soll er wissen, auf welchem der Clients er das Netz finden soll?

Wir gehen noch einmal in das Menü VPN -> OpenVPN und widmen uns dem Reiter "Client Specific Overrides". Für die beiden Firewall in farge und gamma fügen wir eine clientspezifische Konfiguration hinzu. Zuerst die pfSense in farge:

a0cd5587a4c05711ade3a35d9b74eab5 - Klicke auf das Bild, um es zu vergrößern
587dca9caac69cfeb86c4201ff4f2166 - Klicke auf das Bild, um es zu vergrößern

Auch hier wieder die bewährte Zusammenfassung der relevanten Informationen:

  • "Common Name" ist der Name des Zertifikates (siehe oben!). Bitte minutiös eingeben (ich hatte da versehentlich ein Leerzeichen am Ende...)
  • "Tunnel Network" ist unser Tunnelnetz (siehe NAT-rules und Konfiguration des OpenVPN-Servers)
  • "IPv4 Remote Network/s" sind die Netze, die der OpenVPN-Server in farge findet
  • "Advanced": Der ifconfig-push Befehl gibt dem Server und dem Client für genau diese Verbindung jeweils eine statische IP-Adresse im Tunnel
  • "Advanced": Der push-Befehl sagt dem Client nach dem Verbindungsaufbau, welche Netze er über den OpenVPN-Server erreichen kann. In diesem Fall pfHorn zu pfFarge: "Hey - das Netz von pfGamma findest Du übrigens über mich"

Eine Anmerkung zu den statischen IP-Adressen im Tunnel (ifconfig-push): Diese Adressen müssen zusammenpassen. Dazu ein passendes Zitat aus der OpenVPN-Howto:
Die Clientspezifische Konfiguration für gamma unterscheidet sich in einigen Punkten:

2c5fa199a104e674fe23fdc3aae39078 - Klicke auf das Bild, um es zu vergrößern
dfd12dfcbca0ed1e7ca800ccc910f3dc - Klicke auf das Bild, um es zu vergrößern

  • "Common Name" ist der Name des Zertifikates
  • "Tunnel Network" ist unser Tunnelnetz (siehe NAT-rules und Konfiguration des OpenVPN-Servers)
  • "IPv4 Remote Network/s" sind die Netze, die der OpenVPN-Server in gamma findet
  • "Redirect Gateway": Wir erinnern uns - in gamma gibt es den Proxy-Server, den wir nicht benutzen möchten. Also schicken wir von dort aus den gesamten Traffic in das VPN
  • "Advanced": Der ifconfig-push Befehl gibt dem Server und dem Client für genau diese Verbindung jeweils eine statische IP-Adresse im Tunnel. Das ist ein anderes Adresspaar als in der clientspezifischen Konfiguration von pfHorn...(!!!)
  • "Advanced": Der push-Befehl sagt dem Client nach dem Verbindungsaufbau, welche Netze er über den OpenVPN-Server erreichen kann. In diesem Fall pfHorn zu pfGamma: "Hey - das Netz von pfFarge findest Du übrigens über mich"

VPN-Client


Auch wenn der Client-Dialog auf pfFarge und pfGamma etwas länger ist, soll uns das nicht abschrecken. Im Gegenteil - da wir uns gedanklich an unsere Beispielkonfiguration gewöhnt haben und diese gepflegt auswendig kennen, beschränkt sich das auf ein reines Eintippen der Informationen

32356ed7642d17a019b0ac5be8e88675 - Klicke auf das Bild, um es zu vergrößern
4347488e4d29edf11672e4a23d8814d6 - Klicke auf das Bild, um es zu vergrößern
6079ac85b79b9eeb6438f737b74b814a - Klicke auf das Bild, um es zu vergrößern
248e0796944cbf589635c3827338b8ff - Klicke auf das Bild, um es zu vergrößern

Wichtige Informationen:

  • "Server Mode" ist "Peer to Peer (SSL/TLS)"
  • "Server port" und "Protocol" ist wieder 1194 (UDP), vergleiche u.A. die Filterregel und die OpenVPN-Konfiguration auf der Server-Firewall
  • "Server host or address" ist der externe Name der Server-Sense in horn. Dies kann eine IP-Adresse oder ein Hostname sein
  • "User Authentication Settings" lassen wir leer(!). Hier werden auch nicht die Daten eingetragen, die wir beim Ersteller der User-Zertifikate eingetragen haben!
  • "User Name/pass" lassen wir leer - auch wenn wir beim Anlegen des Benutzers ursprünglich Zugangsdaten festgelegt haben...
  • "TLS Authentication": Den Schlüssel haben wir erhalten, als wir auf der Serverfirewall noch einmal das eingerichtete Profil editiert haben. Dieser wird hier mit Copy & Paste eingefügt
  • "Peer Certificate Authority" ist die Stammzertifizierungsstelle, die wir hier importiert hatten
  • "Client Certificate" haben wir auf der pfHorn über den "User Manager" expor- und hier importiert
  • "IPv4 Tunnel Network" kennen wir ebenfalls zur Genüge (unser Transportnetz...)
  • "IPv4 Remote Networks" ist *nur* das Netzwerk auf der Server-Firewall pfHorn. Verlockend wäre "eigentlich", hier auch noch das Netzwerk in gamma einzutragen. Aaaaber - diese Information bekommen wir ja über die clientspezifische Konfiguration gepusht...

Status


Wenn wir unter Services -> OpenVPN den Status aufrufen, bekommen wir nicht nur den Verbindungsstatus angezeigt. Mit der Schaltfläche darunter erhalten wir nach einer gewissen Kalkulationszeit die Routing-Tabelle angezeigt.

pfhorn-status - Klicke auf das Bild, um es zu vergrößern

Wie wir hier sehen können, haben bereits einige Hosts Verbindung über den VPN-Tunnel aufgenommen. Diese Verbindungen werden mit C angezeigt.
Ähnliche Inhalte
Tipps & Tricks
OpenVPN Delegationen
Anleitung von agowa338Tipps & Tricks

Hallo, in dieser Anleitung möchte ich nur kurz erklären, wie man OpenVPN (unter Windows) am besten für Außendienst Mitarbeiter ...

Firewall
PfSense OpenVPN beschleunigen
Tipp von 108012Firewall

Hallo zusammen, ich nutze zwar nur ausschließlich IPSec VPN aber habe gerade mit einem Bekannten zusammen ein paar OpenVPN ...

E-Mail

Drei kritische Sicherheitslücken im Mail-Client Thunderbird

Information von FrankE-Mail2 Kommentare

Im Mail-Client Thunderbird gibt es bis einschließlich Version 52.4 drei kritische Sicherheitslücken. Dabei handelt es sich um CVE-2017-7826, CVE-2017-7828 ...

Sicherheit

Diverse D-Link-Router durch drei Schwachstellen kompromittierbar

Information von kgbornSicherheit1 Kommentar

Hat jemand D-Link-Router in Verwendung? Einige Modelle sind sicherheitstechnisch offen wie ein Scheunentor. Äußerst unschöne Sache, aber nichts neues ...

Neue Wissensbeiträge
E-Books

Ausgewählte Rheinwerk-Bücher jetzt online lesen! Kostenfrei

Information von Maxima2005 vor 18 StundenE-Books1 Kommentar

Vielleicht hat ja jemand Interesse sein Wissen zu erweitern. Ausgewählte Rheinwerk-Bücher jetzt online lesen! Grüße Max

Instant Messaging
Jitsi Meet - April Update verfügbar
Information von Frank vor 20 StundenInstant Messaging4 Kommentare

Im Rahmen des April-Updates erhält Jitsi Meet mehrere interessante Features. Anwender können nun nicht mehr nur ihren Bildschirm, sondern ...

Rechtliche Fragen

Rechtliche Grundlagen: Datenschutz und Datensicherheit im Homeoffice

Information von AnkhMorpork vor 1 TagRechtliche Fragen

Sollte bekannt sein, aber

Router & Routing
"Upgrade" Fritte 7520 zu Fritte 7530 :-)
Information von Lochkartenstanzer vor 1 TagRouter & Routing6 Kommentare

Moin, wie sich herausgestellt hat, ist die 7520 eine per Software kastrierte Version der 7530. Per "Chiptuning", um es ...

Heiß diskutierte Inhalte
Server-Hardware
Wie viel Speicher braucht eine Wissensdatenbank für bis zu 50 User?
Frage von Mrhallo19981Server-Hardware38 Kommentare

Hallo, könnt ihr mir sagen wieviel Speicherplatz eine Wissensdatenbank braucht (die physikalisch speichert, also nicht mit einer Datenbank zusammen) ...

Rechtliche Fragen
Nachweispflicht für Status-Emails?
Frage von VincentGdGRechtliche Fragen36 Kommentare

Moin. Mein Kollege und Datenschutzbeauftragter erfreut mich täglich mit neuen Auslegungen. Heute erklärt er mir, wir müssen die Status-Emails, ...

Festplatten, SSD, Raid
Festplatten Datenvernichtung Server
Frage von survial555Festplatten, SSD, Raid29 Kommentare

Hallo, ich habe noch ein paar alte Server, wo ich die verbauten Festplatten gerne datentechnisch "sicher" löschen möchte. Leider ...

Linux
Internetprobleme mit Wine für Linux um .exe Dateien auszuführen
Frage von WinLiCLILinux22 Kommentare

Hallo zusammen, ich möchte auf meinem debian 10 einen client für cloud-telefonie (cloud pbx) installieren, den es nur für ...