Connect to ipv64.net

Node64 runs perfectly well without an account. Connect it to your ipv64.net account and you add the outside view and the online services: checks of your services from the internet, the ipv64 portal, DynDNS, certificates for your ipv64 domains and CDN64 – without opening a single port.

What connecting gives you

An ipv64.net account is free. Which limits apply to which class is listed on the ipv64.net pricing page.

Two parts: API key and health checks sync

The connection to ipv64.net has two parts that complement each other. You can use both, or just the API key.

Get and enter an API key

1. Log in at ipv64.net and create an API key in the API settings of your account.
2. In Node64, open Settings → ipv64 API key, paste the key and click Save and check.
3. Node64 verifies the key with ipv64 and then shows Connected as …, the key's name and its expiry date.

• There is one key for the whole container – every module uses it. It's stored encrypted in the database and never shown again.
• With a key set, the node registers in the node overview on ipv64.net.
• When the key is about to expire, Node64 warns you. Create a new one at ipv64 in good time and enter it here.
• If you remove the key, the features that need it stop working (such as picking names in the DynDNS updater). DynDNS targets you've already set up keep updating.
• Via the API: PUT /api/ipv64/key (field key) and DELETE /api/ipv64/key.

Setting up the health checks sync

The health checks sync permanently connects the Health checks module to ipv64.net. Open the page Healthchecks sync with ipv64 to set it up.

With one click (API key stored)

If an ipv64 API key is stored, click Link with … and optionally choose a location. The key is only used to redeem the link – the node gets its own credentials, which you can revoke individually at ipv64.

With a code

1. Click Link with ipv64.net. The node shows a code that is valid for 10 minutes.
2. Log in at ipv64.net and enter the code. Choose the location and remote management there.
3. The page in Node64 then connects automatically.

After that, you choose for each check where it is measured: locally on your nodes, online only at ipv64, or both (hybrid). Online and hybrid aren't available for Docker checks or for targets inside your network such as private IP addresses, localhost or .local names. More in Health checks.

What gets synced

Once linked, all nodes of an account form one system: every node may change every check, and the nodes field decides which nodes measure it. If two places change the same thing at the same time, the newer change wins. If changes overlap while there's no connection, Node64 shows them as a conflict and you decide which version applies.

Resolving conflicts

A conflict also arises when ipv64 rejects a change made on the node – for example because the online limit of your account plan is reached, the check belongs to another node or the node isn't connected. On the Healthchecks sync with ipv64 page (/link) the card then names the reason (“ipv64 rejected the change: …”) and shows both versions: the node's and the current state at ipv64. Nothing is overwritten silently.

• Older conflicts without a stored reason are never deleted; Send again fetches the reason and the ipv64 state.
• Local API: GET /api/link/conflicts returns the conflicts including error (the reason), POST /api/link/conflicts/{id} resolves one with keep=server (ipv64 state), keep=local (send again) or keep=ignore (keep here only). The metric node64_link_conflicts counts open conflicts.

DynDNS, certificates and CDN64 don't use the sync – they talk to ipv64 directly via the API key. DNS64 doesn't need ipv64 at all.

Who connects where

Every connection goes from the node outwards. You don't need to open any port on your router to connect.

  # Your home network                      # Internet
 ┌─────────────────────────┐
 │         Node64          │  WebSocket, HTTPS 443  ┌────────────────────────┐
 │  Health checks sync ────┼───────────────────────►│ ipv64.net              │
 │                         │                        │ 2 servers: Nuremberg   │
 │                         │  ipv64 API v2, HTTPS   │ and Falkenstein        │
 │  DynDNS, certificates, ─┼───────────────────────►│ API v2, DynDNS update  │
 │  PROXY64, /plans        │                        │ online checks, portal  │
 │                         │                        ├────────────────────────┤
 │  CDN64 ─────────────────┼───────────────────────►│ 2 edge servers in DE   │
 │                         │  tunnel UDP/TCP        │ (CDN64)                │
 └─────────────────────────┘  7844 or 443           └────────────────────────┘
   no open port needed – the node opens every connection to ipv64

• Health checks sync: a permanent WebSocket connection over HTTPS (port 443) to one of two equivalent ipv64 servers in Nuremberg and Falkenstein.
• API key: individual HTTPS requests to ipv64.net whenever a module needs them – for picking DynDNS names, DNS-01 certificates or the account class (your own every 2 minutes, the limits of all classes hourly) – plus registering in the node overview every 15 minutes.
• DynDNS updates: HTTPS calls to ipv64.net with the record or domain token, only when your IP has changed.
• CDN64: a tunnel to two ipv64 edge servers in Germany (Nuremberg and Falkenstein), over UDP or TCP on port 7844 or 443. Details in CDN64.
• Online checks: they only check the targets you enter for them from outside – services that are publicly reachable anyway. Targets inside your network can't be checked online at all.
• Blocklists and version check: PROXY64 downloads the ipv64 blocklists without logging in; the daily version check only runs if you turn it on.

When something goes down

Node64 is built so your home network keeps running when the internet or ipv64 is gone.

Account classes

The limits of your ipv64 account class apply to everything that runs through ipv64 – online checks, DynDNS updates, SMS and CDN, for example. Local measurements and services of the node don't count against them: health checks in your network, DNS64 and the local reverse proxy have no limit.

• The page /plans in the node (Account classes) shows which class you have and what each class includes – grouped by area and with units (GB/TB, Mbit/s, seconds, days), including CDN domains, CDN traffic and CDN bandwidth. “–” means not included.
• The node fetches the values from ipv64 every hour. If a value is missing or there is no connection, it uses the built-in snapshot.
• The node checks your own class every 2 minutes. After an upgrade, sidebar, plans and account overview are correct within a few minutes, and the health check limits are reloaded right away.
• Upgrades and payment are handled at ipv64.net. The current overview is on the pricing page.

Node overview on ipv64.net

With an API key set, the node registers with ipv64.net. On ipv64.net/nodes.php you then see all your Node64 containers in one list – with health check server, honeypot, CDN64 and modules – and can link, remove or re-admit them there.

• When: at startup (after 20 seconds), on changes (checked every minute) and otherwise every 15 minutes, via POST /node64/hello. Every API request also carries the header X-Node64-Node with the node's ID (in headless mode the sensor ID).
• What: name, location, version, platform, mode, enabled modules and a few features – whether the health check sync is linked, IDs of the health check node and honeypot sensor, whether a CDN64 tunnel or DynDNS is running. No secrets, no measurements.
• If you remove the node on ipv64.net, the server answers it with 403 node_removed. The node then deletes the API key, unlinks the health check sync locally – local data stays – and shows a red notice on the dashboard and in the settings. A new API key lifts this.
• Via the API v2, GET /node64/nodes returns the same list.

Unlinking

You can unlink the health checks sync at any time; the node keeps running standalone. When unlinking, you decide whether the checks measured only by this node should keep running at ipv64 as online checks (as far as your limit allows) or be deleted there. Checks of other nodes and pure online checks in your account stay at ipv64 either way.

Privacy

• Without an API key and link, your data stays in your network. Node64 sends no telemetry.
• With an API key, the node registers for the node overview: name, location, version, modules and a few features – no secrets, no measurements.
• Once the health checks sync is linked, the check configuration and its results are transferred to ipv64.net – including targets in your home network that are only measured locally. The interface points this out before you link.
• The ipv64 API key and all other secrets are stored encrypted on the node (see Login & security).
• The ipv64 servers are located in Germany (Nuremberg and Falkenstein).
• How ipv64.net handles your data is described in the ipv64.net privacy policy.

Something unclear, missing, or a question about Node64? Ask in the official forum v64.tech.