User Tools

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
networking:external_access [2025/02/06 10:14] – willynetworking:external_access [2025/03/13 15:00] (current) – [SSH Tunneling] willy
Line 1: Line 1:
-====== Remote Access to your Home Server ======+====== J) Remote Access to your Home Server ======
  
 Accessing your home server from outside can be tricky. Please note that i am referring to accessing your **home server** from outside, **not** your home network. There is a big difference!  Accessing your home server from outside can be tricky. Please note that i am referring to accessing your **home server** from outside, **not** your home network. There is a big difference! 
Line 32: Line 32:
   * Often ISPs will forbid it   * Often ISPs will forbid it
   * Having a real IP today is really uncommon, CG-NAT is instead the new default.   * Having a real IP today is really uncommon, CG-NAT is instead the new default.
 +  * the //really usefull// ports like 80 (HTTP), 443 (HTTPS), 25 (email) are usually blocked by your ISP anyway
  
 === CG-NAT === === CG-NAT ===
Line 38: Line 39:
  
 If you are behind CG-NAT, port forwarding is moot and you have only two options left: If you are behind CG-NAT, port forwarding is moot and you have only two options left:
-  * Using a VPN service +  * Using a VPN service (not wireguard: a commercial VPN with exit nodes) 
-  * Using an external server as bridge+  * Using an external server as bridge (using wireguard or SSH as tunnel)
  
 In both cases, you need a **server** located externally to your home, and that can be reached from the internet, that you can use as an entry-point toward your home. The main difference is explained below. In both cases, you need a **server** located externally to your home, and that can be reached from the internet, that you can use as an entry-point toward your home. The main difference is explained below.
Line 52: Line 53:
  
 **Note**: when talking about VPN, do not confuse this with Wireguard, which is still a VPN technically, but it's intended to work **on the other direction**, to get back inside. **Note**: when talking about VPN, do not confuse this with Wireguard, which is still a VPN technically, but it's intended to work **on the other direction**, to get back inside.
 +
  
 === External Server === === External Server ===
Line 67: Line 69:
  
 Of course, if you have the means, go for a physical server which will guarantee you better privacy given that you will even rent the actual hardware. I do this, and it's about 20€ per month at the time of writing this page. Of course, if you have the means, go for a physical server which will guarantee you better privacy given that you will even rent the actual hardware. I do this, and it's about 20€ per month at the time of writing this page.
 +
  
 ==== The "getting back in" from outside part ==== ==== The "getting back in" from outside part ====
Line 72: Line 75:
 Once you have established **how** you can make your home server visible on the internet, let's see how you can make so that you can access your services too. As i wrote at the beginning, the focus is on making your home services accessible, not your home network. This, again, is for security and protection. I assume all your services are already protected behind reverse-proxy, even at home, that provides an HTTPS encrypted layer and a common SSO authentication (more on this [[selfhost:nginx|here]] and [[selfhost:sso|here]]). Once you have established **how** you can make your home server visible on the internet, let's see how you can make so that you can access your services too. As i wrote at the beginning, the focus is on making your home services accessible, not your home network. This, again, is for security and protection. I assume all your services are already protected behind reverse-proxy, even at home, that provides an HTTPS encrypted layer and a common SSO authentication (more on this [[selfhost:nginx|here]] and [[selfhost:sso|here]]).
  
-Unless you can have port-forwarding (but in this case you need to take care of Dynamic DNS for example), there are two ways to "get back in". Both are encrypted:+Unless you can have port-forwarding (but in this case you need to take care of Dynamic DNS), there are two ways to "get back in". Both are encrypted:
   * Using Wireguard: you setup a wireguard server at home, then you need to install and configure clients on all the devices connecting from outside   * Using Wireguard: you setup a wireguard server at home, then you need to install and configure clients on all the devices connecting from outside
   * Using an SSH tunnel providing port-forwarding: this will allow __any__ device to access your services, and no specific setup on them.   * Using an SSH tunnel providing port-forwarding: this will allow __any__ device to access your services, and no specific setup on them.
Line 80: Line 83:
 In this case, of course, the backup link will need to use a different port than the main one. In this case, of course, the backup link will need to use a different port than the main one.
  
-=== "getting back in" architecture === 
  
-=== Architecture ===+==== Architecture ====
  
-Is it secure? Yes, security is provided by the reverse-proxy + SSO, and privacy is guaranteed by using HTTPS on all services + encrypted SSH tunnels.+Is it secure? Yes, security is provided by the reverse-proxy + SSO, and privacy is guaranteed by using HTTPS on all services + encrypted SSH/Wireguard tunnels.
  
 So, here are the assumption: So, here are the assumption:
Line 90: Line 92:
   * You have two external servers: **external** and  **failback** (optional)   * You have two external servers: **external** and  **failback** (optional)
   * You have two ISPs at home (optional)   * You have two ISPs at home (optional)
 +
 +I have already stated elsewhere, but i will again state it here since it's very important. 
 +For this approach to be safe, you **must**:
 +  * Use HTTPS on __all__ your service. And i mean **all**.
 +  * Use a reverse-proxy in front of __all__ your services.
 +  * Use strong authentication (proxy-auth, or Authelia or a similar services)
 +
 +All these three points are covered by using [[selfhost:nginx|NGINX reverse proxy]] + [[selfhost:sso|SSO]] as i describe in the linked pages.
  
 I will try with some ASCII art to illustrate: I will try with some ASCII art to illustrate:
Line 147: Line 157:
   * More complex to make the tunnel resillient to disconnections and network issues   * More complex to make the tunnel resillient to disconnections and network issues
  
-[[https://www.openssh.com/|OpenSSH]] is the default- SSH package installed in Gentoo. It creates a safe, encrypted tunnel between two hosts and it's based on [[https://www.openssl.org/|OpenSSL]]. OpenSSH supports many useful features for your use case: +[[https://www.openssh.com/|OpenSSH]] is the default- SSH package installed in Gentoo.
-  * Strong encryption of all exchanged data +
-  * Host identification based on public&private keys +
-  * User authentication based on public&private keys +
-  * Strong password-less authentication with 2FA (certificate + password) +
-  * Port forwarding from local to remote +
-  * Port forwarding from remote to local +
-  * TCP Keep-Alive support+
  
-[[router:ssh_tunnel|This]] page provides you details on how to setup SSH Tunneling.+[[networking:ssh_tunnel|This]] page provides you details on how to setup SSH Tunneling.