staging.inyokaproject.org

Hallo,

ich betreibe 2 nach dem bekannten Wikiartikel konfigurierte OpenVPN-Server. Einen unter Ubuntu. Klappt super. Einen unter Raspbian auf einem RaspberryPi. Letzterer funktioniert nicht, wie erwünscht, da weder das serverseitige LAN noch das Internet durch selbiges erreichbar ist.

Ich bin den Anweisungen im Wikiartikel gefolgt und habe das IP-Forwarding aktiviert. server.conf kann unten eingesehen werden. Die Vermutung ist, daß NAT vllt. nicht eingeschaltet ist, so daß die Antworten an 10.8.1.0 (also Fremdnetz) irrtümlich im DSL-Standard-Router (192.168.178.1) landen und nicht auf dem OpenVPN Server (192.168.178.101 bzw. 10.8.1.1)?

Gruß, CJC

Hier meine server.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

cat /etc/openvpn/server.conf
port 1194
proto udp
dev tun
ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh2048.pem
server 10.8.1.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 192.168.178.1"
push "route 192.168.178.0 255.255.255.0"

client-to-client
keepalive 20 120
comp-lzo
user nobody
group nogroup
persist-key
#persist-tun
status openvpn-status.log
verb 4
keepalive 10 120
mute 20

caiusjuliuscaesar schrieb:

... unter Raspbian auf einem RaspberryPi. Letzterer funktioniert nicht, wie erwünscht, da weder das serverseitige LAN noch das Internet durch selbiges erreichbar ist.

.... Die Vermutung ist, daß NAT vllt. nicht eingeschaltet ist, so daß die Antworten an 10.8.1.0 (also Fremdnetz) irrtümlich im DSL-Standard-Router (192.168.178.1) landen und nicht auf dem OpenVPN Server (192.168.178.101 bzw. 10.8.1.1)?

Wie ist auf deinem PI, die Ausgabe von:

sudo iptables -nvx -L POSTROUTING -t nat

? Hast Du in deinem Router (mit dem PI als OpenVPN-Server) eine statische Route konfiguriert (für das Subnetz 10.8.1.0 mit deinem PI als gateway)?

Starte mal auf deinem PI:

sudo tcpdump -vvven icmp

und mach danach auf einem VPN-Client einen ping auf die IPs 192.168.178.101 bzw. 10.8.1.1.

1. –-

1
2
3

sudo iptables -nvx -L POSTROUTING -t nat
Chain POSTROUTING (policy ACCEPT 158 packets, 14921 bytes)
    pkts      bytes target     prot opt in     out     source               destination

2. –-

Hast Du in deinem Router (mit dem PI als OpenVPN-Server) eine statische Route konfiguriert (für das Subnetz 10.8.1.0 mit deinem PI als gateway)?

Nein, lediglich eine Freigabe des 1194 Ports auf die Adresse 192.168.178.101. DAS WIRD ES WOHL SEIN!!!!

3. –- Vom Windows Client aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

>ping 10.8.1.1

Ping wird ausgeführt für 10.8.1.1 mit 32 Bytes Daten:
Antwort von 10.8.1.1: Bytes=32 Zeit=50ms TTL=64
...
Ping-Statistik für 10.8.1.1:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
>ping 192.168.178.101

Ping wird ausgeführt für 192.168.178.101 mit 32 Bytes Daten:
Antwort von 192.168.178.101: Bytes=32 Zeit=36ms TTL=64
...
Ping-Statistik für 192.168.178.101:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 36ms, Maximum = 39ms, Mittelwert = 37ms

Der tcpdump zeigt nichts:

1
2

root@heizungpi:/home/andreasalef# sudo tcpdump -vvven icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

caiusjuliuscaesar schrieb:

Der tcpdump zeigt nichts:

root@heizungpi:/home/andreasalef# sudo tcpdump -vvven icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

Wie ist auf dem PI, die Ausgabe von:

ip a

? Zu welchem Zeitpunkt hast Du tcpdump gestartet?

Es ist ja erkenntlich, dass aktuell kein NAT stattfindet. Von daher solltest du auf dem Server konfigurieren, dass alle Verbindungen in den Tunnel genattet werden:

1

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE   # tun0 ist geraten, muss durch das Tunnel-Interface ersetzt werden

Außerdem müssen natürlich auch Verbindungen, die aus dem Tunnel kommen und ins LAN gehen, entsprechend maskiert werden, sofern der VPN-Server nicht gleichzeitig das Gateway für das LAN ist. Da es prinzipiell egal ist, wo die Pakete herkommen, kann man die Regel auch sehr generisch gestalten, genau wie oben:

1

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE   # eth0 ist wieder geraten, ggf. durch das LAN-Interface ersetzen