Beim Routing wird jeder Gegenstelle eine virtuelle IPAdresse eines beliebigen subnetzes zugewiesen. Eine Verbindung zum dahinterliegenenden LAN ist grundsaetzlich erstmal nicht moeglich. Es besteht ausschliesslich eine Verbindung von Client zu Server. Der Rest wird ueber Routingtabellen festgelegt.
Hier geht es aber nur ueber OpenVPN mittels Routing.
# aptitude install openvpn
Damit OpenVPN funktioniert muss das Kernelmodul "tun" geladen sein. GGf mit
# modprobe tunnachladen bzw in die /etc/modules eintragen.
Bei virtuellen Systemen tritt oft der Fehler auf, dass das Tunnelinterface nicht korrekt erstellt wird. Deshalb ggf. folgendes ausfuehren:
# sudo mkdir -p /dev/net
# sudo mknod /dev/net/tun c 10 200
# sudo chmod 600 /dev/net/tun
1. Methode: PreShared Keys
nicht so sicher; einfachste Variante; fuer jeden Teilnehmer wird ein Key erstellt, mit dem der Tunnel verschluesselt wird. Server und Client muss der Key bekannt sein. Bei mehreren Usern, fuer jeden User einen eigenen Key. Bekommt jemand anderes den key, kann der Datenverkehr entschluesselt werden.
# cd /etc/openvpn
Key erstellen:
# openvpn --genkey --secret name.key
# chmod go-rwx name.key
Den Key auch auf den Client kopieren (am besten home-Verzeichnis)
Fuer jeden Client muss eine eigene Configfile angelegt werden. Ein Client benoetigt einen eigenen Port!
Konfiguration:
Auf dem Server:
# vim /etc/openvpn/name.conf
dev tun
ifconfig 10.0.0.1 10.0.0.2
secret ./name.key
port 1194
proto udp
Auf dem Client:
# vim /etc/openvpn/servername.conf
remote servername.domain.de
dev tun
ifconfig 10.0.0.2 10.0.0.1
secret /home/username/name.key
port 1194
proto udp
VPN Verbindung herstellen:
Bevor man eine Verbindung herstellen kann, muss sichergestellt sein, dass der Port in der Firewall offen ist. Bei Firehol muss die /etc/firehol/firehol.conf folgendermassen ergaenzt werden:
interface eth0 internet
...
server custom openvpn "tcp/1194 udp/1194" default accept
auf dem Server:
# /etc/init.d/openvpn restart
Es wird fuer jede .conf file im /etc/openvpn/ Ordner ein VPN Server gestartet.
Auf dem Client:
# openvpn --config /etc/openvpn/servername.conf
Spaeter lieber mit network-manager oder aehnliches.
Nun muessten sich Server und Client gegenseitig pingen koennen 10.0.0.1 <-> 10.0.0.2
Damit der Client jetzt auch auf das LAN vom Server zugreifen kann, muss Routing eingefuhert werden:
Auf derm Server in der /etc/firehol/firehol.conf:
Fuer LAN (vorausgesetzt tun0 ist das Tunnelinterface und eth1 das Interface zum LAN)
router vpn2lan inface tun0 outface eth1
# client all accept
# server all accept
masquerade
route all accept
Soll der Client auch ins Internet duerfen (sinnvoll wenn man irgendwo is,es sind viele nette Seiten geblockt, VPN geht aber, dann kann man ueber das Internet des Servers auf die Seiten ;) o.a.)
router vpn2internet inface tun0 outface eth0
# Wenn nicht alles erlaubt sein soll, dann ggf. wie gewohnt erlauben/blocken
masquerade
route all accept
Auf Clientseite wird das Routing ueber die openvpn config geregelt:
Fuer das LAN auf der anderen Seite:
/etc/openvpn/servername.conf
# neues gateway
route-gateway 10.0.0.1
# Netz und Maske des entfernten LANs
route 192.168.0.0 255.255.255.0
Fuer Internet muss zusaetzlich folgendes Routing erstellt werden:
/etc/openvpn/servername.conf
# bisheriges Standardgateway erstetzen
redirect-gateway
# Saemtliche Adressen ueber den VPN Server routen
route 0.0.0.0 0.0.0.0
Der Client geht nun ueber die Internet Verbindung des Servers.
Unter Windows: Route hinzufügen in der Konsole
route add 192.168.99.0 mask 255.255.255.0 10.0.0.1 metric 1 -p
2. Methode: Authentifizerung mit Zertifikaten
Prinzip:
Ein Client startet eine Verbindung zum OpenVPN Server. Der Server uebermittelt sein X.509 Zertifikat, was vom Client auf echtheit ueberprueft wird. Ueberpruefung anhand des public keys.War das erfolgreich authentifiziert sich der Client mit seinem X.509 Zertifikat. jetzt prueft der Server auch ahnhang des public keys der CA ob dieser guelitg ist. Zusaetzlich wird ueberprueft ob der Client in der CRL ist oder nicht. In der CRL (Certificate Revokation List) befinden sich alle zurueckgezogenen Zertifikate. Ist das Clientzertifikat also enthalten (client wurde gesperrt), kann keine Verbindung hergestellt werden. Ist der Client nicht enthalten werden mit ssl/tls keys ausgehandelt um die verbindung zu verschluesseln.
Hat man schon eine eigene RootCA kann man diese einfach verwenden. Man muss lediglich ein Zertifikat fuer den Server und eins fuer den Client erstellen. Dann unten bei Konfiguration fortfahren. sonst bam:
aptitude install openssl
Grobe Einstellungen kann man in der /etc/ssl/openssl.cnf vornhemen:
wenn man will kann man ein paar sachen bzgl Struktur/Name der CA im Block [CA_default] vornehmen, muss aber nicht sein.
Die Anzahl der Bits fuer ein Zertifikat sollte man von 1024 auf 2048 stellen (paranoide nerds 4096, aber achtung. das dauert spaeter noch ewig. also lieber 2048 ;-).
Dh. also im Block [ req ] den Wert von default_bits auf 2048 setzen.
Die CA kann man selbst erstellen, muss aber nciht sein, weil es schon ein Skript gibt was das macht. das liegt in /usr/lib/ssl/misc/CA.sh
dort gegebenfalls den Wert von CATOP=./demoCA auf den gleichen Wert aendern, der in der openssl.cnf im Block [CA_default] angegeben wurde.
Nun kann man eine neue CA mit
# cd /etc/ssl/erstellen.
# /usr/lib/ssl/misc/CA.sh -newca
Das Passwort was man dort eingibt is immer wieder wichtig, um Zertifikate zu erstellen, zu revoken etc...
Falls gewuenscht, eine CRL (Certificate Revokation List) erstellen:
openssl ca -gencrl -out name
Achtung: name muss so heissen wie in der openssl.cnf, sonst funzt spaeter garnix. Standardmaessig ist das crl.pem.
Es kann sein, dass ein Fehler bzgl einer CRLNumber kommt.. Dann einfach im Ordner der CA eine Datei "crlnumber" erstellen, welche "00" gefolgt von einer Leerzeile als Inhalt hat.
Diffie Hellman parameter erstellen (wird benoetigt damit Server und Client einen gemeinsamen schluessel erzeugen koennen):
openssl dhparam -out dh2048.pem 2048(Das dauert ewig)
Server Zertifikat erstellen:
Sign request:
openssl req -nodes -new -keyout servername.key -out servername.csr
Zertifikat signieren:
openssl ca -out servername.crt -in servername.csr
Ich habe mir im Order der CA einen unterordner "csr" gemacht wo alle Sign requests rein kommen.
Die keys die hier mit keyout erzeugt werden gehoeren in den private-Ordner und die Zertifkate gehoeren in newcerts. Ist nicht notewendig, aber Ordnung muss sein.
Client Zertifikat analog erzeugen.
Es ist darauf zu achten das bei der Zertifikatserstellung bei CommonName immer etwas anderes steht. Am besten Server oder Benutzer/Client-Name, da sonst spaeter garnix geht.
Konfigurationsfiles fuer OpenVPN:
wie bei Methode 1 eine config in /etc/openvpn/ anlegen und wie folgt fuellen:
dev tun
ifconfig 10.0.0.1 10.0.0.2
tls-server
dh /etc/ssl/FBCA/dh2048.pem
ca /etc/ssl/FBCA/cacert.pem
cert /etc/ssl/FBCA/newcerts/fblxfw0.pem
key /etc/ssl/FBCA/private/fblxfw0.key
crl-verify /etc/ssl/FBCA/crl.pem
port 1194
proto udp
verb 3
Client konfigurieren:
remote servername.bla.de
dev tun
ifconfig 10.0.0.2 10.0.0.1
tls-client
ca /home/username/cacert.pem
cert /home/username/username.pem
key /home/username/username.key
port 1194
proto udp
verb 3
// Routing wie bei Methode 1. je nach dem was man will.
Im "debug" Mode am besten auf erst auf Server dann auf Client
openvpn --config pfadzurconfigstarten.
Durch "verb 3" in den configs sieht man ob alles mit den Zertifikaten geklappt hat.
War das alles erfolgreich, kann man openvpn auf dem Server als deamon starten
/etc/init.d/openvpn start.
Auf dem Client ginge es genauso, nur is das evlt unguenstig, wenn der Client bei jedem Booten sofort automatisch die VPN Verbindung herstellt. Deshalb entweder die config aus dem /etc/openvpn ordner rausholen oder den openvpn dienst beim systemstart dekativieren und manuell starten.
Zertifikat revoken:
Moechte man, dass ein User/Client keinen Zugriff mehr auf den Server erhalten hat, muss man lediglich sein Zertifikat zurueckziehen.
openssl ca -revoke /etc/ssl/CABLA/newcerts/certifikateTorevoke.pem
Ein zurueckgenommenes Zertifikat kann nie wieder benutzt werden, auch nicht durch neu signieren oder aehnliches... Will man einem User also wieder Zugriff geben, muss ein komplett neues Zertifikat erzeugt werden.
Damit der OpenVPN Server auch ueberprueft, ob ein Zertifikat zurueckgezogen wurde oder nicht, ist folgende Zeile in der openvpn config File des Servers unbedingt notwendig:
crl-verify /etc/ssl/FBCA/crl.pem
"Tuning":
Datenkompression
Um den Datendurchfluss zu erhoehen, kann man LZO-Kompression aktivieren.(ist ressourcenschonend, trotzdem nicht bei uralt kisten)
Dazu einfach in den Configs folgendes ergaenzen:
comp-lzo
Damit das funktioniert, muss OpenVPN mit LZO-Kompression kompiliert worden sein (ist bei etch schon der fall).
DoS Attacken vermeiden
Nur eine zusaetzliche Authentifizierung. Keine extra Verschluesselung; es werden nur die tlspakete signiert. damit kann der Server vor dem Handshake einen nicht berechtigten client erkennen und die verbindung trennen.
openvpn --genkey --secret tlsauth.key
dieser Key muss auf Client und Server vorhanden sein, und durch folgenden Eintrag in der config aktiviert werden:
tls-auth tlsauth.key
Sessionkeys regelmaessig erneuern
reneg-sec 1800
Sessionkeys für die Verschlüsselung werden halbstuendlich erneuern. nicht zu oft sonst verbindungsabbruch.
Zusaetzliche AUthentifizierung durch Username/passwort
Es gibt noch viele moeglichkeiten einer zusaetzlichen Authentifizierung. Authentifizierung gegen ActiveDirector, LDAPVerzeichnis uvm. OpenVPN kann davon ueberhaupt nichts. Es kann nur Skripte starten mit folgendem Eintrag in der server-config:
auth-user-pass-verify skript.sh via-env
gibt das skript den exit-code 0 zurueck, so war die authentifizierung erfolgreich, ansonsten nicht.
Wie das Script aussieht, bleibt jedem selbst ueberlassen.
Die einfachste Variante waere sowas:
#!/bin/sh
USER="bam"
PASSWD="gas"
if [ "$username" == "$USER" ] && [ "$password" == "$PASSWD" ]
then exit 0
fi
exit 1
Keine Kommentare:
Kommentar veröffentlichen