ich habe auf deine Empfehlung aus deinem Vortrag in Hennef mal ifupdown2 probiert und hätte da noch ein paar Fragen an dich. Da das vermutlich auch für andere interessant ist, stelle ich die einfach mal hier öffentlich.
Check markiert eth0 als Fehlschlag, vermutlich wegen der Punkt-zu-Punkt-Konfiguration. Ich hab da noch was im Hinterkopf, dass es dafür einen Patch gibt?
auto eth0
iface eth0 inet static [fail]
address 144.76.81.157/32 [fail]
auto eth0
iface eth0 inet6 static [pass]
address 2a01:4f8:192:3c6::bb/64 [pass]
auto lo
iface lo inet loopback [fail]
address 185.197.132.33/32 [fail]
auto lo
iface lo inet loopback
up ip address add 185.197.132.33/32 dev lo
up ip rule add from 185.197.132.33/32 table ffnet
up ip rule add iif lo table ffnet suppress_prefixlength 0
up ip -6 rule add iif lo table ffnet suppress_prefixlength 0
Da sehe ich aber eigentlich nichts spezielles drin. Hast du eine Idee, warum er das als Fehlschlag markiert?
Gleiches gilt für den V6-Teil dieser Tunnel hier:
auto tun-ffnw-fra1
iface tun-ffnw-fra1 inet static [pass]
address 100.100.32.1/31 [pass]
auto tun-ffnw-fra1
iface tun-ffnw-fra1 inet6 static [fail]
address fe80::2/64 [fail]
auto tun-ffnw-fra1
iface tun-ffnw-fra1 inet static
address 100.100.32.1
netmask 255.255.255.254
pre-up ip tunnel add $IFACE mode gre local 144.76.81.157 remote 89.46.125.8 ttl 255
post-up ip link set $IFACE mtu 1400
post-down ip tunnel del $IFACE
post-up ip rule add iif $IFACE lookup ffnet
pre-down ip rule del iif $IFACE lookup ffnet ||:
iface tun-ffnw-fra1 inet6 static
address fe80::2
netmask 64
post-up ip -6 rule add iif $IFACE lookup ffnet
pre-down ip -6 rule del iif $IFACE lookup ffnet ||:
Ich hab das bisher nur über das fertige Paket ifupdown2_1.0~git20170314-1_all.deb installiert. Ist es dir mal gelungen das aus den Quellen zu bauen? Bei mir wird da immer eine deb erstellt, die fast nichts enthält:
Die Einrückung ist leider irgendwie verloren gegangen. Die Interfaces-Dateien an sich sind von der Syntax her aber korrekt, ifupdown(1) kann die starten.
Vielleicht hast du ein paar Tipps für mich :). Wollte erstmal dich fragen, bevor ich die Macher nochmal mit einem Issue nerve. Ansonsten bin ich sehr begeistert davon! Hab ein Interface aktiviert ohne ein Packet zu verlieren (bck-fanlin):
root@corny ~ # traceroute 192.168.1.14
traceroute to 192.168.1.14 (192.168.1.14), 30 hops max, 60 byte packets
1 192.168.0.14 (192.168.0.14) 0.465 ms 0.468 ms 0.469 ms
2 192.168.1.14 (192.168.1.14) 9.615 ms 9.583 ms 9.607 ms
root@corny ~ # ping 192.168.1.14
PING 192.168.1.14 (192.168.1.14) 56(84) bytes of data.
64 bytes from 192.168.1.14: icmp_seq=1 ttl=63 time=9.61 ms
64 bytes from 192.168.1.14: icmp_seq=2 ttl=63 time=9.55 ms
64 bytes from 192.168.1.14: icmp_seq=3 ttl=63 time=9.67 ms
64 bytes from 192.168.1.14: icmp_seq=4 ttl=63 time=9.59 ms
64 bytes from 192.168.1.14: icmp_seq=5 ttl=63 time=9.54 ms
64 bytes from 192.168.1.14: icmp_seq=6 ttl=63 time=9.55 ms
64 bytes from 192.168.1.14: icmp_seq=7 ttl=64 time=9.37 ms
64 bytes from 192.168.1.14: icmp_seq=8 ttl=64 time=9.16 ms
64 bytes from 192.168.1.14: icmp_seq=9 ttl=64 time=9.08 ms
64 bytes from 192.168.1.14: icmp_seq=10 ttl=64 time=9.19 ms
64 bytes from 192.168.1.14: icmp_seq=11 ttl=64 time=9.09 ms
64 bytes from 192.168.1.14: icmp_seq=12 ttl=64 time=9.18 ms
64 bytes from 192.168.1.14: icmp_seq=13 ttl=64 time=9.22 ms
64 bytes from 192.168.1.14: icmp_seq=14 ttl=64 time=9.15 ms
64 bytes from 192.168.1.14: icmp_seq=15 ttl=64 time=9.92 ms
^C
--- 192.168.1.14 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14001ms
rtt min/avg/max/mdev = 9.089/9.394/9.922/0.260 ms
root@corny ~ # traceroute 192.168.1.14
traceroute to 192.168.1.14 (192.168.1.14), 30 hops max, 60 byte packets
1 192.168.1.14 (192.168.1.14) 9.428 ms 9.398 ms 9.399 ms
Hatte das Interface bck-fanlin erst gelöscht, das sieht man am ersten Traceroute, die Pakete nehmen einen Umweg. Dann wieder einkommentiert und ifreload -a -X eth0 ausgeführt, während der Ping lief. Und dann sieht man am Traceroute, dass es sofort verwendet wird. Auf den anderen Schnittstellen gab es keine Unterbrechung.
Viele Grüße
Matthias
PS: Ich war gerade einfach mal mutig. Er schafft es das Interface eth0 neu zu starten. Vielleicht ist das ein Bug im experimentellen --check-Feature? Und lo scheint auch korrekt nach einem Neustart geladen zu werden. Also ist das wohl nur ein optischer Fehler in der Ausgabe. Glaub ich werde mal einen Bugreport erstellen.
Das ist erwartungskonform. Du setzt die Adresse mit 'nem Up-Befehl, den er nur ausführt, aber nicht weiss, was Du da tust. Warum nicht einfach
auto lo
iface lo
address 185.197..133.33/32
up ip rule add from 185.197.132.33/32 table ffnet
?
Ob Policy Routing: Mal über 'ne VRF nachgedacht, in der Du dann ein dummy-interfaces packst, auf dass die IP kommt? Ist safer.
Warum so kompliziert? Das geht selbst mit ifupdown1 schöner
auto tun-ffnw-fra1
iface tun-ffnw-fra1 inet tunnel
mode gre
local 144.76.81.157
endpoint 89.46.125.8
ttll 255
mtu 1400
address 100.100.32.1/31
address fe80::2/64 ← srsly? Warum kein GUA?
## Policy Routing oder VRF oder so…
Ja, ich habe schon einige Pakete selbst gebaut. Das willst Du aus den debian-prep2 Branch machen, nicht dem Master (war zumindest bisher so). Dann tat das auch immer recht schmerzfrei.
zu 1: Werde ich dann hoffentlich los, wenn ich das gebaut bekomme.
zu 2 und 3: Werde ich beides mal ändern, danke für den Tipp. Glaub die Art wie wir GER-Tunnel bauen haben wir seit drei Jahren nicht angefasst oder so.
zu 4: Hatte die ganzen Zweige gesehen, wollte aber auch nicht alle durchprobieren. Werde das dann mal mit den debian-prep2 probieren.
Nachgedacht ja, finde ich generell auch interessant und gut. Ich will auch dieses verbuggte suppress_prefixlength loswerden, was wir überall drin haben. Aber noch nicht dazu gekommen.
@Barbarossa, auch mit dem Zweig „debian-prep2“ kommt bei mir irgendwie nicht das richtige raus. Ich hab dann kein ifreload und ifquery versteht die Option --check nicht. Entweder ist das eine ältere Version oder er greift auf irgendwas aus dem Betriebssystem zurück.
Hast du da noch irgendwas konfiguriert oder wie baust du das?
Werde ich probieren, dafür muss ich es aber erst gebaut bekommen. Siehe oben. Schaffe es einfach nicht, das zu bauen. Kannst du mal die Befehle Schritt für Schritt einmal hier reinkopieren?
Das erklärt einiges. Muss man auch erstmal drauf kommen, dass das mitgelieferte build-Skript eine falsche Fährte ist und nicht dafür gedacht ist zu funktionieren . Klappt jetzt. Danke.
Nach dem ifupdown1-gretap habe ich schon gegoogelt, dazu findet man genau gar nichts. Ich werde mal schauen, ob ich eine nicht indizierte Doku oder mich im Quelltext zurecht finde.
PS: Mal den Quellcode von ifupdown1 durchwühlt:
$~/Downloads/ifupdown-e45cc73e740e$ grep -ri 'gretap' *
$~/Downloads/ifupdown-e45cc73e740e$ grep -ri 'gre' *
BUGS: * #158089: GRE and IPIP tunnel support
BUGS: * #229503: Please add Greek debconf translation (attached)
BUGS: * #229527: Please add Greek debconf translation (attached)
contrib/ifstate:if ifconfig "$iface" | grep -Fw UP >/dev/null
COPYING:In addition, mere aggregation of another work not based on the Program
COPYING:conditions are imposed on you (whether by court order, agreement or
COPYING: 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
COPYING: If you develop a new program, and you want it to be of the greatest
debian/preinst:if [ -f /etc/network/interfaces ] && ! grep -q '^[^#]' /etc/network/interfaces
debian/rules:export VERSION := $(shell dpkg-parsechangelog|grep Version|cut -d' ' -f2|sed s/.*really//g)
debian/changelog: * Add GRE and IPIP tunnels support (Closes: #158089).
debian/changelog: + Added Greek debconf translation provided by Konstantinos Margaritis.
debian/changelog: + minor phrasing changes aiming at greater clarity
debian/changelog: + Priority: important to agree with override file
debian/postinst: if sed -e '/^[[:space:]]*#/b;:g /\\$/{N;s/\\\n//;bg;}' /etc/network/interfaces | grep -qe "^[[:space:]]*iface[[:space:]]*\\b${iface}\\b[[:space:]]*.*\\bdhcp\\b.*" &&
defn2c.pl: die "Duplicate option use: $newoption (from $method/$option)" if (grep $_ eq $newoption, @variables);
examples/network-interfaces:# with a great deal of care.)
inet.defn: This method is used to create GRE or IPIP tunnels. You need to have
inet.defn: the *ip* binary from the *iproute* package. For GRE tunnels, you
inet.defn: will need to load the ip_gre module and the ipip module for
inet.defn: mode type -- Tunnel type (either GRE or IPIP) *required*
Außerdem steht in der inet.defn auch irgendwo im Quelltext folgendes:
method tunnel
description
This method is used to create GRE or IPIP tunnels. You need to have
the *ip* binary from the *iproute* package. For GRE tunnels, you
will need to load the ip_gre module and the ipip module for
IPIP tunnels.
options
address address -- Local address (dotted quad) *required*
mode type -- Tunnel type (either GRE or IPIP) *required*
endpoint address -- Address of other tunnel endpoint *required*
dstaddr address -- Remote address (remote address inside tunnel)
local address -- Address of the local endpoint
gateway address -- Default gateway
ttl time -- TTL setting
mtu size -- MTU size
Gre scheint also nur für V4 in ifupdown drin zu sein. Und Gretap gar nicht, denn address ist ein erforderliches Feld. Ein L2-Tunnel hat aber keine Adresse. Das ganze ruft dann aber auch einfach ip tunnel auf.
Ich werde die Tage mal probieren, ob ifupdown2 es schöner hinbekommt.
PS: Braucht das einen bestimmten Kernel? Wir haben derzeit 4.9.0.0.bpo.3 drauf (wegen des Tunneldiggerproblems)
PPS: Ich sehe gerade auch, dass er probiert, das Interface mit ip tunnel zu starten. Gretap geht aber über ip link. Demnach dürfte das nie funktioniert haben, es sei denn du hast irgendwie einen Alias bei dir im System?
PPPS: Der Befehl müsste lauten:
ip link add t01-karte type gretap local 144.76.81.139 remote 46.4.80.190
Aber komisch ist auch, dass ifquery direkt failed, also er sich schon an der Syntax in der Konfigurationsdatei stört.
ich hatte die Tage auch angefangen ifupdown2 mehr zu verwenden und es scheint in Bug in ifupdown2 zu sein weshalb der gretap Tunnel nicht erstellt wird. Ich habe dafür bereits einen Issue aufgemacht gretap tunnel cann’t be created
ja, da hat wohl jemand mein Addon kaputtgepatched. Ich habe schon herausgefunden wo es bricht, die Frage ist jetzt, wie man das am geschicktesten heile macht.
. Klappt jetzt. Danke.