[quote=„Freifunker, post:21, topic:6672“]
Sprich Anfragen an die Adressenbereiche die im IC-VPN vorhanden sind rüber zum Gateway weiter schieben.[/quote]
Sofern 10.134.10.1 die anderen GWs direkt erreichen kann (was bei br-ffue gegeben sein sollte), sollte das tun.
[quote=„Freifunker, post:21, topic:6672“]
Wenn jetzt aber ein Paket aus dem IC-VPN zu einem meiner Gateways direkt will, kommt es da an, aber wird über das Default GW beantwortet. Ist ja auch logisch, weil die default Routing Tabelle ja gar keine Routen zu zu den Netzen im IC-VPN kennt.[/quote]
Naja, das verstehe ich nicht wirklich, was da passiert. Mangels Verweis auf Tabelle 42 (per ip rule iif oder iptables-Markierung) greift nur die Tabelle main. Demnach liegt 10.134.10.1 auf br-ffue und 10.134.0.0/16 dahinter. Das klappt über’s ICVPN auch, wenn ich mit ICVPN-Adresse ankomme:
root@gw05:~# traceroute -s 10.207.0.138 -m 5 10.134.10.1
traceroute to 10.134.10.1 (10.134.10.1), 5 hops max, 60 byte packets
1 10.134.10.1 (10.134.10.1) 19.787 ms 20.200 ms 20.239 ms
Es klappt aber verwirrenderweise nicht, wenn ich mit einer FF-10er komme:
root@gw05:~# traceroute -s 10.169.1.1 -m 5 10.134.10.1
traceroute to 10.134.10.1 (10.134.10.1), 5 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
Ratter. Ratter. Oh. Nee, klar: 10.207.0.0/16 dev icvpn proto kernel scope link src 10.207.0.18
, deshalb tut’s da. Sprich: das ICMP REPLY an 10.169.1.1 oder 10.255.255.1 wird via eth0 rausgeschickt, klar. Dennoch verstehe ich nicht, warum es raus… ah, klar: Du kommst via br-ffue, das wird markiert, auf Tabelle 42 geschoben und damit geht’s raus. Die Antwortpakete gehen an 10.134.irgendwas und via Tabelle main nach br-ffue.
[quote=„Freifunker, post:21, topic:6672“]
Die Routen welche mir Bird in die Table 42 schreibt müssten also auch nochmal in der normalen Routing Tabelle eingetragen werden. Kann ich Bird dazu veranlassen?[/quote]
Naja, strictly speaking müßte das nicht sein (indem Du dafür sorgst, daß per ip rule alles, was nicht eth0 ist, über Tabelle 42 läuft) aber:
# don't use kernel's routes for bird, but export bird's
# routes to kernel table 42.
#
# We do not import any routes here, therefore we can be sure
# that no funny routes jump into our waggon.
protocol kernel {
scan time 20; # Scan kernel routing table every 20 seconds
kernel table 42; # routing table for mesh networks
import none; # Import no routes
export all; # Export all routes
};
# export to kernel main table for local services
protocol kernel {
table kernel_main;
scan time 20;
import none;
export all;
persist;
};
Frage ist nur, ob Du das so in Deine bird.conf übernehmen kannst. Sprich: welche internen Tabellen nutzt die …
[quote=„Freifunker, post:21, topic:6672“]
Done…Aber scheinst kein Ping mehr laufen zu haben.[/quote]
Ack, war aus, sorry.
root@bgp1:~# birdc show route 10.134.0.0/16 primary | grep ^10
10.134.0.0/16 via 10.207.0.18 on icvpn [uegw1 15:13:18] * (100) [AS64525i]
root@bgp1:~# tcpdump -n -i icvpn host 10.255.255.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on icvpn, link-type EN10MB (Ethernet), capture size 65535 bytes
18:57:01.001208 IP 10.255.255.1 > 10.134.10.1: ICMP echo request, id 22521, seq 843, length 18
18:57:02.009317 IP 10.255.255.1 > 10.134.10.1: ICMP echo request, id 22521, seq 844, length 18
[…]
sigh Kein Pong. Wo geht die Antwort denn lt. tcpdump jetzt hin?