Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Tue Nov 19, 2019 22:31 Post subject: How-To: Routing DNSCrypt service through the OpenVPN client
Note: rather than have post after post with changes as the code and its description evolves, I am editing this original post and including a change log at the end. So this one post should give a reader a reasonably current picture.
The Startup script below is a DNS experiment to route DNSCrypt queries to one or more -- two in this example -- DNSCrypt servers through the OpenVPN client and so the VPN tunnel. Using this setup, my ISP can no longer tell I'm using DNSCrypt or Quad9 DNS or Adguard DNS, so I need not be concerned that they will throttle their DNS competition (which I've suspected with my ISP, actually). My VPN provider (AirVPN -- see how-to linked in my sig) can't see my DNS queries either, so though they say they don't log DNS queries and I believe them, I don't actually have to trust them on that point. And Quad9 can't see where my queries originate. They say they don't log more than rough location, but now they can't even see that, and even nicer, I don't have to trust them either. Similar for Adguard (which claims no logs at all). This approach seems great for the nontrusting among us!
For dd-wrt builds with an Encrypt DNS button in the DNSMasq part of the GUI, enabling that button actually provides a drop-down menu, but we do not enable that button with this approach. Everything is done in DNSMasq Additional Config and in the Startup code. With or without the button, however, the DNSCrypt-provider menu information is in dd-wrt in csv file /etc/dnscrypt/dnscrypt-resolvers.csv and can be used. In the code here I specify adguard-dns (https://adguard.com/en/adguard-dns/overview.html), which is the first provider in the menu, in this way. A DNSCrypt provider that is not in the menu can also be specified here by providing a shell function to call dnscrypt-proxy with custom parameters. Here this is illustrated using Quad9 DNS (https://quad9.net) as described at the Quad9 link in my sig.
Now if you are both using dd-wrt build 41174 or later and NOT using DNSCrypt, there is a far simpler way to route your DNS activity through the VPN -- see the next post by @egc -- but for users of DNSCrypt or earlier builds (I'm using this on 40009 and 40874), something along these lines appears for now to be the only way. I don't see any way to do this selectively only for the subnets in PBR, so all of the router's DNS needs, even on the non-PBR subnet I use for streaming, is going through the VPN when it is up. Subjectively, DNS response speed seems unaffected, but I haven't attempted careful measurements. This setup may actually confer some modest speed advantage in some cases, as CDNs near my primary DNS server will also likely be near my VPN exit node.
I have used the script for several weeks now (Dec 9, 2019 edit) as it has evolved, and it seems to be working well. Further, log entries look right, and dnsleaktest.com and ipleak.net report what I want to see. When DNS is supposed to be through the VPN, tcpdump -fi tun1 | grep -E '9\.9\.9\.9|176\.103\.130\.130' does indeed show lots of DNS activity (mostly to 9.9.9.9, as Adguard DNS at 176.103.130.130 is relegated to 2nd-place via a strict-order in my DNSMasq config). And when tun1 is replaced in that command with WAN interface eth0 (do ip r | awk '/^default/{print $NF}' in the CLI to identify your router's WAN interface), there is no output.
The most curious thing so far, and the reason the simpler method of the next post seems inapplicable to the DNSCrypt case, was that before I added the restarts of the dnscrypt-proxy processes, I found that while I had connectivity to the DNS servers, their response was stunningly slow. This observation has to fairly be regarded as tentative, and more experimentation with this would be appropriate. For now, though, I have tentatively concluded that the DNSCrypt DNS servers don't like one's IP changing (when the VPN connects and the routes are switched) once the DNSCrypt setups are up and running. Can't say I blame them. It does seem shifty! So for now the code restarts DNSCrypt each time the routing to the DNS servers is changed. If I force an OpenVPN restart (in my config it picks a new server) with killall -HUP openvpn (see the link in my sig), typically this script shifts DNSCrypt activity back to the WAN five or so seconds after the VPN goes down, and in another 25 or so seconds, DNSCrypt is running again through the new VPN server.
So here's how the code looks at this point. It goes in Startup but should be tested in the CLI first. First TUN is defined according to your system. On Linksys/Marvell WRT routers the VPN uses tun1, but on some routers tun0 is used instead. Browse your VPN log or do ifconfig | grep tun in the CLI to see which your router uses. Then functions are defined that obtain an IP address from a DNSCrypt menu entry and that start a dnscrypt-proxy process to proxy to a DNSCrypt server from the menu.
The next section -- five indented lines here -- is key to customizing the script for your purposes, as it's where specific DNSCrypt servers are selected. Here the first three lines show how to set up a DNSCrypt server that is NOT in the menu, in this case Quad9 DNS as DNSCrypt provider 1. To interpret what you see there or create a similar setup for a different provider, see the link in my sig. The next two lines show how to set up a DNSCrypt provider from the menu, in this case Adguard DNS as DNSCrypt provider 2. The menu selections are column 1 of the csv file /etc/dnscrypt/dnscrypt-resolvers.csv, with the other columns giving the parameters associated with that selection. All you need here is the column-1 name, which in the first line of the table used here, is adguard-dns. Using only one DNSCrypt server and using more than two will be discussed following the code below.
This code logs a fair bit to the system log, something I have found extremely helpful, so a logging function is defined next as is a DNSCrypt start/restart function. Because dd-wrt can run the startup code more than once, for example when Apply on certain GUI pages is used, zero-length file /tmp/root/DNSroutingStarted is then created to flag, for future examination, that the code loop has been started so that a rerun of Startup won't cause a second invocation of the part that matters, the loop. The needed dsncrypt-proxy processes are then started immediately, even though they will access the internet through the WAN at this point, so that OpenVPN will be able to resolve server names asap.
Then "(lots of code)" runs the main loop in a subshell, the process ID (pid) of which is logged in the last two lines of the script, both to the system log and, because that log only goes back a few hours (at least on my router), to file /tmp/DNSroutingStarted. The shell pid blah logged there can be used to terminate the script from the CLI if needed during debugging, with killblah.
The main action is in a subshell that defines several shell functions and runs a pair of nested while loops. The outer loop watches for the VPN client to go up, and the inner loop watches for any of several signs that things are not working as hoped: the DNSCrypt routes through the VPN are gone, the VPN gateway cannot be pinged, or none of the DNS servers can be pinged. The idea is that when the VPN goes up, DNSCrypt activity is routed through the VPN, and when the VPN goes down or things otherwise go awry, DNSCrypt activity is routed back through the WAN.
There is nothing special about the durations of the two sleeps that determine how often the tests are performed, but there is quite a bit of experimentation behind the values here. Generally I favor a shorter sleep while watching for the VPN to drop or things to go wrong, because if the VPN hangs and the DNS servers cannot be pinged, I want to move DNS back to the WAN ASAP so as not to inconvenience users. If the VPN connection has been broken and the tunnel taken down, the special routes actually disappear and leave DNS routed through the WAN by default, so that the explicit take-down of the VPN routes here do nothing. The outer loop gets a longer sleep to avoid fast cycling between using VPN and using WAN for DNS if the VPN is technically up but is inadequately responsive, i.e. if the VPN gateway can be pinged but the DNS servers cannot be. So far that has been of theoretical concern only; I have never observed it in my system log.
Here then is the actual code.
Code:
#DNSCrypt with routing through VPN possible. DNSMasq Additional
#Config "no-resolv", "server=127.0.0.X#30" for X=1,2,...,N for N resolvers.
( TUN=tun1
IPfromMenu(){ grep "^$1," /etc/dnscrypt/dnscrypt-resolvers.csv | cut -d, -f11 | cut -d: -f1; }
StartFromMenu(){ dnscrypt-proxy -d -S -a $1:30 -R $2 -L /etc/dnscrypt/dnscrypt-resolvers.csv; }
NAME1='Quad9 DNS'; IP1=9.9.9.9
Start1(){ dnscrypt-proxy -d -S -a 127.0.0.1:30 -r $IP1:8443 -N 2.dnscrypt-cert.quad9.net \
-k 67c8:47b8:c875:8cd1:2024:5543:be75:6746:df34:df1d:84c0:0b8c:4703:68df:821d:863e; }
NAME2='adguard-dns'; IP2=$(IPfromMenu $NAME2)
Start2(){ StartFromMenu 127.0.0.2 $NAME2; }
LogDNS(){ echo $1 | logger -t "DNS routing"; }
RestartDNS(){ killall dnscrypt-proxy; sleep 5; Start1; Start2; }
STARTED=/tmp/root/DNSroutingStarted; [[ -f $STARTED ]] && exit || touch $STARTED
RestartDNS
( ChgTable(){ ip r $1 $2 via $GW dev $TUN 2>/dev/null; }
RerouteAll(){ LogDNS "$2 (starting)"; ChgTable $1 $IP1; ChgTable $1 $IP2
ip r flush cache; RestartDNS; LogDNS "$2 (done)"; }
CanPing(){ { ping -c 1 -W 5 $1 || ping -c 1 -W 5 $1 ; } >& /dev/null; }
while sleep 20; do
if GW=$(ip r s table 10 | awk '{print $3;exit}') && CanPing $GW; then
RerouteAll add 'going to VPN'
VPNSTART=$(date +%s)
while sleep 10; do
if for IP in $IP1 $IP2; do ip r get $IP; done | grep -qv " $GW "
then LogDNS "VPN route(s) through DNS missing"; break
elif ! CanPing $GW; then LogDNS 'VPN-gateway ping failed'; break
elif CanPing $IP1; then :; #no-op
elif for IP in $IP2; do CanPing $IP && LogDNS "1st OK DNS ping: $IP" && break; done; then :;
else LogDNS "DNS-server ping(s) failed"; break
fi
done
VPNSTOP=$(date +%s)
RerouteAll del 'going to WAN'
XTRA=$((300-(VPNSTOP-VPNSTART)/2)) ; sleep $((XTRA*(XTRA>0)))
fi
done ) & \
MSG="shell pid $! managing routes for $IP1 ($NAME1) and $IP2 ($NAME2)"; \
LogDNS "$MSG"; echo "$MSG" >/tmp/DNSroutingMsg )
Just to be complete, note that to make this work as a complete DNSCrypt solution, you need to add this to the dnsmasq Additional Config in GUI>Services>Services:
Code:
no-resolv
server=127.0.0.2#30
server=127.0.0.1#30
By default, both servers will be used with dnsmasq deciding how to balance the load based on response times. You can enable Strict order on the dnsmasq page, however, and the server listed last will generally be used, and the one listed first will be used only rarely. Yes, the order is reversed from what logic would suggest!
To use fewer or more DNSCrypt providers, variables NAME2 and IP2 and function Start2() must be provided for each, with the number 2 changed appropriately. Start functions using StartFromMenu the way Start2 does here are straightforward, but remember to change X in IP 127.0.0.X to a unique value for each provider. Each 127.0.0.X used will need a corresponding server=... line in DNSMasq Additional Config. Then in the definition of RestartDNS, the Start1; Start2; at the end must be modified to include calls to the right number of start functions, each terminated with a semicolon. Similarly, in the definition of RerouteAll, the ChgTable $1 $IP1; ChgTable $1 $IP2 at the end will need more or fewer components, separated by semicolons. In the inner while loop, if for IP in $IP1 $IP2 will need more or fewer $IPX variables named. Then perhaps trickiest, the line beginning with elif for IP in $IP2 should have $IP2 replaced by a space-separated list if there are more than two DNSCrypt providers, for example to $IP2 $IP3 $IP4 for four providers, but the line should be eliminated entirely if there is only one DNSCrypt provider. Finally, it should be obvious at this point how to modify the final message MSG="shell pid $! managing routes for... as desired.
Change log:
(Mon Dec 30 16:10 UTC 2019) Added VPNSTART=..., VPNSTOP=..., and XTRA=... lines to measure unbroken time routes are through VPN, and if that time was under 10m, lessen thrashing by keeping routes through WAN longer before trying to reroute through VPN again. Also improved leading comment.
(Mon Dec 9 15:16 UTC 2019) No significant change in function. In inner loop used for loops for easier tweaking for more/fewer DNSCrypt providers. Tweaks: moved inner-loop sleep into while condition, set GW (formerly VPNGW) more efficiently, did routes-down test with one grep. Cleanup: some renaming, some functions eliminated, shorter/better error messages, STARTED file moved into /tmp/root.
(Sun Dec 8 19:34 UTC 2019) Changed the outer grouping chars { ;} to subshell parens ( ) so that running the script a second time and so triggering the STARTED=... test and its exit command won't crash the startup shell. Had those parens in originally and took them out later when I forgot why they were there! Nice example of the hazards of a saving space with a sparse-commenting style.
(Mon Dec 2 21:33 UTC 2019) Major reorganization, with no change in function, to simplify tailoring the code to other DNSCrypt providers or to use fewer or more DNSCrypt providers.
(Mon Nov 25 22:56 UTC 2019) Cleaned up tests for -- let us hope -- greater efficiency, using cut instead of awk, etc.
(Mon Nov 25 19:02 UTC 2019) Added an initial test in the inner loop to make sure the routes through the VPN were up. This is necessary because Apply on some GUI pages (Services>Services when dnsmasq config is changed, for example) will cause the routes to drop even though the VPN is still up and the DNS servers are pingable.
(Mon Nov 25 16:33 UTC 2019) Added the instrumented option for the inner loop and the menu-item specification of the second DNSCrypt server.
(Thu Nov 21 23:21 UTC 2019) Reorganized to shorten with functions. Replaced outer subshell with a group command. Lengthened ping wait time based on experiments. Set outer/inner sleeps to 20/10 sec.
(Thu Nov 21 14:49 UTC 2019) Lengthened the outer sleep delay for a five-minute worst-case cycle of routing DNS alternately through the VPN and the WAN when the VPN is up but nonresponsive. Side effect: At boot DNS will be through the WAN for for nearly five minutes before its initial routing through the VPN.
(Thu Nov 21 01:38 UTC 2019) Serious re-do: fixed test in inner loop, shortened pings, changed -w (not implemented in dd-wrt) to -W in ping, fixed undefined variable in first dnscrypt-proxy, added more syslog entries, logged loop shell pid for debugging, and made things more terse to save nvram.
(Wed Nov 20 15:20:30 UTC 2019) Cleaned up the writing a bit, esp to note simpler alternative when DNSCrypt is not used. The code is unchanged.
(Wed Nov 20 01:29:29 UTC 2019) Included the dnscrypt-proxy daemon starter and the initial start of the daemons.
(Wed Nov 20 00:43:48 UTC 2019) Added -force to the ip command in the VPNGW= material so that the ip will return a nonzero exit code when the table does not yet exist.
_________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Nov 20, 2019 13:30 Post subject:
egc wrote:
Nice work!
For user using build 41174 or later there is an even easier method just add this to the openVPN Additional config:
Code:
route 9.9.9.9 255.255.255.255 vpn_gateway
The VPN client will set a static route to route 9.9.9.9 via the VPN on startup and will delete the route when the VPN goes down.
For earlier builds your script is very useful.
Thanks
Yes, indeed, that's nice and clean! But how, in those new builds, would one get dnscrypt-proxy restarted when the DNS routing changes? Experiment shows that simply changing the route is not enough in the DNSCrypt case. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Wed Nov 20, 2019 15:29 Post subject:
SurprisedItWorks wrote:
egc wrote:
Nice work!
For user using build 41174 or later there is an even easier method just add this to the openVPN Additional config:
Code:
route 9.9.9.9 255.255.255.255 vpn_gateway
The VPN client will set a static route to route 9.9.9.9 via the VPN on startup and will delete the route when the VPN goes down.
For earlier builds your script is very useful.
Thanks
Yes, indeed, that's nice and clean! But how, in those new builds, would one get dnscrypt-proxy restarted when the DNS routing changes? Experiment shows that simply changing the route is not enough in the DNSCrypt case.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Nov 20, 2019 15:54 Post subject:
egc wrote:
SurprisedItWorks wrote:
egc wrote:
For user using build 41174 or later there is an even easier method just add this to the openVPN Additional config:
Code:
route 9.9.9.9 255.255.255.255 vpn_gateway
Yes, indeed, that's nice and clean! But how, in those new builds, would one get dnscrypt-proxy restarted when the DNS routing changes? Experiment shows that simply changing the route is not enough in the DNSCrypt case.
Interesting maybe this works after the VPN is up:
Code:
ip route flush cache
restart_f unbound
I haven't tried unbound. I gather it's a very capable alternative to dnsmasq for managing DNS (including DNS-over-HTTPS, DNS-over-TLS, and DNSCrypt, even the new DNSCrypt V2 if one is willing to set up entware) but one for which setting up a config requires more effort. My accumulating resource list for when I finally get around to sorting it out:
_________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Although DNScrypt-proxy v2 is claimed as more secure than v 1.95 i find it a slightly resource demanding...
and quite picky on settings...
DNS over TLS , Stubby is the most light and easy to set up solution it works out of the box even without editing of YAML settings file...
I haven't tried entware Unbound yet, but i read that its more sophisticated and sluggish, as well prone to fail....
my old attempts with ddwrt unbound via GUI ware no
good...
personally for me Stubby does the job and its light and fast...and you can run it on old routers with no harm...
At the end FFx has implemented a nice DoH solution via TRR...nothing needed to install and runs on layer 7 _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Nov 20, 2019 18:36 Post subject:
egc wrote:
Just out curiosity does it work with setting the routes in the OVPN client and then from CLI:
Code:
ip route flush cache
restart_f dnscrypt-proxy
With my old build I can't try anything useful in the ovpn client, but just out of curiosity trying the restart_f on its own, the process IDs of my two dnscrypt-proxy instances don't change, and more importantly, the system log does not show any refetching of certificates, which it seems to me would be the key sign of the sort of reinitialization that is needed. (I do see that DNS activity is going through the tunnel as before.) So I can't see any evidence that the restart_f did anything at all. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 18 Mar 2014 Posts: 12917 Location: Netherlands
Posted: Wed Nov 20, 2019 18:49 Post subject:
SurprisedItWorks wrote:
egc wrote:
Just out curiosity does it work with setting the routes in the OVPN client and then from CLI:
Code:
ip route flush cache
restart_f dnscrypt-proxy
With my old build I can't try anything useful in the ovpn client, but just out of curiosity trying the restart_f on its own, the process IDs of my two dnscrypt-proxy instances don't change, and more importantly, the system log does not show any refetching of certificates, which it seems to me would be the key sign of the sort of reinitialization that is needed. (I do see that DNS activity is going through the tunnel as before.) So I can't see any evidence that the restart_f did anything at all.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Nov 20, 2019 22:04 Post subject:
egc wrote:
...you can also try
restart dnscrypt-proxy
or
stopservice dnscrypt-proxy
startservice dnscrypt-proxy
Neither does anything, per the system log which should show both shutdown and restart with new certificate fetches. Also killall -HUP dnscrypt-proxy does nothing. It does look like (if my overburdened memory is recalling those experiments correctly) a plain killall dnscrypt-proxy does shut things down properly, per the system log.
On another note, for a time I flagged the code in the original post in red as a buggy work in progress, but appropriate code changes are in place now, and the warning has been edited out. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Sat Nov 23, 2019 19:23 Post subject:
Always use the code version the first post, as those appearing in these later discussions will not receive all the updates.
Here's how the instrumented version of the script above came to be. A few days experience with the uninstrumented version showed that occasionally it switched back to WAN and then immediately back to the VPN for no obvious reason, i.e. when the vpn connection was up and functioning. One day this was happening multiple times per hour. More typical was once or twice per day, but with it not happening at all on other days. Lengthening the ping wait (see the Change Log) seemed to help, but ultimately I decided to instrument the code so that a look at the system log would clarify what is happening. Quickly I learned that it was the ping of the tunnel gateway ($VPNGW) that typically failed, so I modified the code to replace the single pings with double pings, with success declared immediately if the first ping was successful. I have left the logging instrumention in for now. I also generalized a bit so that rather than have Adguard DNS hardwired, any selection from the DNSCrypt menu (if you have the Encrypt DNS button) or, and this is the same set of choices, the first field of the lines in DNSCrypt database file /etc/dnscrypt/dnscrypt-resolvers.csv can be used. I have specified adguard-dns-family in the code here.
Code:
#start DNS, route through vpn when up, else revert to wan
{ Q9="9.9.9.9"; MENU=adguard-dns-family
MENUIP=$(awk '{FS=","}$1~/^'"$MENU"'$/{print $11}' /etc/dnscrypt/dnscrypt-resolvers.csv \
| sed 's/:.*$//')
StartDNSCrypt(){
dnscrypt-proxy -d -S -a 127.0.0.1:30 \
-r $Q9:8443 -N 2.dnscrypt-cert.quad9.net -k \
67c8:47b8:c875:8cd1:2024:5543:be75:6746:df34:df1d:84c0:0b8c:4703:68df:821d:863e
dnscrypt-proxy -d -S -a 127.0.0.2:30 -R $MENU -L /etc/dnscrypt/dnscrypt-resolvers.csv; }
LogDNS(){ echo $1 | logger -t "startup DNS routing";}
STARTED=/tmp/DNSthruVPNcodeOn
[[ -f $STARTED ]] && exit || touch $STARTED
StartDNSCrypt
( ThruVPN(){ ip r $1 $2 via $VPNGW dev tun1 2>/dev/null; }
DNSthrough(){
LogDNS "$2 (starting)"
ThruVPN $1 $Q9; ThruVPN $1 $MENUIP
ip r flush cache
killall dnscrypt-proxy; sleep 5; StartDNSCrypt
LogDNS "$2 (done)"; }
Ping2(){ { ping -c 1 -W 5 $1 || ping -c 1 -W 5 $1; } >& /dev/null; }
FailedPing(){ LogDNS "failed ping of $1" ; break; }
while sleep 20; do
if VPNGW=$(ip r s table 10 | awk '/^default via /{print $3}') \
&& Ping2 $VPNGW; then
DNSthrough add VPN
#instrumented: while Ping2 $VPNGW && { Ping2 $Q9 || Ping2 $MENUIP; } do sleep 10; done
while :; do
if ! Ping2 $VPNGW
then FailedPing 'VPN gateway'
elif ! Ping2 $Q9; then
if ! Ping2 $MENUIP
then FailedPing "both Quad9 and $MENU"
else LogDNS "Quad9 but not $MENU"
fi
fi
sleep 10
done
DNSthrough del WAN
fi
done ) & LogDNS "shell pid $! managing routes for $Q9 and $MENUIP ($MENU)"; }
Looks like instrumentation and safety things like the lock file to keep it from running twice are doubling the length of this thing, and the lack of comments offends my programming instincts, but space is at a premium in Startup. (I also wish the bb's code construct actually used a fixed-width font like it's supposed to. It would sure make the indentation more useful.)
Edit: I've had this instrumented version running for several days now, and I'm finding I really, really like having the details in the log. The double ping has eliminated my false-alarm switches back to WAN, and when I do killall -HUP openvpn (see the link in my sig about restarting OpenVPN client) to restart the vpn connection, I see in the log that the ping of the vpn gateway fails as it should and triggers switching back to WAN. In truth there is no need to formally switch routes in the code in this particular situation, as when the vpn connection drops and tun1 is taken down, the extra entries in the routing table disappear automagically. But there is no harm in the code's then asking for those deletes, and the asking covers the case of failed ping of the DNS server with the tunnel still up. In any case, the vpn reconnect then triggers a quick move back to routing DNS through the vpn, just as it should. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Nov 25, 2019 16:59 Post subject:
Just a ping to flag that many changes have been made to the first post and to the post just above. I'm keeping the instrumentation in the code that documents in the system log the specific ping test that bumps the DNSCrypt routing back to the WAN, but I've provided more compact, less-instrumented alternative code in the first post as well. At this point the code seems solid enough for me to just go with for at least the medium term. It does what I want. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Mon Dec 02, 2019 21:58 Post subject:
This is just to flag for anyone eccentric enough to be following this that I have rewritten the first post and the code therein with the goal of making it easy to tailor the code to different DNSCrypt providers or to use fewer or more providers. There is no change to the functionality of the code. It works just as before. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 16 Nov 2015 Posts: 6447 Location: UK, London, just across the river..
Posted: Mon Dec 02, 2019 23:05 Post subject:
well, i had a believe the final word for DNS goes to DNSmasq (if you use it)...and than if you use
no-resolv and server= the DNS goes trough those selected in server= and trough the VPN tun...
just got a VPN and it its working with Stubby like that
out of the box no script was needed.....
Will experiment with DNScrypt-proxy2, but it suppose to be the same..i guess...I even have an old DNScrypt 1.95
on a spare R7800 to try it...via VPN too just for fun..
donno why so much hassle....you running that long script... _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55630 WAP
TP-Link WR1043NDv2 -DD-WRT 55723 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55779 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55819 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55779 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913