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

OpenVPN Client2Client

Frage Netzwerke LAN, WAN, Wireless

Mitglied: sschultewolter

sschultewolter (Level 1) - Jetzt verbinden

10.10.2014, aktualisiert 14:13 Uhr, 2323 Aufrufe, 11 Kommentare

Hallo,

ich habe Probleme mit einem auf Linux basierenden OpenVPN Server.

Die Hauptfunktionen stehen soweit. Er stellt eine VPN zu den einzelnen Clients ausserhalb des LANs her. Jedoch kann nur der Server auf die Clients zugreifen.

Jedoch würde ich gerne von bestimmten Rechner/Clients im VPN auf die anderen Clients zugreifen.

Hintergrund, die Clients sind hauptsächlich extern stehende Rechner auf die mit VNC zugegriffen werden muss. Die externen Clients/Clientnetze sollen dabei nicht auf andere Clients zugreifen. Das ist derzeit so gegeben.

Jedoch sollen eine Hand voll Rechner auf alle Clients zugreifen. Auf dem Server läuft eine SQL Datenbank. Ebenfalls hinterlegt sind die VNC Verbindungen. Diese VNC Verknüpfungen sind auf einem Sambashare freigegeben. Nun ist es mir nicht möglich, diese VNC Verknüpfungen zu starten, da die IP Adresse nicht erreichbar ist. Das Routing vom bestimmten Client zum Server und dann zum gesuchten Client geht nicht.

Wäre für jede Hilfe dankbar. Im Anhang hier die server.conf. Sensible Daten sind mit ??? auskommentiert.

Gruß

01.
# Which TCP/UDP port should OpenVPN listen on? 
02.
port 1194 
03.
 
04.
# TCP or UDP server? 
05.
proto udp 
06.
 
07.
# Routed IP tunnel 
08.
dev tun 
09.
 
10.
 
11.
# SSL/TLS root certificate (ca), certificate 
12.
# (cert), and private key (key).  Each client 
13.
# and the server must have their own cert and 
14.
# key file.  The server and all clients will 
15.
# use the same ca file. 
16.
ca ./easy-rsa2/keys/ca.crt 
17.
cert ./easy-rsa2/keys/server.crt 
18.
key ./easy-rsa2/keys/server.key  # This file should be kept secret 
19.
 
20.
# Diffie hellman parameters. 
21.
dh ./easy-rsa2/keys/dh2048.pem 
22.
 
23.
# Configure server mode and supply a VPN subnet 
24.
# for OpenVPN to draw client addresses from. 
25.
# The server will take 10.8.0.1 for itself, 
26.
# the rest will be made available to clients. 
27.
# Each client will be able to reach the server 
28.
# on 10.8.0.1. Comment this line out if you are 
29.
# ethernet bridging. See the man page for more info. 
30.
server 10.8.0.0 255.255.255.0 
31.
 
32.
# Maintain a record of client <-> virtual IP address 
33.
# associations in this file.  If OpenVPN goes down or 
34.
# is restarted, reconnecting clients can be assigned 
35.
# the same virtual IP address from the pool that was 
36.
# previously assigned. 
37.
ifconfig-pool-persist ipp.txt 
38.
 
39.
client-config-dir /etc/openvpn/ccd 
40.
route ???.???.???.??? 255.255.255.0		# client ??? 
41.
route ???.???.???.??? 255.255.255.0		# client ??? 
42.
route ???.???.???.??? 255.255.255.0     # client ??? 
43.
route 192.???.???.??? 255.255.255.255   # client ??? 
44.
push "route 192.168.1.0 255.255.255.0"	# server 
45.
 
46.
 
47.
# Uncomment this directive to allow different 
48.
# clients to be able to "see" each other. 
49.
# By default, clients will only see the server. 
50.
# To force clients to only see the server, you 
51.
# will also need to appropriately firewall the 
52.
# server's TUN/TAP interface. 
53.
client-to-client 
54.
 
55.
 
56.
# The keepalive directive causes ping-like 
57.
# messages to be sent back and forth over 
58.
# the link so that each side knows when 
59.
# the other side has gone down. 
60.
# Ping every 10 seconds, assume that remote 
61.
# peer is down if no ping received during 
62.
# a 120 second time period. 
63.
keepalive 10 120 
64.
 
65.
# Enable compression on the VPN link. 
66.
# If you enable it here, you must also 
67.
# enable it in the client config file. 
68.
comp-lzo 
69.
 
70.
# It's a good idea to reduce the OpenVPN 
71.
# daemon's privileges after initialization. 
72.
73.
# You can uncomment this out on 
74.
# non-Windows systems. 
75.
user nobody 
76.
group nogroup 
77.
 
78.
# The persist options will try to avoid 
79.
# accessing certain resources on restart 
80.
# that may no longer be accessible because 
81.
# of the privilege downgrade. 
82.
persist-key 
83.
persist-tun 
84.
 
85.
# Output a short status file showing 
86.
# current connections, truncated 
87.
# and rewritten every minute. 
88.
status openvpn-status.log 
89.
 
90.
# By default, log messages will go to the syslog (or 
91.
# on Windows, if running as a service, they will go to 
92.
# the "\Program Files\OpenVPN\log" directory). 
93.
# Use log or log-append to override this default. 
94.
# "log" will truncate the log file on OpenVPN startup, 
95.
# while "log-append" will append to it.  Use one 
96.
# or the other (but not both). 
97.
log         /home/???/Schreibtisch/openvpn.log 
98.
;log-append  openvpn.log 
99.
 
100.
# Set the appropriate level of log 
101.
# file verbosity. 
102.
103.
# 0 is silent, except for fatal errors 
104.
# 4 is reasonable for general usage 
105.
# 5 and 6 can help to debug connection problems 
106.
# 9 is extremely verbose 
107.
verb 3 
108.
 
109.
# Silence repeating messages.  At most 20 
110.
# sequential messages of the same message 
111.
# category will be output to the log. 
112.
;mute 20
Mitglied: kurbach
10.10.2014, aktualisiert um 15:31 Uhr
Servus,

Client2Client ist etwas missverständlich.

1. Wenn du willst, dass aus dem Privaten Netz ein Client mit einem VPN Client kommunzieren kann, musst du eine statische Route einrichten.
Auf einem Win-Client im Privaten Netz geht das so:
route ADD 10.8.0.0 MASK 255.255.255.0 192.168.0.254
wenn: 10.8.0.0 dein VPN-Netz mit der Subnetzmaske 255.255.255.0 ist. Das musst du anpassen.
192.168.0.254 musst du durch die LAN-IP von deinem VPN-Gateway ersetzen.
2. Auch wenn ein Server "zurück" ins VPN funken können soll, muss jeder dieser Server der da antworten soll, diese Route ins VPN Netz kennen. (DHCP option für die Clients, Statisch eingerichtet an den Servern)

ODER:

3. Wenn du willst, dass zwei Rechner sich ins VPN einloggen, und diese miteinander kommunizieren können, dann genügt eine Server-Option, da diese ja bereits im selben Subnetz sind. Die Option dafür lautet dann:
client-to-client

Bitte kläre deine Begrifflichkeiten.
Rechner - ?
Server - Der VPN Server
Client - Rechner der VPN mit dem Server macht. ?

Hoffe das klärt einiges auf.

Gruß,
Kay
Bitte warten ..
Mitglied: sschultewolter
10.10.2014 um 15:59 Uhr
Hallo Kay,

im internen Netzwerk hinter dem Router hängt ein kleines ITX Board mit einem Linux BS auf dem OpenVPN Server läuft. Im gleichen (nicht VPN) befinden sich 2 weitere Rechner. Die ebenfalls Zugriff auf die Datenbank haben. Das geht soweit alles.

Nun sind einige VNC Verknüpfungen nur über eine VPN Verbindungen aufzurufen. Diese VNC Verknüpfungen greifen auf ein VNC Router zu, der extern steht. Hierbei habe ich bereits verbunden, sodass ich nicht nur den VPN Router erreiche sonder auch die daran angeschlossenen Geräte.

Diese ganze Geschichte erfüllt bereits den Anforderungen, da von diesen Schnittstellen nicht einem Client zum anderen Client eine Verbindung aufgebaut werden soll.


Nun müssen aber die Rechner, die sich im gleichen lokalen Netzwerk befinden, auf den Server zugreifen. Das ist zum einen möglich über die LAN-Adresse. Testweise habe ich hierfür auch VPN Zertifikate erstellt, da es sich bei einem Rechner um einen Laptop handelt, der auch ausserhalb des Netzwerks darauf Zugriff haben muss.

Nun, sobald ich mit diesen Rechner eine VNC Verknüpfung öffnen möchte, die nur vom VPN aus erreichbar ist, gibt es das Problem, dass nicht geroutet wird.


Begrifflichkeiten:

Rechner: siehe Client


Client:
Hier gibt es 2 verschiedene Typen:
Client Gruppe 1: Es gibt Clients, die sich bereits im selben lokalen Netzwerk befinden (insgesamt 2). Diese müssen alle Clients der Gruppe 2 erreichen können.

Client Gruppe 2:
Hier handelt es sich um Rechner/Steuerungen (Linux) auf die zugegriffen werden muss über eine VNC Verbindung. Hier können keine Routen o.ä. eingetragen werden. Verbunden sind diese mit einem OVpn Router der soweit mit Zertifikaten gefüllt ist, dass er die Verbindung zum Server aufbaut. (Routen siehe server.conf).
Vom Server aus habe ich somit auf alle Geräte Zugriff. Den gleichen Zugriff auf Clients der Gruppe 2 müssen die Clients der Gruppe 1 haben.

Server: Das ist der Linux OVpn Server, dieser befindet sich mit den Client1 im selben lokalen Netzwerk
Bitte warten ..
Mitglied: kurbach
10.10.2014, aktualisiert um 16:25 Uhr
Howdy,

Also - jeder Rechner, der über VPN - VNC machen soll braucht ne static route zum VPN Client der ausserhalb steht.
Entweder einfach gleich die Interne IP des VPN Rechners als Gatewayadresse nehmen, und das VPN Subnetz komplett über das gateway routen.

Mach am Client im LAN in ner Admin-Console (cmd)
~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-server-ip> -p

Und dann ping mal die VPN! adresse eines externen vpn clients an. NICHT die LAN IP vom externen VPN client!!!
also vom LAN Client
~# ping 10.8.0.2
o.ä.
Du solltest ggf darauf achten, dass jeder client stets die selbe Openvpn - IP bekommt, sonst wirst verrückt ; )
Aber so sollte das zum testen erst mal reichen.

Greetz,
Kay
Bitte warten ..
Mitglied: sschultewolter
10.10.2014, aktualisiert um 16:42 Uhr
Hallo Kay,

hört sich gut an, werde ich sofort testen. Die OVpn Clients bekommen immer eine identische IP Adresse zugewiesen, die nach der ersten Verbindung dauerhaft hinterlegt werden.

Edit: Die Route hat leider nicht funktioniert.

>Mach am Client im LAN in ner Admin-Console (cmd)
>~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-server-ip> -p

C:\WINDOWS\system32>route ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.1 -p
OK!

Oder muss die client-to-client in der server.conf zwingend wieder abgeändert werden? Das werde ich gleich noch mal selber testen.
Bitte warten ..
Mitglied: kurbach
10.10.2014, aktualisiert um 16:50 Uhr
STOP!
die Route muss ja auf die LAN IP vom Server zeigen, doch nicht auf dessen VPN IP.
Der Server wird im LAN ja ne IP Adresse haben, wie die Clients auch (192.168.x.x)
DAS muss dein Gateway sein!
Nicht die 10.8.0.1 - die ist ja nicht im gleichen subnet wie der Client.

Merke - das GW muss der LAN-Rechner ja kennen, bzw. finden!

Sprich, der Server hat ne LAN IP - und ne VPN IP (ggf. manchmal auch direkt ne externe, oder DMZ, aber vernachlässigen wir das mal)
Der Server routet die VPN Netze/Kommunikation immer zur 10.8.0.1 rein/raus - und die LAN Kommunikation immer über die 192.168.x.y - wie auch immer die lautet.

Also route nomma löschen und das GW ändern ; )
Bitte warten ..
Mitglied: sschultewolter
10.10.2014 um 17:03 Uhr
Die interne LAN-IP steht mir gerade nicht zur Verfügung. Ich teste hier mit meinem Rechner, der nicht in dem Netz sich befindet. Bin über OpenVPN mit der Console des Servers nur verbunden. Alternativ könnte ich noch die GUI starten und entsprechend mit VNC drauf zugreifen.

Route gelöscht.
Bitte warten ..
Mitglied: kurbach
10.10.2014 um 17:10 Uhr
Auf dem Server:
~# ifconfig
sollte dir die IPs des Servers ausgeben.
Btw: diese Route ist ausschließlich auf den Clients im LAN (dort wo der VPN server steht) nötig.

Greetz,
KAy
Bitte warten ..
Mitglied: sschultewolter
10.10.2014 um 17:14 Uhr
Das könnte ich heute Abend ggf. testen, was muss ansich dann für extern gemacht werden?

Komme definitiv noch nicht meinem Client auf einen anderen Client. Mein Client auf Server geht,.
Bitte warten ..
Mitglied: sschultewolter
17.10.2014, aktualisiert um 12:25 Uhr
Hallo,

habe nun folgendes getestet jedoch noch ohne Erfolg.

Am Client, der auf andere Clients zugreifen soll.
>route ADD 10.8.0.0 MASK 255.255.255.0 192.168.2.103 -p
Wobei hier die *103 die feste IP Adresse des VPN Servers darstellt im internen Netzwerk.

Die anzupingenden Geräte selber sind lediglich VPN Router. Diese stellen eine Verbindung zum VPN Server her. Hintern den VPN Routern befindet sich in der Regel ein Gerät, welches angesprochen werden kann. In diesem Fall über eine 192.168.101.* IP Adresse. Diese Netzwerke sind im VPN Server entsprechend geroutet.

Es bleibt nach wie vor, auf dem Server selber gibt es keinerlei Probleme. Jedoch kann nur der Server die Clients ansprechend, nicht jedoch der Client die anderen Clients (Client -> Server geht selbstverständlich).

Wäre für weitere Ratschläge dankbar. Eventuell eine beispielhafte Konfiguration, bzw. Beispiel, welche Einstellungen in diesem Moment interessant/wichtig sind. Die server.conf hatte ich ja bereits im ersten Post gekürzt um die Kommentare sowie verschlüsseln/verschleiern der Routen.
Bitte warten ..
Mitglied: kurbach
21.10.2014 um 11:01 Uhr
Okay.
Vorab:
Ein Router wird der VPN-Server sein, alle anderen Clients - ich kenne derzeit keine praktikable Möglichkeit ein VPN in physikalischer Netzform zu bilden, sondern immer den Stern, mit dem VPN-Server im Zentrum.
Firewallregeln lasse ich derzeit mal alle außer acht, den ohne die, bekommt man ja nicht mal das vpn aufgezogen, daher setze ich das als funktionierend gegeben voraus.
Folgendes ist essentiell:

1. Jedes Netz hinter einem VPN-Router sollte in einem anderen Subnet liegen, wenn die dahinter liegenden Clients miteinander kommunizieren können sollen.
Z.B. Im LAN des VPN Servers:
192.168.0.0 / 255.255.255.0
IP des VPN-Servers intern:
192.168.0.253
extern:
194.25.2.129 (Beispiel)
VPN Netz:
10.8.0.0 / 255.255.255.0
VPN-Server-IP
10.8.0.1 / 255.255.255.0

Außennetze: (lan netze hinder den anderen vpn routern/clients)
192.168.1.0 / 255.255.255.0
192.168.2.0 / 255.255.255.0
192.168.3.0 / 255.255.255.0
192.168.4.0 / 255.255.255.0
etc.
VPN-GW hat immer die .253 im entfernten Netz auf der LAN-Seite

2. Jeder Client hinter einem VPN Router(auch hinter den vpn clients), auf den zugegriffen werden soll, braucht die Route ins VPN-Netz 10.8.0.0
~# route add 10.8.0.0 MASK 255.255.255.0 <interne-vpn-gateway-ip> -p
Damit ist "nur" sichergestellt, dass sich einwählende Clients, die SELBST im 10-er netz sind eine Antwort erhalten.

Was du offenbar möchtest ist offenbar kein roadwarrior-zugang (was die einfachere variante wäre) d.h. genau DER rechner wählt sich ins vpn, auf den zugegriffen werden soll. (Host-to-Net) Sondern:
die Netze sollen gekoppelt werden (Net-to-net).

Dies setzt voraus, dass jeder vpn-Client (Gateway) eine Route in die übrigen netze bekommt.

Fasse zusammen: Der jeweilige Client hat sein standardgateway ins internet und braucht routen in die übrigen LANs über sein eigenes VPN GW.
Das VPN-GW macht die verbindung zum server und muss die übrigen LANs durch die 10.8er ip Routen
Der Server bekommt Pakete durchs VPN die an ein anderes LAN adressiert sind. daher braucht er ebenfalls Routen in die Außen-LANs - die fix mit den GW-adressen verdrahtet werden müssen: zurordnung von 192.168.X auf 10.8.0.X, 192.168.Y.0 auf 10.8.0.Y, etc

Schritt 1:
Clients benötigen Route in andere Netze über deren VPN-GW
(Wenn die Clients auch in das lan vom VPN Server sollen, einfach die Route nach 192.168.0.0 noch hinzufügen)
Z.B:
Clients in netz 192.168.1.0 so zu konfigurieren:
Route nach 192.168.2.0 / 255.255.255.0 / über GW 192.168.2.253 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 192.168.3.253 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 192.168.4.253 -p

Clients in netz 192.168.2.0 so zu konfigurieren:
Route nach 192.168.1.0 / 255.255.255.0 / über GW 192.168.1.253 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 192.168.3.253 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 192.168.4.253 -p

etc.

Schritt 2
### VPN GWs benötigen Routen über den VPN Server:

GW in netz 192.168.1.0 (also mit 192.168.1.253) so zu konfigurieren:
Route nach 192.168.2.0 / 255.255.255.0 / über GW 10.8.0.1 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 10.8.0.1 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 10.8.0.1 -p
etc.

Schritt 3
### VPN-Server benötigt Routen für die Clientnetze:
(Sinnvoll den VPN-Clients fixe zuordnungen fürs 10.8er netz zu verpassen, aber das ist n anderes thema - denn sonst stimmen diese routenzuordnungen iwann nicht mehr - aber das hier ist die zentrale konfiguration, da der vpn server alles handhaben muss.)
Route nach 192.168.1.0 / 255.255.255.0 / über GW 10.8.0.11 -p
Route nach 192.168.2.0 / 255.255.255.0 / über GW 10.8.0.12 -p
Route nach 192.168.3.0 / 255.255.255.0 / über GW 10.8.0.13 -p
Route nach 192.168.4.0 / 255.255.255.0 / über GW 10.8.0.14 -p

ENDE DER EINSTELLUNGEN

Jetzt solte jeder Client seine Gateways haben - und jedes Gateway die Routen zum Server und den übrigen Teilnetzen.

TESTING:
a. Reiss die Firewalls komplett auf zum testen, eigentlich würde ich eine geschlossene Umgebung vorschlagen, aber das ist halt nicht immer drinne.
b. Pinge zunächst von jeder beteiligten Node jede kürzeste Teilstrecke an, und anschließend die dahinter liegende Node.
z.b. vom 192.168.1.11 (client im Aussennetz 1)
ping auf die 192.168.1.253 (vpn gw)
ping auf die 10.8.0.11 (vpn-ip des eigenen GW) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 10.8.0.1 (vpn-ip des servers) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 192.168.0.X (irgendein host im Lan des VPN Servers, nur wenn du die Route nach 192.168.0.0 auch hast!)
ping auf die 10.8.0.12 (vpn-ip von aussen GW2 in netz 192.168.2.0) (nur wenn du die unter ZUSATZ genannten routen auch hast)
ping auf die 192.168.2.X (ping auf client in aussennetz 2)

c. wenn du pings an anfang durchbekommst und irgendwann nicht mehr, ist die strecke über di du ihn nicht mehr bekommst zu untersuchen.
d. dann geht man am besten auf die node wo es noch ging und pingt die node bei der es nicht mehr ging. - geht der ping hier durch, fehlt meist ne route, oder ist falsch konfiguriert (zahlendreher, o.ä), denn die nodes selbst sehen sich ja.
e. wenn alles geht, kannst du die routen in die 10.8er netze von den Clients auch wieder weg nehmen, da die vpn GWs ja eh alles unter sich über den vpn server routen. zum testen ist diese aber essentiell.

Zusatz:
die Regel CLIENT-TO-CLIENT besagt nicht die verbindung der entsprechenden Netze, sondern lediglich die Verbindung der Clients untereinander, die vom Server eine 10.8.0.0er IP bekommen haben.
Deshalb, wie bereits unter 2.:
Im Außennetz 1 auf den Clients:
~# route add 10.8.0.0 MASK 255.255.255.0 192.168.1.253 -p
In netz 2:
~# route add 10.8.0.0 MASK 255.255.255.0 192.168.2.253 -p
etc...

Grüße
Bitte warten ..
Mitglied: kurbach
27.10.2014 um 17:17 Uhr
Sollte das nun zu kompliziert oder zuviel des guten gewesen sein, kann ich auch gern - sofern es sich um private Infrastruktur handelt - Support via Fernwartung anbieten.
Bitte warten ..
Neuester Wissensbeitrag
Windows 10

Powershell 5 BSOD

(3)

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 ...

Windows Server
Windows Firewall Einstellungen für OpenVPN Tunnel (4)

Frage von Aubanan zum Thema Windows Server ...

Netzwerkgrundlagen
gelöst Heimnetzwerk über Server im Internet und OpenVPN erreichbar machen (16)

Frage von byt0xm zum Thema Netzwerkgrundlagen ...

Heiß diskutierte Inhalte
LAN, WAN, Wireless
gelöst Server erkennt Client nicht wenn er ausserhalb des DHCP Pools liegt (28)

Frage von Mar-west zum Thema LAN, WAN, Wireless ...

Outlook & Mail
Outlook 2010 findet ost datei nicht (18)

Frage von Floh21 zum Thema Outlook & Mail ...

Windows Server
Server 2008R2 startet nicht mehr (Bad Patch 0xa) (18)

Frage von Haures zum Thema Windows Server ...