Remote-Zugriff auf Bridge via Mesh-on-LAN und SSH-Portforwarding

Hi,

ich betreue eine Reihe von Knoten in einer Flüchtlingsunterkunft, die über eine 5-GHZ-Bridge (Loco M5 mit Stock-Firmware) an den „Spender“ angebunden sind, bei dem wiederum der Knoten steht, der das VPN herstellt.

Die Nodes haben alle Mesh-On-LAN aktiviert und sind miteinander per LAN verbunden; die Locos laufen im WDS-Modus, sollten also das Mesh transparent bridgen. Was allerdings aus irgendeinem Grunde nicht klappt - weswegen ich mich jetzt von zuhause aus auf das Konfigurations-Webinterface der Locos einloggen möchte.

Ich habe SSH-Zugriff auf die Freifunk-Nodes (zumindest auf einer Seite). Die Loco hat eine IPv4, über die ich auf das Webinterface komme. Wenn ich lokal den Laptop in die LAN-Buchse irgendeines Knotens (also Mesh-LAN) stecke - und mir natürlich eine statische IP verpasse -, ist das Interface auch erreichbar.

Jetzt sitze ich aber zuhause und will das via SSH bewerkstelligen. Wie kriege ich das hin? Idee war:

  1. Dem LAN-Interface (eth0 - ist ein WR841N) eine zusätzliche IP (v4) aus dem passenden Bereich zuweisen.
  2. Dann einfach SSH-Portforwarding dahin.

Würde das funktionieren, ohne dass ich mir dabei das Mesh zerschieße? Das muss natürlich inzwischen weiterlaufen.

Danke für sachdienliche Hinweise.

Torben

Du benötigst von Deinem Domain-Admin statische RFC1918er. Wahlweise manuell (sinnvoll) oder eben statisch im Domain-Dhcp.

Nein, du hast mich nicht richtig verstanden, befürchte ich.

Die Bridge hängt mit ihrem (einzigen) LAN-Interface nicht am Client-LAN sondern am Mesh-LAN der dortigen Installation. Weil sie das Mesh ja rüber zum Spender bridgen soll. (Es handelt sich um eine Gaststätte, die selbst FF anbietet, und wir nur einen VPN-Link haben wollen; sonst hätten wir den VPN-Node auch direkt in der Unterkunft aufstellen und stattdessen das LAN des Spenders rüberbridgen können.)

Natürlich hat die Loco eine 10.x.x.x-Adresse für die Konfiguration. Meine Frage ist einzig und allein, ob ich einem der FF-Router mal eben mit „ifconfig eth0 10.x.x.x“ auch eine IP aus diesem Subnetz verpassen kann, oder ob ich mir dabei das Mesh zerschieße, das ja auch über eth0 läuft.

Disclaimer:

Natürlich wäre es am saubersten, man würde auf den NanoStations ein Management-VLAN einrichten. Dann käme ich aber noch schlechter drauf, wenn ich mal lokal mit dem Laptop vor Ort bin. Switches, gar managebare, gibt es dort nirgends.

o.k. so herum, auf dem Interface ist ausschließlich bat (mesh) bislang.

Wenn das Webinterface der UBTN auch per IPv6 erreichbar ist, dann würde ich es per Link-Local-Adressen versuchen und mir ggf. von dem FF-Nodes per socat in der /etc/rc.local ein forwarding bauen.

Hallo,

das müsste mittels Portforwarding machbar sein, wenn du von Zuhause auf die Freifunk-Router draufkommst:

ssh root@<Globale IPv6 oder IPv4 aus dem Freifunknetz des 841ers> -L 8080:<IPv4-der-Bridge>:80 

Dann kannst du lokal mit localhost:8080 auf die IPv4:80 zugreifen. Du musst halt nur noch das virtuelle Interface konfigurieren, da bin ich nicht fit, das sollte aber technisch gehen. Ich mache das immer noch mit ifconfig, die Befehle sind aber deprecated.

Irgendwas richtung eth0:2 müsste das dann sein.

Grüße
Matthias

/edit: Ich sehe gerade mit

ip a a 10.99.99.1/24 dev br-client

kann man den gelben Ports zweite IPs zuweisen, ohne Gewähr, probiere das einfach Mal.

Wie man einen SSH-Tunnel baut, weiß ich wohl.

Es geht um die Frage, ob ich auf den Mesh-LAN-Ports (es ist überall Mesh on LAN aktiv!) gefahrlos eine IPv4 hinzufügen kann, ohne dass es das Meshing zerschießt. Weil ich eben im Moment keinen physikalischen Zugriff auf die Router habe, nur SSH via Mesh.

Ich wiederhole nich: Auf den gelben Ports ist kein Client-Netz! Sondern Mesh! Sonst wäre es ja einfach per Alias möglich, und ich müsste mir keine Sorgen machen das Mesh zu zerschießen.

Also wenn ich den gelben Ports, bei Mesh on LAN, eine IPv4 zuweisen will - direkt auf eth0 oder auf eines der Bridge-Devices (und welches dann überhaupt)?

IPv6 ist auf den Locos leider nicht aktiviert (hätte ich das mal getan). Dauerhaften Tunnel brauche ich auch nicht. Ist nur für seltene Konfigurationsaufgaben. Da kann ich den Befehl für den SSH-Tunnel eben von Hand entippen.

Das wird dir niemand zu 100% beantworten können. Probiere es doch einfach mit zwei Routern aus!

Ich würde sagen, dass es sich nicht stört. Denn Batman arbeitet auf Mac-Ebene. Man kann schließlich auch über das WAN-Interface meshen. Eine Garantie geben kann ich nicht.

Grüße
Matthias

Bei mir hatte beides in der Vergangenheit bereits funktioniert. Im Moment klappt es mit Gluon 2016-2.1 aber nicht mehr.

Im konkreten Fall hängt ein 1043er mit Mesh-on-WAN an einer transparenten bridge. Die Frage, die sich mir jetzt auch wieder stellt: Welches Interface braucht die IPv4-Adresse? eth0, br-wan oder noch ein anderes?

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue 
[...]
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan qlen 1000
    link/ether c4:6e:1f:fe:44:e7 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-mesh_lan qlen 1000
    link/ether c4:6e:1f:fe:44:e6 brd ff:ff:ff:ff:ff:ff
4: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop 
    link/ether 02:54:28:ee:61:a5 brd ff:ff:ff:ff:ff:ff
5: teql0: <NOARP> mtu 1500 qdisc noop qlen 100
    link/void 
7: br-mesh_lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master bat0 
    link/ether 6e:89:19:26:97:04 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6c89:19ff:fe26:9704/64 scope link 
       valid_lft forever preferred_lft forever
8: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master bat0 
    link/ether 6e:89:19:26:97:00 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6c89:19ff:fe26:9700/64 scope link 
       valid_lft forever preferred_lft forever
9: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
    link/ether c4:6e:1f:fe:44:e6 brd ff:ff:ff:ff:ff:ff
    inet6 2a03:2260:115:3600:c66e:1fff:fefe:44e6/64 scope global dynamic 
       valid_lft 86379sec preferred_lft 14379sec
    inet6 fe80::c66e:1fff:fefe:44e6/64 scope link 
       valid_lft forever preferred_lft forever
10: local-node@br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
    link/ether de:ad:be:ef:08:01 brd ff:ff:ff:ff:ff:ff
    inet 10.48.32.1/21 brd 10.48.39.255 scope global local-node
       valid_lft forever preferred_lft forever
    inet6 2a03:2260:115:3600::1/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::dcad:beff:feef:801/64 scope link 
       valid_lft forever preferred_lft forever
11: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue master bat0 
    link/ether 6e:89:19:26:97:03 brd ff:ff:ff:ff:ff:ff
12: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-client 
    link/ether c4:6e:1f:fe:44:e6 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c66e:1fff:fefe:44e6/64 scope link 
       valid_lft forever preferred_lft forever
13: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc mq master bat0 qlen 1000
    link/ether 6e:89:19:26:97:01 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6c89:19ff:fe26:9701/64 scope link 
       valid_lft forever preferred_lft forever
14: client0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-client qlen 1000
    link/ether 6e:89:19:26:97:00 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6c89:19ff:fe26:9700/64 scope link 
       valid_lft forever preferred_lft forever
1 Like

Es scheint einfacher, das SSH-Portforwarding mit IPv6 zu machen… Neuere Nanostations haben auch mit Stock-Firmware IPv6-linklocal Adressen.
Der große Vorteil: das IPv4 Setup muss dazu nicht verändert werden.

Die SSH-Kommandozeile ist analog der oben erwähnten, ipv6-Adressen am besten mit eckigen Klammern. Die IPv6 Adresse kann man jeweils mit ping6 ff002::1%eth0 o.ä. herausfinden.

2 Likes

Super, vielen Dank!

Erratum: Die Mulitcast-Adresse hat eine ‚0‘ zu viel, es muss ff02::1 heißen.

Bei unserer Firmware sind die ethX-Ports selbst ohne IP, die entsprechenden bridges haben aber eine IPv6. Was bei mir funktioniert hat (sind zwei CPE210 mit Stock-FW):

root@ffwaf-xxxxxxxxxxx:~# ping6 ff02::1%br-mesh_lan
PING ff02::1%br-mesh_lan (ff02::1%br-mesh_lan): 56 data bytes
64 bytes from fe80::5cb1:aeff:fe9d:10a4: seq=0 ttl=64 time=0.843 ms
64 bytes from fe80::6c89:19ff:fe26:9700: seq=0 ttl=64 time=4.048 ms (DUP!)

Meine Frage: Wie bringe ich dem entfernten Host bei, dass er auch das Port-Forwarding über br-mesh_lan machen soll?
ssh -i .ssh/xxxxxx -L 8081:[fe80::6c89:19ff:fe26:9700%br-mesh_lan]:80 root@2a03:2260:115:3600:xxx:xxxx:xxxx:xxxx
hat nicht funktioniert.

EDIT: Kann auch nicht, da die Link-local-Adresse vom br-wan der Gegenseite (Freifunkrouter) stammt. Die CPE210 hat keine IPv6-link-local-Adresse. :disappointed:

die geschlossene Klammer ] muss vor das %.

1 Like

Nö.

ssh -i .ssh/xxxxxx_rsa -L 2222:[fe80::6c89:19ff:fe26:9700%br-mesh_lan]:22 root@2a03:2260:115:3600:xxxx:xxxx:xxxx:xxxx

Ergebnis:

BusyBox v1.23.2 (2017-04-21 15:54:17 CEST) built-in shell (ash)
usw…

Nächste Shell:
ssh -i .ssh/xxxxxx_rsa -p 2222 root@127.0.0.1

Ergebnis: Erfolgreicher Login auf fe80::6c89:19ff:fe26:9700

Alle anderen Formatierungen werden mit „Bad local forwarding specification“ quittiert.

Mein Problem war, dass ich nicht – wie erwartet – auf die CPE weitergeleitet habe, sondern auf das br-wan-Interface des benachbarten Freifunk-Router. Da war auf Port 80 natürlich nix zu holen.

2 Likes