Ability to manually set locally served and private networks

[BirkhoffLee]

Prerequisites

Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed

Problem Description

in internal/aghnet/subnetdetector.go#87, the LAN subnets are hardcoded. I have this use case where 100.64.0.0/10 is considered a private, secure network (Tailscale). For PTR questions from that network, Adguard Home simply restricts them (in internal/dnsforward/dns.go#327) and returns an NXDOMAIN. If I request with an IP within locServedNets, the PTR question is correctly handled.

Proposed Solution

locServedNets should be configurable in AdGuardHome.yaml as an array.

Alternatives Considered

There is no apparent alternatives.

Additional Information

None.

[ainar-g]

@ameshkov, I remember we've discussed this. This shouldn't be too hard to do in v0.107, considering the current code. What do you think?

[ameshkov]

Let's do it, but v0.107 kinda overloaded, let's plan it for a later milestone.

[EugeneOne1]

@BirkhoffLee, hello again. We've just pushed the latest edge build that implements the feature. Could you please install it and try to set up your own private networks? You may also read the description of the new private_networks field of configuration in the wiki. Note, that for extending the default set of networks you'll need to fill it with all the default networks first.

[jumpsmm7]

@EugeneOne1

Can you guys update documentation on how to better use this feature? After updating my edge version a few days after this was added, my client names are no longer in the client list. ( i am still able to resolve client names locally). They just are not registering to AdGuardHome statistics and logs.

So it looks like, the introduction of this feature also introduced an issue with AdGuardHome Statistics and query logging of client name. Reverse lookups works fine though. I can manually reverse look up perfectly fine with tools like dig/drill/ or nslookup. However, the AdGuardhome statistics and query logs do not properly display client names any more. They are not completing the ARP request and exchanging pertinent information necessary for the logs and statistics to properly display the client names.

[jumpsmm7]

@EugeneOne1

On both the stable, and beta versions, I am having no issue resolving client names to either query log or statistics. It appears that the only impacted version is the Edge version.

The only other pull request that I could immediately think that broke things was this pull request

#3597

It appears the GUI of AdGuardHome is not properly identifying the client names from the ARP request.

[EugeneOne1]

@jumpsmm7, hello and thanks for the remark. There is indeed a bug introduced. We'll fix it in the nearest future.

[jumpsmm7]

@EugeneOne1 , thank you for a timely response. And I completely understand. Awesome work with all the strides you all are taking thus far in regards to AdGuardHome. I will continue to test improvements as they progress.

[EugeneOne1]

@jumpsmm7, well, the latest build in the edge channel is ready to be tested. Could you please take a look at it? FYI, we've changed the runtime clients' sources priority, so AGH will now get a hostname from rDNS first.

[jumpsmm7]

@EugeneOne1 , it appears your changes have fixed the issue. Thank you for your efforts!

[jumpsmm7]

@EugeneOne1 I have made a discovery if you will humor me a bit longer. it is regarding the ARP discoveries.

[jumpsmm7]

@EugeneOne1 ,Some of the devices discovered under ARP, do have an RDNS associated as well.
Is there away this could be a joined feature as well. Maybe RDNS is not working hard enough and needs to be used after ARP is discovered as well.

[EugeneOne1]

@jumpsmm7, well, we're already have a couple of related issues (#1949, #3020). However, if I recall correctly, no one ever suggested to resolve clients recieved from ARP with rDNS. This may be useful since some implementations of ARP don't support hostnames.

@ameshkov, @ainar-g, what do you think?

[jumpsmm7]

@EugeneOne1 , i honestly think it will be useful as the /proc/net/arp on the AsusWRT routers does not appear to list hostnames.

/tmp/home/root# cat /proc/net/arp
IP address HW type Flags HW address Mask Device
192.168.1.133 0x1 0x2 74:e1:82:36:05:ef * br0
192.168.1.183 0x1 0x2 00:c3:f4:df:12:7e * br0
192.168.1.17 0x1 0x2 e4:5f:01:45:57:9d * br0
192.168.1.12 0x1 0x2 34:97:f6:70:16:50 * br0
192.168.1.208 0x1 0x2 10:59:32:6d:4d:39 * br0
192.168.1.217 0x1 0x2 98:41:5c:17:63:6c * br0
192.168.1.152 0x1 0x2 b8:8a:ec:82:f6:a7 * br0

Is a short example.

[jumpsmm7]

Here is also an example using arp -an

/tmp/home/root# arp -an
? (192.168.1.133) at 74:e1:82:36:05:ef [ether] on br0
? (192.168.1.183) at 00:c3:f4:df:12:7e [ether] on br0
? (192.168.1.17) at e4:5f:01:45:57:9d [ether] on br0
? (192.168.1.12) at 34:97:f6:70:16:50 [ether] on br0
##shortened for readability.##

[jumpsmm7]

@EugeneOne1 @ainar-g @ameshkov , If you decide to make this a feature request, I would be willing to contribute my time and resources to testing it for you.

[ainar-g]

@EugeneOne1, @jumpsmm7, I'm not against that, but I also don't think that we should do that in the v0.108 cycle, as we already have quite a lot of changes planned. If that's an enhancement that you would like to have, please write a separate issue about that, and we'll reexamine it once the v0.109 cycle starts.

[EugeneOne1]

@BirkhoffLee, we'll close the issue for now since it seems being resolved. Consider reopening it in case of problems occured with the implementation.