On Tuesday, 7 March 2023 18:11:01 GMT Dale wrote: > Michael wrote: > > On Sunday, 5 March 2023 18:41:10 GMT Dale wrote: > >> Howdy, > >> > >> I use Surfshark and every once in a while, my VPN loses its connection. > >> I sent the info from messages to Surfshark but the info they sent back > >> on how to set the nameserver info doesn't really work with Gentoo. I > >> suspect they are used to systemd stuff. Anyway, I tried to follow in a > >> more Gentoo way but it still didn't work. Then I googled, searched the > >> Gentoo wiki and tried some of those things, still refuses to use the > >> manually entered nameserver. I've tried resolv.conf, resolvconf.conf > >> and resolv.conf-tun0.sv. I installed openresolv to see if that would > >> help. Nope. > > > > AFAIR, you're meant to pull down from the openvpn server the DNS resolvers > > you're meant to use with their service, unless you have your own reasons > > for wanting to override these and set up your own DNS resolvers. Have > > you looked in /etc/openvpn/ for a suitable setting in the configuration > > file? I'm sure it will be set to automatically pull down the DNS > > resolvers and the Up script will set these up for your system when you > > start openvpn. > > This started because I changed to doing OS updates every other weekend. > That means two weeks of login, two weeks of the VPN being active etc > etc. When doing that, the VPN would lose connection after a good > while. Sometimes it would go the whole two weeks with no problems but > on occasion it would lose connection.
When a connection goes down the openvpn client log would provide the reason
for it. It makes sense to start from there any troubleshooting effort. The
DNS resolvers used within the tunnel may be a symptom, rather than the cause.
> I wrote a email to make them
> aware to see if this is expected behavior, if I had bad settings or
> something was wrong on their end. That's when I got the info in the
> original post, to change DNS servers. I'm not sure what that has to do
> with anything but . . .
Heh! Same here, unless the server side logs indicated this was where the
problem actually occurred with your connection.
> You know how awful I am with scripts. Still, I read through the up
> script and even to me, it looks like it is set up to get DNS servers
> during the connection setup. This is the part I see.
>
>
> elif [ "${opt}" != "${opt#dhcp-option DNS *}" ] ; then
> NS="${NS}nameserver ${opt#dhcp-option DNS *}\n"
>
>
> To me, it seems like it is getting the DNS info and putting it
> somewhere. It appears that wherever it puts it, it is the only place it
> looks because nothing I change changes where it goes for DNS info. To
> be honest, I don't know why it should have to be changed. One would
> think that the DNS info they send should work fine otherwise why set it
> up that way.
DNS resolvers will be added to your resolv.conf when the tunnel comes up.
Instead of messing up with the scripts and hardcoding nameserver IP addresses,
have you done any troubleshooting to find out what part of the connection goes
down? Is the tunnel still up? Can you ping IP addresses through the tunnel?
etc.
> >> This is what I got from Surfshark:
> >>> I would recommend changing the DNS addresses on your Linux device. You
> >>> can simply do that by following the steps below.
> >>>
> >>> First, you need to open the terminal with the CTRL + ALT + T
> >>> combination and type in the following commands:
> >>> sudo rm -r /etc/resolv.conf
> >>> sudo nano /etc/resolv.conf
> >
> > Normally, you would not have to do this manually. The Up script will
> > enter
> > the resolver IP addresses in your resolv.conf. If it doesn't, then check
> > your configuration and your openvpn script.
>
> I tried to edit the openvpn.conf file to manually set the nameserver but
> it puked on my keyboard and refused to even connect. I think we are
> back to the server I connect to requires its info to be used and if it
> isn't, it refuses to complete the connection. Everything I try results
> in a error and connection refused. It could even be a security setting
> that requires this.
I recall the openvpn.conf has an entry to specify pulling down the DNS
resolvers from the server as it is establishing the tunnel. Here's some
troubleshooting to confirm if this is the problem, after you reset to defaults
everything you interfered with in the openvpn.conf settings.
> Either way, either this can't be changed and the VPN connect or there is
> a setting somewhere that we are not aware of. I've googled, asked here
> plus looked everywhere I can think of, even some places I couldn't
> imagine having anything to do with it, and had no luck finding where it
> stores the info or how to change it.
>
> Unless someone comes up with a idea, I'm fresh out. I have no clue what
> to do. Hey, it does work almost all the time. It's not the end of the
> world.
>
> Thanks.
>
> Dale
>
> :-) :-)
>
> P. S. Getting close to garden time. :-D
I suggest you test for one thing at a time when the connection fails and start
with the logs. Hardcoding the DNS resolver addresses may not be the problem
you're facing here.
signature.asc
Description: This is a digitally signed message part.
