OK, let's go. I am sorry if I explain to you something you already know, or even already read. But ELI5 you want, ELI5 you get 😁

I'll be giving examples related more to the organisation network. In a homelab they might be a little bit over the top, but I hope they will allow the better understanding of the concepts.

Also, I am purposefully ignoring all the small prints of Ethernet communication, as they are not relevant for the purpose of explaining the VLANs.

First, a little bit of historical background, to establish terminology, and show how some meanings has shifted. Please note, I am doing that using IPv4 and wired Ethernet as a base. Other network protocols might have different meanings or terminology here.

So, in the past we had LANs. Those LANs, if too big, or if required for traffic separation. Those LANs were called subnets. This term also appears in the scheme of the IP addressing. So, it describes different entities, which are closely related. Depending on the context it might mean any of them, or both. For the physical subnet there is also another name: collision domain, which refers to one of the core principles of Ethernet protocol: CSMA/CD. You can check it on your own.

Each subnet is an entity on its own. All devices in subnet can communicate directly, without using another network devices (I'm ignoring switches here, as this is a separate story to tell, about the development of Ethernet itself). To communicate with other subnets, the router is needed. Sometimes we want subnets to be able to communicate with each others, and with the WAN (Wide Area Network, for example Internet), and sometimes we do not.

Please note: the original meaning of LAN was a whole network infrastructure available in a given place, regardless of how much collision domains were set up, but in everyday language (at least in Polish) it has expanded, covering also an individual subnet.

So, there is a server. It could be placed in one of those subnets, or it can have a separate subnet for its own, and for other servers. This subnet is connected to other subnet to router, or routers. And routing must be properly set. So, this is the base architecture. The purest form. Physical entities, well defined roles, configured according to the technology we had at the moment. But it has some drawbacks.

Let's say, there is a huge traffic from one of this subnets to the server. Huge enough it affects the router's performance, and unrelated traffic. So, the solution was to add another NIC to the server, and connect it to the other subnet. It is called multi-homing. Please note, this is a practical solution for a practical problem, not a perfect solution.

Pro: You don't pass the traffic unnecessary through the router.
Con: If there are traffic policies in place, saying which subnets can communicate with each other, the multi-homed server needs to be monitored to make sure it is not going to perform as a router, enabling the unwanted inter-subnets communication.
Con: The server my provide some services to its original subnet (let's say DHCP). The other subnet may already have this service covered. And accidentally adding another provider of this service may have unwanted consequences. The best way to piss off a network admin in your org is to add a rouge DHCP server.

Let's say, we have kind of modern Ethernet network. That means: twisted pair, not a coaxial cables. It is not like they do not exist anymore, but I would say it's rather rare. And we need the gains of a new technology.

So, let's say your organisation has two not adjacent floors in the building. On each floor there are: administration, production, and research. Each department has it's own subnet. Those subnets are not allowed to directly communicating with each other. So, on each floor you need to have three switches, one for each department. And three Ethernet cables for connecting the appropriate switches. So the administration of the 1st floor can communicate with the administration on the 3rd floor, and so one. That costs. So, to simplify it, one had an idea: let's make the switch configurable, so we can tell it, to allow communication between ports only in groups. So, we declare on each switch ports 1-10 to administration, 11-30 to research, and 31-40 to production. And we still need to have three trunk cables to connect the switches on different floors.

So far we are operating on separate physical subnets. Yes, there are sharing the switches, but separate cabling is needed.

Now, let's introduce the new invention: Virtual LANs - VLANs.

Why can't I have just a single trunk cable connecting switches, and some address information. So when forwarding the packet to another switch, it knows to which group of ports it should send the packet to. Well, we can. It's called VLAN tagging.

Side note. If my memory doesn't cheat on me, I have an impression there were few contending standards for that pushed by competing vendors, but finally the VLAN tagging made it into the IEEE 802.1Q standard, which is followed by implementations. But I am not going to die on this hill, apart from the fact that IEEE 802.1Q is a thing.

So, now we are telling the switch: ports 2-10 to administration, 11-30 to research, and 31-40 to production. And port 1 is for trunk connection. So, if anything comes to the switch from ports 2-10, it will send the packet to the other ports in the group, and - after adding "this is administration VLAN" address to the header, to the trunk port. If anything comes to the switch from trunk port, it will check the address data. "This is for administration VLAN, I'm sending that to port 2-10".

Please note, I am giving an example of the office with two slightly separate locations. But one can use VLANs just for the purpose of the separation

So, what about the servers, which I've conveniently ignored so far? If it is single homed server, adding VLANs does not change much. On the abstract layer it is a separate subnet. If it needs to be accessible from a separate subnet, some configuration needs to be made.

But for multi-homed server there are options. One option is to keep two NICs, and connect the server to the two subnets, conveniently ignoring the fact they are subnets. Or connect the server with only one cable, and make it VLAN trunk connection. So, on the switch configure port as a trunk, and on a server configure the NIC as a trunk as well. So, it will be aware of the VLAN tagging, and both, associate incoming traffic to assign it to a proper logical interface created for each handled VLAN, and for outgoing traffic it will assign a proper VLAN tag, according to the logical interface the data came from, before sending it to the switch.

So, that's it about VLANs. Let's get back to the original question: what is the proper way of handling that on the server. My answer is: yes. There are many methods available, and all of them are valid. They might be more or less annoying to establish (and debug in case something doesn't work), and more or less secure (depending of how much you care about that in a homelab). So, you can do a single-homed with a routing, or a port-forwarding on a router. Or a multi-homed with two NICs, or a single NIC on a trunk level. Appropriate firewall rules may or may not be applied in each case.

And my advice is: whenever you think about the network configuration, get back to the abstract architecture of it, as you would do it in early nineties, without all this fancy solution available. That's for the first stage of the design. Then think how you can collate some physical aspects of the network - or your abstract design - using the modern technology, to reduce the physical infrastructure replacing it by proper configuration.

And one more thing, as it might be confusing for some. Right now it is possible to add multiple IP addresses to one NIC. Which is relevant when you need to handle - for example - multiple https domains. In the past it wasn't possible, and one needed to create a logical interface on the NIC. In Linux it is called IP Aliasing. It is still there for backward compatibility, but it is obsoleted. It is not related to VLANs, even if it creates logical interfaces. If you are interested in some Ancient Knowledge of The Elders, there is this brief document: docs.kernel.org/networking/ali…