Kann es sein das im Tng das Routing nicht mehr will, oder das macht was es will?
Sollte nicht, kann aber sein. Kann ich zumindest erst heute Abend gucken …
Die .2 müßte l2tp-ham01 sein lt. test-ansible-ffms/l2tp-ham01 at master · wusel42/test-ansible-ffms · GitHub
Sonst gucke ich heute Abend, bis dahin Grüße vom Schwarzen Meer 
Cool. Fliege Dienstag morgen zurück 
Hmm, das sollte eigentlich tun?
root@l2tp-ham01 ~ # traceroute -s 10.234.128.2 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 bgp-ham02.4830.org (193.26.120.85) 0.275 ms 0.212 ms 0.186 ms
2 de-cix.fra.google.com (80.81.193.108) 12.131 ms 12.105 ms 12.089 ms
3 108.170.251.129 (108.170.251.129) 11.997 ms 11.860 ms 108.170.252.1 (108.170.252.1) 42.170 ms
4 72.14.232.33 (72.14.232.33) 22.789 ms 216.239.54.61 (216.239.54.61) 14.595 ms 216.239.40.235 (216.239.40.235) 14.584 ms
5 dns.google (8.8.8.8) 11.709 ms 11.658 ms 22.622 ms
root@l2tp-ham01 ~ # traceroute -s 10.234.128.2 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 bgp-ham02.4830.org (193.26.120.85) 0.256 ms 0.209 ms 0.183 ms
2 te0-0-1-2-10-br1.frankfurt1.iphh.net (80.81.192.27) 8.864 ms 8.855 ms 8.840 ms
3 ae1-52-br2.hamburg2.iphh.net (213.128.159.217) 8.804 ms 8.737 ms 8.776 ms
4 cloudflare.ham.ecix.net (193.42.155.58) 24.933 ms 24.731 ms 24.667 ms
5 one.one.one.one (1.1.1.1) 19.713 ms 19.693 ms 19.656 ms
Ah, fehlende Rules:
root@l2tp-ham01 ~ # ip route show table 42 0.0.0.0/0
default via 192.168.1.9 dev bck-l2tp-ber01 proto bird
root@l2tp-ham01 ~ # ip route show table main 0.0.0.0/0
default via 193.26.120.113 dev ens3 onlink
root@l2tp-ham01 ~ # ip -4 rule show
0: from all lookup local
15991: from all iif bck-l2tp-gut02 lookup ffnet
15992: from all iif bck-l2tp-gut01 lookup ffnet
15993: from all iif bck-l2tp-ber01 lookup ffnet
15994: from all iif bck-l2tp-ams01 lookup ffnet
15995: from all iif bck-l2tp-fra01 lookup ffnet
15996: from all iif bck-l2tp-ham02 lookup ffnet
15997: from all iif bck-fastd-fra01 lookup ffnet
15998: from all iif bck-fastd-ham02 lookup ffnet
15999: from all iif bck-fastd-gut01 lookup ffnet
16000: from all fwmark 0x1 lookup ffnet
16000: from all iif bat01 lookup ffnet
16000: from all iif bat02 lookup ffnet
16000: from all iif bat03 lookup ffnet
16000: from all iif bat04 lookup ffnet
16500: from all iif lo lookup ffnet suppress_prefixlength 0
32764: from all iif lo lookup ffnet suppress_prefixlength 0
32765: from 192.251.226.214 lookup ffnet
32766: from all lookup main
32767: from all lookup default
Sprich: wenn ich das lokal (aus dem GW) von 10.234.128.2 aus mache, greift trotzdem die Hauptroutingtabelle. Wenn Du das probierst, kommst Du von einem der gelisteten Interfaces und wirst gemäß Freifrunk-Routingtabelle geroutet. Und da ist 192.168.1.9 natürlich Lötzinn:
Verein 4830.org
OS : Ubuntu 18.04 LTS bionic
Hostname : l2tp-ber01
IP address : 193.26.120.99 / 2a06:e881:1706:1:400:c1ff:fe1a:7863
System type : Linux x86_64
Kernel : 4.15.0-74-generic
Besitzer : Verein 4830.org
Domäne-96 : 6.1.0.4 / 2001:bf7:1310:abcd::4
Lies: l2tp-ber01 spielt bei Mesh (»Domäne«) 1 gar nicht mit, hat insofern auch kein NAT für das Netz. Entweder Fehlkonfiguration von mir oder ungültige Annahme im Münsteraner Ansible? Folgerichtig klappt jedenfalls der Rückweg nicht, da nicht geNATet wird:
root@l2tp-ham01 ~ # ip route add 1.1.1.1 via 192.168.1.9
root@l2tp-ham01 ~ # traceroute -s 10.234.128.2 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 192.168.1.9 (192.168.1.9) 6.090 ms 5.765 ms 5.739 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 *^C
root@l2tp-ham01 ~ # ip route del 1.1.1.1 via 192.168.1.9
root@l2tp-ber01 ~ # iptables -L -n -v -t nat
Chain POSTROUTING (policy ACCEPT 705K packets, 44M bytes)
pkts bytes target prot opt in out source destination
705K 44M L2TP_POSTROUTING_domaene_96 all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 SNAT all -- * ens3 6.1.0.0/16 0.0.0.0/0 to:192.251.226.216
0 0 SNAT tcp -- * gre+ 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 to:10.0.0.4
0 0 SNAT udp -- * gre+ 0.0.0.0/0 0.0.0.0/0 udp dpt:53 to:10.0.0.4
Teil des Problems sind auch fehlende Inter-GW-Verbindungen:
root@l2tp-ham01 ~ # birdc show protocol | grep ibgp
ibgp_fastd_gut01 BGP ffnet up 2020-01-15 Established
ibgp_fastd_ham02 BGP ffnet up 2020-01-15 Established
ibgp_fastd_fra01 BGP ffnet start 2020-01-15 Connect
ibgp_l2tp_ham02 BGP ffnet up 2020-01-19 Established
ibgp_l2tp_fra01 BGP ffnet up 2020-01-20 Established
ibgp_l2tp_ams01 BGP ffnet start 2020-01-15 Connect Socket: No route to host
ibgp_l2tp_ber01 BGP ffnet up 2020-01-15 Established
ibgp_l2tp_gut01 BGP ffnet start 2020-02-01 Connect Socket: No route to host
ibgp_l2tp_gut02 BGP ffnet start 2020-01-15 Active Socket: Connection refused
root@l2tp-ham01 ~ #
Wenn die IBGP-Session nicht läuft, lauft i. d. R. auch der OSPF-Link nicht, daher Defaultroute nur aus Berlin und vom lokalen Router:
root@l2tp-ham01 ~ # birdc show route for 0.0.0.0/0 table ffnet
BIRD 1.6.3 ready.
0.0.0.0/0 via 192.168.1.9 on bck-l2tp-ber01 [backbone 2020-02-01] * E2 (150/10/10000) [0.0.0.4]
via 193.26.120.113 on ens3 [upstream 2020-01-31] E2 (150/10/10000) [213.128.133.185]
root@l2tp-ham01 ~ #
Heißt:
- Lokale Route (via OSPF “Upstream”) muß besser “bepreist” sein als die über OSPF “Backbone”
- Die (Tunnel-) Links zwischen den Gateways sollten überwacht werden
Danke für den Hinweis, @Thomas — good catch!
Andere erschlagen mich dafür 
Geht aber aktuell noch nicht über die GW
Es ansibled ja auch noch
Should be fixed.
root@l2tp-ham01 ~ # birdc show route for 0.0.0.0/0 table ffnet all
BIRD 1.6.3 ready.
0.0.0.0/0 via 193.26.120.113 on ens3 [upstream 2020-01-31] * E2 (150/10/10000) [213.128.133.185]
Type: OSPF-E2 unicast univ
OSPF.metric1: 10
OSPF.metric2: 10000
OSPF.tag: 0x00000000
OSPF.router_id: 213.128.133.185
via 192.168.1.21 on bck-l2tp-fra01 [backbone 18:19:05] E2 (150/1000/10000) [0.0.0.10]
Type: OSPF-E2 unicast univ
OSPF.metric1: 1000
OSPF.metric2: 10000
OSPF.tag: 0x00000000
OSPF.router_id: 0.0.0.10
root@l2tp-ham01 ~ # ip route show table 42 0.0.0.0/0
default via 193.26.120.113 dev ens3 proto bird
Danke.
IPv6 braucht auch kein NAT Das wird geroutet, schlimmstenfalls suboptimal.
Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.