Suse Vpn

Aufgabe: Einrichtung eines SuSE-Servers (SuSE 10) mit VPN-Zugang für ein paar Aussendienstmitarbeiter.

Zur Auswahl standen:

• Kauf eines VPN-fähigen DSL-Routers
• ipSEC (FreeSWAN bzw. OpenSWAN)
• PPTP
• OpenVPN

Nach reiflicher Überlegung habe ich mich für OpenVPN entschieden. Der DSL-Router war zu teuer, ipSEC ist zu kompliziert einzurichten, und PPTP ist zu unsicher. OpenVPN http://openvpn.net/ sieht dagegen gut aus.

Installation Linux-Server + Client-Keys

• http://openvpn.net/howto.html#quick
• Zwei mögliche Modi: Routing vs. Bridging. Routing ist einfacher, aber erlaubt z.B. SMB-Zugriff nur auf den Gateway (wegen fehlender Broadcast-Möglichkeit)
• Pub/priv Schlüsselpaar für Server und alle Clients erzeugen

• Master CA (Cert Authority) erzeugen und alle Schlüssel damit signieren

  • cd /usr/share/doc/packages/openvpn/easy-rsa
  • cp -a 2.0 /root/easy-rsa-2.0
  • cd /root/easy-rsa-2.0
  • vim vars
  • ./vars
  • ./clean-all
  • ./build-ca
  • ./build-key-server server
  • ./build-key client1 (z.B: "?LaptopMueller"), oder ./build-key-pass (Key passwortgeschützt)
  • ./build-dh
  • ls -l ./keys

• Kopieren von

  • ca.crt auf alle Clients
  • clientX.{crt,key} auf ClientX
  • vom Server benötigte Files nach /etc/openvpn, dieses entsprechend sichern (geht mode 0700?)

• doc/openvpn/sample-config-files/server.conf

  • UDP 1194 (offiziell), ggf. am Router forwarden!
  • dev tap vs. dev tun (s.o.)
  • bei Tunneln (seperates VPN-LAN) unbenutztes lokales Netz verwenden!)
  • client-to-client on/off (default: off) sollte bleiben, wg. Performance
  • Sicherheit erhöhen durch Ablegen von root-rechten: user,group nobody
  • Optionen: push "dhcp-option DNS xx.xx.xx.xx" und push "dhcp-option WINS xx.xx.xx.xx", Problem: Windows kann Schluckauf kriegen: http://support.microsoft.com/default.aspx?scid=kb;en-us;311218
  • Client-spezifische Zugriffsrechte sind möglich (Benutzerklassen)
• Evtl: http://openvpn-web-gui.sourceforge.net/ (braucht aber Apache2 + PHP5 + Smarty und status-version 2 in server.conf)

Installation Windows-Client

• Download: http://openvpn.se/ thesis
• Zertifikat-Tool: http://openvpn.se/mycert/ (nicht gebraucht, s.o.)

• Konfiguration client.ovpn:

  • ca, cert, key müssen auf die oben erstellten Schlüssel zeigen
  • remote = XXXXXXXX.dyndns.org (der VPN-Server, mit dem verbunden werden soll)
  • dev, comp-lzo, fragment müssen identisch mit server.conf sein

• Autostart beim Booten:

  • Systemst. / Admin tools / Dienste: OpenVPN rechtsklick -> Starttyp=Automatisch (nötig? glaub nicht)

• weitere möglichkeiten:

  • Ganzes FirmenLAN erreichen trotz "dev tun": push "route <server-netz> 255.255.255.0" >> server.conf, ausserdem muss auf dem Gateway (falls != VPN-Server) noch "route add <vpn-lan> gw <vpn-server>" (so ähnlich) eingefügt werden.
  • Mehrere Clients über einen VPN-Client verbinden geht auch (-> HOWTO)
• Windows-VPN Client als NIcht-Administrator starten (aufwändiger): http://openvpn.se/files/howto/openvpn-howto_run_openvpn_as_nonadmin.html

SuSE Firewall Anpassungen

Vorraussetzungen: dev tun (kein bridging). Lokales Netz: 192.168.1.0/24, TUN-Netz (VPN): 192.168.2.0/24.

Server (192.168.1.1) ist gleichzeitig Gateway. Konfiguration des Servers:

local xxxxxx.dnsalias.net
port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem

server 192.168.2.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "route 192.168.1.0 255.255.255.0"
push "dhcp-option WINS 192.168.1.1"
;push "dhcp-option DNS 192.168.1.1"
;push "redirect-gateway"

keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

Konfiguration Client:

client
dev tun
proto udp
remote xxxxxxx.dnsalias.net 1194
resolv-retry infinite
nobind

user nobody
group nobody

persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client5.crt
key /etc/openvpn/client5.key

ns-cert-type server
comp-lzo
verb 3

SuSE Firewall-Anpassungen: (YaST2 > Sicherheit > Firewall, bzw. manuell unter /etc/sysconfig/SuSEFirewall2 bzw. scripts/SuSEfirewall2-custom):

• IP Masquerading muss aktiviert werden
• Erlaubte Dienste nach aussen: TCP 22 (falls SSH gewünscht), UDP 1194 (OpenVPN)
• das tun0 Device muss als interne Schnittstelle hinzugefügt werden
• der Port 1194 muss als UDP-Port von aussen zugänglich sein
• das "-custom" Skript muss aktiviert werden
• im -custom Skript muss in der Funktion _before_denyall() folgendes eingefügt werden, damit der SuSEFirewall den beiden Netzen die Kommunikation miteinander erlaubt:

        iptables -A forward_int -i tun+ -o eth+ -j ACCEPT
        iptables -A forward_int -o tun+ -i eth+ -j ACCEPT

• Sicherstellen, daß FW_DEV_EXT=dsl0 (oder was auch immer) vor FW_MASQ_DEV steht, das war bei mir nicht der Fall und daher hat das Masquerading erst nicht funktioniert.