Quote from: -ck on May 18, 2020, 07:52:30 AM

Also if you're wondering about the web interface, I'm doing as frodocooper suggested and installing https support which is why it's currently unavailable, and of course port 443 is being used by the pool itself so it would need another IP address or irregular port >_<

Thanks, -ck.

The simplest solution to the port problem that I can think of is to let the pool's stratum server listen on port 80 instead of port 443. This frees up port 443 for the web server to use for HTTPS traffic. This makes a bit more sense anyway, since port 80 is intended for unencrypted HTTP traffic, and the stratum protocol is itself unencrypted. Outgoing connections to port 80 are also usually allowed by default in most firewalls.

One downside to this approach is that visitors to the pool's website would have to manually add the https:// prefix to the pool's web address every time they enter it into their browser's address bar, because the pool's web server can't listen on the occupied port 80 to redirect them to port 443—unless the pool's website is (a) included in the HSTS preload list and/or (b) incorporates the EFF's HTTPS Everywhere rulesets to allow visitors using the HTTPS Everywhere browser extension to be automatically directed to port 443. The upside to this approach is that you do not need to configure the web server to forcibly redirect unencrypted HTTP requests to HTTPS URIs.

If you prefer to reserve port 80 for the pool's web server to use, then another simple solution would be to let the pool's stratum server listen on port 53 instead of port 443. This frees up both port 80 and port 443 for the web server to use. Port 53 is meant for unencrypted DNS traffic, and so outgoing connections to port 53 are also usually allowed by default in most firewalls. This approach requires you to configure the web server to forcibly redirect unencrypted HTTP requests to HTTPS URIs. Registering the pool's website on the HSTS preload list and incorporating HTTPS Everywhere rulesets remain highly recommended when using this approach.

A more complicated solution that doesn't involve setting up an additional network interface with additional IP addresses on the same machine, would be to terminate TLS connections at a HAProxy instance on a cheap VPS that in turn relays web traffic to and from the upstream web server (ideally encrypted, over a private network). Upsides to this approach include (a) allowing you to leave the pool's current setup on the dedicated server mostly untouched, and (b) freeing up the pool's dedicated server from not only having to manage TLS connections with web clients, but also from having to manage web traffic with clients at all. The downside to this approach is that it involves more effort and money to set up and maintain, because you would have to manage two servers instead of one.

And then there's setting up an additional virtual network interface with additional IPv4 and IPv6 addresses on the same machine, and binding the pool's stratum server to one virtual interface and the web server to another. This seems quite straightforward in concept, but I do not have any experience with this approach, and so I can't say much about it, nor can I recommend it with confidence. It does seem cheaper and simpler than setting up HAProxy as a reverse proxy on another VPS, though.