Cursed Silicons Wiki - User contributions [en]

CGHMN-IP-Allocations

2025-05-18T03:10:02Z

Ilostmybagel: /* Members' Networks */

=== IP Address Allocations in the CGHMN Network ===
This page documents any IP addresses that are allocated statically to routers, subnets and members.

=== Networks on the CGHMN side ===
This is a list of all networks active on the CGHMN server side.
{| class="wikitable"
|+
!Network Name
!VLAN
!Subnet
!Router IP
!Notes
|-
|Core Services
|4
|172.23.4.0/22
|172.23.4.1
| -
|-
|Servers
|8
|172.23.8.0/22
|172.23.8.1
| -
|-
|Global LAN
|256
| -
| -
|No IP traffic, no assigned IP addresses
|-
|Wireguard Members Tunnel
| -
|100.89.128.0/22
|100.89.128.0
|The .0 for the router is not a typo, on P2P links the network address can also be used for a host
|}

=== Members' Networks ===
This list contains the subnets that are assigned to member routers on the network. Members receive one <code>/24</code> network from the <code>100.96.0.0/13</code> block, in first-come-first-serve sequential order per default.
{| class="wikitable"
|+
!Member Name
!Connection Name
!Tunnel IP
!Routed Subnet(s)
!Notes
|-
|CursedSilicon
|AR300 Router
|100.89.128.1
|100.96.1.0/24
| -
|-
|Talija
| -
|100.89.128.2
|100.96.2.0/24
| -
|-
|Snep
|OPNsense box and PPPoE server
|100.89.128.3
|100.96.3.0/24
| -
|-
|Snep
|PC VPN tunnel
|100.89.128.4
| -
| -
|-
|Hadn69
| -
|100.89.128.5
|100.96.5.0/24
| -
|-
|Lily
| Dell PowerEdge R620
|100.89.128.6
|100.96.6.0/24
| -
|-
|Theothertom
| -
|100.89.128.7
|100.96.7.0/24
| -
|-
|Lily
| Raspberry Pi
|100.89.128.8
|100.96.8.0/24
| -
|-
|Loganius
| -
|100.89.128.9
|100.96.9.0/24
| -
|-
|GothPanda
| -
|100.89.128.10
|100.96.10.0/24
| -
|-
|ch0ccyra1n
| -
|100.89.128.11
|100.96.11.0/24
| -
|}

=== Member-Delegated (Sub-) Domains ===
{| class="wikitable"
|+
!Member Name
!Domain
!Nameserver
!Nameserver IP
!Notes
|-
|Talija
|coyote.retro
|a.ns.coyote.retro
|100.96.2.53
| -
|-
|Snep
|snep.retro
|ns1.snep.retro
|172.23.8.11
| -
|-
|Lily
|lily.retro
|ns1.lily.retro
|100.96.6.250
| -
|-
|Loganius
|loganius.retro
|loganius-win2k3.loganius.retro
|100.96.9.1
| -
|-
|theothertom
|theothertom.retro
|north-foreland.theothertom.retro
|100.96.7.12
|`
|}

=== Member Servers hosted on the CGHMN side ===
{| class="wikitable"
|+
!Member Name
!VM/CT ID
!Server Name
!Server IP
!Notes
|-
|Snep
|10811
|srv01.snep.retro
|172.23.8.11
| -
|-
|Talija
|118
|junko.coyote.retro
|172.23.3.173
|Network diagnostics
|}
[[Category:Compu-Global-Hyper-Mega-Net]]

Signup

2025-05-11T02:36:13Z

Ilostmybagel:

[[Category:Compu-Global-Hyper-Mega-Net]]
So! You want to be a member of CompuGlobalHyperMegaNet?

Excellent! Here's how you sign up

Firstly you'll need to join the [https://discord.gg/TnpSG2P677 Cursed Silicon Discord].

Ping one of our Mod staff and request access to the '''#compu-global-hyper-mega-net''' channel

After you've been granted access to the channel, @compu-global-hyper-mega-net and let us know what you'd like to build or run. A few helpful specifics

* Do you have Systems Admin/Network Admin skills? Do you need help with the stuff you'd like to run?

* Are you volunteering as a single user or are you participating as part of a group?
* Are you intending to use CGHMN's hosting, or do you want to simply attach your own retro hardware to the network?
* What are the best ways we can contact you (usually just in case anything breaks)

Once that's all sorted we'll help you get your project off the ground and running on the network as best we can.

Once it's up and running though please keep in mind '''you will be responsible for maintaining it'''

How to Get Connected

2025-05-11T02:33:31Z

Ilostmybagel:

[[Category:Compu-Global-Hyper-Mega-Net]]
This is a quick and dirty "how do I get on CGHMN"

Right now since the service is in "closed beta" these steps are a bit vague and manual. But over time as we figure out what works we'll add more connection methods and better documentation

Right now to get connected you effectively need three things, hardware wise:

[[File:CGHMN.png|thumb|319x319px|Example CGHMN Router Setup using a GL-AR300M and basic network switch]]

=== Hardware requirements ===
To connect your retro machine(s) to the CGHMN, you'll need the following:
*'''An Ethernet connection on your retro device(s) of choice, with a TCP/IP (v4) stack for now! TrumpetWinSock, Microsoft TCP/IP, whatever. It all works.'''

* '''Something with the ability to run Wireguard and forward IPv4 packets at the minimum and, for any non-IP packets, <code>gretap</code> and <code>nftables</code>. Personally we recommend something running OpenWRT, like the [https://www.gl-inet.com/products/gl-ar300m GL-AR300M] which we have successfully tested to work. We're currently working on a pre-built image for some select routers to make the setup easier for new members. A script to configure already existing OpenWRT instances can be found below.'''
* Alternatively, you can also run the CGHMN routing on any standard Linux box which has at least one Ethernet port and either a second one or WiFi for internet connectivity. <s>A basic script to set up a Linux machine as a router is posted below</s> (TODO!).

* '''Optionally: A simple network switch, in case you want to add multiple machines to the network. You plug one end into the CGHMN Router box and then your clients can all access CGHMN. Super easy!'''

On the right is an example of what a CGHMN router setup could look like.

=== Get connected - With OpenWRT ===
If you chose to go with an OpenWRT compatible router or want to run OpenWRT on typical x86 hardware/in a VM, you can follow these steps to get yourself connected to the CGHMN:

# Update your OpenWRT install to the latest version to ensure all required packages are available and compatible.
# Download [https://raw.githubusercontent.com/jonasluehrig/cghmn-get-connected/refs/heads/main/openwrt/setup-cghmn.sh this script from GitHub] to your OpenWRT router via SSH
# Run the following commands on the router:
## <code>ash setup-cghmn.sh install-pkgs</code>
## <code>ash setup-cghmn.sh init</code>
## You will be asked what network port you'd like to use for the Retro LAN. This is where you will plug in your retro machines to be part of the CGHMN. Choose a port that is not assigned to any OpenWRT interface like '''lan''' or '''wan''' or which not already part of a bridge and enter the Linux interface name, e.g. <code>eth1</code>, then press <code>[Enter]</code> to continue. If your router only has two ports and you're using one for WAN, then you first have to [https://openwrt.org/docs/guide-user/luci/luci.secure#allow_access_from_internet enable the web UI and SSH access via the '''wan''' OpenWRT interface], remove the entire '''lan''' OpenWRT interface to free the network port and continue the setup over the IP address your router got on its WAN side. If you only have a single Ethernet port, you're running on a router setup we can't really recommend, however you can configure VLANs and use a managed switch to both get a WAN DHCP address for internet access and have a separate VLAN for the Retro LAN bridge over a single port. This is commonly referred to as "[[wikipedia:Router_on_a_stick|router on a stick]]". Just enter the VLAN interface name here if you choose to go that route.
# Now you will be given some information on the console, including a Wireguard public key. Send one of the CGHMN admins (currently CursedSilicon and Snep) that key so we can add your router to our Wireguard server.
# In return, you will receive a tunnel IPv4 address (<code>100.89.128.x/32</code>) and a routed IPv4 subnet (<code>100.96.x.0/24</code>) from us. These will be needed on the third and final step of the setup script:
## <code>ash setup-cghmn.sh set-tunnel-ip</code>
# Once the script completed successfully, reboot the router to ensure all interfaces are up properly. After the reboot, your retro devices should receive an IP address in your routed IPv4 subnet on the Retro LAN port you chose above and be able to communicate with other machines on the CGHMN network.

=== Get Connected - Manually (Linux, Wireguard only, GRETAP follows shortly) ===
In case you want to setup a connection into the network manually, here are the required steps and information you should be needing:

* Generate a Wireguard private key and public key, this command writes a fresh Wireguard private key to <code>private-key</code> and the corresponsing public key to <code>public-key</code>:

$ wg genkey | tee private-key | wg pubkey > public-key

* NEVER share your private key, even with us! It should never be required outside of your own Wireguard setup!
* You will, however, need to share your public key with us. Send CursedSilicon or Snep on the Discord or via IRC a message including the public key and we'll add you to the tunnel.
* In return, you'll get two IP addresses from us: Your tunnel IP address, with which your router talks to our router, and a routed subnet, from which you can assign IPs to your own machines so they can talk to other CGHMN member devices on the network without NAT in the way.
* Next, you'll need to fill a Wireguard configuration file with the two IP addresses, like below:

[Interface]
PrivateKey = <Your private key goes here>
Address = <Your tunnel IP address goes here>/32
DNS = 100.89.128.0
MTU = 1420

[Peer]
PublicKey = k/QiJIbMakMKgTCHVt8/D+8k4DzRVM6U33F3gMZfRUg=
Endpoint = wg-admin.cursedsilicon.net:42070
AllowedIPs = 172.23.0.0/16, 100.89.128.0/22, 100.96.0.0/13
PersistentKeepalive = 15

* Save this file as <code>wg-cghmn.conf</code>, for example.
* Then, run <code>wg-quick up ./wg-cghmn.conf</code>, perhaps requiring <code>doas</code>/<code>sudo</code>, to bring the tunnel up and connect to the network!

This should bring whatever system you've set the tunnel up on onto the network and is now reachable for other members on the network, as long as the firewall on your device is congfigured accordingly, of course.

<nowiki>#</nowiki>TODO: Add example of routed subnet configuration, perhaps on a different Wiki site

=== Get connected - Server Side, the Admins Guide ===
[[File:Example Configuration for new Wireguard Peer on Core Router.png|thumb|Example Configuration for new Wireguard Peer on Core Router]]
To get a member onto the network, they will send an admin of the project their randomly generated Wireguard key during the setup via the OpenWRT script. Here are the steps that admin will have to follow to get them up and running on the server side:

# Log in on the [https://router.core.cghmn:8443 Core Router] over an existing CGHMN network link
# Navigate to VPN -> Wireguard -> Peer Generator
# You will be asked to enter some data for the new peer, enter the following:
## '''Instance:''' <code>WG_Member</code>
## '''Endpoint:''' <code>wg-admin.cursedsilicon.net:42070</code>
## '''Name:''' <code>member.''<Nickname of the new member>''</code>
## '''Public Key:''' <code>''<their Wireguard public key they've sent over>''</code>
## '''Private Key:''' <code>''<blank>''</code>
## '''Address:''' ''<code><Next highest IP from 100.89.128.0/22, this is their tunnel IP and is auto-filled></code>''
## '''Pre-Shared Key:''' <code>''<blank>''</code>
## '''Allowed IPs:''' <code>''<the same as Address>'', ''<their routed subnet, [[How to Get Connected#But wait, what even is their routed subnet?|see below]]>''</code>
## '''Keepalive interval:''' ''<code><blank></code>''
## '''DNS Servers:''' <code>''<default value>''</code>
# Hit the "Store and generate next" button
# Navigate to VPN -> Wireguard -> Instances
# Hit the "Apply" button
# Do either one of these steps, depending on if you can SSH into the GRETAP endpoint container:
## SSH into the CGHMN Proxmox Server and enter the command <code>pct enter 10403</code>
## SSH directly into the GRETAP endpoint (formerly VXLAN endpoint) container with <code>ssh root@172.23.4.103</code>
# From there, run the following command: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh <member-tunnel-ip> <member-name></code> where you replace <code><member-tunnel-ip></code> with the IP tunnel address of the member as it was set above in the '''Address''' field, without the <code>/32</code> CIDR subnet mask, and replace the <code><member-name></code> with the same value you've entered above in the '''Name''' field. For example, like this: <code>bash /opt/vxlan-scripts/create-vxlan-interface.sh 100.89.128.6 member.snep.test</code> This will create a GRETAP (and for legacy purposes, a VXLAN) interface and bring them up automagically. ''Ignore the fact it still says "VXLAN" everywhere, it does both.''
# Now you can send the member their Wireguard Tunnel IP and their routed subnet over and they can finish their client-side setup according to the mini-tutorial above.
# Rember to add the member and their tunnel and subnet IPs to the [[CGHMN-IP-Allocations|IP allocations page]] :)

==== But wait, what even ''is'' their routed subnet? ====
Each members routed subnet comes per default from the <code>100.96.0.0/13</code> IPv4 block and has a <code>/24</code> mask. This subnet is their "Retro LAN", to which all their retro computers are hooked into via the router of their choosing. By default, NAT is enabled on the routers, so it wouldn't make a difference which subnet is used on the remote end for the retro machines. However, if someone wants to host servers in the CGHMN and doesn't want to do port forwading, they can disable NAT and let other membres directly connect to their machines via this routed subnet.

To get the routed subnet of a member, take the number from the last octet of the Wireguard tunnel IP of a member, say <code>100.89.128.'''6'''</code>, and put it into the third octet of the <code>100.96.0.0/13</code> IP block and replace the <code>/13</code> with <code>/24</code>, so you get <code>100.96.'''6'''.0/24</code>. That is their routed subnet, simple as that!

CGHMN 1.0

2025-05-11T02:33:13Z

Ilostmybagel:

[[Category:Compu-Global-Hyper-Mega-Net]]
== Tracking sheet for "what would we want in a general 1.0 release" ==

Let's break these down by user just to keep division of labor easy

=== CursedSilicon suggestions ===

The main blocker currently is access to reliable fiber at /dev/hack. Gaining that should give us ample bandwidth to start allowing broader user access to the network generally

Maybe invite a selection of "retro networking" youtube folks (TheSerialPort, ClabRetro, etc) to help tire kick things? Serena also suggested federation of retro network service providers, so this could be a useful step.

CGHMN-Demo-Network

2025-05-11T02:33:01Z

Ilostmybagel:

[[Category:Compu-Global-Hyper-Mega-Net]]
=== Demo Network for the Interim Computer Festival ===
This page documents the quickly set up demo network to show off the CGHMN network at the [https://sdf.org/icf/ SDF's Interim Computer Festival] taking place between March 22nd and 23rd. Consider this a sort-of draft, an experimental first version, a test on what might work and what doesn't.

Currently, the basics are up and running on the CGHMN Proxmox hypervisor living in the [https://devhack.net/ /dev/hack Hackerspace] in Seattle. These include a router and Wireguard endpoint through an OPNsense VM, a VXLAN tunnel endpoint container with some custom scripts to make deploying new member tunnel easier and two containers running a basic authoritative BIND DNS server for <code>.cghmn</code> and <code>.retro</code> and one hosting a custom, internal Certificate Authority for those domains.

=== Changes to the network layout ===
Since this page was written, there have been quite a lot of discussions about how and what we might change going forward, after the initial test of the network at the ICF was a success. The biggest change, so far, has been the idea to move away from VXLANs to GRETAP tunnels for the Layer 2 and non-IP Layer 3 traffic. This is mostly due to the fact that VXLANs, by their RFC definition, MAY NOT fragment packets coming into the VTEP (aka. a VXLAN tunnel endpoint) and packets flowing out of a VTEP MAY be reassembled if fragmented, but don't necessarily have to. In addition to this, the IP packets generated by the VXLAN tunnels have the Don't Fragment bit set, so those packets may also not be fragmented. This means that the underlying transport of the VXLAN tunnels, here Wireguard, would have to open a path that allows 1500 byte frames through its tunnel, which would make the tunnel packets themselves quite large at ~1600 bytes, which would then be fragmented by whatever routers are in between the client router and the CGHMN router. Turns out, that's quite inefficient.

GRETAP tunnels, on the other hand, have the two flags <code>ignore-df</code> and <code>nopmtudisc</code>, which together with <code>ttl 255</code> create a tunnel over IP, which can carry ''and fragment'' 1500 byte Ethernet frames over a smaller underlying transport, still Wireguard in this case. This was a massive boost not only in speed under certain circumstances, like running this all on a small travel router with a weak MIPS CPU, but also reliability, as less dropped packets could be observed and MTU blackholes finally not happening in our testing.

To bring up a GRETAP tunnel within the network to the CGHMN central router, use the following commands on a Linux box:<blockquote><code>ip link add gretap-cghmn type gretap remote 172.23.4.103 dev wg0 ignore-df nopmtudisc ttl 255</code>

<code>ip link set gretap-cghmn master br0 mtu 1500</code>

<code>ip link set gretap-cghmn up</code></blockquote>Where <code>wg0</code> is your CGHMN Wireguard tunnel and <code>br0</code> is the bridge you'd want to bridge the GRETAP tunnel to.

However, to improve performance more and make the network a little more reliable, there was another idea for a change: Sending routable IP traffic not over the Layher 2 tunnel, but rather routing it directly through the Wireguard tunnel, which already is a straight Layer 3 path to the CGHMN core router. This is possible due to the nftables <code>bridge</code> filter table, which can match and filter packets on bridge interfaces, incuding what "bridge port" they come in and go out of. This means we can filter IP traffic from leaving the retro LAN bridge, to which you'd connect your retro machines via a phyiscal LAN port, by creating a filter that says "Block all traffic on bridge <code>br-retrolan</code> which leaves through a GRETAP interface" and "Block all traffic on bridge <code>br-retrolan</code> which comes in on a GRETAP interface". Now, you can assign the router a static IP address on the bridge, so it can talk to your retro machines, enable DHCP and NAT and route IP traffic from your machines straight to the CGHMN via Wireguard. In the future, this shall be extended to work without NAT on the client side, so that every member has a small subnet, /24 for example, which is routed to the Wireugard tunnel client IP. This also means that the VLAN1 described in the next section might not need an IP address in the future so that the VLAN1 is purely non-IP traffic at least from the CGHMN side of things.

Yet another idea mentioned was the ability to span tunnels directly between members, even without going through the CGHMN core network in the first place. This can be accomplished by creating another GRETAP interface whose <code>remote</code> IP argument points to the IP of another members router, either through the existing CGHMN Wireguard tunnel or through a separate tunnel that you span between you and the other member. This GRETAP interface is then bridged to the <code>br-retrolan</code> bridge and with a couple of (perhaps default) bridge firewall rules, you and the other member should be able to communicate directly! Of course, this also means we'd have to implement some sort of loopback protection not just on the member router side (the default bridge firewall rules mentioned in the last sentence), but also on the core router side. so this idea is not yet fully implemented for testing.

IP Allocations within the network are now kept track of [[CGHMN-IP-Allocations|in this Wiki page]], though the IPs listed there might not be applied in the current configuration yet.

=== Network Layout ===
This section describes the network layout currently set up for the CGHMN demo network, none of which is necessarily permanent and already set in stone. I (Snep) made some assumptions about domain names, IP addresses, firewall rules and general design ideas to get something up and running for the computer festival based on info from the many chats and discussions on the Cursed Silicon Discord's CGHMN channel (See [[Signup]] for more details). So, please feel free to give input on things you'd like to see changed or added!

On the Proxmox host, all VLANs mentioned below are available tagged on the bridge <code>brcghmn</code>, with exception of VLAN1, which is untagged and the default network when a new container or VM is added to this bridge.

For servers and retro clients, the subnet <code>172.23.0.0/16</code> is currently in place, divided into smaller subnets, and might be subject to change later down the line. For Wireguard clients, the <code>100.89.128.0/22</code> subnet out of the CGNAT block is used and again, might change later.

Below is a further breakdown of VLANs existing in this CGHMN demo network:

==== VLAN 1 - The Global LAN (172.23.0.0/22) ====
This network is our layer 2 bridged network to all members who wish to participate and is intended to be used for retro computers to directly communicate with each other even across the globe. This is accomplished by spanning a VXLAN tunnel across a Wireguard connection from the CGHMN server infrastructure to each members' router endpoint, which can be any OpenWRT compatible device that contains the packages for VXLANs and Wireguard. The idea is to bridge on of at least two available interfaces from said router to the VXLAN network and thus directly bridge any connected retro machines to VLAN1. All members will be in the same L2 broadcast domain, meaning even non-IP protocols that are able to run over Ethernet should be able to communicate with each other from all over the world.

Machines on this network are able to connect to all hosts on the Server VLAN (see below), the firewall for DNS, NTP and ICMP queries and to the root DNS and CA servers for DNS queries and HTTP access to the CA web server. They may also query DNS lookups at the legacy DNS server at <code>172.23.0.104</code>. They are not, however, able to communicate with any hosts on the internet, the /dev/hack network or any of the other existing VLANs aside from specific exceptions.

Addresses are handed out via DHCP by the router in the range <code>172.23.1.1-172.23.3.254</code>, the range <code>172.23.1.11-172.23.1.255</code> is reserved for static hosts. The search domain for this network is <code>clients.retro</code>.

==== VLAN 4 - Core Services (172.23.4.0/22) ====
This VLAN in intended for core internal services, like the root DNS server, VXLAN endpoint and our custom Certificate Authority. The Proxmox host also has an IP address in this subnet (<code>172.23.4.11</code>), it does not however have any routes to the rest of this CGHMN demo infrastructure and thus can only be accessed from clients in the Core Services subnet.

Hosts in this subnet may currently access the internet, the router for DNS, NTP and ICMP queries, query DNS lookups at the legacy DNS server at <code>172.23.4.104</code> and the VXLAN endpoint may send UDP datagrams to anyone at port <code>4789</code> for VXLAN tunnel replies, any other internal connections are prohibited.

Addresses are handed out via DHCP by the router in the range <code>172.23.7.1-172.23.7.254</code>, the range <code>172.23.4.11-172.23.6.255</code> is reserved for static hosts. The search domain for this network is <code>core.cghmn</code>.

==== VLAN 8 - Servers (172.23.8.0/22) ====
This VLAN will contain all servers hosted and managed by members, which can be any (retro) service that works across an IP router. For anything that requires direct layer 2 access or the same broadcast domain as the client machines, it is advised to host said server in the Global LAN network. This is the only VLAN clients from the bridged Global LAN network may access freely, so members should be wary about what ports they open up for anyone outside of localhost. Another option is to run a tiny router instance based on OpenWRT in front of your server which will act as a basic firewall and NAT router behind which one can run their servers.

Hosts in this subnet may not access the internet inherently, however a firewall rule is in place that allows specific servers internet access, it is still uncertain if this will make it to the final CGHMN or if this subnet is also supposed to be entirely sealed off from the public internet. During a few chats on the Discord server, the idea of hosting local package mirrors of popular distros and projects was mentioned so that both modern and retro systems won't need to connect to internet servers for package installations and upgrades. Hosts may access the router for DNS, NTP and ICMP queries and query DNS lookups at the legacy DNS server at <code>172.23.4.104</code>, other internal connections are prohibited.

Addresses are handed out via DHCP by the router in the range <code>172.23.11.1-172.23.11.254</code>, the range <code>172.23.8.11-172.23.10.255</code> is reserved for static hosts. The search domain for this network is <code>hosting.retro</code>.

==== VLAN 12 - DMZ (172.23.12.0/22) ====
Currently not in use.

=== Containers and VMs ===
Containers and VMs on the Proxmox host are currently assigned in the 10000 ID range to keep clear of existing VMs.

There is one VM and three containers at the time of writing this:

==== VM 10001 (demo-chhmn-router) ====
This is the OPNsense VM running as the primary router, firewall, DHCP server and Wireguard endpoint for the demo network. Its login credentials are currently in the paws of Snep, as I'm still unsure where any passwords for the CGHMN are going to be stored safely and with proper access rights.

The router has the first IP in any of the available demo network subnets and responds to IPv4 and IPv4 ICMP packets, DNS queries to its local Unbound resolver and NTP sync requests to the built-in NTP server.

Unbound currently resolves all requests it cannot resolve locally recursively against the internet root servers and returns those replies to clients, this may be subject to change as we potentially plan on sealing the network off more. It is configured to forward all requests with a TLD of <code>.cghmn</code> and <code>.retro</code> to the internal DNS root server.

The Wireguard endpoint servers as the connection into the CGHMN from the outside internet on <code>66.170.190.194:42070</code> for anyone that wishes to parttake the network. See [[Signup]] for more details on how to join.

==== Container 10401 (demo-cghmn-root-dns, VLAN4, 172.23.4.101) ====
This container, based on the absolutely tiny-footprinted Alpine image, hosts the BIND-based root DNS server for the internal CGHMN domains <code>.retro</code> and <code>.cghmn</code> together with the reverse DNS zone for the 172.23.0.0 network. It lives in the Core Services subnet and is reachable on port 53 for DNS queries from every other internal subnet. Zones are configured in the zone files under <code>/etc/bind/zones</code> and loaded by the zone blocks in the <code>/etc/named.conf</code> file.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10401</code> on the Proxmox host console.

==== Container 10402 (demo-cghmn-ca, VLAN4, 172.23.4.102) ====
This container, also based on Alpine, is hosting the custom Certificate Authority based on OpenSSL created and self-signed certificate files. It is currently constructed in a Root CA -> Intermediate CA -> Server Certificates structure, where the CA signed certificates of the intermediate CA, which then signs all certificates requested for servers and clients on the network. Clients thus should only need to install the CA certificate into their trusted keychain to have valid TLS connections to servers using certificates signed by this internal CA.

Clients can access a web server on <code>certs.cghmn:80</code> or <code>172.23.4.102:80</code> via plain HTTP to download the root CA and intermediate CA certificate files for installation on their retro machines. Note: This is not meant to be secure. When you add this root CA, we could pretend to be any server on the internet under any domain and any system that has the root CA or intermediate CA certificate installed will trust it. Don't add this on machines you would have personal data on or that you would let onto the public internet!

The /root directory of this container contains a script called <code>create-and-sign-server-csr.sh</code> that, when run without any arguments, will ask a few questions on the command line and generate a signed TLS certificate in the root directory for the specified DNS names to make deployment of new TLS certificates a little easier. This requires the password of the private key of the intermediate CA, which again is currently stored in Sneps password manager but of course will be copied to a safe location to store passwords once available for the CGHMN.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10402</code> on the Proxmox host console.

==== Container 10403 (demo-cghmn-vxlan-endpoint, VLAN4, 172.23.4.103) ====
This container, another Alpine instance, connects all the VXLAN clients together under one virtual Linux bridge and is constructed with a couple if-up/if-down scripts and a Bash script to create new tunnels at <code>/opt/vxlan-scripts/create-vxlan-interface.sh</code>.

This script, when called like for example so: <code>create-vxlan-interface.sh 100.89.128.90</code> will do the following:

# Find the first unused VXLAN ID
# Output the VXLAN ID for configuring a new VXLAN tunnel on the client side
# Add an interface configuration to <code>/etc/vxlan-interfaces/</code> which is sourced by ifupdown
# Bring up that new VXLAN interface, which bridges it to the Global LAN bridge

after which the client with IP 100.89.128.90 can connect a VXLAN tunnel with the newly added VXLAN ID to their router and join the network.

This is still a very manual process, though one which will probably become more streamlined in the future of the CGHMN network, perhaps with some APIs and/or custom OpenWRT web interface *wink wink*.

This container is only reachable by the firewall itself and by the clients connecting their VXLAN bridge to port 4789 from the Wireguard tunnel, as it doesn't do any routing or hosting of services directly aside from the VXLAN endpoint.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10403</code> on the Proxmox host onsole.

==== Container 10404 (demo-cghmn-legacy-dns, VLAN4, 172.23.4.104) ====
This container, based on Alpine, runs a dnsmasq instance configured to look up certain DNS overrides either in the hosts file at <code>/etc/cghmn-dns-overrides</code> or by including a dnsmasq configuration file from <code>/etc/dnsmasq-cghmn.d/*.conf</code>. Any other requests it cannot resolve locally are forwarded to the Unbound DNS resolver running on the OPNsense router VM. This setup is used to create DNS overrides for existing domains to make old software, which is hardcoded to specific DNS entries, work again with custom servers hosted internally.

Currently, there is no root password set, console access works either via key-based SSH or by entering <code>pct enter 10404</code> on the Proxmox host console.

=== Proposed Organization of IDs and IPs ===
My (Sneps) idea behind Proxmox container and VM IDs are as follows:

'''101xx - 103xx''' are for Containers and VMs in the bridged layer 2 network, so any hosts that members want to run in the bridged network directly.

'''104xx - 107xx''' are for Containers and VMs in the Core Services VLAN4, so anything that is necessary for the operation of the CGHMN network.

'''108xx - 111xx''' are for Containers and VMs in the Servers VLAN8, so anything that members would choose to host on the CGHMN Proxmox.

For IPs, I left the first 10 IPs in each subnet reserved for things like routers, for example (perhaps a second router and a virtual IP for failover down the line?).

After that, the first half of the subnet (see above under Network Layout for the actual start and end of this range) is supposed to be reserved for any hosts that are set up with a fully static IP. This is entirely outside of the DHCP range to avoid any conflicts. That DHCP range then starts with the second half of the subnet and goes up to the last available host IP of each subnet.

=== Other Notes ===

* Currently, the advertised DNS server via DHCP is the included Unbound Server on the OPNsense instance. If we want to completely seal off clients and servers from the rest of the internet, we could directly point the clients towards our root DNS server for all requests.
* Currently, the OPNsense router does DHCP as it already has an IP in each VLAN and comes with a solid DHCP server that can also support failover out of the box (ISC DHCP). I (Snep) chose this route over a standalone DHCP server to avoid having a second container/VM in each subnet that solely does DHCP or DHCP proxying, mainly to keep the setup and maintenance work as low as possible.
* A customized OpenWRT image for the Gl.iNet MT300n and AR300n are currently being built and tested, which includes required packages and UCI configurations out of the box to make joining the network perhaps a little bit easier. Will update this page or create a new one and link to it once a working image exists!

=== Reserved static IPs ===

* '''VLAN1, 172.23.0.11:''' WIREGUARD-EXTERNAL (CursedSilicon)

Compu-Global-Hyper-Mega-Net

2025-05-11T02:32:20Z

Ilostmybagel:

[[Category:Compu-Global-Hyper-Mega-Net]]
=== Preamble ===
Compu-Global-Hyper-Mega-Net (hereby shortened to '''''CGHMN''''' for easier reference) originally started as me making good on a promise to use a Cisco AS5300 I acquired years ago to make a Dial-Up internet provider. Over time while working on the project and watching other YouTubers work on their own ISP projects it became clear that many of them are happy to set up the hardware, there was very little interest (or ability) to make it usable to other folks, or to have anything fun or useful to "do" with it (beyond the novelty of browsing a few vintage websites such as FrogFinder)

CGHMN (its name [https://www.youtube.com/watch?v=9STeegpxSb0 borrowing from a Simpsons joke, naturally]) is another one of my "biting off far more than I can possibly chew" projects. Intended to be an intersection point between art, shitpost, rejection of "internet modernity", refuge for the nostalgic and a communal home for projects of a specifically retro computing bent.

CGHMN is currently in its embryonic stages as I step through the trial-by-fire of the reality of setting up 1990's era telecommunications infrastructure in a way that is both functional and not inconvenient for myself or others in the space it is physically housed in.

An eventual goal is to provide "open" access to an era of the web that has been not so much "lost" as ''obliterated'' by capitalism. A space that can mimic "the vibe" of the late 1990's internet through faithful reconstruction or mimicry of the hardware and software stacks that powered it.

Mechanisms will be implemented to discourage (but not outright prevent) "modern systems" from accessing the network where possible, both for the security of users on the network and to try and further the "vibe" of using period-accurate hardware and software. Using IRC and playing StarCraft on Windows 11 simply isn't as "fun" for us!

A longer term goal includes providing democratized access for users to begin submitting their own projects and content ala [[wikipedia:GeoCities|Geocities]] and setting up federated networking with other retro computing users, similar to GlobalTalk but with a larger scope of features and functionality
=== So what's this all about? ===

CGHMN is a collaborative project aimed to create a late 1990's/early 2000's compatible "internet" for retro computing enthusiasts and their machines

=== Okay so how do I connect to it ===

You can sign up '''[[Signup|right now]]!''' to "alpha test" the network

=== How fast is it? ===

Total internal network capacity is '''''1Gbps''''' (symmetric) due to limitations of the switches in operation. This speed may be raised or lowered depending on future federation with other members.

Your speed will depend on factors such as how fast your device can run Wireguard and your internet connection

=== Is this safe to use? I thought connecting old PC's to the internet was a bad idea! ===

Compu-Global-Hyper-Mega-Net is not accessible by the wider internet and is specifically designed to be a ''hermetically sealed'' network. Users can only connect via the above methods '''and can only communicate with other devices on the network'''. Users that violate the Terms of Service or attempt to abuse the network (or other members) will have their access '''permanently removed'''. With that said the usual rules about not downloading suspicious files and other "internet hygiene" rules still apply. While we don't expect bad actors to be a problem, please ensure that any files contributed to the network are scanned for malware first! [https://www.virustotal.com/gui/home/upload VirusTotal] provides free scanning services for this.

=== How can I help? ===

A lot of folks have offered to donate server hosting which is wonderful. Though not (yet!) required. The two biggest things we need are

'''Donations to buy infrastructure''' (Particularly hard disks!) there's an Amazon Wishlist here that will get updated over time. https://www.amazon.com/hz/wishlist/ls/1W3S0E9IN7ZB7?ref_=wl_share

'''Volunteers who want to set up services'''. Want to come build a website? Run an old game server? Have some weird retro hardware you want to attach to the network? Please, reach out!

Category:Compu-Global-Hyper-Mega-Net

2025-05-11T02:31:14Z

Ilostmybagel: Created page with "Pages relating to the Compu-Global-Hyper-Mega-Net"

Pages relating to the Compu-Global-Hyper-Mega-Net

CGHMN-IP-Allocations

2025-05-11T00:27:53Z

Ilostmybagel: /* Member-Delegated (Sub-) Domains */ Added lily.retro to the member-delegated domains

=== IP Address Allocations in the CGHMN Network ===
This page documents any IP addresses that are allocated statically to routers, subnets and members.

=== Networks on the CGHMN side ===
This is a list of all networks active on the CGHMN server side.
{| class="wikitable"
|+
!Network Name
!VLAN
!Subnet
!Router IP
!Notes
|-
|Core Services
|4
|172.23.4.0/22
|172.23.4.1
| -
|-
|Servers
|8
|172.23.8.0/22
|172.23.8.1
| -
|-
|Global LAN
|256
| -
| -
|No IP traffic, no assigned IP addresses
|-
|Wireguard Members Tunnel
| -
|100.89.128.0/22
|100.89.128.0
|The .0 for the router is not a typo, on P2P links the network address can also be used for a host
|}

=== Members' Networks ===
This list contains the subnets that are assigned to member routers on the network. Members receive one <code>/24</code> network from the <code>100.96.0.0/13</code> block, in first-come-first-serve sequential order per default.
{| class="wikitable"
|+
!Member Name
!Connection Name
!Tunnel IP
!Routed Subnet(s)
!Notes
|-
|CursedSilicon
|AR300 Router
|100.89.128.1
|100.96.1.0/24
| -
|-
|Talija
| -
|100.89.128.2
|100.96.2.0/24
| -
|-
|Snep
|OPNsense box and PPPoE server
|100.89.128.3
|100.96.3.0/24
| -
|-
|Snep
|PC VPN tunnel
|100.89.128.4
| -
| -
|-
|Hadn69
| -
|100.89.128.5
|100.96.5.0/24
| -
|-
|Lily
| Dell PowerEdge r620
|100.89.128.6
|100.96.6.0/24
| -
|-
|Theothertom
| -
|100.89.128.7
|100.96.7.0/24
| -
|-
|Lily
| Hosting
|100.89.128.8
|100.96.8.0/24
| -
|-
|Loganius
| -
|100.89.128.9
|100.96.9.0/24
| -
|-
|GothPanda
| -
|100.89.128.10
|100.96.10.0/24
| -
|}

=== Member-Delegated (Sub-) Domains ===
{| class="wikitable"
|+
!Member Name
!Domain
!Nameserver
!Nameserver IP
!Notes
|-
|Talija
|coyote.retro
|a.ns.coyote.retro
|100.96.2.100
| -
|-
|Snep
|snep.retro
|ns1.snep.retro
|172.23.8.11
| -
|-
|Lily
|lily.retro
|ns1.lily.retro
|100.96.6.250
| -
|}

=== Member Servers hosted on the CGHMN side ===
{| class="wikitable"
|+
!Member Name
!VM/CT ID
!Server Name
!Server IP
!Notes
|-
|Snep
|10811
|srv01.snep.retro
|172.23.8.11
| -
|}

CGHMN-IP-Allocations

2025-05-09T21:20:17Z

Ilostmybagel: /* Members' Networks */

=== IP Address Allocations in the CGHMN Network ===
This page documents any IP addresses that are allocated statically to routers, subnets and members.

=== Networks on the CGHMN side ===
This is a list of all networks active on the CGHMN server side.
{| class="wikitable"
|+
!Network Name
!VLAN
!Subnet
!Router IP
!Notes
|-
|Core Services
|4
|172.23.4.0/22
|172.23.4.1
| -
|-
|Servers
|8
|172.23.8.0/22
|172.23.8.1
| -
|-
|Global LAN
|256
| -
| -
|No IP traffic, no assigned IP addresses
|-
|Wireguard Members Tunnel
| -
|100.89.128.0/22
|100.89.128.0
|The .0 for the router is not a typo, on P2P links the network address can also be used for a host
|}

=== Members' Networks ===
This list contains the subnets that are assigned to member routers on the network. Members receive one <code>/24</code> network from the <code>100.96.0.0/13</code> block, in first-come-first-serve sequential order per default.
{| class="wikitable"
|+
!Member Name
!Connection Name
!Tunnel IP
!Routed Subnet(s)
!Notes
|-
|CursedSilicon
|AR300 Router
|100.89.128.1
|100.96.1.0/24
| -
|-
|Talija
| -
|100.89.128.2
|100.96.2.0/24
| -
|-
|Snep
|OPNsense box and PPPoE server
|100.89.128.3
|100.96.3.0/24
| -
|-
|Snep
|PC VPN tunnel
|100.89.128.4
| -
| -
|-
|Hadn69
| -
|100.89.128.5
|100.96.5.0/24
| -
|-
|Lily
| Dell PowerEdge r620
|100.89.128.6
|100.96.6.0/24
| -
|-
|Theothertom
| -
|100.89.128.7
|100.96.7.0/24
| -
|-
|Loganius
| -
|100.89.128.8
|100.96.8.0/24
| -
|}

=== Member-Delegated (Sub-) Domains ===
{| class="wikitable"
|+
!Member Name
!Domain
!Nameserver
!Nameserver IP
!Notes
|-
|Talija
|coyote.retro
|a.ns.coyote.retro
|100.96.2.100
| -
|-
|Snep
|snep.retro
|ns1.snep.retro
|172.23.8.11
| -
|}

=== Member Servers hosted on the CGHMN side ===
{| class="wikitable"
|+
!Member Name
!VM/CT ID
!Server Name
!Server IP
!Notes
|-
|Snep
|10811
|srv01.snep.retro
|172.23.8.11
| -
|}

CGHMN-IP-Allocations

2025-05-06T22:42:36Z

Ilostmybagel: /* Members' Networks */ Put what device I'm using in the Connection Name

=== IP Address Allocations in the CGHMN Network ===
This page documents any IP addresses that are allocated statically to routers, subnets and members.

=== Networks on the CGHMN side ===
This is a list of all networks active on the CGHMN server side.
{| class="wikitable"
|+
!Network Name
!VLAN
!Subnet
!Router IP
!Notes
|-
|Core Services
|4
|172.23.4.0/22
|172.23.4.1
| -
|-
|Servers
|8
|172.23.8.0/22
|172.23.8.1
| -
|-
|Global LAN
|256
| -
| -
|No IP traffic, no assigned IP addresses
|-
|Wireguard Members Tunnel
| -
|100.89.128.0/22
|100.89.128.0
|The .0 for the router is not a typo, on P2P links the network address can also be used for a host
|}

=== Members' Networks ===
This list contains the subnets that are assigned to member routers on the network. Members receive one <code>/24</code> network from the <code>100.96.0.0/13</code> block, in first-come-first-serve sequential order per default.
{| class="wikitable"
|+
!Member Name
!Connection Name
!Tunnel IP
!Routed Subnet(s)
!Notes
|-
|CursedSilicon
|AR300 Router
|100.89.128.1
|100.96.1.0/24
| -
|-
|Talija
| -
|100.89.128.2
|100.96.2.0/24
| -
|-
|Snep
|MT300n Router
|100.89.128.3
|100.96.3.0/24
| -
|-
|Snep
|PC VPN tunnel
|100.89.128.4
| -
| -
|-
|Hadn69
| -
|100.89.128.5
|100.96.5.0/24
| -
|-
|Lily
| Raspberry Pi
|100.89.128.6
|100.96.6.0/24
| -
|-
|Theothertom
| -
|100.89.128.7
|100.96.7.0/24
| -
|}

=== Member-Delegated (Sub-) Domains ===
{| class="wikitable"
|+
!Member Name
!Domain
!Nameserver
!Nameserver IP
!Notes
|-
|Talija
|coyote.retro
|a.ns.coyote.retro
|100.96.2.100
| -
|-
|Snep
|snep.retro
|ns1.snep.retro
|172.23.8.11
| -
|}

=== Member Servers hosted on the CGHMN side ===
{| class="wikitable"
|+
!Member Name
!VM/CT ID
!Server Name
!Server IP
!Notes
|-
|Snep
|10811
|srv01.snep.retro
|172.23.8.11
| -
|}