Re: ein kleines routing Problem
On Sat, 28 Mar 2015 12:29:13 +0100, Rico Pietzsch
<rico.pietzsch@freenet.de> wrote:
>Am 27.03.2015 um 12:20 schrieb Marc Haber:
>> On Fri, 27 Mar 2015 10:55:22 +0100, Rico Pietzsch
>> <rico.pietzsch@freenet.de> wrote:
>>> ich habe den Aufbau inline und auch als Anhang beigefügt. Der
>>> Zeilenumbruch machts schwer lesbar.
>Hallo,
>ich sehs auch gerade das der 72 Zeichen Umbruch nicht zuschlug. :-)
>
>> inline ist das hier super lesbar angekommen. Jetzt müsstest Du mir nur
>> nochmal sagen, was genau nicht funktioniert; das ist durch die
>> Änderung der IP-Adressen leider verloren gegangen.
>>
>>> ##############client: ##################################
>>> eth0 inet Adresse:192.168.2.253 Bcast:192.168.2.255 Maske:255.255.255.0
>>> eth1 inet Adresse:10.101.2.253 Bcast:10.101.2.255 Maske:255.255.255.0
>>> tun0 inet Adresse:10.101.101.22 P-z-P:10.101.101.21 Maske:255.255.255.255
>>
>> Ein Client mit zwei Ethernets?
>>
>>> eth0: Netz vom speedport DSL router
>>> eth1: lokales "intranet" was erreichbar gemacht werden soll
>>> tun0 openvpn client mit vom vpnserver zugewiesener Adresse
>>
>> Der Client ist also selbst ein Router?
>Dieser Rechner (momentan ein Raspberrypi) ist ein _VPN Client_
>einerseits. Er kommt mittels eth0 ins Internet und an eth1 (usb-lan
>Adapter) hängt eine Wetterstation (IP:10.101.2.200), welche von dem
>anderen Rechner (Server/Router) aus erreichbar gemacht werden soll.
Ok. Die Wetterstation muss 10.101.2.253 als Defaultgateway eingetragen
haben. Auch die Netzmaske der Wetterstation ist wichtig. Bitte nochmal
prüfen.
>>> ###### ip ro li
>>> default via 192.168.2.254 dev eth0
>>> 10.0.0.0/8 via 10.101.101.21 dev tun0 metric 512
>>> 10.101.2.0/24 dev eth1 proto kernel scope link src 10.101.2.253
>>> 10.101.101.0/24 via 10.101.101.21 dev tun0 metric 512
>>> 10.101.101.21 dev tun0 proto kernel scope link src 10.101.101.22
>>> 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.253
>>
>> Die Route für das komplette 10/8 Netz finde ich persönlich jetzt etwas
>> groß, das sollte hier aber nicht stören, more specific gewinnt.
>>
>> ip route list match <adresse> ist bekannt?
>war mir nicht bekannt, sieht aber praktisch aus.
>Hatte bisher immer traceroute für die Päkchenweg Bestimmung genutzt.
traceroute (oder unter linux schöner mtr bzw mtr-tiny) zeigt Dir was
das Gesamtsystem macht und wo Du näher draufgucken musst. Sollte man
übrigens - wenn möglich - immer von beiden Seiten aus machen,
asymmetrisches Routing existiert und bietet einen ganzen Strauß von
Überraschungen.
ip route list match zeigt, _warum_ _ein_ System die Dinge so tut wie
sie sie tut. Besonders wenn man mit more specific routes arbeitet (was
im Falle der Routen für die locally connected networks gegen die
Defaultroute eigentlich immer der Fall ist) ist ip r l m unglaublich
hilfreich. Leider berücksichtigt es nicht das, was bei ip rule
hinterlegt ist und verliert deswegen in Setups mit Policy Based
Routing viel von seinem Nutzen.
>>> ############### server: #################################
>>> eth0 inet Adresse:10.101.1.1 Bcast:10.101.1.255 Maske:255.255.255.0
>>> eth2 inet Adresse:10.101.200.1 Bcast:10.101.200.255 Maske:255.255.255.0
>>> tun0 inet Adresse:10.101.101.1 P-z-P:10.101.101.2 Maske:255.255.255.255
>>> vmbr0 inet Adresse:10.101.102.1 Bcast:10.101.102.255 Maske:255.255.255.0
>>>
>>> eth0 Intranet wo der DSL Router die 10.101.1.254 hat
>>> eth2 lokales "gastnetz"
>>> tun0 "Vpn Server Netz" es gibt mehrere einzelrechner die hier von
>>> aussen dran sind
>>> vmbr0 "Bridge" für Virtuelles VM-Netz
>>
>> Sieht in erster Näherung auch richtig aus.
>>
>>> ##### ip ro li
>>> default via 10.101.1.254 dev eth0
>>> 10.100.0.0/16 via 10.100.100.253 dev vpn2boe
>>> 10.101.1.0/24 dev eth0 proto kernel scope link src 10.101.1.1
>>> 10.101.101.0/24 via 10.101.101.2 dev tun0
>>> 10.101.101.2 dev tun0 proto kernel scope link src 10.101.101.1
>>> 10.101.102.0/24 dev vmbr0 proto kernel scope link src 10.101.102.1
>>> 10.101.200.0/24 dev eth2 proto kernel scope link src 10.101.200.1
>>> 239.0.0.0/8 dev eth0 scope link
Hier fehlt die Route für 10.101.2.0/24 oder eine Route, die dieses
Netz einschließt. Dein Server weiß nicht, dass Pakete für die
Wetterstation in den Tunnel müssen.
>#######################################################################
>Ich dachte dem Server zu sagen das an dem VPN Client 10.101.101.22 ein
>Netz 10.101.2.0/24 hängt und der VPN Client ist dafür der Router, langt.
>#######################################################################
Du sagst dem Server aber nicht, dass der VPN-Client für 10.101.2.0/24
der Router ist.
>Forward ist an, IPTABLES zeigt das auch
>cat /proc/sys/net/ipv4/ip_forward
>1
das ist das wichtige.
>iptables -L -n
>Chain FORWARD (policy ACCEPT)
Das ist irrelevant, eine FORWARD-Chain existiert auch wenn Forwarding
aus ist. Die Chain kommt nur nie zum Zuge.
>> Und wer kann hier wen jetzt nicht pingen?
>Ich kann die Route auf dem Server nicht setzen ...
>ip ro add 10.101.2.0/24 via 10.101.101.22
>RTNETLINK answers: Network is unreachable
ip ro add 10.101.2.0/24 dev tun0?
ip ro add 10.101.2.0/24 via 10.101.101.22 dev tun0?
Wenn das nicht hilft, geht es nicht ohne OpenVPN, "route 10.101.2.0
255.25.255.0" in der Konfiguration des Servers. An manchen Stellen
sitzt OpenVPN quer zum normalen Routing. Ja, das ist unlogisch und
häßlich.
Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: