honkstar
19.09.07, 09:09
Hallo zusammen,
ich habe da ein kleines Problem, an dem ich mitterweile etwas verzweifle.
Ich habe mir bei Strato einen vserver bestellt und mit Debian 3.1 neu installieren lassen.
Ich habe nun vor, diesen Server als VPN-Gateway im Internet laufen zu lassen, damit ich in (potenziell) unsicheren Netzen (HotSpots) trotzdem noch eine sichere Kommunikation (Mail, etc) erreichen kann.
Als VPVN-Software kommt OpenVPN in der Version 2.0.9 zum Einsatz.
Hier die Konfig des Servers:
port 1194
proto udp
dev tun
ca ca.crt
cert Vserver.crt
key Vserver.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 192.168.10.0 255.255.255.0
push "redirect-gateway def1"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 5
management localhost 7505
crl-verify ./keys/crl.pem
Wie man sieht, habe ich die "redirect-gateway" Sache aktiviert.
Wenn ich diese option weglasse, funktioniert mein VPN wunderbar, d.h. ich kann mich auf mein VPN-Server verbinden, kann auch in jede Richtung pingen, und sogar auf einen Webserver zugreifen, der auf der tun-IP lauscht.
Wenn ich die redirect-Sache aber einbaue, soll ja der gesamte Traffic über das GW laufen, das scheint auch zu funktionieren, zumindest wird der gesamte Traffic zum GW geschickt.
Mein VPN-Server kann aber dann anscheinend nichts mit den Sachen anfangen, denn ein Ping von meinem Client ins Internet verpufft wirkungslos.
Der Server hingegen kann pingen.
Ich habe das Forwarding aktiviert (per echo "1" > /proc/sys/net/ipv4/ip_forward) und dann versucht, den Rest per Iptables zu erledigen.
Meine aktuelle iptables-Geschichte sieht so aus:
INT="venet0"
ECHO="/bin/echo"
IPT="/sbin/iptables"
TUN="tun+"
# Alles verwerfen
$IPT -P INPUT ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT
# Alles loeschen
$IPT -F
# Die NAT-Tabelle extra loeschen
$IPT -t nat -F
# Loopback erlauben
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
# der gesamte Traffic muss wietergeleitet werden
$IPT -t nat -A POSTROUTING -s 10.8.0.0/24 -o $INT -d EXTIP -j SNAT --to-source EXTIP
$IPT -A FORWARD -i $TUN -j ACCEPT
# Alles der bereits aufgebauten Verbindungen erlauben
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Forwarding aktivieren
echo "1" > /proc/sys/net/ipv4/ip_forward
Wie man sieht, ist das ganze recht offen (Default Policy: Accept, aber mittlerweile gehen mir die Ideen aus)
Ich denke es scheitert irgendwo an der Geschichte mit dem SNAT.
ich habe SNAT so verstanden, dass ich damit (im unterschied zum MASQUERADE) auf eine statische IP "leite", und nicht auf eine dynamische.
Ganz davon abgesehen, dass das Target MADSQUERADE gar nicht unter der Kernelversion des vservers funktioniert, da kriege ich immer ein
No chain/target/match by that name
meine Netzwerkgeschichte sieht so aus:
lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1230259146 errors:0 dropped:0 overruns:0 frame:0
TX packets:1631407832 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:1140886041 (1.0 GiB) TX bytes:1095793658 (1.0 GiB)
tun0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:10.8.0.1 P-z-P:10.8.0.2 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:250 errors:0 dropped:0 overruns:0 frame:0
TX packets:158 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:10
RX bytes:19318 (18.8 KiB) TX bytes:29726 (29.0 KiB)
venet0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:127.0.0.1 P-z-P:127.0.0.1 Bcast:0.0.0.0 Maske:255.255.255.255
UP BROADCAST PUNKTZUPUNKT RUNNING NOARP MTU:1500 Metric:1
RX packets:297847 errors:0 dropped:0 overruns:0 frame:0
TX packets:215126 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:32508575 (31.0 MiB) TX bytes:32319654 (30.8 MiB)
venet0:0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:85.214.100.xx P-z-P:85.214.100.xx Bcast:0.0.0.0 Maske:255.255.255.255
UP BROADCAST PUNKTZUPUNKT RUNNING NOARP MTU:1500 Metric:1
Vllt. gibt es auch ein Problem mit dem Interface venet0 und dem Alias venet0:0. Da bin ich mit nicht ganz sicher, wie man das gescheit in die iptables reinbringt.
Mittlerweile drehe ich hier echt am Rad, SuFu und googeln brachte nie das genau Richtige...
Danke für etwas Licht im Dunkel
honkstar
ich habe da ein kleines Problem, an dem ich mitterweile etwas verzweifle.
Ich habe mir bei Strato einen vserver bestellt und mit Debian 3.1 neu installieren lassen.
Ich habe nun vor, diesen Server als VPN-Gateway im Internet laufen zu lassen, damit ich in (potenziell) unsicheren Netzen (HotSpots) trotzdem noch eine sichere Kommunikation (Mail, etc) erreichen kann.
Als VPVN-Software kommt OpenVPN in der Version 2.0.9 zum Einsatz.
Hier die Konfig des Servers:
port 1194
proto udp
dev tun
ca ca.crt
cert Vserver.crt
key Vserver.key # This file should be kept secret
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 192.168.10.0 255.255.255.0
push "redirect-gateway def1"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 5
management localhost 7505
crl-verify ./keys/crl.pem
Wie man sieht, habe ich die "redirect-gateway" Sache aktiviert.
Wenn ich diese option weglasse, funktioniert mein VPN wunderbar, d.h. ich kann mich auf mein VPN-Server verbinden, kann auch in jede Richtung pingen, und sogar auf einen Webserver zugreifen, der auf der tun-IP lauscht.
Wenn ich die redirect-Sache aber einbaue, soll ja der gesamte Traffic über das GW laufen, das scheint auch zu funktionieren, zumindest wird der gesamte Traffic zum GW geschickt.
Mein VPN-Server kann aber dann anscheinend nichts mit den Sachen anfangen, denn ein Ping von meinem Client ins Internet verpufft wirkungslos.
Der Server hingegen kann pingen.
Ich habe das Forwarding aktiviert (per echo "1" > /proc/sys/net/ipv4/ip_forward) und dann versucht, den Rest per Iptables zu erledigen.
Meine aktuelle iptables-Geschichte sieht so aus:
INT="venet0"
ECHO="/bin/echo"
IPT="/sbin/iptables"
TUN="tun+"
# Alles verwerfen
$IPT -P INPUT ACCEPT
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD ACCEPT
# Alles loeschen
$IPT -F
# Die NAT-Tabelle extra loeschen
$IPT -t nat -F
# Loopback erlauben
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
# der gesamte Traffic muss wietergeleitet werden
$IPT -t nat -A POSTROUTING -s 10.8.0.0/24 -o $INT -d EXTIP -j SNAT --to-source EXTIP
$IPT -A FORWARD -i $TUN -j ACCEPT
# Alles der bereits aufgebauten Verbindungen erlauben
$IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Forwarding aktivieren
echo "1" > /proc/sys/net/ipv4/ip_forward
Wie man sieht, ist das ganze recht offen (Default Policy: Accept, aber mittlerweile gehen mir die Ideen aus)
Ich denke es scheitert irgendwo an der Geschichte mit dem SNAT.
ich habe SNAT so verstanden, dass ich damit (im unterschied zum MASQUERADE) auf eine statische IP "leite", und nicht auf eine dynamische.
Ganz davon abgesehen, dass das Target MADSQUERADE gar nicht unter der Kernelversion des vservers funktioniert, da kriege ich immer ein
No chain/target/match by that name
meine Netzwerkgeschichte sieht so aus:
lo Protokoll:Lokale Schleife
inet Adresse:127.0.0.1 Maske:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1230259146 errors:0 dropped:0 overruns:0 frame:0
TX packets:1631407832 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:1140886041 (1.0 GiB) TX bytes:1095793658 (1.0 GiB)
tun0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:10.8.0.1 P-z-P:10.8.0.2 Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:250 errors:0 dropped:0 overruns:0 frame:0
TX packets:158 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:10
RX bytes:19318 (18.8 KiB) TX bytes:29726 (29.0 KiB)
venet0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:127.0.0.1 P-z-P:127.0.0.1 Bcast:0.0.0.0 Maske:255.255.255.255
UP BROADCAST PUNKTZUPUNKT RUNNING NOARP MTU:1500 Metric:1
RX packets:297847 errors:0 dropped:0 overruns:0 frame:0
TX packets:215126 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:32508575 (31.0 MiB) TX bytes:32319654 (30.8 MiB)
venet0:0 Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet Adresse:85.214.100.xx P-z-P:85.214.100.xx Bcast:0.0.0.0 Maske:255.255.255.255
UP BROADCAST PUNKTZUPUNKT RUNNING NOARP MTU:1500 Metric:1
Vllt. gibt es auch ein Problem mit dem Interface venet0 und dem Alias venet0:0. Da bin ich mit nicht ganz sicher, wie man das gescheit in die iptables reinbringt.
Mittlerweile drehe ich hier echt am Rad, SuFu und googeln brachte nie das genau Richtige...
Danke für etwas Licht im Dunkel
honkstar