L2TP / Tunneldigger Thread

Hi zusammen,

Es gab updates für den Tunneldigger und demnach wurde das ffrl-packages Repository geupdated.
Außerdem ist ein neues Paket dazu gekommen „gluon-migrate-vpn“, dies ist ein Meta-Paket welches dazu verwendet wird um von Fastd zu Tunneldigger zu wechseln oder umgekehrt.
Dazu muss das Paket lediglich in der site.mk hinterlegt werden, sonst wird nichts benötigt.

Dies löst das Problem wenn Fastd aktiv war und nach dem Wechsel zu Tunneldigger kein VPN mehr aktiv ist.

Die Pakete findet ihr wie gewohnt unter: GitHub - ffrl/ffrl-packages: FFRL Gluon Packages

Gruß
Cyrus

6 Likes

Was wurde denn genau geändert?
Leider werden auf den Routern irgendwie falsche Routern zugewiesen - wurde hier im package was geändert?

https://github.com/Speedy16/ffos_event_site/blob/master/site.conf

root@FF-OS-Test01-3600:~# ip route show
default via 192.168.178.1 dev br-wan
192.168.178.0/24 dev br-wan src 192.168.178.86

Also V4 Adressen bekommen die Nodes gar nicht über das Mesh. Nodes selbst haben nur Ipv6.
Die Route die du dort gepostet hast ist vom Wan Interface (Ich nehme an eine Fritzbox dahinter, die nutzen auch 192.168.178.0/24).

Edit: Ich sehe gerade eure MTU ist 1492, das ist viel zu groß. Maximum sind etwa 1462. Besser aber man wählt etwas kleineres, z.b. 1312 (1280 ist das Minimum für Ipv6 und 32 Bytes wäre für den Batman Compat 15 Header)

Ja, es sollte ja eine 10.33.0.0/16er Route da sein. Nur diese fehlt.

Komischerweise ging bei 1312 rein gar nichts dfurch den Tunnel. Bei 1492 sind es immerhin 30mbit/s

Wir haben das mit 1364 stabil und schnell laufen.

Gruß

Christian

Was du meinst ist die local-node Route :slight_smile: Diese sollte nachwievor da sein, das Paket hat nichts damit zu tun.

Wenn 1312 bei dir nicht performt versuch mal 1342 oder 1392 :slight_smile:

Die local-node Route - ja. Wodurch wird diese gesetzt?
Leider fehlt diese komplett. Wo kann die MTU auf dem Router denn eingestellt werden, ohne jedesmal eine neue FW backen zu müssen…

Local-node ist normalerweise Bestandteil des Paketes ‚gluon-next-node‘
Die MTU kannst du mit dem folgendem Befehl ändern:

uci set network.mesh_vpn.mtu=1364
uci commit network

Ah danke!
Next-Node ist drin - komischweise fehlt die Route

Wie kommen die Maschinen so mit den hunderten Tunnelinterfaces zurecht? Ist ifconfig noch performant? :grin:

@mattes wird da was sagen koennen wir haben 2/3 umstellt … so knapp 100

ifconfig | less :smiley: 20202020202020

1 Like

Ja, ifconfig war auch eher scherzhaft gemeint :stuck_out_tongue:
Geht mir mehr um die anderen Tools, die auf Interface-Basis arbeiten (z.B. daemons, iptables).

Also ich hab schon mit Systemen gearbeitet welche an die 400-500 Interfaces haben :wink: Dort gab es bis jetzt auch keine Probleme.

Kann der Tunneldigger auch IPv6? Ich habe es bis jetzt nur geschafft das er sich per IPv4 verbindet

Nein, war aber auch relativ leicht zu erörtern :slight_smile:

https://dev.wlan-si.net/ticket/1187

Nein leider noch nicht wie @mattes es schon beschrieben hat.
Ich denke das es nachgeliefert wird, aber selbst via V4 sind die Tunnel performanter als Fastd via nativ V6 :wink:

Übrigens habe ich ein Howto für das Broker Setup gemacht, basiert auf der Düsseldorfer Config. Habe gesehen das ihr euch da in Troisdorf etwas im Kreis dreht (Via Github).

Die Scripts die bei Tunneldigger dabei sind um die Interfaces zu verwalten sind nicht kompatible mit dem Gluon-Paket was ich gebastelt habe. Die Path-MTU discovery funktioniert zwar, aber Batman kommt damit nicht klar.
Zudem zerstört das bündeln der Interfaces in eine Bridge die Möglichkeit rebroadcasting abzuschalten welches den Downstream der Nodes schont und unötige Pakete auf dem VPN Link weiter reduziert.

1 Like

Was meinst du mit den Aussagen? Wir haben in dem up script die MTU statisch gesetzt.

Sobald auf der Bridge rebroudcasting ausgeschaltet ist? Verstehe ich nicht so ganz :smiley:

Ah wenn die MTU statisch gesetzt ist dann ist es kein Problem, aber die Bridge muss halt noch weg ;). Daher am besten die original Interface Scripts in die Tonne hauen.

Splithorizon bzw „No Rebroadcast“ klappt nur wenn jeder Link als einzelnes Interface in bat0 hängt :).

No_rebroadcast sorgt dafür das die Pakete die empfangen werden nicht auf dem selben Interface repliziert werden.
Also nehmen wir an das Node A sich über VPN bemerkbar macht, dann würde in eurem Falle ein „Echo“ von dem Gateway kommen mit dem selben Paket. Dies macht natürlich überhaupt keinen Sinn und verschwendet kostbare Bandbreite auf dem VPN Link.

Da Fastd ähnlich wie die Bridge als nur ein Interface in bat0 hängt, ist es dort das selbe Problem. Alle Nodes werden über ein Interface gesehen und daher müssen die Pakete als Echo zurück geschickt werden da sonst die anderen Nodes nichts von dem Rest mitbekommen.

Bei Funk/Wifi ist das sinnvoll und würde auch ohne nicht funktionieren da die Funk-Verbindung ja ein shared Medium ist und natürlich kann eine weitere Node noch andere Nodes sehen. Daher muss das Paket erneut auf dem selben Interface repliziert werden.

Ah okay.
Wenn du mir dann jetzt noch sagst was ich auf dem Server machen muss, dann schließ ich dich in mein Abendgebet ein.

Der speed ist tatsächlich etwas träge. Mtu ist auf 1312 statisch gesetzt. Up Script habe ich von dir genommen. Wofür setzt du jeweils die mac in dem.Script?