1 |
On Tuesday, 7 March 2023 18:11:01 GMT Dale wrote: |
2 |
> Michael wrote: |
3 |
> > On Sunday, 5 March 2023 18:41:10 GMT Dale wrote: |
4 |
> >> Howdy, |
5 |
> >> |
6 |
> >> I use Surfshark and every once in a while, my VPN loses its connection. |
7 |
> >> I sent the info from messages to Surfshark but the info they sent back |
8 |
> >> on how to set the nameserver info doesn't really work with Gentoo. I |
9 |
> >> suspect they are used to systemd stuff. Anyway, I tried to follow in a |
10 |
> >> more Gentoo way but it still didn't work. Then I googled, searched the |
11 |
> >> Gentoo wiki and tried some of those things, still refuses to use the |
12 |
> >> manually entered nameserver. I've tried resolv.conf, resolvconf.conf |
13 |
> >> and resolv.conf-tun0.sv. I installed openresolv to see if that would |
14 |
> >> help. Nope. |
15 |
> > |
16 |
> > AFAIR, you're meant to pull down from the openvpn server the DNS resolvers |
17 |
> > you're meant to use with their service, unless you have your own reasons |
18 |
> > for wanting to override these and set up your own DNS resolvers. Have |
19 |
> > you looked in /etc/openvpn/ for a suitable setting in the configuration |
20 |
> > file? I'm sure it will be set to automatically pull down the DNS |
21 |
> > resolvers and the Up script will set these up for your system when you |
22 |
> > start openvpn. |
23 |
> |
24 |
> This started because I changed to doing OS updates every other weekend. |
25 |
> That means two weeks of login, two weeks of the VPN being active etc |
26 |
> etc. When doing that, the VPN would lose connection after a good |
27 |
> while. Sometimes it would go the whole two weeks with no problems but |
28 |
> on occasion it would lose connection. |
29 |
|
30 |
When a connection goes down the openvpn client log would provide the reason |
31 |
for it. It makes sense to start from there any troubleshooting effort. The |
32 |
DNS resolvers used within the tunnel may be a symptom, rather than the cause. |
33 |
|
34 |
|
35 |
> I wrote a email to make them |
36 |
> aware to see if this is expected behavior, if I had bad settings or |
37 |
> something was wrong on their end. That's when I got the info in the |
38 |
> original post, to change DNS servers. I'm not sure what that has to do |
39 |
> with anything but . . . |
40 |
|
41 |
Heh! Same here, unless the server side logs indicated this was where the |
42 |
problem actually occurred with your connection. |
43 |
|
44 |
|
45 |
> You know how awful I am with scripts. Still, I read through the up |
46 |
> script and even to me, it looks like it is set up to get DNS servers |
47 |
> during the connection setup. This is the part I see. |
48 |
> |
49 |
> |
50 |
> elif [ "${opt}" != "${opt#dhcp-option DNS *}" ] ; then |
51 |
> NS="${NS}nameserver ${opt#dhcp-option DNS *}\n" |
52 |
> |
53 |
> |
54 |
> To me, it seems like it is getting the DNS info and putting it |
55 |
> somewhere. It appears that wherever it puts it, it is the only place it |
56 |
> looks because nothing I change changes where it goes for DNS info. To |
57 |
> be honest, I don't know why it should have to be changed. One would |
58 |
> think that the DNS info they send should work fine otherwise why set it |
59 |
> up that way. |
60 |
|
61 |
DNS resolvers will be added to your resolv.conf when the tunnel comes up. |
62 |
|
63 |
Instead of messing up with the scripts and hardcoding nameserver IP addresses, |
64 |
have you done any troubleshooting to find out what part of the connection goes |
65 |
down? Is the tunnel still up? Can you ping IP addresses through the tunnel? |
66 |
etc. |
67 |
|
68 |
|
69 |
> >> This is what I got from Surfshark: |
70 |
> >>> I would recommend changing the DNS addresses on your Linux device. You |
71 |
> >>> can simply do that by following the steps below. |
72 |
> >>> |
73 |
> >>> First, you need to open the terminal with the CTRL + ALT + T |
74 |
> >>> combination and type in the following commands: |
75 |
> >>> sudo rm -r /etc/resolv.conf |
76 |
> >>> sudo nano /etc/resolv.conf |
77 |
> > |
78 |
> > Normally, you would not have to do this manually. The Up script will |
79 |
> > enter |
80 |
> > the resolver IP addresses in your resolv.conf. If it doesn't, then check |
81 |
> > your configuration and your openvpn script. |
82 |
> |
83 |
> I tried to edit the openvpn.conf file to manually set the nameserver but |
84 |
> it puked on my keyboard and refused to even connect. I think we are |
85 |
> back to the server I connect to requires its info to be used and if it |
86 |
> isn't, it refuses to complete the connection. Everything I try results |
87 |
> in a error and connection refused. It could even be a security setting |
88 |
> that requires this. |
89 |
|
90 |
I recall the openvpn.conf has an entry to specify pulling down the DNS |
91 |
resolvers from the server as it is establishing the tunnel. Here's some |
92 |
troubleshooting to confirm if this is the problem, after you reset to defaults |
93 |
everything you interfered with in the openvpn.conf settings. |
94 |
|
95 |
|
96 |
> Either way, either this can't be changed and the VPN connect or there is |
97 |
> a setting somewhere that we are not aware of. I've googled, asked here |
98 |
> plus looked everywhere I can think of, even some places I couldn't |
99 |
> imagine having anything to do with it, and had no luck finding where it |
100 |
> stores the info or how to change it. |
101 |
> |
102 |
> Unless someone comes up with a idea, I'm fresh out. I have no clue what |
103 |
> to do. Hey, it does work almost all the time. It's not the end of the |
104 |
> world. |
105 |
> |
106 |
> Thanks. |
107 |
> |
108 |
> Dale |
109 |
> |
110 |
> :-) :-) |
111 |
> |
112 |
> P. S. Getting close to garden time. :-D |
113 |
|
114 |
I suggest you test for one thing at a time when the connection fails and start |
115 |
with the logs. Hardcoding the DNS resolver addresses may not be the problem |
116 |
you're facing here. |