Routing über Telekom IP Adresse?

Hallo ich habe eben nach dem Installieren eines neuen Knoten mal einen Speedest gemacht. Das Ergebnis ist sehr seltsam. Auch nach einem Reboot des Router bleibt es bei dem Ergebnis. Angeblich habe ich die IP Adresse 217.85.126.30 Hostname pD9557E1E.dip0.t-ipconnect.de

Ich bin hier im Hochschulnetz, das ist also auch nicht meine lokale IP.

Ich habe direkt mal auf unserem Router überprüft wo denn der Traffic hingeht, heraus kam folgendes:
v22014122544522061.yourvserver.net

Außerdem besteht noch eine Verbindung zu v22014122544522063.yourvserver.net, da geht der Traffic aber nicht hin. @nomaster kannst du dir die Sache vielleicht erklären?

Könnte es sein, dass wir an „Rogue Gateways“ leiden?

Siehe auch: Exitnode-IPs/Reverse freifunk rheinufer

Leider konnte in diesem Faden das Problem nicht genau eingegrenzt werden, aber scheint was ähnliches zu sein.

Doch, das war ein eingeschlepptes Gateway in einer Düsseldorfer Wolke.

Danach ging der Thread mit der Telekom IP dann weiter, das scheint schon wieder ein neues Problem zu sein.

Mit enorm hoher Wahrscheinlichkeit wieder ein eingeschlepptes Gateway, ich sage den Rheinufer Admins bescheid…

Auf meinem Router liefert ein batctl gwl die folgende Ausgabe:

root@witten-kirmesplatz-13:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: mesh-vpn/c6:72:1f:c7:0c:c6 (bat0)]
   04:be:ef:ca:fe:00 (225) 04:be:ef:ca:fe:02 [  mesh-vpn]: 215 - 96MBit/96MBit
   a2:f3:c1:7c:cf:d2 (133) 04:be:ef:ca:fe:02 [  mesh-vpn]:  41 - 2048KBit/512KBit
=> 04:be:ef:ca:fe:02 (255) 04:be:ef:ca:fe:02 [  mesh-vpn]: 215 - 96MBit/96MBit

Interessant ist da die zweite Zeile. Laut Graph auf http://ffmap.freifunk-rheinland.net/graph.html#a2:f3:c1:7c:cf:d2 hängt der Knoten in der Nähe der Niemandsland-Wolke herum. Kann der das sein?

Das ist er sogar sicher, wir benutzen konsistent im Verein die Einstellung 48Mbit/48Mbit oder 96Mbit/96Mbit…wenn andere Werte auftauchen ist das eine fremde Supernode…

War beim letzten Mal übrigens die selbe Wolke…

@CyrusFox kann das noch der selbe Router sein, dieses Mal mit einer anderen Verbindung?

Hupps, hatte ich wohl nicht genau gelesen.

Jedenfalls: Wenn man des Besitzers habhaft wird, kann man dann evtl nachschauen, was derjenige mit seiner Config gemacht hat? Würde gerne wissen, wieviele Schritte man so braucht, um eine Config so zu borken, dass man versehentlich Traffic außerhalb des VPN leakt. Allein wegen Störerhaftung.

Dann kann man davor für alle „Config-Spieler“ ne kleine Warnung vor der kritischen Einstellung schreiben :slight_smile:

er ist leider noch da

    root@nadeshda:~# batctl gwl
      Gateway      (#/255)           Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: br-wan/e8:94:f6:29:8f:0b (bat0)]
   04:be:ef:ca:fe:02 (217) 04:be:ef:ca:fe:00 [  mesh-vpn]: 215 - 96MBit/96MBit
=> 04:be:ef:ca:fe:00 (255) 04:be:ef:ca:fe:00 [  mesh-vpn]: 215 - 96MBit/96MBit
   a2:f3:c1:7c:cf:d2 (155) 04:be:ef:ca:fe:01 [  mesh-vpn]:  41 - 2048KBit/512KBit
root@nadeshda:~# batctl p a2:f3:c1:7c:cf:d2
PING a2:f3:c1:7c:cf:d2 (a2:f3:c1:7c:cf:d2) 20(48) bytes of data
20 bytes from a2:f3:c1:7c:cf:d2 icmp_seq=1 ttl=48 time=72.60 ms
20 bytes from a2:f3:c1:7c:cf:d2 icmp_seq=2 ttl=48 time=59.61 ms
^C--- a2:f3:c1:7c:cf:d2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss
rtt min/avg/max/mdev = 59.607/66.104/72.601/6.497 ms

Ich hatte letztes WE schon angeboten, da mal rüberzulaufen, ganz ohne schwarzen Kleinbus.
Einfach mal an den Pforten klingeln und schauen, ob man denjenigen oder diejenige findet, der das Ding aufgehängt hat.
Aber vielleicht haben @nomaster oder @pixelistik eine Idee, wie wir das Ding aus dem Netz gekickt bekommen.

Das ist ziemlich einfach, mit folgendem Kommando werden die Gateway-Announcements aktiviert (siehe auch http://www.open-mesh.org/projects/batman-adv/wiki/Gateways):

batctl gw_mode server 10mbit/1mbit

Nicht nachmachen ;-).

Nachtrag: Rückgängig macht man das übrigens mit:

batctl gw_mode client

Und in der Config findet sich das unter batman-adv:

root@witten-kirmesplatz-13:/etc/config# uci show batman-adv
batman-adv.bat0=mesh
batman-adv.bat0.multicast_mode=0
batman-adv.bat0.gw_mode=client
batman-adv.bat0.orig_interval=5000

Und wenn man da irgendwas a la „10GBit symetrisch“ announced, dann hat man ganz fix ganz viele clients… (leider schon passiert… Man sollte dann aber ach was gegen den Mob mit Mistgabeln und Pechfackeln haben…)

1 Like

Hab mal per Mail nachgehakt, wer da einen neuen Router aufgestellt haben könnte.

Was ja für die User denen wir per Routing über unser Netz Schutz vor Störerhaftung versprochen haben (…oder zumindest Eindämmung des Risiko, juristische Betrachtung ausstehend) ja irgendwie doof ist.

Da wir nun mal „offen und bastelfreudig“ sind, werden wir solche Fälle wohl nicht ausschließen können - inkl. beabsichtigter Sabotage oder Datenanalysen unerwünschter Art.

Ich hab sowas in nem anderen Kontext mal mit dem Script aus http://blog.rootshell.be/2010/05/25/detecting-rogue-gateways-on-a-lan/ vor 2-3 Jahren gescannt/beobachtet/gefixt.
Idee erschein gut, auf die Schnelle nix Bessere und frei verfügbares gesehen - und hat nach üblichen hickups funktioniert. Wohlgemerkt aber in nem flotten /16 v4 mit überschauberer host Anzahl.

Sollten wir nicht einen analogen Mechanismus und z.B. Scan während low traffic des Nachts haben ?

Bitte nicht alles durcheinander bringen!

Doof ist es für den User der da falsch geflasht oder gebastelt hat, denn alles was über seinen Router direkt rausgeht, geht dann erstmal zu seinen Lasten.

Die anderen Teilnehmer im Netz sind davon, wenn überhaupt, dann nur durch schlechte Performance betroffen, wenn der Weg über einen Client Router raus geht - geniessen aber dennoch alle Vorteile einer „verschleierten“ Verbindung.

Wenn man sich als Endanwender an simpelste Dinge hält, kann aber auch nichts passieren.

  • neue Router immer mit Factory flashen, um sie nicht zu bricken
  • gebrauchte Router nur innerhalb der selben Community/Domäne mit einfachem sysupgrade flashen, noch besser mittels Festlegung des Branch und autoupdater
  • gebrauchte Router aus unbekannter Herkunft oder beim bewussten Wechsel in ein anderes Netz immer mit sysupgrade -n flashen

Wer sich nicht dran hält, bastelt oder fremde Firmware nutzt muss sich des Risikos bewusst sein und kann dann entsprechend negative Konsequenzen auslösen.

Ist in unserem Fall ein wenig anders, aber durchaus machbar. Beobachtet werden muss der Output von batctl gwl, aus dem sehr leicht abzuleiten ist, ob ein fremdes Gateway im Netz ist.

Problematisch ist derzeit das Aussperren, da wir aktuell noch keinen brauchbaren Weg gefunden haben Router auszusperren die per Wlan verbunden sind, ohne der gesamten lokalen Wolke den fastd Zugang zu sperren - das genau ist auch das Problem an dieser Niemandsland Geschichte, wo die Probleme zuletzt herkamen und scheinbar wieder herstammen…könnte man aktuell nur komplett vom Netz nehmen…

Auch wenn es manchmal so wirkt, als würde sich niemand kümmern, so ist es (wie bspw. in diesem Fall) häufig so das im Hintergrund nach Lösungen gesucht wird die machbar wären.

Und wie gesagt, das ist in einer komplexen Wolke wie Niemandsland nicht ganz so trivial wie man vermuten könnte, ohne das Netz down zu nehmen, aber das will natürlich niemand…

2 Likes

Wobei ich sogar dieses Mal unsicher bin, was genau da abläuft, da diese Mac Adresse augenscheinlich nicht zu einem Client Router gehört, sondern nur als Gateway zwei Treffer hat:

http://ffmap.freifunk-rheinland.net/alfred_merged.json

"node_id": "a0f3c14e8930",
"hostname": "freifunk-pixelnode-hof",
"gateway": "a2:f3:c1:7c:cf:d2",

"node_id": "a0f3c1365bf0",
"hostname": "freifunk-pixelnode-vorne",
"gateway": "a2:f3:c1:7c:cf:d2",
1 Like

Denke Ich nicht - es geht mit um Rouge Gateways.

Jawoll, kaum macht man´s richtig - schon klappt es. Wenn man das will.

Korrekt. Nur ist das ja vielleicht mal gewollt - oder halt unabsichtliches Risiko. Nur leider für Andere. Shit happens.

Historie:
In der früheren Firmware (Router unterhält VPN Tunnel nach Schweden) dropte dieser und danach wurde fröhlich direkt ins Internet geroutet.
Während die Nutzer&Aufsteller mit Verügbarkeit bei nem geschenkten Gaul nie ein Thema hatten, war dies ein Thema. Da ging´splötzlich um Haftung. Ausfall - ok, Haftung - nicht ok.

These:
Bei uns wird viel gebastelt - was prima ist. Dabei kann Ich mir ja mit OpenWRT auch was stricken, dass sich bei uns als Gateway announced. Und dann an uns vorbei routet.

→ Denkfehler ?
Ich muss gestehen da früher nicht drüber nachgedacht zu haben, bilde mir aber ein nen Gateway in unserem Netz bauen und announcen zu können.

Was hilft,hilft. War nur ein Beispiel für die Idee.

Das weiß Ich und stelle es somit nicht in Frage.
Ist ja pragmatisch auch ein sinnvolles Vorgehen.
Ich wollte das Thema mal aus anderem Winkel beleuchten und Richtung „Überlegung zu Automatisierung der Problemfindung“ bringen.

Keine Frage.

Aehm… auf die Gefahr von Tomaten hin:

  • wenn die Netzintegrität (illegale Routen…)
  • oder die Netzstabilität relevant (deutliches Degrade der Performance, DHCP fluppt nimmer wie gehabt, …)
    nicht nur gefährdet, sondern kompromittiert ist:
    Stecker ziehen, sofort.

Ich denke , dass unsere eine andere Vorgehensweise mehr schadet als nützt.
Macht m.E. höchstens die Frage auf, ob man mal sowas wie ne „Testlab Domäne“ zum testen/spielen/entwickeln haben muss. Aber das ist nu 3 Züge weiter.

Dieser „cf:d2“ (wie ich ihn nenne, denn mehr Infos finde ich nirgends zu ihm) liefert keine Alfred-Daten.
Folglich taucht er nur in der batctl o Liste auf, und als gateway.
Und da er offensichtlich lokal da im Niemandsland steht (Koordinaten aus dem alfred gibt’s ja nicht, s.o.) bietet er sich den Nodes dort als Uplink an.

Wir können ihn noch nichtmal auf Wifi-Ebene isolieren, weil er viele Nachbarknoten hat, an die wir ebenfalls nicht herankommen, weil derzeit „unmanaged“.

Kann man die MAC-Adresse nicht irgendwo mit einer höheren Priorität einspeisen? Insgesamt ein böses Angriffsszenario, für das es noch keine Lösung gibt, oder verstehe ich das falsch?

1 Like

Siehe hier:

Es handelt sich um eine veraltete Freifunk Advanced Node, da kann man nur physisch dran um das Problem zu lösen.

1 Like

Das klappt leider nicht, ein Batman Adv Client wählt den Gateway aufgrund von Linkqualität und Bandbreite die der Gateway anbietet. Batman-Adv sendet dann z.b. DHCP Requests nur an diesen Gateway und nicht an das ganze Netzwerk. Daher würde das sperren nur dafür sorgen das wohl nichts passiert weil der Traffic innerhalb der Batman Frames übertragen wird die dann erst beim Gateway „ausgepackt“ werden.
Man müsste um dies in Zukunft zu verhindern einen Patch für Batman-adv schreiben der whitelisting/blacklisting von Gateways erlaubt. Dann bräuchte man nur die Mac Adressen der erlaubten Gateways in der Firmware der Nodes mitliefern. Da man ja eh für die Supernodes die Fastd-Config mitliefern muss wäre es nicht so viel Aufwand.

Sorry, das bezog sich ausschließlich auf:

da nur der Anwender, der den Amok laufenden Router bei sich am Internet angestöpselt hat überhaupt betroffen sein kann. Da dies durch den Tunnel Zwang in Gluon nicht möglich ist, kann es jedoch auch nur einen User betreffen der mit fremder Firmware oder bastelnd am Router sabotiert, wo wir uns nicht mehr in der Verantwortung sehen.

Der restliche Text war damit nicht gemeint, mea culpa!