OpenVPN Gateway funktioniert nicht

A

Aldaris

New Member
Hallo zusammen,

ich habe auf meinem vServer mit Ubuntu 14.04 von 1blu einen OpenVPN Server aufgesetzt und betreibe ihn mit einer Config, die auf einem anderen vServer (Stratro) problemlos funktioniert hatte. Die Verbindung zum Server wird problemlos aufgebaut, allerdings routet der Server keinen Traffic durch. Sowohl mit dem Windows Client (als Admin ausgeführt) als auch auf einem Android Tablet klappt es nicht. Habt ihr vielleicht eine Idee, was ich noch versuchen könnte? Das Tun/Tab-Device ist nach FAQ von 1blu aktiviert worden.

Hier sind die configs:
server.conf

Code: 
dev tun
port 29437
proto udp

ca ./easy-rsa/keys/ca.crt
cert ./easy-rsa/keys/server.crt
key ./easy-rsa/keys/server.key
dh ./easy-rsa/keys/dh2048.pem


# Subnetz, welches der Server erzeugen soll
# (darf keines der vorhandenen privaten Netzwerke sein!)
server 10.8.0.0 255.255.255.0

# In dieser Datei speichert der Server die Client-IPs
ifconfig-pool-persist ipp.txt

# Gebe dem Client Routen-Informationen mit, damit dieser
# das private Subnetz findet
push "route 10.8.0.0 255.255.255.0"

# Damit wird erzwungen, dass am Client alle Anfragen
# (DNS, Browser) ueber den Tunnel laufen
push "redirect-gateway def1"

# Wichtig fuer Windows-Nutzer:
# traegt das Standardgateway in den TUN/TAP-Adapter ein
push "route 0.0.0.0 0.0.0.0"

# Hier werden die Adressen von OpenDNS mitgeschickt, damit
# die Namensaufloesung ebenfalls durch den Tunnel geschieht
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option WINS 208.67.220.220"

# Clients koennen sich auch "sehen", nicht nur
# die Clients den Server
client-to-client

ping-timer-rem
keepalive 10 120

# Hash-Algorithmus
auth SHA256

# Schnelle und sichere Blowfish-Verschluesselung
cipher AES-256-CBC

# Kompression
# (wenn angegeben, muessen auch alle Clients dies unterstuetzen!)
comp-lzo

# Verbindung immer gleich halten
persist-key
persist-tun

# Optionen fuers Logging
status openvpn-status.log
log-append  openvpn.log

# "Verbose" Level - Logge nur Fehler
verb 3

#Just in case needed...
keysize 256

rc.local:

Code: 
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -o eth0 -i tun0 -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Client.conf:

Code: 
dev tun
port 29437
proto udp
remote xxxxxxxxxx
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
auth SHA256
cipher AES-256-CBC
comp-lzo
verb 3
route-method exe
route-delay 2
keysize 256

Dann kommen die Zertifikate...
 
Du schreibst, dass die Config so auf einem anderen System funktioniert hat. Es ist also davon auszugehen, dass das Problem nicht in der Config zu finden ist.

Deshalb solltest du:
1. prüfen, ob das IP-Forwarding im Kernel aktiviert ist
2. die Logs nach auffälligen Zeilen absuchen und diese hier posten

Client-to-Server und Client-to-Client funktioniert?
 
Ich würd vorallem mal nach der IPTables NAT Table schauen. ;)
Die ist bei vServer Produkten vieler Hoster nicht aktiv.

Einfach zu prüfen mit "iptables -t nat -L -n -v".
 
Besten Dank für Eure Antworten.

Client-to-Server funktioniert einwandfrei. Client-to-Client habe ich nicht getestet.

iptables -t nat -L -n -v liefert

Code: 
Chain PREROUTING (policy ACCEPT 37906 packets, 2381K bytes)
 pkts bytes target     prot opt in     out     source               destination                       

Chain POSTROUTING (policy ACCEPT 38987 packets, 2439K bytes)
 pkts bytes target     prot opt in     out     source               destination                       
    0     0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0                        

Chain OUTPUT (policy ACCEPT 2105 packets, 137K bytes)
 pkts bytes target     prot opt in     out     source               destination

Passt das so? Was kann ich noch testen um zu sehen, wo das Problem liegt?
 
Mal mit tcpdump auf den einzelnen Interfaces des Server geguckt, was überhaupt mit dem Traffic passiert? Auf dem tun Interface solltest du ihn ja mindestens eingehend sehen.
Dann wäre interessant, ob er auf dem richtigen Interface (dem Public Interface des vServers) auch raus geht und in welcher Form, also ob er genattet oder "original" raus geht.

Wenn da kein Traffic ankommt, ist das Forwarding nicht aktiv.
Wenn da Traffic ankommt, aber die Privte IP des VPN Clients noch drin steht, funktioniert das NAT nicht.
Wenn da Traffic ankommt, die richtige Source IP drin steht, muss man sich die Antwort Pakete anschauen. Da gilt dann der ganze Kram gleichermaßen.

Wenn die Antwortpakete nicht beim VPN Client ankommen, könnte auch schlicht eine Rückroute fehlen oder kaputt sein.

Bist du dir sicher, dass dein vServer ein eth0 hat und kein venet0? In deiner NAT Regel steht eth0. Wenn dein vServer aber ein venet0 hat, wird diese NAT Regel nie greifen. ;)
 
Herzlichen Dank Firewire2002! Das war genau der Fehler. Habe jetzt venet0 eingefügt und siehe da, es funktioniert :)
 
You must log in or register to reply here.
Back
Top