Mit ein wenig Konfigurations-Fuu lässt sich das ohne Probleme umsetzen.

Die Ausgangssituation

Ich habe zwei Server:

Server A

• OpenVPN Server im 10.10.0.1/24 Netz
• Setzt Default-Route beim Client (push „redirect-gateway def1 bypass-dhcp“)

Server B

• OpenVPN Client mit 10.10.0.10/24 IP am tun1
• Benutzer dessen Traffic weitergeleitet werden soll namens „yacy“

Wie anfangs schon erwähnt möchte ich nur den ausgehenden Traffic des Benutzers „yacy“ über das VPN zu Server A schicken. Folgende Probleme gilt es also auf Server B zu lösen:

• Droppen der „Default“ Route
• Weiterleitung des ausgehenden Traffics des „yacy“ Benutzers
• Der restliche Traffic soll uneingeschränkt über das eth0 Netzwerkinterface laufen

Die Umsetzung

OpenVPN Konfiguration anpassen

Um das erste Problem zu lösen, müssen wir unserem OpenVPN Client mitteilen, das er die vom OpenVPN Server gepushte Default Route nicht annehmen soll. Dazu muss man die folgende Option in die entsprechende „.ovpn“ Konfigurationsdatei eintragen:

#No default route
route-nopull

Trafficweiterleitung

Wir werden später mittels den Iptables Pakete von unserem Benutzer markieren, um diese eine bestimmte Route zu schicken. Dazu erstellen wir zunächst eine neue Routing-Tabelle mit dem Namen „vpn.out“.

echo 201 vpn.out | sudo tee -a  /etc/iproute2/rt_tables

Danach erstellen wir eine Regel, welche alle Pakete mit der Markierung „1“ durch die Tabelle „vpn.out“ jagt:

sudo /sbin/ip rule add fwmark 1 table vpn.out

Bisher sollte unsere neue Routing-Tabelle noch leer sein und die Pakete wissen noch nicht wohin. Das ändert sich jetzt:

sudo /sbin/ip route add default via 10.10.0.10 dev tun1 table vpn.out

Default-mäßig werden alle Pakete die in diese Tabelle kommen über das tun1 Device zum Server A geschickt.

Als nächstes bringen wir unserem „tun1“ Device bei, das es etwas lockerer mit der Überprüfung der Routebarkeit von Paketen sein soll. Der Wert „2“ erlaubt das Akzeptieren des Paketes falls es irgendwie auf irgendeinem Device geroutet werden kann.

sudo /sbin/sysctl -w net.ipv4.conf.tun1.rp_filter=2

Als nächstes müssen wir sicherstellen das alle Pakete vom Benutzer „yacy“, die das System über eth0 verlassen wollen, mit „1“ markiert werden. Dazu verwenden wir die Iptables:

sudo /sbin/iptables -t mangle -A OUTPUT -m owner --uid-owner yacy -o eth0 -j MARK --set-mark 1

Zuletzt müssen wir uns noch darum bemühen das die Pakete auch wieder zu uns zurück finden. Ein Source-NAT ist dafür genau richtig:

sudo /sbin/iptables -t nat -A POSTROUTING -o tun1 -j SNAT --to-source 10.10.0.10

Fertig :)

~ Sebastian

ich hab in letzter Zeit doch etwas häufiger eine nette Email von Fail2Ban bezüglich dem SSH-Port erhalten. Dabei kam es u.a. vor, dass alle 10 Minuten derselbe Angreifer gebannt wurde. Durch einen kleinen Fehler bei den Kommentaren in der Konfigurationsdatei wurde die falsche Bantime verwendet.

Es gibt nämlich 2 verschiedene Kommentarzeichen in der Fail2ban-Konfigurationsdatei.

Einmal das einfache Rautezeichen:

#Ich bin eine Kommentarzeile

Dieses kommentiert eine ganze Zeile aus, egal wo es in dieser steht. Zum Beispiel ist die folgende Zeile ebenfalls ein Kommentar:

Das ist doch komisch! # Warum nicht?

Da ich mit großen Zahlen nicht unbedingt arbeiten kann, sah die BanTime Einstellung bei mir so aus:

bantime  = 86400 #1 Tag

Das führt leider dazu, das Fail2Ban diese Zeile ignoriert und daher seine 10 minütige bantime nutzt. Hätte man mal ins /var/log/fail2ban.log geschaut wäre das einem auch aufgefallen…

2014-04-10 12:59:02,036 fail2ban.filter [25385]: INFO    Set maxRetry = 1
2014-04-10 12:59:02,037 fail2ban.filter [25385]: INFO    Set findtime = 600
2014-04-10 12:59:02,038 fail2ban.actions[25385]: INFO    Set banTime = 600
2014-04-10 12:59:02,132 fail2ban.jail   [25385]: INFO    Jail 'ssh' started

Richtig lautet es daher so hier:

bantime  = 86400 ;1 Tag

Das Semikolon ist das Kommentarzeichen, welches ab Erscheinen den Rest der Zeile auskommentiert. Also das, was man eigentlich vom „#“-Zeichen erwartet hätte.

Nun ja, jetzt sind wir schlauer :)

~Sebastian

Ich habe zwischen meinen Servern ein VPN Netz aufgebaut, damit diese besser untereinander kommunizieren können. Ich wollte nun vom tun0-Interface auf einen Port auf dem Localhost weiterleiten.

Nach dem Durchforsten einiger Tutorials und Büchern zum Thema Portforwarding, kam ich auf folgende Regeln:

sudo iptables -A PREROUTING -t nat -d 10.0.0.1 -p tcp --dport 50000 -j DNAT --to-destination 127.0.0.1:50001
sudo iptables -A FORWARD -p tcp -d 127.0.0.1 --dport 50001 -j ACCEPT 

Die erste Regel leitet alle Pakete mit dem Ziel 10.0.0.1:50000 nach 127.0.0.1:50001 um. Die zweite Regel lässt dann die Pakete mit dem Ziel 127.0.0.1:50001 durch.

Doch das wollte nicht ganz funktionieren. Nach einiger Zeit des Kopfzerbrechens fand ich dann auch eine Erklärung auf Stackoverflow (1. Antwort). Laut dem RFC 5735 darf bzw. kann kein Traffic nach 127.0.0.1 ge-DNAT-ed werden.

Die Lösung bestand dann darin, sich mittels

sudo apt-get install rinetd

rinetd zu installieren. Das Programm dient dann als kleiner Proxy zwischen 10.0.0.1 und 127.0.0.1. Dazu muss man einfach die entsprechenden Portweiterleitungen in die Konfigurationsdatei einfügen (/etc/rinetd.conf):

# bindadress    bindport  connectaddress  connectport
10.0.0.1    50000   127.0.0.1   50001 #Portforward

Danach muss man nur noch den Port 50000 mittels einer INPUT-Regel von außen zugänglich machen, und man hat sein Ziel erreicht.

~Sebastian