Hallo, 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. > >> ###### 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. > >> ############### 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 > > Woher kommt die Route für 10.100.0.0/16 und das Device vpn2boe? Das > taucht in der Interfaceliste nicht auf. > Am Server hängen noch 3 weitere Lans via VPN(p2p), allerdings sind da komplette Netze zusammen gehangen die selber auch noch routen können, was ich hier eigentlich nicht erst machen wollte (vpn2boe, mit 10.100.* ist ein solches ... die hier aber nicht reinspielen. Daher ist die /8'er Router auf dem vpn-client nicht so verkehrt. ####################################################################### 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. ####################################################################### Forward ist an, IPTABLES zeigt das auch cat /proc/sys/net/ipv4/ip_forward 1 iptables -L -n Chain FORWARD (policy ACCEPT) > 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 also dachte ich - eine Hostroute hilft: --> route add -host 10.101.101.22 gw 10.101.101.1 geht, bringt nur nix, also --> route add -host 10.101.2.253 gw 10.101.101.22 kann ich setzten --> route -n |grep tun Ziel Router Genmask Flags Metric Ref Use iface 10.101.2.253 10.101.101.22 255.255.255.255 UGH 0 0 0 tun0 10.101.101.0 10.101.101.2 255.255.255.0 UG 0 0 0 tun0 10.101.101.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.101.101.22 10.101.101.1 255.255.255.255 UGH 0 0 0 tun0 da sind die 2 UGH Routen. --> ip ro li match 10.101.2.253 default via 10.101.1.254 dev eth0 10.101.2.253 via 10.101.101.22 dev tun0 Ping geht nicht auf 10.101.2.253. --> ip ro ad 10.101.2.0/24 via 10.101.2.23 RTNETLINK answers: Network is unreachable mich irritiert, das openvpn beim client die 10.101.101.21 als Ziel des pointtopoint Tunnels verwendet. Beim vpn-Server ja auch die 10.101.101.2 Ping / ssh geht jeweils nur auf die unter interfacs gefundenen 10.101.101.1 oder beim Client .101.22 > > Grüße > Marc > ich weiß da gerade nicht mehr weiter: bin fast soweit das ganze auf peer-to-peer openvpn umzustellen. Das funktioniert wenigstens. Gruß, Rico
Attachment:
signature.asc
Description: OpenPGP digital signature