Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

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
GELÖST

OpenVPN-Verbindung wird bei Last unterbrochen

Frage Sicherheit Firewall

Mitglied: atbs84

atbs84 (Level 1) - Jetzt verbinden

14.01.2011, aktualisiert 18.10.2012, 7643 Aufrufe, 15 Kommentare, 1 Danke

Grüße, Admins!
Ich habe auf einer pfsense Installation den openVPN-Server aktiviert (mit Zertifikaten). Als Clients setze ich Windows 7 64bit ein. Meine Verbindung ist VDSL25, der Server steht "in der Nähe" (Deutschland) und hat eine Breitbandanbindung (Standleitung). Als Router / Firewall / VPN-Server läuft ein PCengines alix2 mit pfsense. Last durch andere Nutzer / Dienste ist auszuschließen.

Den Client habe ich zum Laufen bekommen und habe auch schon mehrmals problemlos VPN-Verbindungen mit viel "Last" herstellen können.
Nun tritt leider das Problem auf, dass die Verbindung plötzlich nicht mehr funktioniert, sobald ich irgend ein Protokoll einsetze, was etwas mehr Last als Ping & nslookup auf der VPN-Verbindung erzeugt. Konkret sind das bei mir Remotedesktop auf den Windows-Server hinter der Firewall und SCP auf einen Linux-Server.
Also: Verbindung mit openVPN herstellen klappt immer wunderbar und geht fix. Nslookup und ping sind auch kein Problem aber sobald ich eine RDP-Sitzung öffnen will oder einen SCP-Transfer initiiere, kommen keine ICMP-Antworten mehr (im Hintergrund ein ping -t).

Komisch daran: Weder im openVPN-Server noch im Client sagt das Logfile irgendetwas aus. Im Server steht gar nichts und im Client kommt irgendwann eine Timeout-Meldung und dann ein Reconnect welcher auch funktioniert. Allerdings bricht die Verbindung bei Last wieder zusammen. Das seh ich an den ICMP-Antworten, die versiegen sobald ich RDP oder SCP nutzen will.

Noch komischer: Auf meinem ersten Client hat es zunächst einwandfrei funktioniert. Plötzlich trat das Problem auf und ich richtete openVPN auf dem zweiten Client ein um das Problem einzukreisen. Da funktionierte es auch für einige Zeit problemlos, bis es dann auch nicht mehr ging. Auf beiden Clients habe ich bisher nie wieder eine fehlerfreie Verbindung bekommen. Ich könnte wetten, der 3. Client machts auf für ein paar Tage und dann ist Feierabend.

Wireshark auf dem Client bringt viele mit "TCP Window Full" markierte Pakete. Woran könnte das liegen?

Bin für sämtliche Ideen dankbar, ich bin mit meinem Latein am Ende (ist so ein blödes "ging doch mal und plötzlich nicht mehr"-Problem)
Mitglied: masterofdisaster09
14.01.2011 um 22:46 Uhr
Spontan aus dem Bauch heraus würde ich es mal mit einer reduzierten MTU versuchen.
In der client- und server-conf folgende Zeile einfügen:
tun-mtu 1400
Bitte warten ..
Mitglied: aqui
15.01.2011, aktualisiert 18.10.2012
Das wäre einen Versuch wert in der Tat. Ebenso wäre einmal interessant was die CPU Last im ALIX sagt ??
Generell kann das ALIX solche Bandbreiten problemlos verkraften, nebenbei erzeugt RDP ja nun auch nur minimalen Traffic..generell also kein Problem.
Bist du nach folgender Anleitung vorgegangen: ??
http://www.administrator.de/wissen/openvpn-server-installieren-auf-dd-w ...
Hast du ggf. noch einen Router VOR der pfSense ??
Bitte warten ..
Mitglied: atbs84
17.01.2011 um 09:55 Uhr
Das mit der MTU werde ich ausprobieren. Klingt einerseits vielversprechend, andererseits frage ich mich warum ich zuvor mehrfach funktionierende Verbindungen aufbauen konnte ohne die MTU zu reduzieren...

Die CPU-Last werde ich mir auch mal anschauen. Wobei ich denke, dass die Anbindung ans Internet eigentlich zu wenig Bandbreite hat, um die CPU auszulasten.

Der Anleitung bin ich in etwa gefolgt. Habe das ganze noch um eine AD-Authentifizierung erweitert (Auth LDAP Plugin).
Einen weiteren Router vor der Firewall betreibe ich nicht.
Bitte warten ..
Mitglied: atbs84
21.01.2011 um 15:01 Uhr
OK, ich war heut in der Firma und habe die MTU mal auf 1400 geändert. Der Test mit dem Notebook an der WAN-Schnittstelle des Routers hat auch geklappt. Da gab es allerdings auch nie Probleme. Von zu hause aus kann ich aber weiterhin keine anständige Verbindung aufbauen. Im Prinzip hat sich nichts geändert.

In der Server-Konfiguration steht in dem Feld "custom options" (pfsense GUI) nur der Eintrag zum LDAP Auth Plugin und davon mit Semikolon getrennt "tun-mtu 1400".

Die Konfiguration des Clients:
01.
client 
02.
dev tun 
03.
proto udp 
04.
remote XXX.XXX.XXX.XXX 1194  
05.
resolv-retry infinite 
06.
nobind 
07.
persist-key 
08.
persist-tun 
09.
ca "C:/Program Files (x86)/OpenVPN/easy-rsa/keys/ca.crt" 
10.
cert "C:/Program Files (x86)/OpenVPN/easy-rsa/keys/client2.crt" 
11.
key "C:/Program Files (x86)/OpenVPN/easy-rsa/keys/client2.key" 
12.
ns-cert-type server 
13.
comp-lzo 
14.
verb 3 
15.
auth-user-pass 
16.
push "route 192.168.70.0 255.255.255.0" 
17.
tun-mtu 1400
Hier mal das Log des Clients während des Verbindungsaufbaus:
01.
Fri Jan 21 14:41:20 2011 OpenVPN 2.2-beta3 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Sep  2 2010 
02.
Fri Jan 21 14:41:25 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables 
03.
Fri Jan 21 14:41:25 2011 LZO compression initialized 
04.
Fri Jan 21 14:41:25 2011 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400) 
05.
Fri Jan 21 14:41:25 2011 Control Channel MTU parms [ L:1442 D:138 EF:38 EB:0 ET:0 EL:0 ] 
06.
Fri Jan 21 14:41:25 2011 Socket Buffers: R=[8192->8192] S=[8192->8192] 
07.
Fri Jan 21 14:41:25 2011 Data Channel MTU parms [ L:1442 D:1442 EF:42 EB:135 ET:0 EL:0 AF:3/1 ] 
08.
Fri Jan 21 14:41:25 2011 Local Options hash (VER=V4): 'a6ae7d69' 
09.
Fri Jan 21 14:41:25 2011 Expected Remote Options hash (VER=V4): '006a55ce' 
10.
Fri Jan 21 14:41:25 2011 UDPv4 link local: [undef] 
11.
Fri Jan 21 14:41:25 2011 UDPv4 link remote: XXX.XXX.XXX.XXX:1194 
12.
Fri Jan 21 14:41:25 2011 TLS: Initial packet from XXX.XXX.XXX.XXX:1194, sid=54d5ff99 3ceb2123 
13.
Fri Jan 21 14:41:25 2011 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 
14.
Fri Jan 21 14:41:26 2011 VERIFY OK: depth=1, /C=DE/ST=XXX/L=XXX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX 
15.
Fri Jan 21 14:41:26 2011 VERIFY OK: nsCertType=SERVER 
16.
Fri Jan 21 14:41:26 2011 VERIFY OK: depth=0, /C=DE/ST=XXX/O=XXX/OU=XXX/CN=XXX/emailAddress=XXX 
17.
Fri Jan 21 14:41:26 2011 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key 
18.
Fri Jan 21 14:41:26 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 
19.
Fri Jan 21 14:41:26 2011 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key 
20.
Fri Jan 21 14:41:26 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication 
21.
Fri Jan 21 14:41:26 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA 
22.
Fri Jan 21 14:41:26 2011 [openvpn_server] Peer Connection Initiated with XXX.XXX.XXX.XXX:1194 
23.
Fri Jan 21 14:41:28 2011 SENT CONTROL [openvpn_server]: 'PUSH_REQUEST' (status=1) 
24.
Fri Jan 21 14:41:28 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.168.70.0 255.255.255.0,dhcp-option DOMAIN XXX,dhcp-option DNS 192.168.70.110,dhcp-option WINS 192.168.70.110,route 192.168.71.1,ping 10,ping-restart 60,ifconfig 192.168.71.6 192.168.71.5' 
25.
Fri Jan 21 14:41:28 2011 OPTIONS IMPORT: timers and/or timeouts modified 
26.
Fri Jan 21 14:41:28 2011 OPTIONS IMPORT: --ifconfig/up options modified 
27.
Fri Jan 21 14:41:28 2011 OPTIONS IMPORT: route options modified 
28.
Fri Jan 21 14:41:28 2011 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified 
29.
Fri Jan 21 14:41:28 2011 ROUTE default_gateway=192.168.2.55 
30.
Fri Jan 21 14:41:28 2011 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{B7928640-66D5-49D1-96FF-7B1B4EE937B5}.tap 
31.
Fri Jan 21 14:41:28 2011 TAP-Win32 Driver Version 9.8  
32.
Fri Jan 21 14:41:28 2011 TAP-Win32 MTU=1500 
33.
Fri Jan 21 14:41:28 2011 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.71.6/255.255.255.252 on interface {B7928640-66D5-49D1-96FF-7B1B4EE937B5} [DHCP-serv: 192.168.71.5, lease-time: 31536000] 
34.
Fri Jan 21 14:41:28 2011 Successful ARP Flush on interface [23] {B7928640-66D5-49D1-96FF-7B1B4EE937B5} 
35.
Fri Jan 21 14:41:33 2011 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up 
36.
Fri Jan 21 14:41:33 2011 C:\WINDOWS\system32\route.exe ADD 192.168.70.0 MASK 255.255.255.0 192.168.71.5 
37.
Fri Jan 21 14:41:33 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4 
38.
Fri Jan 21 14:41:33 2011 Route addition via IPAPI succeeded [adaptive] 
39.
Fri Jan 21 14:41:33 2011 C:\WINDOWS\system32\route.exe ADD 192.168.71.1 MASK 255.255.255.255 192.168.71.5 
40.
Fri Jan 21 14:41:33 2011 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4 
41.
Fri Jan 21 14:41:33 2011 Route addition via IPAPI succeeded [adaptive] 
42.
Fri Jan 21 14:41:33 2011 Initialization Sequence Completed
Wird nun eine MTU von 1400 benutzt oder nicht? Was läuft da falsch? Was kann ich noch probieren?
Bitte warten ..
Mitglied: aqui
21.01.2011 um 19:35 Uhr
Sieh doch einfach mal ins Log ...
Fri Jan 21 14:41:25 2011 Control Channel MTU parms [ L(ength):1442 ...
Sieht also aus das ja !
Bitte warten ..
Mitglied: atbs84
21.01.2011 um 23:32 Uhr
Versteh ich nicht, sorry.
Also ich seh die Zahl da aber das sind weder 1400 noch 1500. 1500 ist doch die Standard-Einstellung oder?
Wo liegt denn jetzt der Fehler?
Bitte warten ..
Mitglied: aqui
22.01.2011 um 18:03 Uhr
Mag sein das OpenVPN nur feste MTU Standardwerte supportet und so aufrundet auf den nächst höheren Wert. Müsste man mal in die Doku sehen ?!
Bitte warten ..
Mitglied: atbs84
23.01.2011 um 15:15 Uhr
Ich hab die MTU testweise noch niedriger gesetzt, brachte aber auch nix.
Habe auch den Link-MTU-Parameter mal ausprobiert, da der "einfacher" funktioniert (man muss nicht die UDP-IP-Umverpackung als Overhead abziehen, da link-mtu das beinhaltet und tun-mtu dementsprechend setzt). Habe auch den --fragment und den mssfix Schalter ausprobiert - alles ohne Erfolg. Mit Wireshark sieht man, dass Pakete, die größer als die MTU sind, einfach nicht ankommen. TCP Retransmission kommt ganz oft und am Ende TCP Window Full.

Mit link-mtu 1400 und fragment 1300 kommt im Log folgendes raus:
01.
Sun Jan 23 15:06:41 2011 Control Channel MTU parms [ L:1400 D:138 EF:38 EB:0 ET:0 EL:0 ] 
02.
Sun Jan 23 15:06:41 2011 Socket Buffers: R=[8192->8192] S=[8192->8192] 
03.
Sun Jan 23 15:06:41 2011 Data Channel MTU parms [ L:1400 D:1300 EF:46 EB:135 ET:0 EL:0 AF:3/1 ] 
04.
Sun Jan 23 15:06:41 2011 Fragmentation MTU parms [ L:1400 D:1300 EF:45 EB:135 ET:1 EL:0 AF:3/1 ]
Ping bis 1326 Byte funktioniert problemlos, 1327 kommen schon nicht mehr an (egal ob mit oder ohne -f Schalter). Im Client-Log erscheint dann jedes mal so etwas wie:
01.
Sun Jan 23 15:07:08 2011 read from TUN/TAP  [State=AT?c Err=[c:\src\openvpn-2.2-beta3\tap_build\7600\tap-win32\tapdrvr.c/2636] #O=9 Tx=[2946,0] Rx=[3603,0] IrpQ=[0,1,16] PktQ=[0,43,64] InjQ=[0,1,16]]: Es sind mehr Daten verfügbar.   (code=234)
Bin irgendwie ratlos - warum funktioniert openVPN nicht mit der Verbindung? Selbst wenn ich die MTU stark reduziere, kommt keine brauchbare Verbindung zustande. DSL (PPPoE) kann ja nich das Problem sein oder? Und die Anbindung an der Firma läuft übers DFN...

Wäre das TCP-Protokoll für openVPN eine Alternative?
Bitte warten ..
Mitglied: aqui
23.01.2011 um 16:57 Uhr
OK, mit 1400 klappt es einwandfrei wie du sehen kannst:
15:06:41 2011 Control Channel MTU parms [ L(ength):1400... Hier hält er also die 1400 Byte ein.
Das 1327 schon nicht mehr ankommen ist schon merkwürdig. Kann es sein das der DFN Router irgendwo eine MTU konfiguriert hat ?? Sieh dir mal das WAN Interface dazu an und ermittle den max. MTU Wert !! Das ist dann natürlich fatal wenn dort eine kleinere MTU als bei dir im Tunnel konfiguriert ist...dann kommt es zu Problemen.
Du kannst die max. MTU auch ganz einfach ermitteln:
http://www.gschwarz.de/mtu-wert-ermitteln
Der kleineste Wert der da rauskommt ist dann auch der minimalwert deiner MTU. Wenn der Tunnel Pakete mit größerer MTU schickt als ein WAN Interface auf der Strecke hat dropt der Router diese zu großen Frames:
http://www.cisco.com/en/US/tech/tk175/tk15/technologies_tech_note09186a ...
TCP macht nicht wirklich Sinn da der Overhead noch erheblich größer wird und das die Performance deiner VPN Verbindung verschlechtert. Außerdem löst das das MTU Problem auch nicht ! Das bleibt ja. Es mag aber sein das mit TCP eine MTU Path Discovery ausgeführt wird, was eigentlich immer Standard ist.
Käme auf einen Versuch an... Ist ja schnel in der Konfig Datei geändert....
Bitte warten ..
Mitglied: atbs84
24.01.2011 um 12:45 Uhr
Ich hatte heut die Gelegenheit, mal von anderer Stelle aus die VPN-Verbindung zu initiieren und es klappt problemlos. Also liegt es zu hause am DSL-Anschluss?
Allerdings kann ich auch von hier aus (Uni-Netz, also auch DFN, ca 5 Hops zum Ziel-Server) über das VPN keine größeren Pings absenden als von zu hause. Remotedesktop und SCP ist aber kein Problem... Die verwendeten Einstellungen entsprechen den o.g. (link-mtu 1400, fragment 1300, mssfix). Theoretisch unterscheidet den DSL-Anschluss doch nur die um 8 Byte kleinere MTU (wegen PPPoE). Bei einer so geringen MTU (1300 hab ich ja auch ausprobiert) geht es aber dennoch nicht. Warum?
Bitte warten ..
Mitglied: aqui
25.01.2011 um 18:06 Uhr
Das ist richtig. Entweder hast du einen zu schwachen Billigrouter der einfach die Packet Forwarding Rate nicht schafft und/oder der kann nicht korrekt mit dem MTU Handling umgehen ?! Immerhin hast du VDSL 25 da spielt Paket Forwarding eine nicht unerhebliche Rolle. Hast du vor dem OpenVPN pfSense noch einen Router oder gehst du direkt ins VDSL ? http://www.heise.de/netze/artikel/pfSense-als-VDSL-Router-221500.html
Störungen auf dem DSL Link oder ein billiges Modem was damit nicht umgehen kann wären ein weiterer Grund.
Hast die die Firmware deines Zuhause Routers auf dem aktuellsten Stand ??
Ansonsten einmal testweise einen anderen Router oder Modem austesten.
Bitte warten ..
Mitglied: atbs84
25.01.2011 um 18:29 Uhr
Also die pfSense-Kiste ist direkt mit fester öffentlicher IP-Adresse als Gateway zum Internet eingerichtet. D.h. die Router die dazwischen liegen, sind nicht unter meiner Kontrolle. Hier zu Hause habe ich nen gemieteten Telekom Speedport W722V Typ B (Arcadyan, integr. VDSL-Modem), der zugegebenermaßen nicht ganz einwandfrei scheint (Beim Messen der WLAN-Geschwindigkeit mit iperf mehrmals abgestürzt, ein Gerät im Haushalt kommt manchmal partout nicht ins WLAN bis man den Router resettet - bzw. er tut das dann nach mehreren Verbindungsversuchen manchmal sogar von selbst und dann gehts irgendwann). Hab grad mal n Firmwareupdate (1.18) gemacht, aber das löst das Problem leider nicht. Die DSL-Verbindung ist ansonsten total in Ordnung, also von der Übertragungsrate und Latenz her... Ein alternatives Modem werde ich mir wohl mal zulegen müssen, wenn rauskommt dass der Router Schuld ist (Speedport 300HS bei ebay + irgendeinen anderen Router). Früher hatte ich ein WRAP mit m0n0wall + ADSL Modem + Switch + Access Point, diesen Gerätezoo hab ich allerdings zugunsten der "Ein-Gerät-Lösung" aufgegeben :D

Ich werde als nächsten Schritt mal bei nem Bekannten am ADSL-Anschluss die VPN-Verbindung testen...
Bitte warten ..
Mitglied: aqui
26.01.2011 um 12:46 Uhr
Oha....und da wunderst du dich bei so einem wackeligen Router ?? Den solltest du dann als allererstes ersetzen. Scheinbar bist du nicht der einzige...es gibt dazu hunderte von Threads...
http://www.mac-tv.de/Forum/showthread.php?t=11204
Bitte warten ..
Mitglied: atbs84
26.01.2011 um 17:36 Uhr
Ich hatte keine Ahnung, dass VPN so "besonders" ist. Habe mit anderen Diensten keinerlei Probleme - Auch nach oder während aufgebauter VPN-Verbindung. Noch dazu funktionierte die VPN-Verbindung ja anfangs problemlos mit diesem Router...
Uni-VPN (Cisco-Client mit IPsec) ist ja auch kein Problem. Was also macht openVPN so besonders?
Bitte warten ..
Mitglied: aqui
26.01.2011 um 19:00 Uhr
OK, wenn das parallel störungsfrei rennt ist das sicher nicht das Thema denn besonders ist das keineswegs..eher noch robuster als IPsec.
Dann liegt es an den speziellen Tunnelendpunkten bzw. Konfiguration der VPN Endgeräte.
Über ein Forum da jetzt aber detailiertes Troubleshooting zu machen sprengt den Rahmen, denn da müsste man mit Wireshark und anderen Tools ins eingemachte gehen.... Denn ein MTU Problem hast du, das ist nicht von der Hand zu weisen...
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(8)

Tipp von agowa338 zum Thema Windows 10 ...

Ähnliche Inhalte
Router & Routing
OpenVpn Verbindung Synology NAS hinter Zywall USG 40 (2)

Frage von Tirgel zum Thema Router & Routing ...

Firewall
gelöst PFSense Squid Proxy über OpenVpn Verbindung nutzen (4)

Frage von horstvogel zum Thema Firewall ...

Heiß diskutierte Inhalte
Microsoft
Ordner mit LW-Buchstaben versehen und benennen (20)

Frage von Xaero1982 zum Thema Microsoft ...

Outlook & Mail
gelöst Outlook 2010 findet ost datei nicht (19)

Frage von Floh21 zum Thema Outlook & Mail ...

Netzwerkmanagement
gelöst Anregungen, kleiner Betrieb, IT-Umgebung (18)

Frage von Unwichtig zum Thema Netzwerkmanagement ...

Festplatten, SSD, Raid
M.2 SSD wird nicht erkannt (14)

Frage von uridium69 zum Thema Festplatten, SSD, Raid ...