gluon icon indicating copy to clipboard operation
gluon copied to clipboard

Published 20 hours ago • verified publisher icon freifunk-gluon

Clarify or extend gluon-wan use case

Open yanosz opened this issue 4 years ago • 7 comments

Bug report

Given: (ifconfig)

br-wan    Link encap:Ethernet  HWaddr FE:04:6C:BF:7C:30  
          inet addr:192.168.23.123  Bcast:192.168.23.255  Mask:255.255.255.0
          inet6 addr: fe80::fc04:6cff:febf:7c30/64 Scope:Link
          inet6 addr: 2001:16b8:1ca7:fd00:fc04:6cff:febf:7c30/64 Scope:Global
          inet6 addr: fd95:a5b8:4a78:0:fc04:6cff:febf:7c30/64 Scope:Global
          inet6 addr: fd9f:3d52:a3dc:0:fc04:6cff:febf:7c30/64 Scope:Global
          inet6 addr: fd95:a5b8:4a78::f6b/128 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:125944 errors:0 dropped:0 overruns:0 frame:0
          TX packets:64169 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:21923638 (20.9 MiB)  TX bytes:13568471 (12.9 MiB)

br-client Link encap:Ethernet  HWaddr A0:F3:C1:74:91:BE  
          inet6 addr: fdd3:5d16:b5dd:1fc:a2f3:c1ff:fe74:91be/64 Scope:Global
          inet6 addr: fe80::a2f3:c1ff:fe74:91be/64 Scope:Link
          inet6 addr: 2a03:2260:11e:302:a2f3:c1ff:fe74:91be/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:37678 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25181 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3502134 (3.3 MiB)  TX bytes:3693472 (3.5 MiB)

Executing gluon-wan ssh www2.jluehr.de yields server-side: Dec 13 23:44:27 www2 sshd[13403]: Connection closed by authenticating user root 2a03:2260:11e:302:a2f3:c1ff:fe74:91be port 40644 [preauth] i.e. an address of br-client is used instead of br-wan.

System is v2020.2.2 - TP Link TL-WDR4300 v1, no custom patches

yanosz avatar Dec 13 '20 22:12 yanosz

maybe related to #1132 ? just guessing though

rotanid avatar Dec 14 '20 01:12 rotanid

Hmm, i don't see the issue here. gluon-wan only redirects DNS queries to the WAN DNS server and should not affect the routing decision.

The routing decision is based on a packet mark which is configured in the fastd config.

blocktrron avatar Dec 14 '20 02:12 blocktrron

Hmm... I don't remember gluon-wan to be a DNS only thing. Afair it is designed as a general wrapper to execute arbitrary commands using the gluon-mesh-vpn unix group. I had a discussion with @NeoRaider a few years ago on IRC, from which gluon-wan seemingly evolved, but I don't remember many details.

I don't know the packet marking process in detail. Afair it's possible to mark packets based on uid / gid using iptables and to apply to policy routing then ... but gluon firewalling somehow feels like a black box for me.

For me, it feels natural, either

  • To Implement policy routing based on the gid of a process
  • or to outline the DNS-specific case for gluon-wan by a proper documentation or even by renaming this tool to gluon-wan-dns.

yanosz avatar Dec 14 '20 08:12 yanosz

I've had a closer look on gluon-wan today. It's indeed only relevant for the DNS redirection to the wan dnsmasq. Thus closing here.

blocktrron avatar Dec 14 '20 12:12 blocktrron

Reopening as I believe we should clarify or extend the usage as requested in https://github.com/freifunk-gluon/gluon/issues/2160#issuecomment-744284482.

mweinelt avatar Dec 14 '20 14:12 mweinelt

A posible and easy fix would be to rename it to gluon-wan-dns.

lemoer avatar Dec 21 '20 21:12 lemoer

A posible and easy fix would be to rename it to gluon-wan-dns.

Besides proposing exactly this before: I think the better way is a change in iptables, to match al traffic from gid=gluon-mesh-vpn. However, I don't know why such a rule is not in place as of now, are there unwanted side-effects? (@NeoRaider)

yanosz avatar Dec 27 '20 10:12 yanosz