DIY public node guide

I wanted to put together a more thought out and easy to digest version of how to setup your 3 node as a public gateway node and be able to supply public ip addresses on the grid.

At this time, you have to have access to a public ip block from your isp. This guide is going to assume you have one and it is co figured correctly.

Video Tutorial

-Setting up your node-

you need to have two network ports connected to function in this capacity. Your first network port needs to have access to your private subnet by dhcp and will serve zos. Your second Network interface will handle the public gateway workload so this should be your fastest connection and it will need access to your private subnet by dhcp, and the ability to access your public subnet via static device configuration.

-Configuring your node as a public gateway-

Setting your node up as a public gateway allows your node to help support network capacity it will serve as an access point to both wiregaurd and Yggdrasil while assisting in the forwarding of traffic. This is beneficial in itself even if you have few public ips or even only 1 available because your node becomes a integral part of the mesh network.

To do this you will go to dashboard.tfgrid.io and navigate to your farms page, for this you will be configuring an individual node within your farm. Find the node and click the globe to the far right, in this box you will enter your configuration details


Ipv4-this is public IP address you want your node to utilize for gateway functions. This will be one of the addresses from your public IP block. Proper format is the ip in cidr notation. Ex 162.205.240.131/25

Gateway 4/GW4- this is the default gateway for your public subnet proper format is just the IP address ex. 162.205.240.254

Ipv6-your nodes public ipv6 in cidr notations ex 2600:1700:c1e0:1150:f4d0:96ff:fec9:ecca/64

Gw6-your nodes ipv6 default gateway for the public ipv6 address ex. 2600:1700:c1e0:1150::1

Domain-a web domain that is pointed to the above public configurations with the following record configurations again using 3081 as an example

A: accelerator.tfcloud.us : 162.205.240.131

AAAA: accelerator.tfcloud.us : public ipv6

C_Name: *.accelerator.tfgrid.us

Ns record: _Acme-challenge.accelerator.tfcloud.us

-Making public ips available for use on the grid-

Once you have a node configured as a gateway it also gains the ability to offer additional ips in your public block for deployment, to add these options you will go to the farms page, and expand your farm and navigate to the public ip menu->add ip.


image

You will then have 2 options

Add a single ip or a range of ips, these will be ips that will be attached to deployed vms, so they will become dedicated to the grid at registration, but only used when deployed.

You will need to enter the available IP address in cidr format ex. 162.205.240.131/25 followed by the gateway as just the ip ex 162.205.240.254

Will be doing a few more posts in this thread to follow to detail setting up a domain and going into more detail for the more visual Learners this is my network map and how I document my public configurations.

-3081, the example addresses above, is offline

6 Likes

Reserved for dns post

2 Likes

Threefold Networking, Why its so complicated?

As you enter the space of the threefold public configurations, you will find it gets significantly more complicated then your setup of your DIY three node, And honestly I hope by the end of this you will see that its worth the work and why it is so complicated. I want to start this out by addressing some of the problems you have to be familiar with to understand why all of this is necessary.

With that being said ZOS has a few features that will allow zos to overcome some of these problems but ultimately the TFgrid has ability to create a whole new version of the internet that will allow for significant improvements to modern capabilities.

  • How it works, basically -

The “nuts and bolts” of the threefold network currently run on Wire guard, Yggdrasil, IPV4 and IPV6. You will find that the way these are used allows the technology to be used to do things far beyond the farming and deployment of VMs.

I find the best way to explain what the nodes is doing is to describe it in the form of what you see of the screen, so when you look at your nodes status screen you will see 4 IP address sections ZOS, DMZ, YGG, PUB. To break these down I will address their functions individually

ZOS- This is where ZOS communicates back to the grid, receives updates and is generally the “Management Network” it receives its address by DHCP and is part of your network’s private subnet.

DMZ- This is a virtual interface generated using the same network cable as ZOS, but, this interface is where the magic of Yggdrasil happens. Because most 3nodes exist in homes, they need to be zero configuration while having only a private subnet address, this interface maintains a fully encrypted ipv6 tunnel to the Planetary Network that allows it to receive inbound traffic without a true public address. this address is assigned by dhcp within your private subnet

YGG- This is your nodes Yggdrasil ipv6 address, the concepts behind Yggdrasil are this, It’s a mesh overlay that is decentralized/opensource that uses cryptographic keys to generate ipv6 addresses. The address then belongs to that key not the network. This allows for instance a node to be moved to a different physical location and its workloads still be accessible over Yggdrasil/planetary at the same address without configuration changes. The most important highlight is the Yggdrasil network creates a spanning tree map of every connected node and eventually this could lead to nodes being able to build intra-node IP transport networks. This address is generated by ZOS and will not appear anywhere on your network devices.

PUB- This will be empty unless you have applied a gateway configuration to your node. If your node is configured as a gateway this will be the Ip addresses that are being utilized to server the “backbone” of the grid. Having your node configured as a gateway allows it to become the local hub where three nodes that don’t have public access can enter and receive traffic from the threefold network. It does this in three ways this address is assigned by static configuration when you configure it on the dashboard on the second online nic of your 3node

Wire guard Access Point - This allows other nodes that are local to your node to use that local public Ip address as their wire guard access point. This means that instead of having to go from Belgium to Washington State directly. Your node will also have the option to send that data to a node in Tulsa, OK with a 5-gigabit connection and a sub 100 MS ping to Belgium and have it air mailed over that faster channel.

Planetary Public Peer- This allows your node to become one of the Public Access points for the planetary network/Yggdrasil, you must think of the planetary network as one big “Lan Party”. Or the network of the multiverse. With the planetary network you can abandon the ideas and understanding you have of Ip addresses because they are used for compatibility, but the functions are entirely different. A planetary address is based on cryptographic key pair and has no ”ties” to any particular “fiat network?” this means that I can open my laptop on connected to any network on the planet with internet access and have the same planetary ip address that is publicly accessible to the entire planetary network.

This technology is truly the keystone of what threefold can bring to the table as a huge benefit to the overall planet and how it addresses the problems I discussed above. It fixes the ip address shortage, all planetary traffic is encrypted end to end, and most importantly the planetary network will lay the stage for the threefold grid to be able to exist without dependence on every node having its own ISP connection. When you consider that every single address in the planetary network is a “Public Address” you will start to see how the threefold grid can bring the internet to new places and provide true decentralization

For instance the Planetary network concept supports the ability for a local area to have its own local intranet or “regional Internet” that is interfaced to the public internet through the planetary network. Here in the U.S. another project working on this is Massachusetts Mesh (https://massmesh.org/) they are using Yggdrasil to create a decentralized ISP for their local area.

As a more easy to understand example, the planetary network tech could allow me to place a outdoor wifi antenna on my house that allows them to only access my network over the planetary network, then neighbors could connect to that Wi-Fi Lan, install the planetary network client, and connect to my public planetary address and receive internet over the planetary network without gaining access to my traditional networks. They could then repeat the process and the network would continually expand. This presents every device the option to hop to the fastest local connection at every hop instead of all traffic having to progress through the traditional gateway structuring. Theoretically, if every home in the us had a 3node with a public gateway configuration, traffic could travel over planetary only having to exit the threefold network in extreme locations where there aren’t 2 3nodes within range of each other.

Domain Names- when configuring your gateway nodes you will setup a domain name for the ip address in use and it will have 3 records minimum, an A record, A NS record, and a C_name

A Record- This record allows your node to be accessed using a easily memorable name instead of its IP address.

AAAA Record- This is the ipv6 version and it is optional but good practice.

NS Record- When ZOS deploys a Workload using a domain it will be a subdomain of the nodes gateway domain EX “Workload.Starbuck.Tfcloud.US”. this configuration will allow your name server to find those records on your node * need more documentation here*

C_NAME- This record will be configured so that all Subdomains of your nodes gateway domain are redirected to the IP of your gateway Threenode. This allows your node to dynamically generate new subdomains for deployed workloads, and have them accessible at the IP address of your gateway node.

7 Likes