Benutzer:Torte/FindDeviceDraft

Aus wiki.freifunk.net
Zur Navigation springenZur Suche springen

Diese Seite soll Hilfestellungen geben, wie man in einem fehlkonfigurierten Netzwerk die vorhandenen Geräte dennoch erreichen kann.

Allgemeines

  • Backups: Kann man nicht oft genug erwähnen (und anlegen).
    Spätestens nach jeder abgeschlossenen Konfigurationsänderungen sollte man ein Backup anlegen - im Zweifel lieber zu oft.
    Dabei an alle Geräte denken, auch die Switches!
  • Reboot tut gut: Ob eine Konfigurationsänderung wirklich funktioniert, weiss man frühestens, nachdem die komplette Anlage einmal neu gestartet wurde und dann immer noch läuft. Manchmal lösen sich auch Probleme von alleine durch Aus-/Einschalten von Geräten, z.B. können sich auch einfache Switche mal "verschlucken" und z.B. Pakete nicht weiterleiten.
  • Verkabelung: Die Netzwerkkabel bis zum nicht erreichbaren Gerät prüfen (sitzt der Stecker?) und mal testweise tauschen. Dabei auch nachsehen, ob z.B. die Switches auch eingeschaltet sind.

Exemplarischer Aufbau

Soweit nicht anders erwähnt, gilt in den Beispielen folgender Aufbau:

  • 1 Core-Router
    Name: core
  • 1 Managed Switch
  • 4 Router für die Umgebung
    Namen: nord, ost, sued, west
  • Core und Umgebungs-Router befinden sich am gemeinsamen Switch.
    Das Interface, über das sich alle Geräte erreichen können (sollen), heisst auf allen Geräten "eth0.11" und hat die VLAN-ID=11

Serielle Konsole

  • Vorteil: Es kann schon sehr früh im Boot-Prozess eingegriffen werden, z.T. schon vor dem Laden des Kernels
  • Nachteile:
    • Gerät muss physisch erreichbar sein
    • Gehäuse muss geöfnet werden
    • Meist muss erst eine Pfostenleiste eingelötet werden, in einigen Fällen auch noch zusätzliche Widerstände oder Brücken
    • Ersetzt keine Netzwerkverbindung, z.B. ist so kein Zugriff auf die Weboberfläche des Gerätes möglich
    • TTL-Wandler oder USB-TTL-Adapter ist erforderlich
Important.png Wichtig: Auf keinen Fall die seriellen Anschlüsse direkt mit einem anderen Gerät verbinden, sondern auf die unterschiedlichen Spannungen achten!
  • Die RS232-Schnittstelle eines PC benutzt +/-12V, die seriellen Anschlüsse der Router dagegen meist 3,3V.
  • OpenWRT Wiki: Benutzung des seriellen Anschlusses
  • OpenWRT Wiki: Liste mit seriellen Adaptern

IPv6

IPv6 bringt einige Verbesserungen gegenüber IPv4 mit, die es erlauben, Geräte auch in fehlkonfigurierten Netzwerken zu erreichen.
IPv6 in der Wikipedia

Link-Local Adressen

Sofern das Gerät IPv6 unterstützt (und sich standardkonform verhält), gilt:

  • Netzwerkschnittstellen bekommen automatisch eine IPv6 "Link Local Unicast"-Adresse zugewiesen. Sie ergibt sich rechnerisch aus der MAC-Adresse des Interface (funktioniert auch anders herum), d.h. diese Adresse bleibt auch nach Neustart des Gerätes gleich.
  • Link-Local Adressen werden nicht geroutet. Daher muss zum Ansprechen eines Gerätes über eine Link-Local-Adresse auch immer der Name der Schnittstelle mit angegeben werden. Beispiel: "ping ff02::1%eth0.11" (die Schnittstelle folgt nach dem "%", hier "eth0.11").
  • Es sind nur Link-Local Adressen erreichbar, die sich am Switch im gleichen VLAN befinden.

Da die "Link Local Unicast" Adressen auch ohne DHCP oder manuelle Zuweisung feststehen und auch ein falsch konfiguriertes Routing die Erreichbarkeit dieser Adressen idR nicht beeinflusst, eignen sie sich besonders gut für Service- und Diagnosezwecke.

Übersichtliche Erklärung der IPv6 Adressbereiche

  • Link Local Unicast Adressbereich: fe80::/10
    Jedes der mit diesem Interface verbundenen Geräte kann mit seiner eigenen Adresse angesprochen werden.
  • Multicast Adressbereich: ff00::/8
    Besonders nützlich ist hier die Adresse ff02::1, damit können alle mit diesem Interface verbundenen Geräte erreicht werden (Broadcast).
    Beispiel: "ping ff02::1%eth0.11".

Rezepte: IPv6

Interface ermitteln

Zuerst muss man das Interface herausfinden, über das die Geräte kommunizieren können. Wenn man dazu nichts dokumentiert hat und auch die Benennung der Interfaces keine Hinweise gibt, muss man sie einzeln durchprobieren. Eine Liste der Interfaces erhält man mit dem Befehl "ifconfig": 

root@core:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 30:B5:C2:3E:9D:FB
          inet6 addr: fe80::32b5:c2ff:fe3e:9dfb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:98086947 errors:0 dropped:0 overruns:8 frame:0
          TX packets:110619671 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:325003034 (309.9 MiB)  TX bytes:1707952294 (1.5 GiB)
          Interrupt:4

eth0.10   Link encap:Ethernet  HWaddr 30:B5:C2:3E:9D:FB
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3500857 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3266652 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:923155922 (880.3 MiB)  TX bytes:3365257313 (3.1 GiB)

eth0.11   Link encap:Ethernet  HWaddr 30:B5:C2:3E:9D:FB
          inet addr:10.20.30.1  Bcast:10.20.30.255  Mask:255.255.255.0
          inet6 addr: fe80::32b5:c2ff:fe3e:9dfb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33128035 errors:0 dropped:8751 overruns:0 frame:0
          TX packets:57652658 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3929493768 (3.6 GiB)  TX bytes:63172311135 (58.8 GiB)

Geräte aufspüren

Hat man das passende Interface (oder probiert sie einzeln durch), führt man einen "ping" auf die Multicast Adresse dieses Interfaces aus. Es melden sich dann alle über dieses Interface erreichbaren Geräte zurück: 

root@core# ping ff02::1%eth0.11
PING ff02::1%eth0.11 (ff02::1%eth0.11): 56 data bytes
64 bytes from fe80::32b5:c2ff:fe3e:9dfb: seq=0 ttl=64 time=0.487 ms
64 bytes from fe80::9ade:d0ff:fe88:6f5a: seq=0 ttl=64 time=2.923 ms (DUP!)
64 bytes from fe80::9ade:d0ff:fe65:dbca: seq=0 ttl=64 time=3.425 ms (DUP!)
64 bytes from fe80::9ade:d0ff:fe88:7174: seq=0 ttl=64 time=3.606 ms (DUP!)
64 bytes from fe80::9ade:d0ff:fe88:7662: seq=0 ttl=64 time=3.685 ms (DUP!)
64 bytes from fe80::32b5:c2ff:fe3e:9dfb: seq=1 ttl=64 time=0.440 ms
64 bytes from fe80::9ade:d0ff:fe88:7174: seq=1 ttl=64 time=1.447 ms (DUP!)
64 bytes from fe80::9ade:d0ff:fe88:6f5a: seq=1 ttl=64 time=1.506 ms (DUP!)
64 bytes from fe80::9ade:d0ff:fe65:dbca: seq=1 ttl=64 time=1.562 ms (DUP!)
64 bytes from fe80::9ade:d0ff:fe88:7662: seq=1 ttl=64 time=1.731 ms (DUP!)
^C

In diesem Fall gibt es 5 Antworten: Eine vom Gerät, auf dem man arbeitet (hier: "core"), die wegen der Laufzeiten als erste ankommt, sowie 4 weitere Geräte. Weil alles Antworten auf die selbe "ping" Frage sind, erscheint bei den doppelten Antworten "(DUP!)". Nach dem zweiten Durchlauf wurde mit "STRG+C" abgebrochen.

Geräte einzeln erreichen

Nachdem man so die Liste der "Link Local Unicast" Adressen ermittelt hat, kann man die Geräte über diese Adressen ansprechen, z.B. per "ssh" (auch hier das Interface explizit angeben): 

root@core:~# ssh fe80::9ade:d0ff:fe88:6f5a%eth0.11

Host 'fe80::9ade:d0ff:fe88:6f5a%eth0.11' is not in the trusted hosts file.
(ssh-rsa fingerprint md5 56:e9:f6:d2:06:9a:64:d3:5e:2a:ad:67:fb:04:a5:9e)
Do you want to continue connecting? (y/n) y
root@fe80::9ade:d0ff:fe88:6f5a%eth0.11's password:


BusyBox v1.25.1 () built-in shell (ash)

  _____        _  __             _
 |  ___|      (_)/ _|           | |
 | |_ _ __ ___ _| |_ _   _ _ __ | | __
 |  _| '__/ _ \ |  _| | | | '_ \| |/ /
 | | | | |  __/ | | | |_| | | | |   <
 \_| |_|  \___|_|_|  \__,_|_| |_|_|\_\

 Firmware Berlin (Hedy 1.0.0 rev 9cd06054a3)
 Generic - ar71xx/generic
 https://wiki.freifunk.net/Berlin:Firmware
 https://github.com/freifunk-berlin
 -----------------------------------------------------

 If you find bugs please report them at:

   https://github.com/freifunk-berlin/firmware/issues

 For questions write a mail to <berlin@berlin.freifunk.net>
 or check https://berlin.freifunk.net/contact for our weekly meetings.

root@nord:~#

Auf der Shell sieht man nun anhand des Prompts, auf welchem Gerät man gelandet ist.
Das ist ein guter Zeitpunkt, in seiner Dokumentation zu vermerken, welches Gerät welche IPv6 Link-Local-Unicast Adresse hat.

SSH

Port-Forwarding

Mit "ssh" kann man sich nicht nur auf Geräten einloggen, sondern (unter anderem) auch Port-Weiterleitungen zu weiteren Geräten in diesem Netzwerk einrichten, die sonst ggf. nicht erreichbar sind. Die Syntax dafür ist: ssh user@host -L localport:remotehost:remoteport "remotehost" kann dabei eine IPv4-Adresse, IPv6-Adresse oder ein Hostname sein. Beim Weiterleiten von IPv6-Adressen muss diese Adresse in eckige Klammern ('[' und ']') eingefasst werden.

Rezepte: SSH

Webserver weiterleiten

Angenommen, man kann von seinem PC aus "core" erreichen, jedoch nicht die weiteren Geräte in dessen Netz (z.B. weil ein Routing Daemon falsch konfiguriert ist). Vom "core" aus ist jedoch eine Verbindung zu den weiteren Geräten über die IPv6 Link-Local Adressen möglich (siehe oben).
Um dann z.B. an die Weboberfläche eines der verbundenen Geräte (z.B. "nord") zu gelangen, kann man "ssh" anweisen, den Webserver-Port eines Gerätes (fe80::9ade:d0ff:fe88:6f5a%eth0.11) an den lokalen PC weiterzuleiten: 

ssh root@core -L 8080:[fe80::9ade:d0ff:fe88:6f5a%eth0.11]:80

Das bedeutet umgangssprachlich: «ssh: Verbinde dich als Benutzer "root" mit dem Gerät "core". Öffne auf meinem lokalen PC den Port 8080, und wenn ich mich mit diesem verbinde, leite das an die Adresse "fe80::9ade:d0ff:fe88:6f5a%eth0.11" an den Port 80 weiter.»

Man kann dann in seinem Browser http://localhost:8080/ öffnen und landet so auf dem Webserver des Routers "nord".

Um sich per HTTPS zu verbinden, muss beim ssh-Aufruf der HTTPS Port 443 (statt 80) angegeben werden: 

ssh root@core -L 8080:[fe80::9ade:d0ff:fe88:6f5a%eth0.11]:443

Und im Browser ist dann https://localhost:8080/ (auf das https achten!) anzuwählen.

SSH weiterleiten

Das kann z.B. sinnvoll sein, wenn das Zielgerät nicht direkt erreichbar ist und auch kein Passwort-Login erlaubt, aber man einen public-key auf dem Zielgerät installiert hat.

Man könnte nun seinen private-Key auf den "core" kopieren, und sich dann von diesem aus weiter verbinden, aber private-Keys haben auf Routern nicht wirklich was zu suchen (es wäre nicht das erste Mal, dass eine schlecht programmierte Webseite den Download beliebiger Dateien vom Host erlaubt).

Dazu zuerst den SSH-Port des entfernten Gerätes ("nord") auf den lokalen Port 2222 weiterleiten: 

ssh root@core -L 2222:[fe80::9ade:d0ff:fe88:6f5a%eth0.11]:22

Im zweiten Schritt verbindet man sich über diesen Tunnel zum Gerät "nord": 

ssh -p 2222 root@localhost
Abgerufen von „https://wiki.freifunk.net/index.php?title=Benutzer:Torte/FindDeviceDraft&oldid=42762“