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:10] – [Remote Access to your Home Server] 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 5: Line 5:
 You want to access the **services** hosted on your home server. You want to access the **services** hosted on your home server.
  
-=== Remote access to the server or to the network? ===+==== Remote access to the server or to the network? ====
  
 Access to the **home server** means access to your home services. You can, and should, remap using the reverse proxy any service which is not on the home server itself.  Access to the **home server** means access to your home services. You can, and should, remap using the reverse proxy any service which is not on the home server itself. 
Line 16: Line 16:
  
  
-=== External Reachability ===+==== External Reachability ====
  
 You have a network interface of some kind between your home and your ISP provider. It could be a router or a gateway, it can be provided by the ISP or a device you bought and connected. This device acts as a firewall of kind and ensures that your home network is __not__ accessible from outside.  You have a network interface of some kind between your home and your ISP provider. It could be a router or a gateway, it can be provided by the ISP or a device you bought and connected. This device acts as a firewall of kind and ensures that your home network is __not__ accessible from outside. 
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 68: Line 70:
 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 ====
  
 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 79: Line 82:
  
 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.
 +
 +
 +==== 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/Wireguard tunnels.
 +
 +So, here are the assumption:
 +  * You choose the "external server" solution
 +  * You have two external servers: **external** and  **failback** (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:
 +<code>
 +        ┌───────────┐         
 +        │Home       │         
 +        │ ▲ Server ▲│         
 +        └─┼────────┼┘         
 +          │        │          
 +          │        │          
 +          │        │          
 +   ┌──────┼─┐    ┌─┼──────┐   
 +   │ISP 1 │ │    │ │ISP 2 │   
 +   └──────┼─┘    └─┼──────┘   
 +          │        │          
 +          │        │          
 +          │        │          
 +┌─────────┴┐      ┌┴─────────┐
 +│External  │      │External  │
 +│ Server 1 │      │ Server 2 │
 +│          │      │          │
 +│┌────────┐│      │┌────────┐│
 +││ IPF n.1││      ││ IPF n.2││
 +│└────────┘│      │└────────┘│
 +└──────────┘      └──────────┘
 +</code>
 +
 +The **home-server** will port-forward to **external.mydomain.com** via **ISP 1** and, at the same time, to **failsafe.mydomain.com** via **ISP 2**.
 +
 +If you have only one ISP or one external server, just ignore the other. Of course you can use any mix of two ISPs and one external server, or one ISP and two external servers as you like, each step is a bit less redundant than the other of course.
 +
 +The IPF (IP forward) can be either one or a mix of the WireGuard or SSH tunnels described below.
 +
  
 ===== Wireguard Redirects ===== ===== Wireguard Redirects =====
Line 104: 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.
  
  

This website uses technical cookies only. No information is shared with anybody or used in any way but provide the website in your browser.

More information