• Auf dem OpenVPN-Server muss IP-Forwarding angeschaltet sein

sysctl -w net.ipv4.ip_forward=1

bzw. dauerhaft in /etc/sysctl.conf eintragen.

• Ebenfalls muss das OpenVPN-Netz beim Übergang ins Internet geNATet werden. Dazu muss eine iptables Regel gesetzt werden. Diese Befehlszeile muss jedesmal ausgeführt werden, wenn OpenVPN gestartet wird, damit es funktioniert. Deswegen wird unter /etc/openvpn/firewall.sh ein Script angelegt, welches folgenden Inhalt hat.

#!/bin/sh
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Und anschließend muß noch in die OpenVPN-Konfigurationsdatei auf dieses Script gezeigt werden.

route-up /etc/openvpn/firewall.sh

Dann wird für in die clientspezifische Konfigurationsdatei in /etc/openvpn/ccd folgendes geschrieben:

push "redirect-gateway def1"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

Ersteres weist den Client an den OpenVPN-Server als Default-Gateway einzutragen und die nächsten beiden Anweisungen geben dem Client die OpenDNS-Server als DNS-Server.

Ich habe dafür extra clientspezifische Konfigurationsdateien in /etc/openvpn/ccd abgelegt, damit man zukünftig die Wahl hat.

Backup von bestimmten Dateien

Häufiger möchte man, wenn man mal schnell etwas in einer Config-Datei etwas ändert, davon fix ein Backup anlegen. Klassisch habe ich das meist schnell mit

cp DATEI.conf DATEI.conf.orig

gelöst. Was aber passiert, wenn man dann später nochmal was ändern will respektive ein neues Backup angelegt werden soll?! Wie man dieses Problem erschlägt, habe ich schon mal in diesem Artikel erklärt — das war aber nur ein Schnellschuß. Das Problem dabei ist nämlich, das man ja jeweils die alten Backups nochmal mitsichert und dadurch die Backups immer größer werden. Dies kann man durch einen Exclude-Parameter von tar auschließen. Der Befehl um in einem Verzeichnis alle Dateien zu sichern lautet also

tar -cz --no-recursion --exclude=backup-*.tar.gz -f backup-$(date +%F-%H-%M).tar.gz *

Backup von ganzen Pfaden inkl. der Unterverzeichnisse

In einigen Fällen will man nicht nur die Dateien in einem Verzeichnis sichern sondern lieber gleich den Inhalt gesamte Verzeichnis inklusive aller Unterverzeichnisse

tar -cz --exclude=backup-*.tar.gz -f backup-$(date +%F-%H-%M).tar.gz .

Backup von Dateien bzw. Pfaden, die im gesamten System verteilt sind

Und schließlich hat man den Fall, das man alle wichtigen Dateien eines Systems sichern will, die aber über das gesamte System verteilt sind. Dies erreicht man mit einer Include-Datei

tar cvzf /backup-$(date +%F-%T).tar.gz -T /etc/backup-include-dir.conf

wobei man in die Datei /etc/backup-include-dir.conf alle Pfade bzw. alle Dateien reinschreibt, die gesichert werden sollen. Wichtig ist dabei nur: Pro Datei/Pfad jeweils eine Zeile.

Und denkt daran: Solche Befehlszeilen eignen sich wunderbar dazu als alias definiert zu werden, damit man schnell drauf zugreifen kann, wenn man es mal braucht.

Ich nutze schon seit Jahren Router, die ich mit der alternativen Firmware OpenWRT betreibe. Mir geht es dabei nicht darum, das ich den Herstellern misstraue, sondern primär darum, das mir OpenWRT die Möglichkeit lässt selbst zu entscheiden, welche Dienste ich auf dem Router anbieten will und welche nicht. Dazu kommt, das die Firewall deutlich besser konfigurierbar ist und das ich mich per SSH auf den Router und über darüber gesetzte Tunnel auch auf das Netzwerk dahinter Zugriff habe. Davon einmal ganz abgesehen ist es natürlich auch gut zu wissen, das die Macher hinter OpenWRT Sicherheitslöcher stopfen — ein Verhalten, was man sich von den Hardware-Herstellern wünschen würde. Ich bin bis dato immer gut mit den Routern der Firma ASUS gefahren — zuerst hatte ich einen Asus WL-500g Deluxe, später einen Asus WL-500g Premium. Der Vorteil dieser Router: Sie haben zwei USB 2.0-Ports — da kann man z.B. Festplatten dranhängen und diese als Netzwerkplatten freigeben.

Aber zurück zu OpenWRT: Mit der neuesten Version von OpenWRT Kamikaze 8.09.1 ist aber über die Weboberfläche LuCI keine Steuerungs– und Konfigurationsmöglichkeit von OpenVPN möglich. Deswegen kann aus dem OpenWRT-Forum der Tipp, es mit der Trunk-Version von OpenWRT zu probieren. Da es diese Versionen aber nicht als fertiges Image gibt, muss man diese selbst kompilieren.

Dazu habe ich mir in einer VM ein frisches Debian Lenny aufgesetzt und mit

apt-get install build-essential mercurial subversion cvs zlib1g-dev gawk bison flex libncurses5-dev unzip

die Basis geschaffen.

Update: Also entweder hat noch nie jemand versucht meine Anleitung nachzuvollziehen, Ihr wart zu faul was zu schreiben oder aber Ihr hattet schon fertige Debian-Installationen — in der Aufzählung der benötigten Pakete fehlte noch unzip. Ich habe die Befehlszeile mal vervollständigt.

Anschließend legt man sich am besten ein neues Unterverzeichnis an

mkdir openwrt

und wechselt in dieses Verzeichnis

cd openwrt

Jetzt kann man sich die OpenWRT-Dateien herunterladen

svn co svn://svn.openwrt.org/openwrt/trunk/ .

Wichtig dabei ist, das man dies alles als normaler Nutzer macht — nicht als root.

Da die LuCI-Weboberfläche für OpenVPN nur in den Trunk-Paketen ist, müssen die Quellen für die Pakete noch angepasst werden

echo "src-svn packages svn://svn.openwrt.org/openwrt/packages" >> feeds.conf
echo "src-svn luci http://svn.luci.subsignal.org/luci/trunk/contrib/package" >> feeds.conf

Jetzt noch die Paketliste aktualisieren

./scripts/feeds update

Und die Pakete für LuCI einbinden

./scripts/feeds install -a -p luci

Und schon kann man mit

make menuconfig

das Image vorbereiten — sprich die Auswahl machen, was alles in das Image hinein soll.

Abschließend ein

make

und nach ewig langer Zeit liegt ein Imagefile in dem Unterverzeichnis bin, welches geflasht werden möchte.

Links

http://openwrt.org/

http://de.asus.com/products.aspx?l1=29&l2=172&l3=743&l4=59&model=1121&modelmenu=1

http://de.asus.com/products.aspx?l1=12&l2=43&l3=0&l4=0&model=359&modelmenu=1

http://kamikaze.openwrt.org/8.09.1/

http://www.openvpn.net/index.php/open-source.html

https://forum.openwrt.org/viewtopic.php?pid=94844#p94844

# deb cdrom:[Debian GNU/Linux 5.0.2 _Lenny_ - Official i386 NETINST Binary-1 20090629-11:06]/ lenny main
 
deb http://ftp.de.debian.org/debian/ lenny main
deb-src http://ftp.de.debian.org/debian/ lenny main
 
deb http://security.debian.org/ lenny/updates main
deb-src http://security.debian.org/ lenny/updates main
 
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main

Das Format einer solchen Zeile läßt sich wie folgt zusammenfassen:

deb/deb-src uri distribution [component1] [component2] [...]

Kurz zum Aufbau einer solchen Zeile:

deb bzw. deb-src

Darüber definiert man die Art der Pakete. deb stellt dabei die debian-Pakete im Binärformat dar, deb-src die Pakete mit den Programmquellen, welche selbstständig kompiliert werden können. Wenn man nicht selber aus Quelldateien etwas kompilieren will, kann man alle deb-src Einträge löschen — das spart Platz und beschleunigt die Aktualisierung der zur Verfügung stehende Pakete.

uri

Hier steht die URL des sogenannten Repository,  sprich dem Ort, wo alle Pakete zu finden sind.

distribution

Mit diesem Eintrag definiert man die debian-Version, für die man Pakete haben möchte. Dies geht einmal über den Namen der Version — im obigen Beispiel lenny, oder aber über die Platzhalter stable, testing und unstable.

component

Das ist der interessanteste Teil der Zeile, da hier die Paketsektion definiert ist, die aus lizenzrechtlichen Gründen eingerichtet wurden — die Unterscheidung ist bisher main, contrib und non-free.  Wen die Unterschiede näher interessiert, der sollte hier weiterlesen.

Nun aber zum »Pimpen« der/etc/apt/sources.list:

In meinem Fall fliegen alle deb-src Einträge weg, alle deb Einträge bekommen zu main noch contrib und non-free hinzu. Dann kommen die Backports Einträge hinzu. Was das ist, sagen die Macher perfekt

Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. I recommend you to pick out single backports which fits your needs, and not to use all backports available here.

Damit sieht die sources.list jetzt so aus

# deb cdrom:[Debian GNU/Linux 5.0.2 _Lenny_ - Official i386 NETINST Binary-1 20090629-11:06]/ lenny main
 
deb http://ftp.de.debian.org/debian/ lenny main contrib non-free
 
deb http://security.debian.org/ lenny/updates main contrib non-free
 
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free
 
deb http://www.backports.org/debian lenny-backports main contrib non-free

Nachdem man die Backports eingetragen hat, muss man noch die digitalen Signatur für die Backports installieren:

apt-get install debian-backports-keyring
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
Die folgenden NEUEN Pakete werden installiert:
  debian-backports-keyring
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 3362B an Archiven heruntergeladen werden.
Nach dieser Operation werden 49,2kB Plattenplatz zusätzlich benutzt.
WARNUNG: Die folgenden Pakete können nicht authentifiziert werden!
  debian-backports-keyring
Diese Pakete ohne Überprüfung installieren [j/N]? j
Hole:1 http://www.backports.org lenny-backports/main debian-backports-keyring 2009.02.20 [3362B]
Es wurden 3362B in 0s geholt (9289B/s)
Wähle vormals abgewähltes Paket debian-backports-keyring.
(Lese Datenbank ... 30406 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke debian-backports-keyring (aus .../debian-backports-keyring_2009.02.20_all.deb) ...
Richte debian-backports-keyring ein (2009.02.20) ...
OK

Das Alles kann man natürlich noch verfeinern mit den Quellen von testing und unstable, aber wer da noch nicht soviel drüber weiß, kann Vieles kaputt machen — deswegen lieber »Finger weg«.

Links

http://debiananwenderhandbuch.de/sources.list.html

http://www.debian.org/distrib/packages.de.html

http://www.backports.org/

Zuerst habe ich einen neuen Service in /etc/services definiert

# Local services
exchange        12345/tcp                       # Hilfsport für Exchangeeinlieferung

Anschließend wird ein neuer Transportweg in /etc/postfix/master.cf definiert

exchange inet n    -       n       -       -     smtpd
        -o content_filter=
        -o smtpd_delay_reject=no
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_tls_clientcerts,reject
        -o smtpd_data_restrictions=reject_unauth_pipelining
        -o smtpd_end_of_data_restrictions=
        -o smtpd_restriction_classes=
        -o mynetworks=127.0.0.0/8
        -o smtpd_error_sleep_time=0
        -o smtpd_soft_error_limit=1001
        -o smtpd_hard_error_limit=1000
        -o smtpd_client_connection_count_limit=0
        -o smtpd_client_connection_rate_limit=0
        -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
        -o local_header_rewrite_clients=
        -o smtpd_milters=
        -o local_recipient_maps=
        -o transport_maps=hash:/etc/postfix/transport
        -o relay_recipient_maps=

Damit haben wir den Weg für den Exchange-Server auf dem Mail-Gateway geebnet. Nun müssen wir noch den Exchange-Server konfigurieren. Zuerst müssen wir den Smarthost  definieren, also den Server, an den der Exchange alle Mails schicken soll, für die er selber nicht zuständig ist. Das ist in unserem Fall das Mail-Gateway. Definiert wird das Ganze im Default-SMTP-Connector, in meinem Fall heißt dieser Smallbusiness-SMTP-Connector und ist zu unter Administrative Gruppen/Erste administrative Gruppe/Routinggruppen/Erste Routinggruppe/Connectors. Auf der Reiterkarte Allgemein gibt man entweder den FQDN an oder aber, wie in meinem Falle,  die IP in eckigen Klammern an.

Im SMTP-Connector wird der Smarthost definiert

Weitere Informationen findet man in der Microsoft Knowledgebase.

Anschließend muß man noch festlegen, an welchen Port der Exchange-Server für seine ausgehende SMTP-Kommunikation benutzt. Dies definiert man in Administrative Gruppen/Erste administrative Gruppe/Server/SERVERNAME/Protokolle/SMTP. Hier legt der Server nach der Grundinstallation den Virtueller Standardserver für SMTP an. In der Reiterkarte Übermittlung gibt es Ausgeh. Verbindungen und dort findet man den TCP-Anschluß.

Im virtuellen Standardserver für SMTP wird der ausgehende Port definiert

Weitere Infos zum ausgehenden Port findet man in der Microsoft Knowledgebase.

• abgesicherte Kommunikation
• exklusive und vertraute Verbindungen
• Umgehung von providerabhängigen Gängeleien

Neben dem reinen Interesse an der Technik möchte ich folgendes davon erreichen:

• Über den VPN-Tunnel soll mein Heim-Exchange seine Mails an das Mail-Gateway absetzen können — dabei kann ich die spezielle smtpd-Instanz mit weniger Restriktionen laufen lassen (z.B. keine Überprüfung auf Viren und Spam)
• wenn ich das nächste Mail in China bin möchte ich über den VPN-Tunnel ohne Einschränkungen im Internet unterwegs sein können

Aber nun zur Einrichtung:

Vorbereitung

Zuerst müssen wir die Pakete openvpn (klar, was sonst) und udev installieren. udev benötigen wir, damit das Erstellen des virtuellen Interface dynamisch erfolgt.

aptitude install udev openvpn

Damit man über den Server eine Verbindung ins Internet aufbauen kann muß man noch das IP-Forwarding einschalten. Dazu editiert man die Datei /etc/sysctl.conf und aktiviert den Eintrag net.ipv4.ip_forward = 1

Zertifikate erstellen

Wir benötigen für OpenVPN Zertifikate, d.h. eine bestehende CA und müssen dann weitere Clientzertifikate erstellen. Zuerst aber müssen wir einen sogenannten Diffie-Hellman Parameter erzeugen. Dieser wird, laut dem OpenVPN.eu-Wiki, »vom OpenVPN Server verwendet um bei vielen gleichzeitigen Clientverbindungen den TLS-Handshake zu beschleunigen.«

/etc/ssl# openssl dhparam -out dh1024.pem 1024
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
..................+......................+......+...............

Nun nutze ich mein Zertifikatsskript zur Erstellung des Server-Zertifikats

create_certs vpn.domain.de

Und damit habe ich folgende Dateien erstellt, die ich zukünftig brauche /etc/ssl/vpn.domain.de-cert.pem /etc/ssl/private/vpn.domain.de-key.pem Natürlich brauche ich noch Zertifikate für die Clients, diese erstell ich mit

create_certs client1

Wichtig ist dabei, das als common name der Clientname (in dem Beispiel client1) angegeben wird. Anschließend können die Dateien /etc/ssl/client1-cert.pem und /etc/ssl/private/client1-key.pem sowie /etc/ssl/cacert.pem auf den Client kopiert werden, damit dieser sich mit einem gültigen Zertifikat später verbinden kann.

Konfigurationsdatei erstellen

Anschließend habe ich aus /usr/share/doc/openvpn/examples die Datei server.conf.gz nach /etc/openssl kopiert und dort ausgepackt. Beim Editieren dieser Datei habe ich die Pfade und die Namen der Zertifikatsdateien sowie das Logging angepaßt. Die Datei (meine Änderungen sind rot markiert) sieht anschließend so aus

#################################################
# Sample OpenVPN 2.0 config file for            #
# multi-client server.                          #
#                                               #
# This file is for the server side              #
# of a many-clients <-> one-server              #
# OpenVPN configuration.                        #
#                                               #
# OpenVPN also supports                         #
# single-machine <-> single-machine             #
# configurations (See the Examples page         #
# on the web site for more info).               #
#                                               #
# This config should work on Windows            #
# or Linux/BSD systems.  Remember on            #
# Windows to quote pathnames and use            #
# double backslashes, e.g.:                     #
# \"C:\\Program Files\\OpenVPN\\config\\foo.key\" #
#                                               #
# Comments are preceded with '#' or ';'         #
#################################################
	
# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
	
# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 1194
	
# TCP or UDP server?
;proto tcp
proto udp

# \"dev tun\" will create a routed IP tunnel,
# \"dev tap\" will create an ethernet tunnel.
# Use \"dev tap0\" if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use \"dev-node\" for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun
	
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one.  On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this.
;dev-node MyTap
	
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key).  Each client
# and the server must have their own cert and
# key file.  The server and all clients will
# use the same ca file.
#
# See the \"easy-rsa\" directory for a series
# of scripts for generating RSA certificates
# and private keys.  Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see \"pkcs12\" directive in man page).
ca /etc/ssl/cacert.pem
cert /etc/ssl/vpn.domain.de-cert.pem
key /etc/ssl/private/vpn.domain.de-key.pem  # This file should be kept secret
	
# Diffie hellman parameters.

# Generate your own with:
#   openssl dhparam -out dh1024.pem 1024
# Substitute 2048 for 1024 if you are using
# 2048 bit keys.
dh /etc/ssl/dh1024.pem
	
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.8.0.0 255.255.255.0
	
# Maintain a record of client <-> virtual IP address
# associations in this file.  If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt
	
# Configure server mode for ethernet bridging.
# You must first use your OS's bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface.  Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 10.8.0.4/255.255.255.0.  Finally we
# must set aside an IP range in this subnet
# (start=10.8.0.50 end=10.8.0.100) to allocate
# to connecting clients.  Leave this line commented
# out unless you are ethernet bridging.
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
	
# Configure server mode for ethernet bridging
# using a DHCP-proxy, where clients talk
# to the OpenVPN server-side DHCP server
# to receive their IP address allocation
# and DNS server addresses.  You must first use
# your OS's bridging capability to bridge the TAP
# interface with the ethernet NIC interface.
# Note: this mode only works on clients (such as
# Windows), where the client-side TAP adapter is
# bound to a DHCP client.
;server-bridge

# Push routes to the client to allow it
# to reach other private subnets behind
# the server.  Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push \"route 192.168.10.0 255.255.255.0\"
;push \"route 192.168.20.0 255.255.255.0\"
	
# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory \"ccd\" for client-specific
# configuration files (see man page for more info).
	
# EXAMPLE: Suppose the client
# having the certificate common name \"Thelonious\"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
	
# Then create a file ccd/Thelonious with this line:
#   iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN.  This example will only work
# if you are routing, not bridging, i.e. you are
# using \"dev tun\" and \"server\" directives.
	
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
	
# Then add this line to ccd/Thelonious:
#   ifconfig-push 10.9.0.1 10.9.0.2
	
# Suppose that you want to enable different
# firewall access policies for different groups
# of clients.  There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
#     group, and firewall the TUN/TAP interface
#     for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
#     modify the firewall in response to access
#     from different clients.  See man
#     page for more info on learn-address script.
;learn-address ./script
	
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
;push \"redirect-gateway def1 bypass-dhcp\"
	
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses.  CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
# The addresses below refer to the public
# DNS servers provided by opendns.com.
;push \"dhcp-option DNS 208.67.222.222\"
;push \"dhcp-option DNS 208.67.220.220\"
	
# Uncomment this directive to allow different
# clients to be able to \"see\" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.
;client-to-client
	
# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names.  This is recommended
# only for testing purposes.  For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE \"COMMON NAME\",
# UNCOMMENT THIS LINE OUT.
;duplicate-cn
	
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
	
# For extra security beyond that provided
# by SSL/TLS, create an \"HMAC firewall\"
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
#   openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
;tls-auth ta.key 0 # This file is secret
	
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
	
# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo
	
# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100
	
# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
;user nobody
;group nogroup
	
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
	
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log
	
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the \"\Program Files\OpenVPN\log\" directory).
# Use log or log-append to override this default.
# \"log\" will truncate the log file on OpenVPN startup,
# while \"log-append\" will append to it.  Use one
# or the other (but not both).
;log         openvpn.log
log-append  /var/log/openvpn.log
	
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3
	
# Silence repeating messages.  At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20

Natürlich ist die Konfiguration noch lange nicht optimiert und ermöglicht noch nicht alles, was ich mir als Ziel gesetzt habe. Mit einem

/etc/init.d/openvpn start

starten wir den Server. Um zu schauen, ob alles funktioniert schauen wir uns zuerst die Datei /var/log/openvpn.log an

Wed Jun  3 23:26:18 2009 OpenVPN 2.1_rc11 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Sep 18 2008
Wed Jun  3 23:26:18 2009 Diffie-Hellman initialized with 1024 bit key
Wed Jun  3 23:26:18 2009 WARNING: file '/etc/ssl/private/vpn.domain.de-key.pem' is group or others accessible
Wed Jun  3 23:26:18 2009 /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Wed Jun  3 23:26:18 2009 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Jun  3 23:26:18 2009 ROUTE default_gateway=180.190.200.1
Wed Jun  3 23:26:18 2009 TUN/TAP device tun0 opened
Wed Jun  3 23:26:18 2009 TUN/TAP TX queue length set to 100
Wed Jun  3 23:26:18 2009 /sbin/ifconfig tun0 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Wed Jun  3 23:26:18 2009 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Wed Jun  3 23:26:18 2009 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Jun  3 23:26:18 2009 Socket Buffers: R=[129024->131072] S=[129024->131072]
Wed Jun  3 23:26:18 2009 UDPv4 link local (bound): [undef]:1194
Wed Jun  3 23:26:18 2009 UDPv4 link remote: [undef]
Wed Jun  3 23:26:18 2009 MULTI: multi_init called, r=256 v=256
Wed Jun  3 23:26:18 2009 IFCONFIG POOL: base=10.8.0.4 size=62
Wed Jun  3 23:26:18 2009 IFCONFIG POOL LIST
Wed Jun  3 23:26:18 2009 Initialization Sequence Completed

Damit steht unser Server schon mal und in einem weiteren Beitrag zeige ich, wie man sich mit einem Client verbindet.

locale -a

ein. Sollte die Ausgabe

C
POSIX


sein, dann ist klar, warum das nicht funktioniert. Ein

aptitude install locales

Und dann als Auswahl

Nach einem Neustart von apache2 mit

/etc/init.d/apache2 restart

sollte dann alles in Deutsch sein.

Weiter gehts im schnellen Lauf, denn der Teddy gibt nicht auf

Hier der versprochene zweite Teil zum Thema postfix und relay_recipient_maps vom Exchange.

Nachdem wir nun nahezu automatisch die Liste aller gültigen Empfänger auf das Mail-Gateway kopieren können, müssen wir nun die Liste so aufbereiten, das postfix damit etwas anfangen kann.

Bisher sieht die Liste in etwa so aus:

dn: CN=Administrator,CN=Users,DC=example,DC=de
changetype: add
proxyAddresses: SMTP:Administrator@example.de
proxyAddresses: X400:c=DE;a= ;p=EXAMPLE;o=Exchange;s=Administrator;

So kann man die Liste natürlich nicht an postfix geben. Wenn man sich dann die Liste genau anschaut, dann findet man viele Einträge von EMail-Adressen, die der Exchange selber benötigt und die man nicht über das Mail-Gateway erreichbar machen muß. Es müssen also folgende Dinge gemacht werden:

1. Löschen der unnötigen Zeilen.
2. Aufbereiten der Textdatei
3. Hinzufügen des Kommandos OK zu jeder Zeile
4. Löschen der unbenötigten Emailadressen

Dazu verwenden wir das Script von postfix-buch.com. Leider hat sich in dem Script ein kleiner Fehler eingeschlichen . Das Original-Script sieht so aus:

#!/bin/bash
# Extract all Adresses that start with SMTP or smtp from
# an Active Directory export, but omit those that are listed in blacklist
cat $1 | tr -d \" | tr , \\n| tr \; \\n | awk -F\: '/(SMTP|smtp):/ {printf("%s\tOK\n",$2)}' |
grep -v -f blacklist > $2

Wenn man sich das Script aus dem Buch anschaut, dann findet man schnell den Fehler — nach der Korrektur sieht das Script so aus:

#!/bin/bash
# Extract all Adresses that start with SMTP or smtp from
# an Active Directory export, but omit those that are listed in blacklist
cat $1 | tr -d \" | tr , \\n| tr \; \\n | awk -F\: '/^proxyAddresses: (SMTP|smtp):/ {printf("%s\tOK\n",$3)}' |
grep -v -f blacklist > $2

Die Email-Adressen, welche man nicht in der Tabelle haben möchte, schreibt man in eine Datei blacklist. Meine blacklist sieht so aus:

SystemMailbox
Administrator
Default
exchangeV1
globalevents
internal
KontaktevonEXAMPLE
EXAMPLE
EXAMPLE-Archiv
OABVersion2
OABVersion3a
Offlineadressbuch-firstadministrativegroup
PublicFolder08275515@example.de
PublicFolder94568143@example.de
schema-root

Wenn man jetzt das Script ausführt

./extract_valid_recipient /home/exchange/recipient.txt /home/exchange/relay_recipient

So sieht das Ergebnis (less /home/exchange/relay_recipients) dann so aus:

user1@example.de^M OK
useruser2@example.de^M OK
user2@example.de^M OK
Administrator@example.de^M OK

Wie man sieht hat debian Probleme mit dem DOS-Zeilenumbruch. Um diesen Unix-Konform geradezubiegen installiert man sich das Paket tofrodos, welches den Befehl dos2unix mit sich bringt.

Mit einem
dos2unix relay_recipients
wandelt man die Liste um und Voilá!

Das ist natürlich falsch. Man muß die DOS-Zeilenumbrüche in der Original-Datei recipient.txt schon löschen und kann anschließend die Datei durch den Filter schicken.

(Wer es komplizierter mag, der nehme den Befehl flip. Eine Erklärung dazu findet er hier.)

Jetzt wandeln wir die Datei in eine Postfix-Datenbank um

postmap hash:/home/exchange/relay_recipients

und kopieren wir die Datei in das postfix-Verzeichnis

mv /home/exchange/relay_recipients.db /etc/postfix/relay_recipients.db

Wichtig ist der Hinweis im Buch, das die Datenbank-Datei im Home-Verzeichnis unseres exchange-Users erstellt und anschließend kopiert wird, da es beim Fehlschlagen des postmap–Befehls ansonsten keine relay_recipients.db im postfix-Verzeichnis geben und Postfix seinen Betrieb einstellen würde.

Eingebunden in postfix wird es mit einem Eintrag in der /etc/postfix/main.cf

relay_recipient_maps = hash:/etc/postfix/relay_recipients

Jetzt kann man, wenn man es möchte, natürlich das Ganze noch automatisieren und in Scripte packen, dazu noch als Taskplaner/cron ausführen lassen. Aber das kommt später.

Jetzt aber zur Realisierung:

Zuerst muß auf dem Exchange die aktuelle Email-Adressenliste generiert werden. Die Daten sind schon alle im Active Directory vorhanden, man muß sie da nur rausbekommen. Das geht mit Boardmitteln, aber der Reihe nach. Als Erstes lohnt es sich für den Austausch der Listen ein eigenes Verzeichnis anzulegen:

mkdir c:\mailgw

Dann wird die Liste extrahiert:

ldifde -m -n -g -f "C:\Mailgw\recipient.txt" -r "(mailnickname=*)" -l proxyAddresses

Ein kurze Erklärung zu den Parametern:

–g Deaktiviert die seitenweise Suche.
–m Aktiviert die SAM-Logik beim Export.
–n Exportiert keine Binärwerte.
–f Dateiname Dateiname für die Eingabe bzw. Ausgabe.
–r Filter LDAP-Suchfilter (Standard: »(objectClass=*)«).
–l Liste Liste der Attribute (durch Komma getrennt), nach denen bei
der LDAP-Suche gesucht wird.

Das Komplizierteste ist nun der Datenaustausch vom Exchange-Server zum Mail-Gateway. Um dies zu bewältigen muß man dem Exchange-Server zuerst beibringen, wie man per Secure Copy (kurz SCP) Dateien verschicken kann. Es gibt verschiedene Programme dafür, am bekanntesten ist aber als Kommandozeilentool PuTTYs PSCP. Wir benötigen die beiden Programme pscp.exe und puttygen.exe.

Nun legen wir zuerst auf dem debian-Server einen neuen Benutzer an, der nur für den Transfer der Listen auf das Mail-Gateway verantwortlich ist:

useradd -d /home/exchange/ -m exchange

Im Gegensatz zu den Angaben im Buch mußte ich bei debian Lenny das Homeverzeichnis explizit mit angeben, da Lenny anscheinend das nicht selbstständig anlegt.

Nachdem der Benutzer existiert geben wir ihm zuerst einmal ein Passwort:

passwd exchange

Anschließend generieren wir ein SSH-Schlüsselpaar, damit der Dateitransfer ohne die Eingabe von Passwörtern erfolgen kann:

su - exchange
cd ~
ssh-keygen -t rsa

Bei der Nachfrage nach einer Passphrase bitte nix eingeben. Nur wenn hier kein Passwort eingegeben wird, kann der Dateiaustausch wirklich vollautomatisch erfolgen.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/exchange/.ssh/id_rsa):
Created directory '/home/exchange/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/exchange/.ssh/id_rsa.
Your public key has been saved in /home/exchange/.ssh/id_rsa.pub.
The key fingerprint is:
ba:90:03:e8:06:20:5f:30:00:52:a9:11:c6:2e:ae:10 exchange@example.de
The key's randomart image is:
+--[ RSA 2048]----+
|&+..             |
|=*.              |
|.o+              |
|.+ +             |
|. o +   S        |
|E. . . o         |
|..    =          |
|o      +         |
|.     .          |
+-----------------+

Es werden nun zwei neue Dateien im Unterverzeichnis .ssh erstellt: id_rsa und id_rsa.pub

Damit der Server weiß, das der Benutzer exchange mit Hilfe von Schlüsseln auf den Server zugreifen darf, muß man noch den Inhalt der Datei id_rsa an die Datei ~/.ssh/authorized_keys angehängt werden. Dazu gibt man

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

ein und gibt mit

chmod 644 authorized_keys

der Datei die richtigen Rechte.

Nun muß der private Schlüssel des Paares auf einem sicheren Weg zum Exchange-Server kommen. Dazu nutzen wir gleich die pscp.exe.

pscp exchange@mail.example.de:/home/exchange/.ssh/id_rsa .

Ich denke der Syntax ist klar. Natürlich müssen wir uns jetzt mit einem Passwort authentifizieren — genau mit dem, welches wir oben vergeben haben.

Um die Schlüsseldatei nutzen zu können müssen wir sie in ein PuTTY-verträgliches Format wandeln. Dazu nutzen wir die von PuTTY mitgelieferte puttygen.de

puttygen c:\mailgw\id_rsa

es öffnet sich eine GUI

Nach eine Klick auf OK öffnet sich der PuTTY Key Generator-Dialog:

Hier kann man im Feld Key comment dem konvertierten Schlüssel einen Namen wegen und anschließend Save private key drücken.

Aufgrund der leeren Passphrase wird hier eine Warnung ausgegeben, was aber ok ist.

Nun können wir mit dem eben erstellten/konvertierten Key eine verschlüsselte Verbindung zu unserem Mail-Gateway aufnehmen

pscp -i mail.example.de.ppk recipient.txt exchange@mail.example.de:/home/exchange/

Nachdem das geklappt hat, können wir dem Benutzer exchange auf dem Mail-Gateway das Passwort wegnehmen — dann ist ein einloggen nur noch mit dem Key möglich.

usermod -L exchange

Weiter geht es im zweiten Teil, der demnächst erscheint.