105

I've been following this community for some time in order to learn about self-hosting and, while I have learnt about a bunch of cool web services to host, I'm still lost on where/how to start. Does anyone have, like, a very beginner guide that is not just "install this distro and click these buttons"? I have an old laptop that runs Arch (btw), but I'm not familiar with networking at all. So anything starting from "you can check your IP address using ip a" would be appreciated.

More specifically, I have a domain that I want to point to an old laptop of mine (I intend to switch to a VPS if/when I feel like the laptop is starting to lose it). How do I expose my laptop to the internet for this to work (ideally without touching my router, because I'll be traveling quite a bit with my laptop and don't mind the occasional downtime). I assume that once I'm able to type my domain name on my mobile and see it open anything from my laptop, I can then setup all the services I want via nginx, but that's step 2. I tried to follow a few online guides but, like I mentioned, they're either too simplistic (no I don't want to move to Ubuntu Server just for this) or too complex (no I don't know how DHCP works).

Thanks in advance

you are viewing a single comment's thread
view the rest of the comments
[-] Shdwdrgn@mander.xyz 57 points 1 year ago

It sounds like maybe you're looking for a primer on how networking works across the internet? If so, here's a few concepts to get you started (yeah unfortunately this huge post is JUST an overview), and note that every one of these services can also be self-hosted if you really want to learn the nuts & bolts...

DNS is the backbone of everything, it is the service that converts names like "lemmy.world" into an actual IP address. Think of it like the phone book of the internet, so like if you wanted to call your favorite pizza place you would find their name, and that would give you their phone number. Normally any domain that you try to reach has a fixed (or static) IP address which never (or rarely) changes, and when you register your domain you will point it to a DNS server that you have given authoritative access to provide the IP where your server can be found.

But what if you're running a small setup at home and you don't actually have a static IP for your server? Then you look to DDNS (Dynamic DNS) and point your domain's DNS to them. There are several free ones available online you can use. The idea is you run a script on your server that they provide, and every time your IP from your ISP changes, the script notifies the DDNS service, they update their local DNS records so the next person looking for your domain receives the updated IP. There can be a little delay (up to a few minutes but usually only seconds) in finding the new address when your IP changes, but otherwise it will work very smoothly.

You mentioned DHCP, so here's a quick summary of that. Basically you are going to have a small network at your home. Think of your internet router as the front-end, and everything behind it like you computers or mobile devices are going to be on their own little private network. You will typically find they all get an IP address starting with 192.168.* which is one or the reserved spaces which cannot be reached from the internet except by the rules your router allows. This is where DHCP comes in... when you connect a device it sends out a broadcast asking for a local network IP address that it is allowed to use. The DHCP server keeps track of the addresses already in use, and tells your device one that is free. It will also provide a few other local details, like what DNS server to use (so if you run your own you can tell the DHCP service to use your local server instead of talking to your ISP). So like the phone book analogy, your DHCP service tells all of your local devices what phone number they are allowed to use. other Now to put all of this together, you probably have a router from your ISP. That router has been pre-programmed with the DHCP service and what DNS servers to use (which your ISP runs). The router also acts like the phone company switchboard... if it sees traffic between your local devices like a computer trying to reach your web server, it routes those calls accordingly. If you are trying to get to google then the route sends your call to the ISP, whose routers then send your connection to other routers, until it finally reaches google's servers. Basically each router becomes a stepping stone between your IP address and someone else's IP address, bringing traffic in both directions.

OK so now you want to run a web server for your domain. This means that besides getting the DNS routing in place, you also need to tell your router that incoming web traffic needs to be directed to your web server. Now you need to learn port numbers. Web pages traffic on port 80, and SSL pages use port 443. Every type of service has its own port number, so DNS is port 53, ftp is port 21, and so on. Your router will have a feature called port-forwarding. This is used when you always want to send a specific port to a specific device, so you tell it that any incoming traffic on port 80 needs to be sent to the IP address of your web server (don't worry, this won't interfere with your own attempts to reach outside websites, it only affects connections that are trying to reach you).

Now if you've followed along you might have realized that even on your local network, DHCP means that your server's own IP address can change, so how can you port-forward port 80 traffic to your web server all the time? Well you need to set a local static IP on your server. How that is done will be specific to each linux distribution but you can easily find that info online. However you need to know what addresses are safe to use. Log in to your router, and find the DHCP settings. In there you will also see a usable range (such as 192.168.0.100 to 192.168.0.199). You are limited to only changing the last number in that set, and the router itself probably uses something like 192.168.0.1. Each part of an address is a number between 0-255 (but 0 and 255 are reserved, so except in special cases you only want to use the numbers 1-254), so with my example of the address range being used by DHCP, this means that you would be free to use any address ending in 200-254. You could set the static IP of your web server to 192.168.0.200, and then point the port-forwarding to that address.

Now remember, your local IP address (the 192.168 numbers) are not the same as your external internet address. If you pay your provider for a static internet address, then your router would be programmed with that number, but your web server would still have its local address. Otherwise if you're using DDNS then you would tell that service the outside IP address that your router was given by your ISP (who coincidentally is running a DHCP that gave your router that address).

Let me see if I can diagram this... OK so imagine your router has the internet address of 1.2.3.4, your web server has the local address of 192.168.0.200, and someone from the internet who has address 100.1.1.1 is trying to reach you. The path would be something like this:

100.1.1.1 -> (more routers along the way) -> your ISP -> 1.2.3.4 (router) -> 192.168.0.200 (server)

They send a request to get a web page from your server, and your server send the page back along the same path.

Yes there's a lot to it, but if you break it down one step at a time you can think of each step as an individual router that looks to see if the traffic going to something on the outside or going to something on the inside. Which direction do I need to send this along? And eventually the traffic gets to a local network that says "hey I recognize this address and it needs to go over to this device here." And the key to all of this routing is DNS which provides hints on where to forward the information to the next router in the path. I can break things down further for you if something isn't clear but hopefully that gives you a broad overview on how things move around on the internet.

[-] goddard_guryon@sopuli.xyz 5 points 1 year ago

Holy shit dude, that was actually very helpful! I'll need a few more go-throughs to fully grasp every piece here, but thanks a ton for writing it so precisely.

Based on this though, is there no way to have port-forwarding except setting it up explicitly in my router? I ask this because 1) in my personal setup, I'll be switching between wifi and mobile data quite often, and 2) I may end up on an institutional wifi after some time, in which case I won't have access to the router

[-] KrokanteBamischijf@feddit.nl 6 points 1 year ago

You might want to consider setting up a VPN tunnel to your own network. Main benefit is that you can access your home network as if you were connected to it locally. Which makes switching between mobile data and WiFi a non-issue.

This requires some sort of VPN server and usually a single port-forwarding rule for the protocol which your VPN software of choice uses. For the simplest default configuration of OpenVPN this means setting UDP port 1194 to point to your OpenVPN server.

Generally, keeping things simple, there's two types of VPN you can set up:

  • split tunnel VPN, which gives you access to your home network but accesses the internet directly.
  • full tunnel VPN, which sends all of your traffic through your home router.

It is a little more complicated than that, and there's more nuance to it, such as wether to user your own DNS server or not, but all that is best left to some further reading.

I've setup an OpenVPN server myself, wich is open source and completely free to mess around with. (Save for maybe some costs for registring your own domain or DDNS serviced. Those are all optional though, and mainly provide convienience and continuity benefits. You can definitely just setup a VPN server and connect with your external IP adress)

[-] spez_@lemmy.world 5 points 1 year ago

Or use Tailscale, it's quite easy and it's how I access all of my services

[-] LinuxSBC@lemm.ee 3 points 1 year ago

Correct. What you'd need in that case is a reverse proxy like ngrok, which is a bit more difficult to set up.

[-] Shdwdrgn@mander.xyz 3 points 1 year ago

Sorry for the late reply, we had a yard sale today and then company this evening so I'm just getting back to the computer. God this feels like the longest I've been offline in like a decade! Anyway I'm glad it was helpful, I literally rolled out of bed and this was the first post I read this morning so I just started typing, I was a bit worried I might have been incoherent writing so much before I even had breakfast but hey if it came across then I'm glad I helped!

Happy to see others have already stepped in to answer your questions, as with most things there are multiple solutions to your challenges but the first goal is to understand what's going on so you know the right questions to ask. Get your basic setup in place, poke around to see how it all interconnects, and you'll start understanding how other things come in to play. The bit I mentioned about being able to direct your port 80 incoming traffic without affecting your web browsing from another computer (which of course ALSO talks on port 80) really tripped me up until I realized I was overthinking things, so I just trusted that it would keep working and eventually I did find the answers.

So as I mentioned, yep there really is a lot of information to digest when you're learning how networking works, but once you get some of these basics concepts down then the rest will start coming easier. A lot of what I have learned comes from taking a single piece, playing with it a bit to get the hang of essentially what it is doing without getting so deep that I'm overwhelmed, and then moving on to the next piece to see how they interconnect. If you do that long enough you'll start coming back to the first pieces and going deeper into them. Or you'll find some pieces that you can get by only knowing the basics and you'll never need to dig any deeper. The big thing is having an overview of how things connect to each other because yeah, you're going to want to try different things with your servers. Just wait until you build your first firewall with multiple internal networks and even multiple ISP connections (my home network has five local zones plus two ISPs -- just because I can!)...

[-] goddard_guryon@sopuli.xyz 1 points 1 year ago

Haha I think it's best if I stop running towards just getting my own server up and actually learn this stuff instead, regardless of how long it takes. I'll try to follow through on this, thanks again for all the help :D

[-] Shdwdrgn@mander.xyz 2 points 1 year ago

Hey no worries, you'll get there. Just kick back and enjoy the ride, because its a lot of fun learning all this stuff!

[-] Mars2k21@kbin.social 4 points 1 year ago* (last edited 1 year ago)

Honestly one of the most well written posts I've read. Thanks a lot, helped me understand all of this networking stuff involved with self-hosting since I literally just bought a PC to function as my home server like 2 days ago.

[-] Shdwdrgn@mander.xyz 3 points 1 year ago

Thanks! Maybe if I hadn't just climbed out of bed five minutes before writing that I might have been able to organize the info a little better, but apparently everyone is happy with it. 😄

Don't get caught up on needed fancy new hardware to run servers from, the last new computer I bought was a 386. This Spring I just rolled my VM servers off of some 2006 rack servers (dual-core and 8GB of memory, getting a bit painful!), and I'm serving up live internet content. You can go a long ways with old hardware. I always say play with what you've got, or with the stuff other people are throwing away. By doing this you can push a machine to its limits to see what it can really handle, which gives you a good idea of what hardware you want to upgrade to for YOUR specific needs. My new servers are from 2012-2014, and a massive upgrade at about $150 each!

this post was submitted on 19 Aug 2023
105 points (95.7% liked)

Selfhosted

40697 readers
140 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS