Client-Netz am Offloader geht nicht, kein Gateway / kein DNS

Hallo Freifunker,
ich möchte das Clientnetz aus einem Offloader heraus nutzen. Das funktioniert nicht: die Rechner, die ich mit dem Client-LAN des Offloaders verbinde, bekommen zwar eine v6 IP, aber keine v4 IP, keinen DNS und kein Gateway. Pingen im Client-Netz geht: ich erreiche das Gateway und andere Router in demselben Netz.

Zur Installation:

  • Gluon 2017.1
  • Offloader mit Mesh-on-Lan auf eth1: http://map.freifunk-uelzen.de/#/de/map/5254005877b1
  • Offloader eth0 = WAN, eth1 Mesh, eth2 = Client-LAN
  • Offloader als KVM-Image
  • 3 WR841-Router über Mesh on LAN verbunden, dort Mesh-VPN deaktiviert
  • Freifunknetz funktioniert im WLAN auf allen Funk-Nodes über Mesh-on-Lan mit diesem Offloader
  • Es ist eine Neuinstallation, es ist also nicht so, dass es schon mal gegangen ist.

Ich würde gerne Freifunk-Client-Netz auch auf ausgewählte Netzwerkdosen bringen. Leider funktionieren aber die Teilnehmer im Client-LAN am Offloader nicht. Sie bekommen keinen DNS und kein Gateway. ping auf Gateway und meine anderen Router im Client-Netz geht.

Auf dem Client im LAN sieht es so aus:

    root@remus:~# ifconfig eno1           
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fd83:e002:c8a1:0:724:c6a6:beb2:a437  prefixlen 64  scopeid 0x0<global>
        inet6 fd83:e002:c8a1:0:587e:cf92:c6df:d3e7  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::25e0:bce6:c1f7:253e  prefixlen 64  scopeid 0x20<link>
        ether 20:47:47:bd:11:9a  txqueuelen 1000  (Ethernet)
        RX packets 20160  bytes 1988227 (1.9 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2255  bytes 326583 (326.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 2
        device interrupt 20  memory 0xf7200000-f7220000  

root@remus:~# ping ffuegw7.ffue
PING ffuegw7.ffue(ffuegw7.ffue (fd83:e002:c8a1::7)) 56 data bytes
64 bytes from ffuegw7.ffue (fd83:e002:c8a1::7): icmp_seq=1 ttl=64 time=39.4 ms
^C
--- ffuegw7.ffue ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 39.448/39.448/39.448/0.000 ms
root@remus:~# systemd-resolve --status 
Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test
[....]
Link 2 (eno1)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: fd83:e002:c8a1::1
                      fd83:e002:c8a1::3
                      fd83:e002:c8a1::6
                      fd83:e002:c8a1::2
                      fd83:e002:c8a1::5
                      fd83:e002:c8a1::4
                      fd83:e002:c8a1::7

Was weiter auffällig ist, dass auf der Statusseite des Offloaders keine Namen der Nachbarknoten angezeigt werden: http://[fd83:e002:c8a1:0:5054:ff:fe58:77b1]/
im Vergleich z.B. zu http://[fd83:e002:c8a1:0:fa1a:67ff:fe31:6a74]/

Ich bin leider ziemlicher Freifunk-Newbie und etwas ratlos. Ein paar Hinweise, was ich mal an meinem Offloader prüfen könnte, wären super-nett.

Danke vorab,

Martin

Moin,

ifconfig ist tot. Zeig mal bitte die Ausgabe von

ip a 

und

brctl show

sowie

batctl if

jeweils bis auf das letzte sowohl vom Gluon als auch vom Hypervisor.

Liebe Grüße
Matthias

bitte einmal ausgabe von

brtctl show 

und

batctl if

plus

ip a

Moin Leute, so endlich wieder zu Hause. Hier die Ausgaben als txt-Anhang:

LG, Martin

host.txt (5,6 KB)
gluon.txt (3,7 KB)

Edit: Ich habe auf dem Host mittels „brctl addif br-ff-client eth1“ einmal das Clientnetz auch auf auf das zweite Ethernet des Servers gelegt, um mögliche VLAN-Probleme auszuschließen. Ergebnis ist das gleiche, und der Traffic sieht mit tcpdump betrachtet gefühlt gleich aus wie auf dem Client-VLAN…

Das widerspricht deiner Ausgabe von brctl show auf dem Knoten. Dort ist eth1 (wie es normaler Weise immer ist) das WAN-Netz.

Du müsstest einfach nur die zweite Netzwerkkarte auf WAN schalten, statt die erste.

Hi Matthias, danke, du hast recht: Die Aussage selbst war falsch :lying_face:. Trotzdem müsste aber sonst alles passen:

  • Node-Client-Netz ist auf der Bridge br-client
  • Dieser Bridge ist Node-eth2 mit MAC 52:54:00:f8:37:c0 zugehörig
  • Node-eth2 entspricht wiederum vnet2 auf dem Hypervisor (mit gleicher MAC)
  • Und vnet2 ist wiederum Teil der Bridge br-ff-client auf dem Hypervisor, an dessen Interfaces ich den Möchtegern-Freifunkclient anstecke.

echo "Node:";echo; ssh root@ff-0 brctl show\; ip a show eth2\; ip a show eth0\; ip a show eth1;echo;echo Host:;echo; ip a show vnet2; ip a show vnet0; ip a show vnet1; brctl show

Node:

bridge name     bridge id               STP enabled     interfaces
br-client               7fff.5254005877b1       no              eth2
                                                        bat0
br-mesh_lan             7fff.6eee58d4c4fc       no              eth0
br-wan          7fff.6eee58d4c4f8       no              eth1
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-client state UP qlen 1000
    link/ether 52:54:00:f8:37:c0 brd ff:ff:ff:ff:ff:ff
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-mesh_lan state UP qlen 1000
    link/ether 52:54:00:e6:72:c5 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br-wan state UP qlen 1000
    link/ether 52:54:00:59:77:b1 brd ff:ff:ff:ff:ff:ff

Host:

13: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br-ff-client state UNKNOWN group default qlen 1000
    link/ether fe:54:00:f8:37:c0 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fef8:37c0/64 scope link 
       valid_lft forever preferred_lft forever
11: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br-ff-mesh state UNKNOWN group default qlen 1000
    link/ether fe:54:00:e6:72:c5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fee6:72c5/64 scope link 
       valid_lft forever preferred_lft forever
12: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:59:77:b1 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe59:77b1/64 scope link 
       valid_lft forever preferred_lft forever
bridge name     bridge id               STP enabled     interfaces
br-ff-client            8000.0cc47a92872e       no              eth0.11
                                                        eth1
                                                        vnet2
br-ff-mesh              8000.0cc47a92872e       no              eth0.10
                                                        vnet0
br0             8000.0022aabbccdd       no              eth0.1
                                                        netdev-apps
                                                        netdev-daten
                                                        netdev-extern
                                                        vnet1
                                                        vnet3

Edit:

Dass das vnet2 des Nodes tatsächlich der Host-Bridge br-ff-client richtig zugeordnet ist, sieht man - nicht wie ich oben geschrieben an der MAC-Adresse, die ist zwar ähnlich, aber nicht gleich - sondern an der Ausgabe von virsh dumpxml:

<interface type='bridge'>
  <mac address='52:54:00:f8:37:c0'/>
  <source bridge='br-ff-client'/>
  <target dev='vnet2'/>
  <model type='virtio'/>
  <alias name='net2'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
</interface>

Sieht von hier aus eigentlich gut aus.

Kannst du mal von einem Klienten aus dem Netz gucken, wie die Netzverbindung aussieht?

  • IPV4/V6 vergeben?
  • Standardroute?
  • DNS-Server?

Hallo Matthias, danke nochmal für das genaue Nachfragen, das einen selber nochmal zum besseren Nachdenken bringt.

Es funktioniert jetzt. :rofl:

Ursache für den Fehler war keine fehlerhafte Bridge-, VLAN- oder Gluon-Konfiguration sondern das Folgende:

Auf dem Host waren iptables-Regeln wirksam, die vollständiges Verbinden mit dem Client-Netz (insbesondere DHCP und DNS) verboten haben. ICMP jedoch funktionierte, weil ich echo request/reply immer durchlasse, daher die etwas merkwürdigen Symptome. Nachdem ich auf dem Client-Netz die FW aufgemacht habe, läuft es jetzt.

Danke an alle, die mitgedacht haben.

Viele Grüße,

Martin

Freut mich, dass es jetzt klappt :slight_smile: .