Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse

Cloudron Forum

Apps | Demo | Docs | Install

"Special" treatment of port 53 does not work in all cases

Scheduled Pinned Locked Moved Solved Support
6 Posts 2 Posters 308 Views
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    Robin
    wrote on last edited by
    #1

    I tried installing AdGuard Home to give it a try. However, I noticed that I wasn't getting any responses to DNS queries I was throwing at the Cloudron machine. I connected in through ssh, and checked netstat -anlp, and saw that port 53 was only bound on one of the two interfaces that machine has.

    I went digging, and found that src/docker.js treats port 53 in a special manner (see getLowerUpIp). This doesn't work for my specific case, where I have two interfaces, and one of those interfaces is for a special internal-only purpose and doesn't really have any external network access.

    I'm not sure how this could best be resolved. I guess the easy solution might be to bind to all external interfaces, rather than just the first?

    girishG 2 Replies Last reply
    0
  • girishG Offline
    girishG Offline
    girish Staff
    replied to Robin on last edited by
    #2

    @robin would it work for you if I made it bind to all the IPv4 interfaces (other than loopback)?

    We have to figure a way to filter out all the internal docker interfaces and bridges.

    You can quickly check this like below on your server:

    $ node
    Welcome to Node.js v14.15.4.
    Type ".help" for more information.
    > os.networkInterfaces()
    
    R 1 Reply Last reply
    0
  • girishG Offline
    girishG Offline
    girish Staff
    replied to Robin on last edited by
    #3

    @robin Ideally, I would want to bind to 0.0.0.0 but we can't because there is an internal DNS server on port 53. The code then needs a way to bind explicitly to the "external" interfaces of the server.

    Looks like we can:

    • ls -l /sys/class/net/ | grep -v virtual and this lists potential interfaces
    • ip link show - this shows even the virtual interfaces. not sure how i can filter them out . there is ip link show type but cannot find a suitable type option to use
    1 Reply Last reply
    0
  • R Offline
    R Offline
    Robin
    replied to girish on last edited by
    #4

    @girish Yeah, binding to all interfaces would work for me. And I think it's reasonable enough to assume that Cloudron can "own" any interfaces it is given access to, just like a 0.0.0.0 bind would normally, so that seems fine...

    Some searching finds me this, which looks potentially useful:

    https://serverfault.com/questions/1019363/using-ip-address-show-type-to-display-physical-network-interface

    The one liner given there (with jq) does indeed report only the two physical interfaces I have:

    # ip -details -json link show | jq -r '
    > .[] | 
    >       if .linkinfo.info_kind // .link_type == "loopback" then
    >           empty
    >       else
    >           .ifname
    >       end
    > '
    enp1s0
    enp2s0
    
    girishG 1 Reply Last reply
    0
  • girishG Offline
    girishG Offline
    girish Staff
    replied to Robin on last edited by
    #5

    @robin thanks, I have fixed it here -https://git.cloudron.io/cloudron/box/-/commit/1e665b63234ba7cfdfd6d16679a2261418c7449c . It will be in the next release.

    R 1 Reply Last reply
    1
  • R Offline
    R Offline
    Robin
    replied to girish on last edited by
    #6

    @girish I patched my docker.js manually, and I can confirm that port 53 is now exposed on all interfaces, as I would expect! Thanks!

    1 Reply Last reply
    1

  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Login

  • Don't have an account? Register

  • Login or register to search.