feat: Moves network documentation to it's own file.

Network.md

@@ -0,0 +1,80 @@
+---
+date: 2025-4-02
+updated: 2025-04-02
+author: "Michael Housh"
+---
+
+# Networking
+
+All of the networking setup is done through [unifi](https://unifi.ui.com). The
+network is segmented into several different networks to isolate communication.
+
+## Networks
+
+An overview of the networks that are setup.
+
+### Default Network
+
+The default network can not be deleted, it comes as the default network on the
+unifi networking gear. It is also generally the network a new device will go if
+it is plugged into an ethernet cable / switch. For this reason this network is
+isolated from communicating with other networks.
+
+New devices that end up on this network should be configured to the appropriate
+network by a network administrator.
+
+### Management Network
+
+This network is for unifi equipment (wireless access points, switches, etc.).
+This network is isolated from other networks to reduce any attack surface if
+someone gained access to the network.
+
+### Main Network
+
+This is where the majority of "trusted" devices should be placed on the network,
+such as computers, phones, etc. This is also the network when people join the
+non-guest WiFi.
+
+This network has the ability to communicate with most all other networks.
+
+### housh.dev Network
+
+This is the network where all the servers are placed. This network is primarily
+setup to allow "responses", but not initiate communication with other networks.
+This is to help reduce the risk if one of the servers gets compromised, an
+attacker should not easily be able to transition to another network.
+
+### Phones Network
+
+This is the network where all the VoIP phones are on. It is considered
+"untrusted" and should not be able to communicate with any other network.
+
+### IoT Network
+
+This is the network where all IoT (internet of things) devices are. This is
+considered an "untrusted" network and communications with other networks are
+minimized to what is actually needed to work.
+
+The exception to items placed on the IoT network is "apple" specific devices,
+such as home-pods and apple-tv because there are network challenges with these
+devices operating properly when placed on the IoT network (which may be resolved
+in the future).
+
+## Firewall
+
+The unifi management console is what handles firewall rules for the networks. It
+is accessed via `Settings -> Security -> Firewall` on the management console.
+
+![firewall](./img/firewall.png)
+
+This is where settings are made to either allow or deny traffic on the networks
+from communicating with other networks or the internet.
+
+## DNS
+
+DNS is what translates IP addresses to domain names (i.e. `po.housh.dev` ->
+`192.168.50.6`). This is managed by the unifi management console and is accessed
+via `Settigns -> Routing -> DNS`.
+
+We primarily use wildcard records, which allow the actual routing to be handled
+by the servers to the correct service.

README.md

@@ -1,6 +1,7 @@
 ---
 date: 2025-4-02
 updated: 2025-04-02
+author: "Michael Housh"
 ---
 
 # Homelab Documentation
@@ -16,7 +17,16 @@ orchestrator, currently using [komo](https://komo.housh.dev).
 All of the services have a corresponding repository for their configuration that
 is hosted on an [internal git server](https://git.housh.dev/homelab). The
 configuration will consist of a docker compose file (generally named
-`compose.yaml`). There is often an `example.env` file service the example are
-for documentation purposes. The environment variables themselves as well that
-will have the names of environment variables needed for the service to run, the
-values in are setup in the container orchestrator for the
+`compose.yaml`). There is often an `example.env` file for the service, these are
+examples for documentation and variable naming purposes. The environment
+variables themselves are setup in the container orchestrator for the service.
+
+### Container orchestrator
+
+The container orchestrator is where the actual configuration for the service is
+done. It configures which physical server that the service will run on, it is
+responsible for pulling the proper container images, pulls the configuration /
+`compoose.yaml` file from the repository, sets up environment variables, and
+deploys the service onto the server.
+
+It also has some features for monitoring CPU and Memory usage of the servers.