gfwleak/zhangyang-zerotierone
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

C++ network config master ready to test.

Browse Source
This commit is contained in:
Adam Ierymenko
2015-01-08 14:27:55 -08:00
parent 60fb28a90a
commit 64ba596e0b
9 changed files with 306 additions and 117 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
redis-schema.md
View File

@@ -22,7 +22,7 @@
Network records are used by the network configuration master to issue configurations and certificates to virtual network members. These are the record types you should be interested in if you want to run your own netconf node.
### zt1:network:\<nwid\>:~
### [Hash] zt1:network:\<nwid\>:~
- !R id :: must be \<nwid\>
- !M name :: network's globally unique short name, which can contain only characters valid in an e-mail address. It's the job of the code that populates this DB to ensure that this is globally unique.
@@ -42,22 +42,38 @@ Network records are used by the network configuration master to issue configurat
- M allowPassiveBridging :: if true, allow passive bridging
- M multicastLimit :: maximum number of recipients to receive a multicast on this network
- M multicastRates :: string-encoded dictionary containing multicast groups and rates (see below)
- M encryptionMode :: encryption mode -- 0=always (default), 1=non-local only, 2=disable
- M subscriptions :: comma-delimited list of subscriptions for this network
- M revision :: network revision number
- M ui :: arbitrary field that can be used by the UI to store stuff
Multicast rates are encoded as a dictionary. Each key is a multicast group in "MAC/ADI" format (e.g. *ff:ff:ff:ff:ff:ff/0*), and each value is a comma-delimited tuple of hex integer values: preload, max balance, and rate of accrual in bytes per second. An entry for *0* (or *0/0* or *00:00:00:00:00:00/0*) indicates the default setting for all unspecified multicast groups. Setting a rate limit like *ffffffff,ffffffff,ffffffff* as default will effectively turn off rate limits.
Incrementing the network's revision number causes network configurations to be regenerated automatically on next query by a peer. It's important to note that certificates of membership for private networks permit revision numbers to vary by up to **2**. Thus, revision should be incremented once for changes that do not have authorization implications and twice when de-authorizing a member from a network. For better continuity this double-increment can happen with a time delay between each increment to give still-authorized peers more time to get an updated certificate.
The encryption field allows encryption and full cryptographic authentication to be turned off in some or all cases. This improves performance for fast links such as LANs at the expense of security. Possible values are: (0) -- always encrypt (the default), (1) -- encrypt only for public IP destinations (e.g. not 10.x.x.x), (2) -- disable encryption. When encryption is disabled your traffic is vulnerable to both snooping and man-in-the-middle attacks, so most users will want to stick with the default. For same-data-center SDN-like uses cases we recommend sticking with (1). Only use (2) if you really know what you're doing.
### zt1:network:\<nwid\>:member:\<address\>:~
### [Decimal Integer] zt1:network:\<nwid\>:revision
The revision number holds a decimal integer that can be incremented with the INCR Redis command. It should be changed whenever any network or network member setting changes that impacts the network configuration that is sent to users.
For private networks, the revision is used as part of the network membership certificate. *Certificates agree if their revision numbers differ by no more than one.* This has important implications. Generally speaking, you should INCR the revision *once* for most changes but *twice* when you de-authorize a member. This double increment may be performed with a time delay to allow the surviving members time to grab up to date network configurations before de-authorized members fall off the horizon.
### [Set] zt1:network:\<nwid\>:activeBridges
This is a set of ZeroTier addresses of designated active bridges on this network. It mirrors the state of the activeBridge field in the member record. Code should automatically remove entries from this set when activeBridge is false and add them when activeBridge is true.
### [Hash] zt1:network:\<nwid\>:ipAssignments
This is a hash mapping IP/netmask bits fields to 10-digit ZeroTier addresses of network members. IPv4 fields contain dots, e.g. "10.2.3.4/24" or "29.1.1.1/7". IPv6 fields contain colons. Note that IPv6 IP abbreviations must *not* be used; use \:0000\: instead of \:\: for zero parts of addresses. This is to simplify parser code and canonicalize for rapid search. All hex digits must be lower-case.
This is only used if the network's IPv4 and/or IPv6 auto-assign mode is 'zt' for ZeroTier assignment. The netconf-master will auto-populate by choosing unused IPs, and it can be edited via the API as well.
### [Hash] zt1:network:\<nwid\>:member:\<address\>:~
Each member of a network has a hash containing its configuration and authorization information.
- !R id :: must be \<address\>
- !R nwid :: must be \<nwid\>
- M authorized :: true if node is authorized and will be issued valid certificates and network configurations
- M activeBridge :: true if node is an active bridge
- M activeBridge :: true if node is an active bridge (must mirror state of acticeBridges set)
- M name :: name of member (user-defined)
- M notes :: annotation field (user-defined)
- R authorizedBy :: user ID of user who authorized membership (unused by netconf master)
@@ -68,7 +84,7 @@ Each member of a network has a hash containing its configuration and authorizati
- R lastAt :: real Internet IP/port where node was most recently seen
- R ipAssignments :: comma-delimited list of IP address assignments (see below)
- R netconf :: most recent network configuration dictionary
- R netconfRevision :: revision of network when most recent netconf was generated
- R netconfRevision :: network revision when netconf was generated (decimal integer)
- R netconfTimestamp :: timestamp from netconf dictionary
- R netconfClientTimestamp :: timestamp client most recently reported
- M ui :: string-serialized JSON blob for use by the user interface (unused by netconf-master)
@@ -77,13 +93,7 @@ The netconf field contains the most recent network configuration dictionary for
updated whenever network configuration or member authorization is changed. It is sent to clients if
authorized is true and if netconf itself contains a valid string-serialized dictionary.
The ipAssignments field is re-generated whenever the zt1:network:\<nwid\>:ipAssignments hash is modified for this member. Both the API code and the netconf-master code must keep this in sync. This field is read-only for API users; the ipAssignments part of the API must be used to modify member IP address assignments.
### zt1:network:\<nwid\>:ipAssignments
This is a hash mapping IP/netmask bits fields to 10-digit ZeroTier addresses of network members. IPv4 fields contain dots, e.g. "10.2.3.4/24" or "29.1.1.1/7". IPv6 fields contain colons. Note that IPv6 IP abbreviations must *not* be used; use \:0000\: instead of \:\: for zero parts of addresses. This is to simplify parser code and canonicalize for rapid search. All hex digits must be lower-case.
This is only used if the network's IPv4 and/or IPv6 auto-assign mode is 'zt' for ZeroTier assignment. The netconf-master will auto-populate by choosing unused IPs, and it can be edited via the API as well.
The ipAssignments field is re-generated whenever the zt1:network:\<nwid\>:ipAssignments hash is modified for this member. Both the API code and the netconf-master code must keep this in sync.
# Users (ZeroTier Networks only)
@@ -91,11 +101,9 @@ This record type is only of interest to ZeroTier Networks itself. It holds user
Netconf masters do not use these records so you don't need to worry about this if you are trying to run your own.
### zt1:user:\<auth\>:\<authUserId\>:~
### [Hash] zt1:user:\<auth\>:\<authUserId\>:~
Note: users are referred to elsewhere in the database by their compound key \<auth\>:\<authUserId\> as stored here in the id field.
- !R id :: must be auth:authUserId
- !R id :: must be auth:authUserId -- this is the full key for referencing a user
- !R auth :: authentication type e.g. 'google' or 'local'
- !R authUserId :: user ID under auth schema, like an e-mail address or a Google profile ID.
- M email :: user's email address