Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(VPN) cannot be resolved, possible DNS issues #70

Closed
soupdoup opened this Issue Aug 17, 2018 · 23 comments

Comments

Projects
None yet
7 participants
@soupdoup
Copy link

soupdoup commented Aug 17, 2018

running this and rtorrent on synology docker, both working fine for many months until last week when i started getting error -
[crit] australia-sydney-ca-version-2.expressnetw.com cannot be resolved, possible DNS issues

Same error on both deluge and rtorrent. I have tried differnt VPN servers and receive the same error.

NAME_SERVERS addresses from my provider (express) and have always worked. no other addresses. also doesnt work with google or no value.

Same issue when changing setting STRICT_PORT_FORWARD to no

Any help very much appreciated.

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Aug 17, 2018

I'm assuming that you are a Synology user if so then the problem is related to the command dig it looks like for some reason Synology boxes cannot run the latest dig command included in the container no fix other than to roll back to the previous tagged image

@oneMadRssn

This comment has been minimized.

Copy link

oneMadRssn commented Aug 25, 2018

EDIT: I have confirmed the tagged release "1.3.15+14+gb8e5ebe82-1-11" works fine. I don't know if one of the later ones might also work.

@binhex - I am not technically knowledgable enough to know what "dig" is or how to tell what your latest release is that doesn't use "dig." Can you assist?

For what it's worth - your container is quite popular among Synology users, so we all appreciate your work.

ORIGINAL:
Can you please elaborate on what you mean by "roll back to the previous tagged image"?

@wojo

This comment has been minimized.

Copy link

wojo commented Sep 9, 2018

Have the same issue on a Synology NAS, just noticed it and haven't had time to look at the issue, yet.

If it's a certain dig command line parameter, perhaps we can find another syntax that works?

@napcae

This comment has been minimized.

Copy link

napcae commented Oct 18, 2018

OS Debian GNU/Linux 8, running into the same problem. 1.3.15_14_gb8e5ebe82-1-10 works for me. I'd like to debug this with you to resolve this issue if possible.

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 18, 2018

@napcae ok sure, i would like to get this issue resolved one way or another. firstly can you tell me what kernel you are running, you should be able to find that out by issuing:-

uname -r

Can you also post the output of the following command (shows version info):-

cat /etc/os-release

i suspect you are running an earlier kernel and thus there is an incompatibility with the compiled version of dig and the kernel version (current theory as to why it affects synology users), just to be clear we are not talking about parameters for the dig command, this is a crash of the dig process.

i woud like to look into the crash some more, can you try running the following on your host once the container is running (assuming it stays up and running long enough):-

docker exec -it <container name> dig

im hoping you will see some output from that, preferably with the crash, hoping that might give me more of a clue as to whats going on (i cant currently replicate the crash).

also can you try executing drill to see if this also crashes:-

docker exec -it <container name> drill

@napcae

This comment has been minimized.

Copy link

napcae commented Oct 18, 2018

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 18, 2018

sorry you might of missed my edits, when you get a chance can you have a go at the other commands, but what you have posted gives me some info, so thanks.

@dcendents

This comment has been minimized.

Copy link

dcendents commented Oct 19, 2018

Hi,

I would also like to help, I run this on Synology:

uname -r

3.10.105

cat /etc/VERSION

majorversion="6"
minorversion="2"
productversion="6.2.1"
buildphase="GM"
buildnumber="23824"
smallfixnumber="0"
packing="iSCSI"
packing_id="1"
builddate="2018/09/07"
buildtime="17:03:43"

cat /proc/version

Linux version 3.10.105 (root@build3) (gcc version 4.9.3 20150311 (prerelease) (crosstool-NG 1.20.0) ) #23824 SMP Fri Sep 7 12:50:31 CST 2018

docker run --rm -it --entrypoint dig binhex/arch-delugevpn:1.3.15_14_gb8e5ebe82-1-15

random.c:102: fatal error: RUNTIME_CHECK(ret >= 0) failed

docker run --rm -it --entrypoint drill binhex/arch-delugevpn:1.3.15_14_gb8e5ebe82-1-15

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 39587
;; flags: qr rd ra ; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; .    IN      NS

;; ANSWER SECTION:
.       229646  IN      NS      k.root-servers.net.
.       229646  IN      NS      b.root-servers.net.
.       229646  IN      NS      m.root-servers.net.
.       229646  IN      NS      i.root-servers.net.
.       229646  IN      NS      g.root-servers.net.
.       229646  IN      NS      d.root-servers.net.
.       229646  IN      NS      l.root-servers.net.
.       229646  IN      NS      j.root-servers.net.
.       229646  IN      NS      a.root-servers.net.
.       229646  IN      NS      f.root-servers.net.
.       229646  IN      NS      c.root-servers.net.
.       229646  IN      NS      e.root-servers.net.
.       229646  IN      NS      h.root-servers.net.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 27 msec
;; SERVER: 64.145.73.2
;; WHEN: Fri Oct 19 02:06:42 2018
;; MSG SIZE  rcvd: 228

I hope this can help you, ask for more if you need me to run other commands

@napcae

This comment has been minimized.

Copy link

napcae commented Oct 19, 2018

cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

docker exec -it drill

root@twix /opt/torrent # docker run -it binhex/arch-delugevpn:latest drill
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3521
;; flags: qr rd ra ; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; .    IN      NS

;; ANSWER SECTION:
.       447045  IN      NS      l.root-servers.net.
.       447045  IN      NS      m.root-servers.net.
.       447045  IN      NS      a.root-servers.net.
.       447045  IN      NS      b.root-servers.net.
.       447045  IN      NS      c.root-servers.net.
.       447045  IN      NS      d.root-servers.net.
.       447045  IN      NS      e.root-servers.net.
.       447045  IN      NS      f.root-servers.net.
.       447045  IN      NS      g.root-servers.net.
.       447045  IN      NS      h.root-servers.net.
.       447045  IN      NS      i.root-servers.net.
.       447045  IN      NS      j.root-servers.net.
.       447045  IN      NS      k.root-servers.net.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 1 msec
;; SERVER: 213.133.100.100
;; WHEN: Fri Oct 19 08:27:29 2018
;; MSG SIZE  rcvd: 228

Also I'd like to mention that the container doesn't crash, deluge just won't come up, there is only a error message:

[crit] australia-sydney-ca-version-2.expressnetw.com cannot be resolved, possible DNS issues
@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 19, 2018

@napcae @dcendents thank you both, this is really useful info.

so the first interesting fact is that both of you are indeed running an earlier kernel (3.10/3.16)latest stable being 4.18.15 as this time, i dont see any issues on unraid (main platform i support and use myself) and this is probably due to the fact that unraid does indeed keep up with kernel releases, im not at my server right now so i cant tell you the exact version but i think its around 4.10.xx, and this matches with my current theory that the issue is related to earlier kernel versions running a later version of dig.

so onto what we can do to fix this, there are two options:-

  1. include a statically compiled earlier version of dig and use this instead - theory being if its an earlier version then it SHOULD be ok with the earlier kernel versions.
  2. use drill instead of dig - i need to check drll gives me everything i need, but this is quite a nice option.

i probably will start looking at drill as a replacement, as i can see from the above that drill does indeed work fine on both of your systems, if that gets too tricky to use then i will switch over to static dig.

@napcae

This comment has been minimized.

Copy link

napcae commented Oct 19, 2018

Cool beans, let me know if I can be helpful in some way.

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 19, 2018

ok progress on this, lots of regex trill and error required to get through drill's limitations but i got there :-), currently building the openvpn image first, i will let you know shortly how to test it.

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 19, 2018

so the image is now built, please can you guys test it, it has a tag name of "test", so pull down image using:-

docker pull binhex/arch-delugevpn:test

then create container as per normal making sure to reference the new image and tag name:-

docker run...binhex/arch-delugevpn:test

@napcae

This comment has been minimized.

Copy link

napcae commented Oct 19, 2018

It works now, although: /usr/lib/python2.7/site-packages/pkg_resources/__init__.py:1231: UserWarning: /home/nobody/.cache/Python-Eggs is writable by group/others and vulnerable to attack when used with get_resource_filename. Consider a more secure location (set with .set_extraction_path or the PYTHON_EGG_CACHE environment variable).

Thanks for the fix!

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 19, 2018

@napcae yeah thats a minor niggle regards permissions for python eggs, ive just put a fix in which im going to incorporate into the next build with tag latest.

@edsai

This comment has been minimized.

Copy link

edsai commented Oct 19, 2018

Did this get pushed to latest? watchtower updated the container about 1hr15min ago and it broke for me as well. Rolling back to 1.3.15_14_gb8e5ebe82-1-15 fixed it for me.

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 19, 2018

@edsai i need more details than this, can you please post your /config/supervisord.log file so i can see whats going on, please remove username and password before posting.

@edsai

This comment has been minimized.

Copy link

edsai commented Oct 19, 2018

I haven't changed the UID/GID yet but here's the logs from failed :latest.

018-10-19 11:22:44.406054 [info] System information Linux 51bc8f74218f 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 GNU/Linux
2018-10-19 11:22:44.438736 [info] PUID defined as '0'
2018-10-19 11:22:44.499878 [info] PGID defined as '0'
2018-10-19 11:22:44.547908 [info] UMASK defined as '000'
2018-10-19 11:22:44.582193 [info] Permissions already set for volume mappings
2018-10-19 11:22:44.621463 [info] VPN_ENABLED defined as 'yes'
2018-10-19 11:22:44.661668 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/DE Berlin.ovpn
dos2unix: converting file /config/openvpn/DE Berlin.ovpn to Unix format...
2018-10-19 11:22:44.716846 [info] VPN remote line defined as 'remote de-berlin.privateinternetaccess.com 1198'
2018-10-19 11:22:44.747231 [info] VPN_REMOTE defined as 'de-berlin.privateinternetaccess.com'
2018-10-19 11:22:44.783245 [info] VPN_PORT defined as '1198'
2018-10-19 11:22:44.820838 [info] VPN_PROTOCOL defined as 'udp'
2018-10-19 11:22:44.856771 [info] VPN_DEVICE_TYPE defined as 'tun0'
2018-10-19 11:22:44.886157 [info] VPN_PROV defined as 'pia'
2018-10-19 11:22:44.915752 [info] LAN_NETWORK defined as '192.168.1.0/24'
2018-10-19 11:22:44.947116 [info] NAME_SERVERS defined as '209.222.18.222,37.235.1.174,1.1.1.1,8.8.8.8,209.222.18.218,37'
2018-10-19 11:22:44.977994 [info] VPN_USER defined as ''
2018-10-19 11:22:45.004419 [info] VPN_PASS defined as ''
2018-10-19 11:22:45.031932 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2018-10-19 11:22:45.065388 [info] STRICT_PORT_FORWARD defined as 'yes'
2018-10-19 11:22:45.095250 [info] ENABLE_PRIVOXY defined as 'yes'
2018-10-19 11:22:45.146668 [info] Starting Supervisor...
2018-10-19 11:22:45,552 INFO Included extra file "/etc/supervisor/conf.d/delugevpn.conf" during parsing
2018-10-19 11:22:45,552 INFO Set uid to user 0 succeeded
2018-10-19 11:22:45,555 INFO supervisord started with pid 8
2018-10-19 11:22:46,557 INFO spawned: 'start-script' with pid 143
2018-10-19 11:22:46,557 INFO spawned: 'deluge-script' with pid 144
2018-10-19 11:22:46,558 INFO spawned: 'deluge-web-script' with pid 145
2018-10-19 11:22:46,559 INFO spawned: 'privoxy-script' with pid 146
2018-10-19 11:22:46,559 INFO reaped unknown pid 9
2018-10-19 11:22:46,564 DEBG 'start-script' stdout output:
[info] VPN is enabled, beginning configuration of VPN

2018-10-19 11:22:46,564 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2018-10-19 11:22:46,564 INFO success: deluge-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2018-10-19 11:22:46,564 INFO success: deluge-web-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2018-10-19 11:22:46,564 INFO success: privoxy-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2018-10-19 11:22:46,566 DEBG 'deluge-script' stdout output:
[info] Deluge config file already exists, skipping copy

2018-10-19 11:22:46,568 DEBG 'deluge-script' stdout output:
[info] VPN is enabled, checking VPN tunnel local ip is valid

2018-10-19 11:22:46,627 DEBG 'start-script' stdout output:
[info] Default route for container is 172.18.0.1

2018-10-19 11:22:46,633 DEBG 'start-script' stdout output:
[info] Adding 209.222.18.222 to /etc/resolv.conf

2018-10-19 11:22:46,636 DEBG 'start-script' stdout output:
[info] Adding 37.235.1.174 to /etc/resolv.conf

2018-10-19 11:22:46,643 DEBG 'start-script' stdout output:
[info] Adding 1.1.1.1 to /etc/resolv.conf

2018-10-19 11:22:46,649 DEBG 'start-script' stdout output:
[info] Adding 8.8.8.8 to /etc/resolv.conf

2018-10-19 11:22:46,653 DEBG 'start-script' stdout output:
[info] Adding 209.222.18.218 to /etc/resolv.conf

2018-10-19 11:22:46,661 DEBG 'start-script' stdout output:
[info] Adding 37 to /etc/resolv.conf

2018-10-19 11:22:46,670 DEBG 'start-script' stderr output:
Warning: Could not create a resolver structure: Syntax error, could not parse the RR ((null))
Try drill @localhost if you have a resolver running on your machine.

2018-10-19 11:22:46,674 DEBG 'start-script' stdout output:
[crit] de-berlin.privateinternetaccess.com cannot be resolved, possible DNS issues

2018-10-19 11:22:46,674 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 139676000737544 for <Subprocess at 139676000737832 with name start-script in state RUNNING> (stdout)>
2018-10-19 11:22:46,674 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 139676000736752 for <Subprocess at 139676000737832 with name start-script in state RUNNING> (stderr)>
2018-10-19 11:22:46,674 INFO exited: start-script (exit status 1; not expected)
2018-10-19 11:22:46,674 DEBG received SIGCLD indicating a child quit
2018-10-19 11:30:34,710 WARN received SIGTERM indicating exit request
2018-10-19 11:30:34,710 DEBG killing privoxy-script (pid 146) with signal SIGTERM
2018-10-19 11:30:34,710 INFO waiting for deluge-script, deluge-web-script, privoxy-script to die
2018-10-19 11:30:34,711 DEBG fd 26 closed, stopped monitoring <POutputDispatcher at 139676000709088 for <Subprocess at 139676000736320 with name privoxy-script in state STOPPING> (stderr)>
2018-10-19 11:30:34,711 DEBG fd 22 closed, stopped monitoring <POutputDispatcher at 139676000708440 for <Subprocess at 139676000736320 with name privoxy-script in state STOPPING> (stdout)>
2018-10-19 11:30:34,711 INFO stopped: privoxy-script (terminated by SIGTERM)
2018-10-19 11:30:34,711 DEBG received SIGCLD indicating a child quit
2018-10-19 11:30:34,712 DEBG killing deluge-web-script (pid 145) with signal SIGTERM
2018-10-19 11:30:34,712 DEBG fd 17 closed, stopped monitoring <POutputDispatcher at 139676000360640 for <Subprocess at 139676000295320 with name deluge-web-script in state STOPPING> (stdout)>
2018-10-19 11:30:34,712 DEBG fd 21 closed, stopped monitoring <POutputDispatcher at 139676000709304 for <Subprocess at 139676000295320 with name deluge-web-script in state STOPPING> (stderr)>
2018-10-19 11:30:34,712 INFO stopped: deluge-web-script (terminated by SIGTERM)
2018-10-19 11:30:34,712 DEBG received SIGCLD indicating a child quit
2018-10-19 11:30:34,713 DEBG killing deluge-script (pid 144) with signal SIGTERM
2018-10-19 11:30:34,713 DEBG fd 16 closed, stopped monitoring <POutputDispatcher at 139676000361720 for <Subprocess at 139676001383920 with name deluge-script in state STOPPING> (stderr)>
2018-10-19 11:30:34,713 DEBG fd 11 closed, stopped monitoring <POutputDispatcher at 139676001409432 for <Subprocess at 139676001383920 with name deluge-script in state STOPPING> (stdout)>
2018-10-19 11:30:34,713 INFO stopped: deluge-script (terminated by SIGTERM)
2018-10-19 11:30:34,713 DEBG received SIGCLD indicating a child quit

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 19, 2018

Your issue is a badly configured name_servers env var, you have a rogue '37' at the end of your list of name servers, that is not a valid ip

@edsai

This comment has been minimized.

Copy link

edsai commented Oct 19, 2018

Lol. I do. I thought that it had to do with the update and that the DNS list was being fed from somewhere else. I'm not sure how that got inserted into the docker-compose and it was misleading that everything started reverting when I tagged the older branch. latest is working now. Thanks!

@binhex

This comment has been minimized.

Copy link
Owner

binhex commented Oct 19, 2018

Closing issue as I think this one is finally put to bed, nice!

@binhex binhex closed this Oct 19, 2018

@dcendents

This comment has been minimized.

Copy link

dcendents commented Oct 20, 2018

Thanks I can confirm it works for me as well

@wojo

This comment has been minimized.

Copy link

wojo commented Oct 20, 2018

Verified working on Synology Docker 17.05.0-0394 and DSM 6.2.1-23824.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.