Re: OpenVPN: Ping nicht in alle Richtungen möglich
On Sat, Nov 15, 2008 at 11:19:02AM +0100, Simon Bienlein wrote:
>> Wofür brauchst Du Pings? -Probier doch einfach mal eine beliebige
>> TCP-Verbindung aus.
> im lokalen Netzwerk teste ich die Erreichbarkeit eines anderen Rechners
> auch immer zunächst mit einem Ping. Für mich gehört der Ping bisher
> quasi zum Standardtest. Erst wenn der geht kann man andere dienste (z.
> B. Dateifreigaben) versuchen. Die gehen aktuell in keine Richtung.
Die Vorgehensweise mit dem Ping ist voellig in Ordnung. Wenn es trotzdem
nicht klappt, koennte die weitere Vorgehensweise folgende sein (jeweils von
A und B aus machen):
- ping auf die IP vom Tunnelinterface, bei mir z.B. die 172.16.10.1, da:
9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
inet 172.16.10.1 peer 172.16.10.2/32 scope global tun0
PING 172.16.10.1 (172.16.10.1) 56(84) bytes of data.
64 bytes from 172.16.10.1: icmp_seq=1 ttl=64 time=0.174 ms
- mittels tcpdump schauen, ob die pings auf der Gegenseite jeweils ankommen.
- tun sie es nicht, mittels traceroute oder mtr schauen, wo die Pakete
stattdessen hingeroutet werden.
- Routing ueberpruefen und gegenbenenfalls die Routen anpassen. Mittels
tcpdump sieht man auch sehr schoen, dass die Pings nicht die IPs aus dem
Ursprungsnetz haben, sondern die von den Tunnelendpunkten:
PING vserv.localnet (172.16.12.1) 56(84) bytes of data.
64 bytes from 172.16.12.1: icmp_seq=1 ttl=64 time=25.4 ms
fuehrt zu:
12:07:12.964274 In ethertype IPv4 (0x0800), length 100: 172.16.10.1 >
172.16.12.1: ICMP echo request, id 23142, seq 5, length 64
12:07:12.964308 Out ethertype IPv4 (0x0800), length 100: 172.16.12.1 >
172.16.10.1: ICMP echo reply, id 23142, seq 5, length 64
Der Ping wurde jedoch auf 192.168.0.1 gestartet, fuer den Tunnelendpunkt auf
dem Server kommen die Pings aber von 172.16.10.1. Warum das so ist, zeigt
ein ip route show auf dem Client:
172.16.10.2 dev tun0 proto kernel scope link src 172.16.10.1
Moechte man aber vom Server aus nun das Netz hinter dem Tunnelendpunkt vom
Client pingen, also 192.168.0.0/24, muss natuerlich auch eine Route auf dem
Server auf das Tunnelinterface bzw. das entsprechende Gateway zeigen:
192.168.0.0 172.16.12.2 255.255.255.0 UG 0 0 0 tun3
Oder kurzum:
Ein bisschen mehr Infos im urspruenglichen Posting waeren schon hilfreich
gewesen. Die Configs sind zwar nett, aber zusaetzlich waeren die Routen noch
sinnvoll gewesen.
Da dein Client ein Windows ist, musst Du dir halt entsprechende Pendants zu
den hier verwendeten Linux Tools suchen.
--
Ciao... // Fon: 0381-2744150
Ingo \X/ http://blog.windfluechter.net
gpg pubkey: http://www.juergensmann.de/ij_public_key.asc
Reply to: