search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.68k stars 492 forks source link

Changing Apache listening port in order to use Owncloud externally #4880

Closed K92Pi closed 2 years ago

K92Pi commented 2 years ago

Creating a bug report/issue

Required Information

Additional Information (if applicable)

Steps to reproduce

I'm looking to change the Apache web server default listening port, because I'd like to use Owncloud remotely. I'm using a private VPN service, my device is connected to it all the time. The VPN provider allows to open ports, so what I think might work in this case is to open a port on my VPN provider site and configure Owncloud for that random port.

Expected behaviour

I'm expecting to have an open port to the web through my VPN provider and use Owncloud remotely that way. Also, I'd like to use the HTTPS protocol to encrypt the communication between my devices. If you could give me some instructions in regarding that, that would be very good!

Actual behaviour

Owncloud is unreachable from the web.

I hope my point is understandable and you'll be able to help me with this. Thank you in advance!

MichaIng commented 2 years ago

Check out /etc/apache2/sites-enabled/000-default.conf where you can change the port from 80 to whatever you need. Additionally you need to add or change it in /etc/apache2/ports.conf.

Connecting to a webserver through a VPN is somehow a rare aim, not sure what you want to achieve with this? Usually I'd keep using ports 80, bypassing the VPN, and enable HTTPS with forced redirect and HSTS to assure authenticity and encryption, e.g. via Certbot and dietpi-letsencrypt. At least Let's Encrypt certificates can only be renewed when the webserver is reachable via port 80, otherwise you'd need to manually change this back and forth every 3 months (certificate live time). The HTTPS vhost port, when enabled via Certbot, can be changed in /etc/apache2/sites-enabled/000-default-le-ssl.conf then.

Joulinar commented 2 years ago

Yeah connecting to a system with active VPN connection to a public VPN provider is a bit of a challenge. I guess something for the docs on how to create iptable rules and exclude web server from VPN connection. We had couple of request for this scenario but never find a working iptable configuration

MichaIng commented 2 years ago

Ah of course when a VPN client is running, usually remote access bypassing the VPN is not possible OOTB but requires a split tunneling configuration then so that the system bypasses the VPN when answering the request. So yeah, probably piping everything through the VPN, when it supports port forwarding, is easier then. I'm not sure how inbound connections are achieved then, e.g. do you have a personal IP or domain from the VPN provider, aside of the forwarded port (range), or is the domain/IP of the VPN server itself used and correct forwarding (to your connected VPN client) is done based on the port only?

K92Pi commented 2 years ago

What I wanted to archive is to have a fix IP address to reach out Owncloud externally. I have a fix IP from the VPN provider. However they don't allow port 80 to open for security reasons. I could also use a subdomain for the VPN server's IP. So I guess the easiest thing would be if I set up remote access with a dynamic DNS provider?

Joulinar commented 2 years ago

Thats the normal way. Did your VPN provider is giving you a fixed external IP that can be used?

MichaIng commented 2 years ago

So I guess the easiest thing would be if I set up remote access with a dynamic DNS provider?

Yes exactly. With an account, you can use dietpi-ddns to setup a cron job to keep domain and external IP in sync. A VPN (running in client mode) is usually not meant to be used for external access but for anonymous outgoing connections, while it makes inbound connections more complicated. So if you do not need to privacy for outgoing connection, provided by a VPN, I would skip it and instead force HTTPS (respectively TLS encryption) for all inbound traffic.

Port forwarding provided by a VPN provider, as far as I faced it, is more meant to be used in situations where you need 3rd parties to connect to your system (inbound connection) without knowing your actual IP/domain, and hidden from ISPs at any end. Typical use case is running a BitTorrent server so that you can anonymously download through the VPN but as well can seed downloads through the VPN effectively. Without port forwarding from the VPN, inbound connections cannot be established, so seeding only works when your system connects to peers actively (rather than the other way round), which does not always work well, or takes long before a significant amount of peers are connected, also depending on the indexer.

But actually, if you do have a fixed IP from your VPN provider, and the connection is sufficiently fast for your needs, why not use it for regular webserver access. If you want the VPN connection for other purpose, then this sounds much easier than setting up split tunnelling, where at least I always need to again lookup how to achieve that 😄. Indeed we need a documentation about this.

K92Pi commented 2 years ago

I've installed dietpi-ddns with No-IP. Well, it's not that easy as I thought. This Pi is a media server for my home, I use torrents, Plex, Owncloud, etc. So I need to have an active VPN client connection all the time, but due to my VPN provider limitations, I won't be able to open port 80 or 443 even with a fix IP address. As far as I see the situation, the only way to make everything work is to utilize split tunneling. This project with Owncloud is just an experiment for me, however it would be very good to have my media accessible anywhere. The next thing I'd like to try is remote.it service. I'll keep you updated.

MichaIng commented 2 years ago

With Apache ports changed to some which are redirected by your VPN, this would be an alternative. Only for certificate renewal you'd need to either change the Apache ports back temporarily, or let Certbot spin up its internal webserver (and stop the VPN until renewal is done).

K92Pi commented 2 years ago

The remote.it solution isn't working with Owncloud, because I couldn't find a way to add their domain to the trusted domains. @MichaIng I'll try your suggestion, it's quite challenging for me to make this project happen the way I have planned.

MichaIng commented 2 years ago

In /var/www/owncloud/config/config.php there is the trusted_domains array. Adding another entry with the IP/domain you use to access through the VPN (or remote.it) does not work?

MichaIng commented 2 years ago

Marking this as closed. Feel free to reopen when required.