How the pieces fit together
The hierarchy VIEW → GUARD → node → ATS/NTS, who connects to whom, and what keeps working when a link is down.
The hierarchy#
SENTRA VIEW governs (optional)
└── SENTRA GUARD (one or more) orchestrates
└── node (server or VM, runs the node agent)
└── Web App · ATS or Internet · NTS enforce on customer traffic
- A node is a server or VM registered on a GUARD. It runs the node agent, which receives work from the GUARD and reports health, traffic and threats back.
- On each node runs one shield: ATS (for websites) or NTS (for internet lines). Each customer gets their own firewall instance.
- VIEW is optional. A GUARD on its own is a complete system with customers, billing, licensing and users. VIEW adds fleet-wide command above several GUARDs.
- ATS and NTS can also run stand-alone, with no GUARD at all: each has its own console, licence and updates.
Who connects to whom#
SENTRA is designed so that lower tiers connect out to the tier above. Nothing needs to reach into a node or a GUARD from outside.
| From | To | What travels | How often |
|---|---|---|---|
| Node agent | its GUARD | Health, traffic, threats, licence state; receives provisioning, updates, users and licences | Polls every 10 seconds by default |
| GUARD | VIEW | A snapshot of customers, nodes, services, invoices and users; receives VIEW's changes (customers, prices, users, licences, updates) | Every 2 seconds while linked |
| VIEW, GUARD (as authorities) | Licensing Authority | Enrolment, and a signed report of every key they issued | On enrolment, then periodically when online |
| Stand-alone ATS / NTS | Licensing Authority | The licence keys it holds (check-in): receives revocations and renewals | About 2 minutes after start, then every 6 hours |
| VIEW, stand-alone ATS / NTS | Release server | Fetch the signed release list and packages | Periodically, and when an admin clicks Check now |
| GUARD | VIEW | Releases for itself and its nodes come from VIEW, with their proofs | When VIEW has a release |
The control plane (VIEW, GUARD, Licensing Authority) is never in the traffic path. If any of them is unreachable, the shields keep inspecting and enforcing with the last policy they received.
When a link is down#
| What is down | What keeps working | What waits |
|---|---|---|
| VIEW | Every GUARD keeps running customers, nodes, billing and users on its own; changes made on a GUARD are sent to VIEW when it is back | Tickets (VIEW only); changes made on VIEW for that GUARD are queued and shown as waiting for the GUARD |
| A GUARD | Its nodes keep protecting traffic; boxes keep signing users in from their cached copy, and a glass-break admin on each box works only while the GUARD is unreachable | Provisioning, moves and updates for those nodes |
| Licensing Authority | All licences keep working offline; VIEW and GUARD authorities keep licensing their fleets within their limits | Revocations and renewals until the next check-in |
| Release server | Nothing changes on the boxes | New updates |
Two directions of change#
When VIEW is linked, both VIEW and each GUARD can change customers, nodes, instances and billing:
- A change made in VIEW is sent to the GUARD that owns the record, which runs it through its own rules and records it as VIEW <user>.
- A change made in a GUARD reaches VIEW with the next snapshot.
- If the same record changed on the GUARD after the VIEW user last saw it, the GUARD refuses VIEW's change and VIEW shows the current values — nothing is silently overwritten.
Some things are owned by VIEW when it is present: the fleet price book (once VIEW has pushed it, GUARDs show prices read-only) and tickets. A GUARD can also be set to Billing from VIEW, in which case only VIEW bills that GUARD's customers.