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:
Dem LAN-Interface (eth0 - ist ein WR841N) eine zusätzliche IP (v4) aus dem passenden Bereich zuweisen.
Dann einfach SSH-Portforwarding dahin.
Würde das funktionieren, ohne dass ich mir dabei das Mesh zerschieße? Das muss natürlich inzwischen weiterlaufen.
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.
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.
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.
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?
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.
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.
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.