Menü: Tutorial OpenVPN 2
zur Seite1: Tutorial Point-to-Point-VPN-Tunnel über OpenVPN
Anstatt nur zwei einzelne Computer miteinander sicher zu verbinden (siehe routed P2P-VPN-Tunnel), wollen Sie evtl. mehreren Clients sicheren Zugriff auf Ihr komplettes Office-Netzwerk geben (z.B. auf das ERP-System, den Mailserver u.s.w.). Ein klassisches Beispiel: mehrere mobile Vertreter sollen sicher von aussen auf das Firmennetzwerk zugreifen können (typisches Roadwarrior-Szenario). Auch wir IT-Nomaden hegen immer den Wunsch, mit unseren Maschinen und Anwendungen “zuhause” (there´s no place like localhost :-) verbunden zu sein :-)
Dies ist mit OpenVPN entweder über ein “routed” oder ein “bridged” VPN möglich und das ganz ohne zusätzliche Kosten für Software- und/oder Hardwarelösungen (wie VPN-Router o.ä.). Wir gehen nachstehend auf das Bridging (siehe Vor- und Nachteile zum Routing unter Punkt 10.) ein und stellen ein Beispiel - von der Installation, über die Bildung von Schlüssel und Zertifikaten, bis zur Erstellung der Konfigurationsdateien und Netzwerkbrücke (VPN-Server) - zur Verfügung:
Ausgangssituation:
Es besteht ein lokales Office-Netzwerk mit folgenden Daten:
Subnet: 192.168.1.0 | Mask: 255.255.255.0 | Gateway 192.168.1.1
Der einzurichtende VPN-Server (kann ein beliebiger Computer aus dem Zielnetzwerk-LAN sein) hat in diesem Subnet die feste* lokale IP-Adresse 192.168.1.10 - die IP-Adressen aller anderen Netzwerkteilnehmer (File-Server, Application-Server, Mail-Server, NW-Drucker, NW-Kameras, Clients....) befinden sich im Range 192.168.1.20-192.168.1.100 per DHCP. Deshalb wählen wir für die VPN-Clients den IP-Adressbereich über *.*.*200, um Konflikte (auch bei späteren IP-Adressenerweiterungen des Zielnetzwerks) auszuschliessen!
*dem VPN-Server sollte eine FESTE IP-Adresse zugewiesen werden, um die Konfiguration zu vereinfachen. Alternativ kann über eine fest reservierte IP-Adresse für diesen Rechner per DHCP verfahren werden.
Es sollen nun drei Notebooks, die sich zukünftig im mobilen Einsatz befinden, SICHER auf das komplette interne Netz über einen VPN-Tunnel zugreifen können. Beispielsweise möchten Vertreter beim Kunden (wie aus dem LAN gewohnt) auf die Desktopverknüpfung zum firmeneigenen ERP-System klicken, um diese Anwendung zu öffnen. Auch soll Zugriff zu freigegebenen Dateien im Firmen-Netzwerk möglich sein. Kein Problem, siehe folgenden Workaround.
Workaround:
1. Installation von OpenVPN (Download): Für Windows gibt es eine Installationsroutine (.exe) und für Linux neben rpm’s auch distributionsabhängige Pakete (siehe z.B. apt-get unter Debian oder emerge unter Gentoo) oder man bedient sich “./configure make install” über den angebotenen Source-Tarball-Download. Unter Linux weist OpenVPN die Abhängigkeiten zu openssl-devel, lzo-devel und pam-devel auf, d.h. die Pakete sind davor zu installieren, sofern noch nicht vorhanden. Unter der 64-bit-Version von Vista oder Windows 7 muss der virtuelle VPN-Adapter im sog. Debug-Modus (Taste F8 während des Bootvorgangs drücken und Bootmodus auswählen), der auch nicht signierte Treiber akzeptiert, installiert werden!
OpenVPN sollte unter Linux in das Verzeichnis /etc/openvpn/ installiert werden. Unter Windows installiert sich das Programm in C:\Programme\OpenVPN bzw. unter Vista und Windows 7 unter C:\Program Files (x86)\OpenVPN , sofern nichts anderes vorgegeben - Ferner wird auf dem System ein virtueller Netzwerkadapter angelegt (unter Windows: TAP-Win32 adapter | unter Linux: tap0). Dieser sollte bei den späteren (Windows-)VPN-Clients (nicht Server! siehe dazu Punkt 3.) gleich in einen sinnvollen, eindeutigen Namen umbenannt werden, z.B. “OpenVPN” (keinesfalls “LAN-Verbindung 2” o.ä.) . Der Hintergrund: In der Konfigurationsdatei der Clients muss später auf den verwendeten OpenVPN-Adapter Bezug genommen werden (Punkt dev-node). Unter Linux ist “tap0” eigentlich gut zu merken und eindeutig genug, so dass hier nichts zu machen ist.
Für Windows gibt es auch ein grafisches Interface (GUI), was hernach installiert werden kann, siehe Downloadseite der GUI-Version.
2. Zur Authentication der mobilen Computer mit dem VPN-Server verwenden wir zum einen die symmetrische Methode über einen statischen Schlüssel (Preshared Key), d.h. dieser muss auf dem VPN-Server wie -Client identisch vorhanden sein (dient zur Vorbeugung von DoS-Attacken und UDP-Port-Flooding). Zum anderen verwenden wir anschliessend die asymmetrische PKI-(public key infrastruction using certificates and private keys)-Methode über öffentliche Zertifikate und private Schlüssel, d.h. jeder Client erhält zusätzlich sein eigenes Schlüsselpaar - bestehend aus dem öffentlichen Zertifikat und dem privaten (geheimen) Schlüssel - welches mit dem Master-Zertifikat des OpenVPN-Servers zur späteren Authentication signiert wird.
Die Schlüssel- und Zertifikat-Dateien wollen wir später in einem Unterverzeichnis “keys” ablegen, weshalb wir diesen Ordner zuvor auf dem VPN-Server wie auf den VPN-Clients anlegen:
Unter Windows: C:\Programme\OpenVPN\easy-rsa\keys
Unter Linux: /etc/openvpn/easy-rsa/keys
2.1 Zum Generieren des statischen Schlüssels (ta.key) wie folgt vorgehen:
Windows-Kommandozeile (Administrator):
openvpn --genkey --secret <Pfad_zum_Speicherort>ta.key
In unserem Beispiel machen wir es so:
openvpn --genkey --secret C:\Programme\OpenVPN\easy-rsa\keys\ta.key
Linux-root-Shell:
openvpn --genkey --secret <Pfad_zum_Speicherort>ta.key
In unserem Beispiel:
openvpn --genkey --secret /etc/openvpn/easy-rsa/keys/ta.key
2.2 Zum Generieren des Master-Zertifikats und -Schlüssels (Certificate Authority = CA) wie folgt vorgehen:
Unter Linux öffnet man eine root-shell im Verzeichnis /etc/openvpn/easy-rsa/. Unter Windows öffnet man die Eingabeaufforderung und wechselt zum Verzeichnis C:\Programme\OpenVPN\easy-rsa\ und startet die Batchdatei mit dem Befehl:
init-config
Nun muss die vars-Datei (Windows: vars.bat) editiert werden und bestimmte Angaben (Land, Stadt, eMail etc.) gemacht werden. Es müssen alle Felder ausgefüllt werden.
Nun wird die PKI (public key infrastruction using certificates and private keys) initialisiert.
Windows-Kommandozeile (Administrator):
vars
clean-all
build-ca
Linux-root-Shell:
. ./vars
./clean-all
./build-ca
Vorsicht: clean-all löscht alle Dateien im Keys-Verzeichnis, d.h wenn nachträglich VPN-Client-Zertifikate angelegt werden, darf nur die vars geladen werden!
Das Script gibt nun im weiteren Verlauf die Angaben aus der vars-Datei (Windows: vars.bat) zurück. Fehlende Angaben sind hier noch anzugeben (z.B. der “Common Name”). Hier kann z.B. “Mein-OpenVPN-CA” stehen. Ferner kann ein Passwort vergeben werden, welches dann zur späteren Erstellung von Client-Zertifikaten (Punkt 2.4) benötigt wird.
Im Verzeichnis C:\ProgrammeOpen\VPN\easy-rsa\keys\ (bzw. unter Linux: /etc/openvpn/easy-rsa/keys/) sollten sich jetzt die Dateien ca.key und ca.crt befinden, sonst ist etwas falsch gelaufen.
2.3 Zum Generieren des Zertifikats und Schlüssel für den VPN-Server geben wir folgendes ein:
Windows-Kommandozeile (Administrator):
build-key-server server
Linux-root-Shell:
./build-key-server server
Wie bei der Bildung des Master-Schlüssels, werden die Defaults aus der vars-Datei vorgeschlagen und es muss zuätzlich ein Common Name namens “server” eingeben werden. Zusätzlich ist ein Passwort anzugeben und es müssen noch die beiden Fragen zum Signieren des Zertifikats mit Yes (y) beantwortet werden.
Im Verzeichnis C:\Programme\OpenVPN\easy-rsa\keys\ (bzw. unter Linux: /etc/openvpn/easy-rsa/keys/) sollten sich jetzt die Dateien server.key und server.crt befinden, sonst ist etwas falsch gelaufen.
2.4 Zum Generieren des Zertifikats und Schlüssel für die VPN-Clients geben wir folgendes ein:
Windows-Kommandozeile (Administrator):
build-key notebook1
build-key notebook2
build-key notebook3
Linux-root-Shell:
./build-key notebook1
./build-key notebook2
./build-key notebook3
Die Schritte sind die gleichen wie beim Generieren des Server-Keys. Allerdings muss für jeden Client ein eigener unikater Common Name vergeben werden (z.B. “client1”, “client2”, “client3”). Wurde ein Passwort bei der Erstellung des Master-CA-Zertifikats unter Punkt 2.2 vergeben, muss dieses hier auch angegeben werden!
Im Verzeichnis C:\Programme\OpenVPN\easy-rsa\keys\ (bzw. unter Linux: /etc/openvpn/easy-rsa/keys/) sollten sich jetzt für jeden Client die Dateien notebookx.key und notebookx.crt befinden, sonst ist etwas falsch gelaufen.
Anmerkung: Werden irgendwann zu einem späteren Zeitpunkt weitere Client-Zertifikate erzeugt, muss lediglich die VARS-Datei geladen (siehe Punkt 2.2) und mit Punkt 2.4 fortgefahren werden. Auch benötigt man natürlich das seinerzeit (beim Erstellen des Master-Zertifikats) vergebene Passwort für das Erstellen von Client-Zertifikaten! Keinesfalls darf aber in diesem Fall clean-all ausgeführt werden, weil dies u.a. zur Löschung des Master-CA-Zertifikats führen würde (dann kann man von vorne beginnen oder man verfügt über eine Sicherung, die die Wiederherstellung der Schlüssel möglich macht :-)
2.5 Generieren der unikaten Diffie-Hellman-Parameter für den späteren Schlüsselaustausch:
Windows-Kommandozeile (Administrator):
build-dh
Linux-root-Shell:
./build-dh
Der Vorgang kann eine ganze Weile dauern, weshalb sich hier eine Pause anbietet.
Im Verzeichnis C:\Programme\OpenVPN\easy-rsa\keys\ (bzw. unter Linux: /etc/openvpn/easy-rsa/keys/) sollte sich hernach die Datei dh1024.pem befinden, sonst ist etwas falsch gelaufen.
2.6. Zusammenfassung aller gebildeten Dateien:
Im Verzeichnis C:\Programme\OpenVPN\easy-rsa\keys\ (bzw. unter Linux: /etc/openvpn/easy-rsa/keys/) müssen sich jetzt folgende Dateien befinden:
ca.key (geheimer Master/Root-Schlüssel) --> verbleibt alleinig auf dem VPN-Server
ca.crt (öffentliches Master/Root-Zertifikat) --> benötigen VPN-Server- wie Clients
dh1024.pem (Diffie-Hellman-Parameter) --> verbleibt alleinig auf dem VPN-Server
server.crt (öffentliches Server-Zertifikat) --> verbleibt alleinig auf dem VPN-Server
server.key (geheimer Server-Schlüssel) --> verbleibt alleinig auf dem VPN-Server
notebook1.crt (öffentliches Client1-Zertifikat) --> verbleibt alleinig auf dem VPN-Client1
notebook1.key (geheimer Client1-Schlüssel) --> verbleibt alleinig auf dem VPN-Client1
notebook2.crt (öffentliches Client2-Zertifikat) --> verbleibt alleinig auf dem VPN-Client2
notebook2.key (geheimer Client2-Schlüssel) --> verbleibt alleinig auf dem VPN-Client2
notebook3.crt (öffentliches Client3-Zertifikat) --> verbleibt alleinig auf dem VPN-Client3
notebook3.key (geheimer Client3-Schlüssel) --> verbleibt alleinig auf dem VPN-Client3
ta.key (geheimer Pre-Shared-Key) --> benötigen VPN-Server- wie Clients
2.7 Übertragung der notwendigen Dateien auf die Clients
Die Client-Dateien “notebookx.crt” und “notebookx.key” kopieren/verschieben (der Server benötigt diese Dateien NICHT) wir auf sicherem Wege ins Verzeichnis C:\Programme\OpenVPN\easy-rsa\keys\ (bzw. unter Linux: /etc/openvpn/easy-rsa/keys/) der jeweiligen Notebooks. Zusätzlich KOPIEREN (Dateien müssen auch auf dem Server liegen) wir noch die Dateien:
ca.crt
ta.key
ins Key-Verzeichnis der Clients.
3. Anlegen der OpenVPN-Netzwerkbrücke auf dem VPN-Server
Das Anlegen der Netzwerkbrücke ist natürlich nur auf dem VPN-Server notwendig. Bei den Clients ist hier nichts zu tun.
Unter Windows (nur XP/Vista/7/Server 2003/Server 2008! W2K unterstützt von Haus aus kein Bridging):
Der Single-Netzwerkadapter, welcher von OpenVPN bei der Installation angelegt wurde, ist in “tap-bridge” umzubenennen. Nun bilden Sie zwischen dem verbundenen physischen Netzwerkadapter und dem tap-bridge-Adapter eine Netzwerkbrücke (dazu beide Adapter markieren, rechte Maustaste, Netzwerkbrücke hinzufügen...) und vergeben der Brücke eine feste IP-Adresse. In unserem Beispiel wäre das:
IP-Adresse: 192.168.1.10 | Mask: 255.255.255.0 | Gateway 192.168.1.1 | DNS-Server 192.168.1.1
Eine evtl. installierte/aktivierte Firewall-Lösung auf dem Windows-VPN-Server-Rechner muss dahingehend angepasst werden, dass sie Verkehr auf den beiden neuen Adaptern (NW-Brücke und tap-bridge) zulässt.
Unter Linux:
Editieren Sie das bridge-start Script und vergeben Sie für br0 (spätere Netzwerkbrücke) die IP-Adresse (wie im vorherigen Absatz unter Windows beschrieben) in Anlehnung an die überbrückte physikalische Netzwerkanbindung (kann vorher mit dem Kommandobefehl ifconfig gecheckt werden).
Starten Sie jetzt das bridge-start Script, welches dann einen tap0-Adapter (VPN-Adapter) und br0-Adapter (Netzwerkbrücke) erstellt und mit dem aktiven Netzwerkadapter verbindet (überbrückt). Die Linux-Firewall wäre dahingehend anzupassen, dass sie Packete durch die neuen Netzwerkadapter br0 ud tap0 passieren lässt:
iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT
Die OpenVPN-Bridge kann jetzt über folgende Befehlssequenz gestartet bzw. gestoppt werden:
4. Anlegen der OpenVPN-Konfigurations-Dateien
Diese lauten “server” und “client1”, “client2”, “client3” mit der Endung “.ovpn” (unter Windows) bzw. “.conf” (unter Linux) und weisen OpenVPN an, wie zu verfahren ist. Starten Sie einen Texteditor Ihrer Wahl und geben folgende Parameter ein (beinhaltet alle grundlegenden Einstellungen, sprich es handelt sich um eine rudimentäre Konfiguration):
4.1 server.conf | server.ovpn (zum obigen Beispiel):
# die lokale IP-Adresse des physikalischen Netzwerkadapters (nur bei mehreren aktiven Adaptern
# erforderlich), der verwendet werden soll In unserem Beispiel ist das 192.168.1.10:
local 192.168.1.10
# Server-Mode
mode server
# zusätzlich TLS-Authentication-Server
tls-server
#Auf welchen TCP oder UDP Port soll der VPN-Server reagieren? Möchten Sie mehrere OpenVPN-Sessions
# auf derselben Machine betreiben, geben Sie für jede Session einen eigenen Port an. In unserem Beispiel:
port 5000
#Angabe des Transport-Protokolls (UDP oder TCP)
proto udp
#Angabe des Modus: Bridging (TAP-Device) oder Routing (TUN-Device)
dev tap
#Welcher Adapter soll verwendet werden:
dev-node tap-bridge
#Verbindung zum lokalen Netzwerk
push “route-gateway 192.168.1.1”
#Wo befinden sich die Schlüssel und Zertifikate:
#Unter Windows muss in der .ovpn-Datei für den Backslash ein doppelter Backslash
#für Pfade eingegeben werden (unter Windows 7: Pfade zusätzlich mit Anführungszeichen einfassen!).
#In unserem Bsp.
#
#Windows:
ca c:\programme\openvpn\easy-rsa\keys\ca.crt
cert c:\programme\openvpn\easy-rsa\keysserver.crt
key c:\programme\openvpn\easy-rsa\keysserver.key
# Der zweite Parameter zu tls-auth lautet 0 beim Server und 1 beim Client
tls-auth c:\programme\openvpn\easy-rsa\keys\ta.key 0
dh c:\programme\openvpn\easy-rsa\keys\dh1024.pem
#
#Linux:
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
# Der zweite Parameter zu tls-auth lautet 0 beim Server und 1 beim Client
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
#Soll komprimiert werden? Wenn ja:
comp-lzo
#Welcher Verschlüsselungs-Algorithmus soll verwendet werden?
cipher AES-256-CBC
#Aufrechterhaltung der Verbindung
keepalive 10 120
#Wieviele Verbindungen parallel (in unserem Bsp. drei):
max-clients 3
4.2 client1.conf | client1.ovpn (zum obigen Beispiel):
# Bekanntmachung als Client
client
#Die (Internet-)IP-Adresse (oder Host) und der Port des VPN-Servers.
# Eine statische Internet-IP-Adresse des Servers wäre hilfreich, ansonsten kann man sich z.B. über eine
# dynamische DNS-Auflösung helfen (z.B. über DynsDNS.org) und den Host angeben
# In unserem Bsp. ist die aktuelle (feste) Internet-IP 217.30.25.18 und es wird der
# Standard-UDP-Port 5000 vom Server verwendet:
remote 217.30.25.18 5000
#Port des Clients (z.B. port 1194). Wird nobind angeben, ist dies standardmässig 1194
nobind
#Angabe des Transport-Protokolls (UDP oder TCP) für die gewählten Ports:
proto udp
#Angabe des Modus: Bridging (TAP-Device) oder Routing (TUN-Device)
dev tap
#Welcher Adapter soll verwendet werden (es muss der Name des Single-OpenVPN-Adapters angegeben werden, wenn dieser “OpenVPN” benannt wurde sieht´s wie folgt aus):
dev-node OpenVPN
#IP-Adresse im VPN-Netz (bridged) = Zielnetzwerk. Wir vergeben eine IP-Adresse, die nicht in Konflikt
#mit bereits vorhandenen IP-Adressen-Ranges (z.B. des DHCP-Servers) gerät. In unserem Beispiel sind
#wir im Bereich über *.*.*200 im absolut sicheren Bereich:
ifconfig 192.168.1.201 255.255.255.0
#Wo befinden sich die Schlüssel und Zertifikate:
#Unter Windows muss in der .ovpn-Datei für den Backslash ein doppelter Backslash
#für Pfade eingegeben werden (unter Windows 7: Pfade zusätzlich mit Anführungszeichen einfassen!).
#In unserem Bsp.
#Windows:
ca c:\programme\openvpn\easy-rsa\keysca.crt
cert c:\programme\openvpn\easy-rsa\keys\client1.crt
key c:\programme\openvpn\easy-rsa\keys\client1.key
# Der zweite Parameter zu tls-auth lautet 0 beim Server und 1 beim Client
tls-auth c:\programme\openvpn\easy-rsa\keys\ta.key 1
#
#Linux:
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/client1.crt
key /etc/openvpn/easy-rsa/keys/client1.key
# Der zweite Parameter zu tls-auth lautet 0 beim Server und 1 beim Client
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 1
#Soll komprimiert werden? Wenn ja:
comp-lzo
#Welcher Verschlüsselungs-Algorithmus soll verwendet werden?
cipher AES-256-CBC
Es ist wir unter 4.2 zu verfahren, wobei die Schlüsseldateien und Zertifikate nun auf
client2 respektive client3 lauten und für
Client2 die IP-Adresse 192.168.1.202 sowie für Client3 die IP-Adresse 192.168.1.203
unter ifconfig anzugeben wäre.
5. Öffnen des gewählten Ports auf NAT-Router des Zielnetzwerks (sog. Virtual Server o. Portforwarding):
Auf einem evtl. vorhandenen Router wäre der gewählte Port an die interne/lokale IP-Adresse weiterzuleiten. In unserem Fall wäre das der Standard-UDP-Port 5000 an 192.168.1.10
6. Anpassung evtl. vorhandener Firewalls auf VPN-Server- und -Client-System sowie evtl. Router und weitere Server. Siehe nähere Details im Kapitel I, es ist mit den hiesigen Verhältnissen äquivalent zu verfahren. Zusätzlich muss natürlich den neuen IP-Adressen 192.168.1.201-203 der Weg im LAN geebnet werden, d.h. evtl. vorhandene Firewalls auf den Servern, die von den VPN-Clients im LAN angesteuert werden sollen, sind entsprechend anzupassen. Evtl. auch Berechtigungsebenen, sofern diese auf IP-Adressen basieren.
7. Starten des OpenVPN-Servers:
8. Starten des OpenVPN-Clients (am Bsp. von Client1):
Der Client befindet sich beispielsweise im Hotel und verbindet sich über das angebotene WLAN (unsicher) mit dem Internet (unsicher). Nach dem Aufbau der VPN-Verbindung, werden ALLE Daten, die zwischen dem Notebook und dem VPN-Server ausgetauscht werden streng (AES) verschlüsselt. Potentielle Angreifer, die versuchen Pakete im Hotel-WLAN oder im Internet abzugreifen, erhalten somit nur Datenmüll.
9. Testen der Verbindung:
Der OpenVPN-Server sollte diesen Status melden:
Peer Connection Initiated with
Initialization Sequence Completed
Der OpenVPN-Client sollte ebenfalls den Status connected mit der zugeteilten IP-Adresse melden.
Der Server oder Client kann nun zum Test angepingt werden (natürlich muss der Router und das OpenVPN-Server-System ICMP-Verkehr zulassen).
10. Zugriff auf das (VPN-bridged) Ziel-Netzwerk:
Jetzt ist es möglich, auf das Zielnetzwerk sicher zuzugreifen als wäre man physisch vor Ort im LAN (z.B. Öffnen von freigegeben Ordnern über Samba- oder Windows-Shares oder Abruf der eMails vom internen Mailserver, Zugriff auf Application-Server-Anwendungen....).
Der grosse Vorteil des VPN-Bridging gegenüber dem VPN-Routing ist, dass Verbindungen möglich sind, die von LAN-broadcasts (z.B. Windows NetBIOS file sharing) abhängig sind, d.h. Netzwerk-Browsen funktioniert, ohne dass ein separater WINS-Server (z.B. Samba) aufgesetzt werden muss (wie beim Routing). Der Nachteil gegenüber dem Routing ist, dass Bridging viel Verkehr produziert und die Verbindung deshalb langsamer ist. Auch ist das Management von Berechtigungen schwieriger zu handhaben.
11. Beenden von OpenVPN:
Unter Windows genügt das Beenden der VPN-Anwendung oder Systemdienstes. Unter Linux muss der Prozess manuell gestoppt werden (z.B. über Befehl killall openvpn mit root-rechten, wenn man die Prozess-ID nicht kennt).
Bei einem bridged VPN ist darauf zu achten, dass es keine IP-Adress-Konflikte mit dem Zielnetzwerk gibt (innerhalb des Subnet), d.h. es ist - bei statischer Vergabe der VPN-IP-Adressen (wie im obigen Beispiel) - ein VPN-Adressbereich ausserhalb eines evtl. vorhandenen DHCP-Servers bzw. von statischen IP-Adressbereichen des Zielnetzwerks zu wählen.
 Kommentieren
|
Menü: Tutorial OpenVPN 2
