15.5, wireguard, resolve-dns.sh script not available? not needed anymore?
Support, a very simple 15.5 with wireguard, dynamic chaning public ipv4 addresses as endpoint hostname:port i am rather new to this, yet I am not aware if this script for tackling this situation
<https://github.com/WireGuard/wireguard-tools/blob/master/contrib/reresolve-dns/reresolve-dns.sh>
is still part of the whole deal, as the wireguard-tools package rpm, does not list this file as its content on leap 15.5 is this deprecated? as maybe
hints? or whatever that state there means? I have just set up my wireguard with two peers total, so I will see within the next hours or days or so if this tunnel survives dns (ip) changes of the public ipv4 address (endpoint) and how this works. any experience with this on opensuse current versions? ----------- rpm -qi wireguard-tools --filesbypkg .... wireguard-tools /etc/wireguard wireguard-tools /usr/bin/wg wireguard-tools /usr/bin/wg-quick wireguard-tools /usr/lib/systemd/system/wg-quick.target wireguard-tools /usr/lib/systemd/system/wg-quick@.service wireguard-tools /usr/share/bash-completion/completions/wg wireguard-tools /usr/share/bash-completion/completions/wg-quick wireguard-tools /usr/share/doc/packages/wireguard-tools wireguard-tools /usr/share/doc/packages/wireguard-tools/README.md wireguard-tools /usr/share/licenses/wireguard-tools wireguard-tools /usr/share/licenses/wireguard-tools/COPYING wireguard-tools /usr/share/man/man8/wg-quick.8.gz wireguard-tools /usr/share/man/man8/wg.8.gz ------------- ty
Hi, as far as I remember reresolve-dns.sh was never part of the rpm. If you use the "PersistentKeepAlive" option, your tunnel should survive. If both IPs change simultaneously, then you need the re-resolve-script, I guess. HTH, Christof On Thursday, 4 January 2024 23:48:57 CET cagsm wrote:
Support,
a very simple 15.5 with wireguard, dynamic chaning public ipv4 addresses as endpoint hostname:port
i am rather new to this, yet I am not aware if this script for tackling this situation
<https://github.com/WireGuard/wireguard-tools/blob/master/contrib/reresolve-dns/reresolve-dns.sh>
is still part of the whole deal, as the wireguard-tools package rpm, does not list this file as its content on leap 15.5
is this deprecated? as maybe
hints? or whatever that state there means?
I have just set up my wireguard with two peers total, so I will see within the next hours or days or so if this tunnel survives dns (ip) changes of the public ipv4 address (endpoint)
and how this works.
any experience with this on opensuse current versions?
----------- rpm -qi wireguard-tools --filesbypkg .... wireguard-tools /etc/wireguard wireguard-tools /usr/bin/wg wireguard-tools /usr/bin/wg-quick wireguard-tools /usr/lib/systemd/system/wg-quick.target wireguard-tools /usr/lib/systemd/system/wg-quick@.service wireguard-tools /usr/share/bash-completion/completions/wg wireguard-tools /usr/share/bash-completion/completions/wg-quick wireguard-tools /usr/share/doc/packages/wireguard-tools wireguard-tools /usr/share/doc/packages/wireguard-tools/README.md wireguard-tools /usr/share/licenses/wireguard-tools wireguard-tools /usr/share/licenses/wireguard-tools/COPYING wireguard-tools /usr/share/man/man8/wg-quick.8.gz wireguard-tools /usr/share/man/man8/wg.8.gz -------------
ty
On Fri, Jan 5, 2024 at 10:45 AM Christof Hanke <christof.hanke@mpcdf.mpg.de> wrote:
as far as I remember reresolve-dns.sh was never part of the rpm. If you use the "PersistentKeepAlive" option, your tunnel should survive. If both IPs change simultaneously, then you need the re-resolve-script, I guess.
i checked the tunnel today and no traffic was passing through. I also checked the router logs when the broadbad on both sides has possibly changed its addresses, and it was like an hour or so apart, so it should have survived by re-establishing the still known valid side from one side or the other whichever side one would look into it from? too bad it didnt though or I have yet to understand how wg sets up the endpoint stuff exactly? my wg0.conf files has endpoint hostnames (dynamic dns provider) on both sides. a ddclient service (systemd) run on both ends, both leap 15.5 that gets updated to the newly changed public ipv4 within 5minutes or so upon ipv4 change. the tunnel still wasnt valid and working any more until I wg-quick down wg0 and wg-quick up wg0 on both sides of the tunnel, on both leap 15.5 machines. I somewhere once? read that the wg scripts and what not resolve the endpoint hostname exactly once into a then-valid ip address and use that as the actual config and network layer or so. But does it not update or amend or modify the actual ip address into the more-current ip address due to the flow of proper and security-authenticated packets still coming in from the still unchanged side of the wg tunnel? that was my understanding from consulting some discussions or documentations and theory in the past. apparently something is more complex or it doesnt actually work this way? i wish it would be simpler. I have not yet made use of systemd to create a service? for the wg0 stuff on both sides, I only use wg-quick just yet. how would I then use this script? also from yet another systemd service to be running it from? or via some simpler crontab or something? thanks for all the input and hints. ty
On Fri, Jan 5, 2024 at 10:45 AM Christof Hanke <christof.hanke@mpcdf.mpg.de> wrote:
as far as I remember reresolve-dns.sh was never part of the rpm.
I wonder why this script never made it into wireguard release inside opensuse distro? is the contrib dir, and scripts being talked about for years and very early on in the original source project itself, not actually good stuff to include in the rpm ? if i am not wrong, other linux distros do have this script (and others?) in their wireguard release. anyhow where would i put that script on an opensuse leap 15.5 actually to be able to run it as a service similar to this page mentioning the whole proceedings:
<https://techoverflow.net/2021/08/19/how-to-automatically-re-resolve-dns-in-wireguard-on-linux/>
/usr/share/doc/wireguard-tools/..... seems not to be the right place on a leap, there is /usr/share/doc/packages/wireguard-tools/ ... but there is only the readme where does the script go to not mess up directories belonging to other native opensuse packages etc ty.
On Tue, Jan 9, 2024 at 6:23 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
It does not matter as long as you use the full pathname to this script in the service definition.
thank you for your hints and advice. the vpn seems stable now have also lowered the persistent keepalive setting to 5 seconds, that keeps the connection stable. now I am trying to connect two networks site to site situation, but something about the routes stuff, is still not set up, and yast system settings about networking and route and its gui is confusing to me i have not yet come to terms with ty
On Wed, Jan 10, 2024 at 11:01 AM cagsm <cumandgets0mem00f@gmail.com> wrote:
now I am trying to connect two networks site to site situation, but something about the routes stuff, is still not set up, and yast system settings about networking and route and its gui is confusing to me i have not yet come to terms with
learning the hard way or noob but progressing a bit every now and then, I figured, yast2 firewall stuff needs to assign a zone of type "trusted" to the wg0 interface on both site locations (on opensuse leap 15.5 boxes on both sides) otherwise it would pass some ping but no tcp connect. now I can connect from one side to the other so far, e.g. surfing a local printer webinterface (tcp/80) on the e.g. right side. the right side network has the leap 15.5 box there as default gateway so I guess that is a simple stuff. so far so good. i can not access the left side network from the right side though, except for pings so far, traceroutes, unfortunately the suse 15.5 box on the left side is not the default gatway there, but the actual default gateway on the left side LAN has the route (to the right side LAN network) set and pointing to the suse 15.5 box on the left side place. will see if I can deduct more from this current situation. ty.
On Wed, Jan 10, 2024 at 7:23 PM cagsm <cumandgets0mem00f@gmail.com> wrote:
i can not access the left side network from the right side though, except for pings so far, traceroutes, unfortunately the suse 15.5 box on the left side is not the default gatway there, but the actual default gateway on the left side LAN has the route (to the right side LAN network) set and pointing to the suse 15.5 box on the left side place.
fortunately i am apparently not that of a noob, i seem to know some networking stuff after all. after contacting the admin of the default gateway router on the left side network, only a few traffic rules (allowing) were needed, my part of the situation, the wireguard tunnel itself etc were already nicely set up, and now accessing from the right side network to the left also works just fine. thanks for all the input.
On Tue, Jan 9, 2024 at 6:23 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
It does not matter as long as you use the full pathname to this script in the service definition.
revisiting this issue, trying to really actually run such a reresolve sh script (bash), but i dont see the endpoint actually being updates through a call of the wg tool. I have checked by shutting down the wg service on the distant side of my situation here (having two places connecting each other via wg) and dynamicdns hostnames (fully qualified domain name in endpoint) i observe the dyndns hostname changing after re-triggering the internet connection on the distant side, updating. but sudo wg show still shows the old dynamic dns ip address on the endpoint output even after many minutes and after an hour still. i would like to debug this situation to detect whats really going on, also I even asked chatgpt (i am a noob :( ) to explain me exactly where and what statement in that bash file does the actual lookup for the domain name, as I find it hard to understand. chatgpt only hallucinates? about awk and host -t ... and getent ahosts host..... but I dont find all these expressions in this bash file from the contrib/reresolve of the wireguard project. unfortunately opensuse doesnt come with this pretty essential? contribution script to make this work for dynamically changing ip addresses on hostnames for endpoints. so: took this as raw:
<https://github.com/WireGuard/wireguard-tools/blob/master/contrib/reresolve-dns/reresolve-dns.sh>
put this into e.g.
/usr/local/bin/share/doc/wireguard-tools/examples/reresolve-dns/
as a file, added root users executable flag (chmod) and acted accordingly to
<https://techoverflow.net/2021/08/19/how-to-automatically-re-resolve-dns-in-wireguard-on-linux/>
the manual way.... I have the .timer file and the .service file put into place
/etc/systemd/system/wg-reresolve-dns@.timer /etc/systemd/system/wg-reresolve-dns@.service
the timer becomes active I can check its state and it calls reguarily the .service file and it seems okay, journalctl shows entries (a lot) for the .timer and for the .service the config file for wireguard is wg0.conf all right in /etc/wireguard/ everything seems simple How would I debug this stuff to actually see how this wg set line gets called and what content of the hostname gets set?
https://github.com/WireGuard/wireguard-tools/blob/13f4ac4cb74b5a833fa7f825ba...
and more importantly I would like to understand where and how that bash script? or what part does actually resolve the dns name of my changing dyndns stuff any hints on how to narrow this? thank you so much for making me learn. would gladly have this contrib script in the official wireguard of opensuse leap? thanks!
On Fri, Apr 12, 2024 at 11:27 AM cagsm <cumandgets0mem00f@gmail.com> wrote:
How would I debug this stuff to actually see how this wg set line gets called and what content of the hostname gets set?
You can always add set -x at the top and get a complete execution trace.
https://github.com/WireGuard/wireguard-tools/blob/13f4ac4cb74b5a833fa7f825ba...
and more importantly I would like to understand where and how that bash script? or what part does actually resolve the dns name of my changing dyndns stuff
It does not. "wg set ... endpoint $ENDPONT" does DNS lookup on the $ENDPOINT value. Did you check what address ping your.dns.name is using? Does it change when your address changes? Does it match what you see in "wg show" output?
On Fri, Apr 12, 2024 at 10:55 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
You can always add set -x at the top and get a complete execution trace.
in the bash script?
https://github.com/WireGuard/wireguard-tools/blob/13f4ac4cb74b5a833fa7f825ba... and more importantly I would like to understand where and how that bash script? or what part does actually resolve the dns name of my changing dyndns stuff It does not. "wg set ... endpoint $ENDPONT" does DNS lookup on the $ENDPOINT value. Did you check what address
okay so that actual line with the variable $ENDPOINT then takes my dyndns hostname from the wg0.conf file and does then at the moment of that call do a dns lookup and thus then takes the then-current value and sets it as endpoint, right?
ping your.dns.name is using? Does it change when your address changes? Does it match what you see in "wg show" output?
no it doesnt match, as I have stated. I am logged into the one machine (opensuse, ssh) and i check there. the commands e.g. host and nslookup my-dyndns-hostname eventually changes within a few minutes after the machine on the far side has reestablished into the internet and updates (ddclient) the hostname. so the essential basic steps are all in place. I can also reach both places via ssh and their then current ip addresses obviously. these fundamental steps are working. my trouble is that wg show on the one machine that is left running (I shut down the wg device on the other machine intentionally so that no wg packets cause a re-establishing of the wg tunnel) "forever" shows the old address in wg show, the old address of the other distant side, the old ip address of the dyndns hostname of the distant side, even though at the same time a resolve on the ssh/bash/terminal already shows that it can and does resolve the updated dyndns hostname properly and that this ip address has changed etc. I like waited for an hour in this situation just to be patient. then i issued a systemctl restart wg-quick@wg0.service (or so) and it immediately updates the resolved hostname in the endpoint (wg show) to the proper current updated dyndns hostname of the far side. no actual connection will be established, as I have stated above, I did shut down the far side (other machine) wg tunnel. when I then restart the wg service on the far side machine as well, the whole tunnel comes alive. thats how I try to diagnose and narrow things down. i want to get this re-resolve stuff working. apparently somethings amiss here on opensuse leap 15.5 thanks for helping.
On Fri, Apr 12, 2024 at 1:50 PM cagsm <cumandgets0mem00f@gmail.com> wrote:
On Fri, Apr 12, 2024 at 10:55 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
You can always add set -x at the top and get a complete execution trace.
in the bash script?
Yes. Or simply run it as bash -x reresolve-dns.sh
https://github.com/WireGuard/wireguard-tools/blob/13f4ac4cb74b5a833fa7f825ba... and more importantly I would like to understand where and how that bash script? or what part does actually resolve the dns name of my changing dyndns stuff It does not. "wg set ... endpoint $ENDPONT" does DNS lookup on the $ENDPOINT value. Did you check what address
okay so that actual line with the variable $ENDPOINT then takes my dyndns hostname from the wg0.conf file and does then at the moment of that call do a dns lookup and thus then takes the then-current value and sets it as endpoint, right?
Yes.
ping your.dns.name is using? Does it change when your address changes? Does it match what you see in "wg show" output?
no it doesnt match, as I have stated.
Well, run bash -x reresolve-dns.sh ping your.dns.name and post output. Obfuscate wg keys if you like.
On Fri, Apr 12, 2024 at 1:50 PM cagsm <cumandgets0mem00f@gmail.com> wrote:
fundamental steps are working. my trouble is that wg show on the one machine that is left running (I shut down the wg device on the other machine intentionally so that no wg packets cause a re-establishing of the wg tunnel) "forever" shows the old address in wg show,
Was this tunnel ever active? Post wg show wg show latest-handshake
On Fri, Apr 12, 2024 at 2:15 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Apr 12, 2024 at 1:50 PM cagsm <cumandgets0mem00f@gmail.com> wrote:
fundamental steps are working. my trouble is that wg show on the one machine that is left running (I shut down the wg device on the other machine intentionally so that no wg packets cause a re-establishing of the wg tunnel) "forever" shows the old address in wg show,
Was this tunnel ever active? Post
wg show wg show latest-handshake
Scratch it. The script is using $EPOCHSECONDS and it is not defined in Leap 15.5 bash. Use $(date +%s) instead
On Fri, Apr 12, 2024 at 1:19 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Apr 12, 2024 at 2:15 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Apr 12, 2024 at 1:50 PM cagsm <cumandgets0mem00f@gmail.com> wrote:
fundamental steps are working. my trouble is that wg show on the one machine that is left running (I shut down the wg device on the other machine intentionally so that no wg packets cause a re-establishing of the wg tunnel) "forever" shows the old address in wg show, Was this tunnel ever active? Post
yes the tunnel as is works fine. I just want to make it more robust in case both sides both parties on their ISPs go down similarly to each other and fail to have current dyndns hostnames just yet before being able to continue receiving packets from the other side (and sending into nirvana) when both sides change ip addresses close in time.
wg show wg show latest-handshake Scratch it. The script is using $EPOCHSECONDS and it is not defined in Leap 15.5 bash. Use $(date +%s) instead
I guess i copied the most current version of that script as far as I have seen there is also a mention about epoch commit stuff at
<https://git.zx2c4.com/wireguard-tools/log/?qt=grep&q=epoch>
they did have you variation in that script before:
<https://git.zx2c4.com/wireguard-tools/commit/?id=1fd95708391088742c139010cc6b821add941dec>
thanks a great deal. will try if this brings any progress. ty.
On Fri, Apr 12, 2024 at 1:25 PM cagsm <cumandgets0mem00f@gmail.com> wrote:
On Fri, Apr 12, 2024 at 1:19 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Apr 12, 2024 at 2:15 PM Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Apr 12, 2024 at 1:50 PM cagsm <cumandgets0mem00f@gmail.com> wrote:
fundamental steps are working. my trouble is that wg show on the one machine that is left running (I shut down the wg device on the other machine intentionally so that no wg packets cause a re-establishing of the wg tunnel) "forever" shows the old address in wg show, Was this tunnel ever active? Post
yes the tunnel as is works fine. I just want to make it more robust in case both sides both parties on their ISPs go down similarly to each other and fail to have current dyndns hostnames just yet before being able to continue receiving packets from the other side (and sending into nirvana) when both sides change ip addresses close in time.
wg show wg show latest-handshake Scratch it. The script is using $EPOCHSECONDS and it is not defined in Leap 15.5 bash. Use $(date +%s) instead
I guess i copied the most current version of that script as far as I have seen there is also a mention about epoch commit stuff at
<https://git.zx2c4.com/wireguard-tools/log/?qt=grep&q=epoch>
they did have you variation in that script before:
<https://git.zx2c4.com/wireguard-tools/commit/?id=1fd95708391088742c139010cc6b821add941dec>
thanks a great deal. will try if this brings any progress. ty.
thanks I just verified with your helps changed bash file (remove epochseconds stuff) and shut down the wg0 device on the remote machine2 and re-triggered a re-dial into the broadband provider with an ip change also updating the dynamicdns hostname of that machine. within a few minutes the other machine, whose wg0 device and service is still running, how also displays the new ip address in wg show for the endpoint address being resolved and printed and set to this new ip address. so I guess everything regarding this matter is fine now. many thanks really much to you. ty! if anyone cares, please package this dns-reresolve bash script for the wireguard package as well it seems pretty basic and somewhat? essential. thanks.
participants (3)
-
Andrei Borzenkov -
cagsm -
Christof Hanke