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


#1

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


#2

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


#3

bitte einmal ausgabe von

brtctl show 

und

batctl if

plus

ip a

#4

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…


#5

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.


#6

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>

#7

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?

#8

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


#9

Freut mich, dass es jetzt klappt :slight_smile: .