Nicco Kunzmann

→

Essays

→

OLSR Roaming mit ARP Spoofing

OLSR Roaming mit ARP Spoofing

Die Zeichnung zeigt, was ich mir vorgestellt habe. Wie kann man das umsetzen? In der Problemstellung git es das, womit ich Hilfe brauche.

Roaming

Roaming funktioniert so, dass sich ein Client das für ihn Stärkste Netz auswählt.

Die Access Points und die Clients können über die Netze hinweg nicht miteinander reden: 192.168.99.1 ist mein Gateway, 192.168.99.2 ist ein anderes. Jetzt kann ich das eine Pingen, das andere nicht:

>ping /t 192.168.99.1

Pinging 192.168.99.1 with 32 bytes of data:
Reply from 192.168.99.1: bytes=32 time=1ms TTL=64
Reply from 192.168.99.1: bytes=32 time=1ms TTL=64

>ping /t 192.168.99.2

Pinging 192.168.99.2 with 32 bytes of data:
Reply from 192.168.99.18: Destination host unreachable.
Reply from 192.168.99.18: Destination host unreachable.
Reply from 192.168.99.18: Destination host unreachable.
Reply from 192.168.99.18: Destination host unreachable.
Reply from 192.168.99.18: Destination host unreachable.

Jetzt mache ich meinen Access Point aus:


>ping /t 192.168.99.2

Pinging 192.168.99.2 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.           
Reply from 192.168.99.2: bytes=32 time=6ms TTL=64
Reply from 192.168.99.2: bytes=32 time=31ms TTL=64
Reply from 192.168.99.2: bytes=32 time=3ms TTL=64
Reply from 192.168.99.2: bytes=32 time=1ms TTL=64

Scenario 1 Freifunk + Arp Spoof

Gerade bekommen alle Clients eine IP aus einem eigenen Adressraum. Also muss jeder Router, der am Roaming teil nimmt, sich als Gateway für die Clients, die wechseln, ausgeben.

Dafür muss zusätzliche Software entstehen.

Hiermit sagt der Freifunk-Router allen Clients im DHCP-Netz, dass die IP des andere Freifunk-Routers 10.22.73.129 unter seiner MAC-Addresse erreichbar ist.

echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
arping -A -U -s 10.22.73.129 -I br-dhcp 0.0.0.0 &

Quelle

Das ist meine Client-Konfiguration von einem anderen Freifunk-Router:

Es funktioniert:

>ping -t 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=515ms TTL=45
Reply from 8.8.8.8: bytes=32 time=25ms TTL=45

Ein ähnliches Script kann für alle Knoten laufen, die irgendwie als Freifunk Router erkannt werden. Datenbasis:

Alle /32 Adressen -> dann kann jeder Knoten, der roaming mag, sich so announcen. (sinnloser Traffic)

Alle HNA ist eine effizientere Quelle, da nur von dort die Clients Anfragen können:

So stelle ich fest, dass sich ein Client verbunden hat:

root@254-121-heinrich-von-kleist:~# ip neigh
10.22.73.155 dev br-dhcp lladdr 7c:7a:91:4b:ca:6c REACHABLE

Dieser Arp-Eintrag zeigt deutlich, dass sich ein Client aus einem fremden Netz verbunden hat, welches gleichzeitig auch in den HNA steht. Der Algorithmus ist klar: Sollte sich ein Client verbinden, der aus einem anderen Netz kommt, so kann ihm proaktiv alles angeboten werden. Das verursacht vielleich viel Traffic?

Traffic begrenzen: Um den Traffic effektiv zu begrenzen, kann man die ARP-Requests benutzen, die von dem neuverbundenen Client reinkommen.

Algorithmus

Dieser Algorithmus kann auf jedem Freifunk-Router laufen, um HNA-Roaming anzuschalten:

Problemstellung

Ich kann es als (1) Shellscript machen, das (2) proaktiv alle IPs der HNA spooft.

Es gibt OLSR-ARPRoaming. Der Algorithmus steht in der C-Datei.

Auf die Anfrage in der Mailingliste gab es Antworten. Mehr Diskussion März 2018. In Potsdam gibt es eine Anleitung.

Fails

Die nachfolgenden Versuche haben nicht geklappt.

Scenario 2 Freifunk + eigenes Roaming Netz

Da die Roaming APs und clients sich nicht sehen können, können wie ein gleiches Roaming Netz für alle einrichten. Das wäre z.B. 192.168.X.X. Dann brauchen wir uns nicht um die DHCP-IP-Vergabe kümmern. Clients wechseln und haben Internet, sind aber nicht mehr wirklich über das Freifunk-Meshnetz aus erreichbar.

Scenario 3 Ansatz vereinigen (fail)

Um Roaming erfolgreich in einem OLSR-Netz zu machen braucht es diese (zusätzlichen) Einstellungen zum Potsdamer Freifunknetz:

  1. Wir brauchen eine einheitliche SSID
  2. Wir brauchen eine einheitliche Gateway IP, z.B. 10.22.0.1. Wir können zwei Gateways angeben, DHCP-Option 3 (siehe nächster Schritt). Dieses Gateway-Interface akzeptiert auf 255.255.0.0.
  3. DHCP: Der Router gibt den Clients die Möglichkeit den Router zu erreichen:
    • Durch eine erweiterte Netzmaske: 255.255.0.0. Dann können die Clients keine anderen Freifunkgeräte mehr erriechen, weil sie nicht das Gateway für Freifunk benutzen.
    • Durch eine Zusätzliche Route mit der DHCP-Option 121. Dieser Artikel beschreibt das für Windows Server 2009. Es werden wohl nicht alle Clients diese Option verstehen.
      Diese ermöglicht also alten Geräten einen stationären Gebrauch und neuen Geräten ein Roaming.

Static Route mit DHCP

Reading:

121,10.22.0.1/32,0.0.0.0
249,10.22.0.1/32,0.0.0.0
3,10.22.0.1,10.22.DHCP.IP

Fail: Die Routen werden beim Client richitg angelegt. Das Problem: Der Fall von Scenario 2 tritt wieder in Kraft.

Notizen

TODO:

DONE

user@ubuntu:~$ ip route
default via 192.168.99.1 dev wlx7cdd9058f352  proto static  metric 600 
169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown 
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown 
192.168.99.0/24 dev wlx7cdd9058f352  proto kernel  scope link  src 192.168.99.20  metric 600 

user@ubuntu:~$ ip neighbor
192.168.99.1 dev wlx7cdd9058f352 lladdr a6:03:8f:71:c1:00 STALE

Go to other roaming wifi.

user@ubuntu:~$ ip neighbor
192.168.99.2 dev wlx7cdd9058f352 lladdr a6:03:8f:71:c1:1d STALE

user@ubuntu:~$ sudo ip neighbor add 192.168.99.1 lladdr a6:03:8f:71:c1:1d nud permanent dev wlx7cdd9058f352

user@ubuntu:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=45 time=84.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=45 time=72.4 ms