lokales Netzwerk - Bluetooth-NAP

[Westwind]

Hallo zusammen,

ich habe auf einem Debian-Server (Jessie) eine Bridge eingerichtet, die mir einen Bluetooth-NAP anbindet. Funktioniert auch alles, ich komme mit verschiedenen Smartphone per Bluetooth ins Internet, das Smartphone bekommt vom Router wohl eine Adresse per DHCP. Der Server ist im lokalen Netz eingebunden und erreicht dort auch jede IP und wird auch selbst erreicht. Alles gut bis dahin.

Was nicht geht, ist, mit dem Smartphone eine Adresse im lokalen Netz zu erreichen. Der Server 192.168.0.8 ist erreichbar, aber kein anderes Gerät. Ist wohl auch erklärbar. Nur - ich hab keine Ahnung, wie ich mir helfen soll...

Welche Einstellung muss ich auf dem Server vornehmen, damit das Smartphone auch im lokalen Netz gleichberechtigt funktioniert? Es muss irgendwie über die iptables gehen, aber ich habe keine Ahnung, wie ich das korrekt abbilden soll.

Hier meine Konfiguration (die ein wenig dünn aussieht, ich weiß...aber sie funktioniert immerhin fürs Internet):

Code: Alles auswählen

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.4     0.0.0.0         UG    0      0        0 br0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br0

Code: Alles auswählen

bnep0     Link encap:Ethernet  Hardware Adresse 00:1a:7d:da:71:04  
          inet6-Adresse: fe80::21a:7dff:feda:7104/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:12375 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23753 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:869487 (849.1 KiB)  TX bytes:33236908 (31.6 MiB)

br0       Link encap:Ethernet  Hardware Adresse 00:1a:7d:da:71:04  
          inet Adresse:192.168.0.8  Bcast:192.168.0.255  Maske:255.255.255.0
          inet6-Adresse: fe80::3a60:77ff:fe92:8d4a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:148697 errors:0 dropped:0 overruns:0 frame:0
          TX packets:97257 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:194252611 (185.2 MiB)  TX bytes:12256018 (11.6 MiB)

eth0      Link encap:Ethernet  Hardware Adresse 38:60:77:92:8d:4a  
          inet6-Adresse: fe80::3a60:77ff:fe92:8d4a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:292931 errors:0 dropped:0 overruns:0 frame:0
          TX packets:174327 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:343121173 (327.2 MiB)  TX bytes:19804711 (18.8 MiB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX packets:4302 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4302 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:369124 (360.4 KiB)  TX bytes:369124 (360.4 KiB)

Wäre toll, wenn jemand einen heißen Tipp hätte und vielleicht eine Seite, in der das für Dummies wenigstens in den Grundzügen erklärt wird, damit ich auch verstehe, was ich da tue...

Dankeschön!
Andreas

[BenutzerGa4gooPh]

Hi Andreas, den Zweck einer Routing table (und iptables auch noch) auf einer Bridge verstehe ich nicht - wenn sich da mal nichts beisst ... .
https://de.m.wikipedia.org/wiki/Bridge_(Netzwerk)
https://wiki.debian.org/BridgeNetworkConnections
https://wiki.magenbrot.net/linux/linux_ ... ter_debian

[Westwind]

Hi Andreas, den Zweck einer Routing table (und iptables auch noch) auf einer Bridge verstehe ich nicht - wenn sich da mal nichts beisst ... .

Doch, da beißt sich bestimmt was

Das ist ja gerade mein Problem...

Aber erstmal Danke für die Antwort und die Links!

Also die Bridge (br0) verbindet meinen Bluetooth-Piepser (bnep) mit der Netzwerkkarte (eth0). Soweit habe ich es verstanden und auch hinbekommen.

Und dann habe ich irgendwo gelesen, dass ich, um ins lokale Netz zu kommen (und nicht nur ins Internet), den eingehenden Netzwerkverkehr auf die Bluetoothschnittstelle maskieren muss, im Server also - damit der Router denkt, die Anfrage käme vom Server selbst. Soweit mein Verständnis...

Und dann fehlt mir das entscheidende Puzzleteil und ich finde es im Netz nicht, da mir die Grundlagen fehlen...

[BenutzerGa4gooPh]

Dazu müsstest du wohl deine Konfiguration posten, die in der oben bereits verlinkten Website aufgeführt ist.
https://wiki.debian.org/BridgeNetworkConnections
(Habe gerade keine Lust, den genauen Dateinamen der Konfig. selbst zu suchen.)

Bekommen all deine LAN-Kisten/Phones eigentlich ihre ihnen als DHCP-Client zustehende IP-Konfig?

[Westwind]

Oh, Du meinst bestimmt diese, aber die hat doch kaum Informationsgehalt, oder?

Code: Alles auswählen

bridge name	bridge id		STP enabled	interfaces
br0		8000.001a7dda7104	no		bnep0
						eth0

Nein, ich hab für alle Clients bei mir zuhause statische IP's vergeben. Nur mein Home-Office-Rechner ist auf DHCP fixiert und die Smartphones.

[dufty2]

Also wenn es sich um dieses Konstrukt wirklich um eine reine Bridge handeln sollte, dann müsste das verbundene Smartphone ja eine Adresse auf dem 192.168.0.0/24-Netz haben, denn nichts anderes macht eine Bridge (reine Layer-2 Geschichte).
Dann müsstest Du auf dem Server auch per

Code: Alles auswählen

$ ip n

das Smartphone als (n)eighbor sehen in der dort aufgeführten Liste.
Ein tcpdump/wireshark auf Device bnep0 müsste dies auch zeigen.
Und auf dem Router (der auch den DHCP-Server spielt, richtig?) müsste das Smartphone ja auch auftauchen mit einer 192.168.0.x-Adresse.

Bluetooh ist jetzt nicht meine Spezialität, aber scheinbar wird bei diesen napd/pand viel mit "Bridge + NAT" gearbeitet, so das obiges nicht unbedingt richtig sein muss.

Ein Blick auf

Code: Alles auswählen

# iptables -L -n -v

könnte auch zur Erhellung beitragen

[BenutzerGa4gooPh]

Bluetooh ist jetzt nicht meine Spezialität ... .

Meine auch nicht. Zumindest nicht bezüglich Netzwerken.

Eine Einbindung von Smartphones in das LAN mit Internetzugang würde man schon wegen der Reichweite eher per WLAN realisieren. (Bluetooth für lokalen Dateitransfer Smartphone-PC, Mäuse, Kopfhörer, Tastaturen ...) Wäre sinnvoller und vmtl. einfacher als Protokolle zu "vergewaltigen".

Dann meinte ich in meiner letzten AW:

To make your bridge a little more permanent, you will need to edit /etc/network/interfaces

Vgl. a. https://wiki.debian.org/BridgeNetworkConnections

[Westwind]

Eine Einbindung von Smartphones in das LAN mit Internetzugang würde man schon wegen der Reichweite eher per WLAN realisieren. (Bluetooth für lokalen Dateitransfer Smartphone-PC, Mäuse, Kopfhörer, Tastaturen ...) Wäre sinnvoller und vmtl. einfacher als Protokolle zu "vergewaltigen".

Ja, das mag sein. Ich finde es aber mit Bluetooth mehr als ausreichend, der Stromverbrauch ist geringer, die Strahlung auch, es ist von Haus aus sicher. Ich sehe eben die Vorteile.

Der Nachteil: Ja, es ist unüblich, aber nicht unbedingt völlig aus der Welt.

So, und mein Problem ist ja gerade, dass dem Smartphone problemlos eine lokale IP-Adresse zugewiesen wird (sehe ich sowohl im Android, als auch im Router), es aber mit dieser Adresse nicht ins lokale Netz kommt.

Und die Ursache muss irgendwo hier begraben liegen:



"Shorewall configuration
By now you should be able to connect to your NAP, be assigned an IP address and have IP connectivity with the server. However, you will not be able to access any other machines on your local network, nor the Internet. For that we are going to use shorewall to perform IP Masquerading. This means that any connections from our NAP clients will appear to come from the server's primary network interface (eth0 in this HOWTO). "

Das habe ich hier gefunden...

https://forums.gentoo.org/viewtopic-t-419301.html

Verstehe aber zuwenig davon - zumal das auf eine eigene Firewall hinausläuft und ich vermute, dass man das auch mit Bordmitteln hinbekommt...

Vom Smartphone aus:

ping auf den Server geht.

ping auf den Router geht auch.

ping auf andere lokale Maschine geht nicht...


Keiner eine zündende Idee?

[dufty2]

Keiner eine zündende Idee?

Nö, solange Du nicht bereit bist, einige Konfigausgaben zu zeigen
Oben hab' ich Dich gebeten, die Firewall-Konfig auszugeben:

Code: Alles auswählen

# iptables -L -n -v

Der Gentoo-Artikel vewendet Masquerading, also letztendlich NAT, somit haben
PANU-clients selbst andere IPs/Netze als ein LAN-Client aus "LAN-Infrastructure".
Sowas würde man sehen, wenn man die Ausgaben vergleichen könnte ...

[BenutzerGa4gooPh]

ping auf andere lokale Maschine geht nicht...

dufty2 wird wohl den Finger in der offenen Wunde haben ...
Zur Fehlereingrenzug auch mal eine Live-Iso in der o. g. "anderen lokalen Maschine" booten, Ideal-Standard-NW-Einstellungen und anpingen.
dufty2 trotzdem nicht (wieder) ignorieren.

[Westwind]

Nun, ich hatte das als Tip verstanden und es hatte mich eben nicht erhellt

But here you are:

Code: Alles auswählen

Chain INPUT (policy ACCEPT 37471 packets, 29M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 37616 packets, 4103K bytes)
 pkts bytes target     prot opt in     out     source               destination  

Der Laie würde schätzen: Keine Firewall konfiguriert, Debian-Urzustand. Es geht was rein und es kommt was raus.

[dufty2]

Gut, weiter im Text:
Was sagt

Code: Alles auswählen

$ ip n

auf dem Server, wenn 3x auf dem NAP-Client und auch router ge-ping-t wurde?

[Westwind]

Puh:

5x ping auf Server 192.168.0.8

4x ping auf Router 192.168.0.4

Ausgabe:

Code: Alles auswählen

192.168.0.34 dev br0 lladdr 58:c3:8b:46:67:d0 STALE (Smartphone, das den ping erzeugt hat)
192.168.0.31 dev br0 lladdr 00:01:2e:36:bf:dc REACHABLE (mein Client mit dem ich hier gerade im Netz bin, keine Ahnung, warum der da jetzt auftaucht)

[dufty2]

Gut, weiter im Text:

Code: Alles auswählen

# ebtables --list

# arptables --list

auf dem Server ausgeführt.

[Westwind]

Die Befehle kennt er nicht, ich schaue mal, ob ich die passenden Pakete dazu finde.

[Westwind]

O.K. Pakete installiert.

Keine Auffälligkeiten würde ich sagen:

Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT


Chain INPUT (policy ACCEPT)

Chain OUTPUT (policy ACCEPT)

Chain FORWARD (policy ACCEPT)

[dufty2]

Righty right.
Es schaut nicht so aus, als würde der Server irgendwas "blocken".
arptables & ebtables kannst Du wieder de-installieren.

Du könntest noch ein
# tcpdump -i eth0
und gleichzeitig ein weiteres
# tcpdump -i bnep0
auf dem Server laufen lassen, während Du
a) den Router anpingst
b) Deinen client anpingst
immer vom smartphone aus.

[Westwind]

O.K. Verstehe, damit schneide ich den Netzwerkverkehr mit...

Ich habe jetzt mal meinen Geschäftsrechner angeworfen - ein Windows-PC der normalerweise per VPN verbunden wird. Die VPN-Verbindung habe ich nun getrennt und mit dem mal rumgepingt...

Der kann alle statischen IP-Adressen im lokalen Netz anpingen und auch meinen Debian-Client, der ausnahmsweise auch per DHCP eingebunden ist. Das Smartphone sieht er nicht.

Umgekehrt wird es aber richtig merkwürdig: Mein lokaler Debian-Client kann den Geschäftsrechner nicht anpingen. O.K. Liegt evtl. an den Sicherheitseinstellungen der Windows-Kiste.

Der Server selbst sieht den nämlich auch nicht. Der findet alles, auch das Smartphone (einigermaßen logisch), außer dem Windows-Rechner.

Puh. Zum Netzverkehr:

ping auf den Server, kommt bei bnep0 an:

21:52:13.004286 IP noname > debianserver.NETZWERK: ICMP echo request, id 3, seq 1, length 64
21:52:13.004383 IP debianserver.NETZWERK > noname: ICMP echo reply, id 3, seq 1, length 64
21:52:15.553361 IP noname > debianserver.NETZWERK: ICMP echo request, id 3, seq 2, length 64
21:52:15.553476 IP debianserver.NETZWERK > noname: ICMP echo reply, id 3, seq 2, length 64
21:52:15.553601 IP noname > debianserver.NETZWERK: ICMP echo request, id 3, seq 3, length 64
21:52:15.553679 IP debianserver.NETZWERK > noname: ICMP echo reply, id 3, seq 3, length 64
21:52:15.636845 IP noname > debianserver.NETZWERK: ICMP echo request, id 3, seq 4, length 64
21:52:15.636921 IP debianserver.NETZWERK > noname: ICMP echo reply, id 3, seq 4, length 64
21:52:16.765517 IP noname > debianserver.NETZWERK: ICMP echo request, id 3, seq 5, length 64
21:52:16.765631 IP debianserver.NETZWERK > noname: ICMP echo reply, id 3, seq 5, length 64


eth0 kriegt davon nix mit (verständlich, die Bridge wird nicht benötigt, so erkläre ich mir das)


ping auf den Router, bnep0:

21:52:37.137265 IP noname > fritzbox: ICMP echo request, id 4, seq 1, length 64
21:52:37.137980 IP fritzbox > noname: ICMP echo reply, id 4, seq 1, length 64
21:52:39.579060 IP noname > fritzbox: ICMP echo request, id 4, seq 2, length 64
21:52:39.579291 IP noname > fritzbox: ICMP echo request, id 4, seq 3, length 64
21:52:39.579625 IP fritzbox > noname: ICMP echo reply, id 4, seq 2, length 64
21:52:39.579936 IP fritzbox > noname: ICMP echo reply, id 4, seq 3, length 64


eth0: wird korrekt durchgeleitet.

21:52:39.579122 IP noname > fritzbox: ICMP echo request, id 4, seq 2, length 64
21:52:39.579325 IP noname > fritzbox: ICMP echo request, id 4, seq 3, length 64
21:52:39.579597 IP fritzbox > noname: ICMP echo reply, id 4, seq 2, length 64
21:52:39.579905 IP fritzbox > noname: ICMP echo reply, id 4, seq 3, length 64


Den nächsten ping, auf einen Client mit statischer IP (den er eben nicht findet), sehe ich weder im bnep-Protokoll, noch bei eth0, müsste ja wieder ein 64er-Paket sein...hat er aber nicht mitgeloggt.

Hab auch nochmal die Fritz-Box kontrolliert, die ist zwar steinalt, aber die Einstellung "alle Computer befinden sich im selben Netzwerk" ist aktiv.

Ach, was ein Mist...

Ist das mit der Windows-Kiste so korrekt, dass die Kontakt aufnehmen kann, umgekehrt aber nicht gefunden wird, oder hat meine Fritz-Box ein Problem?

[dufty2]

Tja, theoretisch sollte es funktionieren.
Irgendwo gelesen, dass dieses Bluetooh bnep0 so eine Art Pseudo-Ethernet ist, vielleicht liegt es daran.

Evlt. muss halt doch ge-Nat-et werden.

[Westwind]

Tja, theoretisch sollte es funktionieren.
Irgendwo gelesen, dass dieses Bluetooh bnep0 so eine Art Pseudo-Ethernet ist, vielleicht liegt es daran.

Evlt. muss halt doch ge-Nat-et werden.

Ja, vorstellbar.

Ich hab ja auch nix dagegen, das einzurichten, wenn es denn überhaupt funktioniert.

Ich hab verstanden, dass ich die Netzpakete bzw. deren Absender maskieren muss. Und ich krieg das auch bestimmt auf der Kommandozeile hin...tue mir aber mit der Wahl der richtigen Schnittstellen schwer - wegen der Bridge...

Was ist die Quelle und was das Ziel? Quelle bnep0? Macht eigentlich Sinn. Ziel eth0? Obwohl die Bridge jetzt die Adresse übernommen hat? Oder Ziel doch die Bridge? Und wie beschränke ich das auf das interne Netz bzw. auf den einen Client?

Anleitungen habe ich gelesen, auch schon mal ahnungslos was eingetippt - hatte nur zur Folge, dass dann mein Drucker nicht mehr erreichbar war und meine Frau Amok gelaufen ist