PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenVPN anderes Netzwerk antwortet nicht



Biepon
02.05.05, 10:02
Hallo,
habe eine kleines Problem mit OpenVPN 2.0.
Der Client stellt, unter Windows XP, erfolgreich eine Verbindung mit dem Server her. Ich bekomme automatisch die IP 10.12.34.6 zugewiesen und erreiche den Server unter 10.12.34.1.

Nur möchte ich auch gerne das dahinterliegende 192.168.1.* Netzwerk erreichen können. Mit hilfe des Befehls "tcpdump -n -i tun0" sehe ich das der Client versucht zu Pingen aber keine Antwort bekommt.

Hier meine Konfigurationsdateien:

client:


client
dev tun
remote <SERVERIP> 1194

ca my-ca.pem
cert client1-cert.pem
key client1-key.pem

cipher AES-256-CBC
auth SHA1
comp-lzo

verb 3




server:


port 1194
proto udp
dev tun

ca /etc/openvpn/my-ca.pem
cert /etc/openvpn/servercert.pem
key /etc/openvpn/serverkey.pem
dh /etc/openvpn/dh2048.pem
server 10.12.34.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 192.168.1.0 255.255.255.0"

keepalive 10 120
auth SHA1
cipher AES-256-CBC
comp-lzo
verb 3


Gruß Biepon

Biepon
02.05.05, 17:50
Vielleicht hilft das?

# route -n // Vor dem Starten des OpenVPN's:


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo


# route -n // Nach dem Starten des OpenVPN's:


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.12.34.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.12.34.0 10.12.34.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

Fly
03.05.05, 07:30
Hallo,

ich habe auch genau die gleiche Konfiguration und bei mir klappt es taddellos. Die Routingtabelle scheint in Ordnung zu sein.

Vermutlich hast du im /proc/sys/net/ipv4/ip_forward ein "0" (deaktiviert) drinnen? ;)

Biepon
03.05.05, 09:47
Hallo Fly,

habe das IP Forwarding dort schon auf "1". :(
Irgendwo muss doch der haken sein.

Gruß Biepon

Fly
03.05.05, 11:47
Hast du die mtu auf 1300 gesetzt? Kannst du die Ausgabe von tcpdump -n -i tun0 posten? WIe sieht dein FW aus?

Biepon
03.05.05, 12:23
Hast du die mtu auf 1300 gesetzt?

Ja gerade eben.


Kannst du die Ausgabe von tcpdump -n -i tun0 posten?



IP 10.12.34.6 > 10.12.34.1: icmp 40: echo request seq 6912
IP 10.12.34.1 > 10.12.34.6: icmp 40: echo reply seq 6912
IP 10.12.34.6 > 192.168.1.99: icmp 40: echo request seq 7936
.
.
.



WIe sieht dein FW aus?

Habe ersteinmal nur die IPTABLES angepasst.



iptables -I INPUT -p udp --dport 1194 -j ACCEPT
iptables -I OUTPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

Fly
03.05.05, 12:53
Im Moment ist mir bei dir nur die Ausgabe der Tcpdump aufgefallen. Jedoch verstehe ich nicht warum es bei dir so ausergewöhnlich ist...

Bei mir hinter einem 172.16er Netz wenn ich den Server 172.16.1.10 anpinge bekomme ich folgendes:


12:56:30.449190 IP 10.8.0.6 > 172.16.1.10: icmp 40: echo request seq 7168
12:56:30.449527 IP 172.16.1.10 > 10.8.0.6: icmp 40: echo reply seq 7168
12:56:31.449824 IP 10.8.0.6 > 172.16.1.10: icmp 40: echo request seq 7424
12:56:31.450035 IP 172.16.1.10 > 10.8.0.6: icmp 40: echo reply seq 7424
12:56:32.449287 IP 10.8.0.6 > 172.16.1.10: icmp 40: echo request seq 7680
12:56:32.449501 IP 172.16.1.10 > 10.8.0.6: icmp 40: echo reply seq 7680
12:56:33.450835 IP 10.8.0.6 > 172.16.1.10: icmp 40: echo request seq 7936
12:56:33.451033 IP 172.16.1.10 > 10.8.0.6: icmp 40: echo reply seq 7936

Kannst du mir bitte die Ausgabe von iptables -vnxL posten?

Mir ist erst jetzt aufgefallen, dass dein Server kein default gateway hat

Biepon
03.05.05, 13:45
Den default-gateway lege ich wie fest? Mit "redirect-gateway"?

EDIT:

Hier der auszug von den iptables:



Chain INPUT (policy ACCEPT 497 packets, 64288 bytes)
pkts bytes target prot opt in out source destination
234 22354 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
11 660 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2 120 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 42 packets, 4262 bytes)
pkts bytes target prot opt in out source destination
316 30337 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state ESTABLISHED

Fly
03.05.05, 14:00
Dein Firewall ist nicht aktiv, da die Policies auf ACCEPT sind, aber das hat eher nichts mit vpn Problem zu tun.

Ich weiss nicht welches distribution du benutzt, wie man den Standardgateway einträgt.

Versuch mit route add default gw 192.168.1.1

Ich hoffe diesmal klappt es. Bezüglich iptables kannst du unter www.netfilter.org nachsehen...

Biepon
03.05.05, 14:22
Habe SuSE 9.3 als Destri.

Habe den Default-Gateway eingetragen, wie auch beim aufrufen von "route -n" zu sehen:



default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0


Nur klappt es leider immer noch nicht. Der Client (Windows XP) hat beim Verbinden kein Gateway eingetragen, nur IP und Subnet. Weiß nicht ob es damit zusammen hängen könnte.

Fly
03.05.05, 14:58
Nur klappt es leider immer noch nicht. Der Client (Windows XP) hat beim Verbinden kein Gateway eingetragen, nur IP und Subnet. Weiß nicht ob es damit zusammen hängen könnte.
Meinst du die virtuelle Ethernetadapter hat kein Gateway? Wenn ja, dann ist ok.

Nach jeder Änderung, die VPN-Verbindung trennen und neu aufbauen?

Versuch bei deiner Firewall folgendes, falls es sich um ein Testsystem handelt:


iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp --sport 1194 -j ACCEPT

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

Vorsicht, dass du dich nicht aus dem Server aussperrst! Ich gehe davon aus, dass du mit ssh an deinem System anmeldest... Vorher die FW-Regeln mit iltables -F löschen, aber natürlich vorher die Policies auf ACCEPT setzen... ;)

Biepon
03.05.05, 15:11
Jap das ist Richtig :).

Habe die iptables eingetragen und konnte eine Verbindung vom Client aus herstellen.

Nur kommt der Client nicht durch, auch wenn ich nun versuche den Server (unter der VPN IP 10.12.34.1) zu erreichen bekomme ich nur ein Timeout.

:-/

Fly
03.05.05, 15:35
Nein, die virtuelle IP vom Server kann man nicht pingen. Ich dachte du kannst das Netz hinter dem VPN Server nicht pingen? Du solltest den Router oder ein anderen Rechner hinter dem Netz pingen können oder was war dein Problem :confused:

Biepon
03.05.05, 15:37
Ja, ich möchte die Rechner hinter dem VPN-Server pingen können.
Nur war es immer so das ich auch den Server unter der VPN IP pingen konnte.

Fly
03.05.05, 15:43
Ja, ich möchte die Rechner hinter dem VPN-Server pingen können.
Nur war es immer so das ich auch den Server unter der VPN IP pingen konnte.
Das kannst du jetzt aufgrund der neuen iptables Regeln nicht mehr. Das ist auch nicht notwendig...
Mir fällt im Moment leider nichts mehr ein...
Vielleicht postest du noch mal alles (ifconfig der VPN Server, iptables -vnxL und route -n). Bitte vorher den Openvpn neu starten. Falls die Ausgabe der tcpdump -n -i tun0 was anderes ausgibt wie zuvor, dann auch bitte Posten...

Biepon
03.05.05, 16:14
ifconfig:



eth0 Link encap:Ethernet HWaddr 00:30:84:9E:F9:4A
inet addr:192.168.1.211 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:84ff:fe9e:f94a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:210 errors:0 dropped:0 overruns:0 frame:0
TX packets:105 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:26892 (26.2 Kb) TX bytes:14339 (14.0 Kb)
Interrupt:11 Base address:0xe000

eth1 Link encap:Ethernet HWaddr 00:D0:09:FA:3F:50
inet addr:169.254.58.142 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::2d0:9ff:fefa:3f50/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:164 errors:0 dropped:0 overruns:0 frame:0
TX packets:150 errors:0 dropped:0 overruns:0 carrier:0
collisions:4 txqueuelen:1000
RX bytes:17508 (17.0 Kb) TX bytes:15476 (15.1 Kb)
Interrupt:5

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:872 (872.0 b) TX bytes:872 (872.0 b)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.12.34.1 P-t-P:10.12.34.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:15 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:792 (792.0 b) TX bytes:0 (0.0 b)


iptables -vnxL:



Chain INPUT (policy DROP 62 packets, 6587 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
100 9836 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194

Chain FORWARD (policy DROP 12 packets, 612 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy DROP 18 packets, 1668 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22
89 8747 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:1194


route -n:



Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.12.34.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
10.12.34.0 10.12.34.2 255.255.255.0 UG 0 0 0 tun0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0


Mh ... Die Firewall dropt viele packete. tcpdump -n -i tun0 zeigt nur noch requests aber es kommt kein reply von irgendeiner IP.

Fly
03.05.05, 16:45
Wie ich es sehe versuchst du im internen Netz eine VPN Verbindung herzustellen. Das kann nicht funktionieren... Ich gehe davon aus, dass der Server im gleichen Netz ist wie der Client...

Ich schlage dir vor, wenn du weiter testen willst:

Bei eth1 die Adresse 172.16.1.1 nehmen und ein Testrechner hinter dem eth1 anhängen mit IP Adresse 172.16.1.10. Dann kannst du eine VPN Verbindung im 192er Netz herstellen und den 172.16.1.10 Rechner anpingen. Viel Spaß! :)

Biepon
03.05.05, 16:56
Danke.

Nur ist der Test-Client (169.254.58.141) mit einem HUB an eth1 (169.254.58.142) verbunden und baue auch von dort die Verbindung auf.
Das 192er Netz liegt auf eth0.

*verwirr* :D