Document how invitation files work.
This should eventually be merged in to tinc.texi.
This commit is contained in:
parent
a31e1f03c4
commit
b2200f2166
1 changed files with 87 additions and 0 deletions
87
doc/INVITATIONS
Normal file
87
doc/INVITATIONS
Normal file
|
@ -0,0 +1,87 @@
|
|||
Introduction
|
||||
------------
|
||||
|
||||
Invitations are URLs that encode a tinc server's hostname, port, an ephemeral
|
||||
public key and a cookie. This is enough for an invitee to connect to the
|
||||
server that generated the invitation, verify that it is indeed connected to the
|
||||
right server, and present the cookie to the server as proof that it got the
|
||||
invitation. The server then checks whether it has a corresponding invitation
|
||||
file in its invitations/ directory. The contents of an invitation file that is
|
||||
generated by the "tinc -n vpn invite client" command looks like this:
|
||||
|
||||
Name = client
|
||||
Netname = vpn
|
||||
ConnectTo = server
|
||||
#-------------------------------------#
|
||||
Name = server
|
||||
Ed25519PublicKey = augbnwegoij123587...
|
||||
Address = server.example.com
|
||||
|
||||
The file is basically a concatenation of several host config blocks. Each host
|
||||
config block starts with "Name = ...". Lines that look like `#---#` are not
|
||||
important, it just makes it easier for humans to read the file.
|
||||
|
||||
The first host config block is always the one representing the invitee. So the
|
||||
first Name statement determines the name that the invitee will get. From the
|
||||
first block, the tinc.conf and hosts/client files will be generated; the "tinc
|
||||
join" command on the client will automatically separate statements based on
|
||||
whether they should be in tinc.conf or in a host config file. Some statements
|
||||
are special and are treated differently:
|
||||
|
||||
- "Netname" is a hint to the invitee which netname to use for the VPN. It is
|
||||
used if the invitee did not already specify a netname, and if there is no
|
||||
pre-existing configuration with the same netname.
|
||||
|
||||
- (TBI) "Ifconfig" statements are hints for generating a tinc-up script. The
|
||||
syntax is similar to Subnet statements:
|
||||
|
||||
- "Ifconfig a1:b2:c3:d4:e5:f6" is a MAC address, and hints that the tun/tap
|
||||
interface should get that hardware address.
|
||||
- "Ifconfig 1.2.3.4/16" hints that the tun/tap interface should get IPv4
|
||||
address 1.2.3.4 and netmask 255.255.0.0.
|
||||
- "Ifconfig 1234::5/48" hints that the tun/tap interface shouldg et IPv6
|
||||
address 1234::5 and prefixlength 48.
|
||||
|
||||
Additionally, the following arguments are supported:
|
||||
|
||||
- "Ifconfig dhcp" hints that the tun/tap interface should get an IPv4 address
|
||||
and netmask from DHCP.
|
||||
- "Ifconfig dhcp6" hints that the tun/tap interface should get an IPv6
|
||||
address and netmask from DHCP.
|
||||
- "Ifconfig slaac" hints that the tun/tap interface should get an IPv6
|
||||
address and netmask from SLAAC. Multiple Ifconfig statements are allowed.
|
||||
|
||||
How a tinc-up script is generated depends on the operating system the client
|
||||
is using.
|
||||
|
||||
- (TBI) "Route" statements are similar to "Ifconfig" statements but add routes
|
||||
instead of addresses. These only allow IPv4 and IPv6 routes.
|
||||
|
||||
Subsequent host config blocks are copied verbatim into their respective files
|
||||
in hosts/. The invitation file generated by "tinc invite" will normally only
|
||||
contain two blocks; one for the client and one for the server.
|
||||
|
||||
Writing an invitation-created script
|
||||
------------------------------------
|
||||
|
||||
When an invitation is generated, the "invitation-created" script is called (if
|
||||
it exists) right after the invitation file is written, but before the URL has
|
||||
been written to stdout. This allows one to change the invitation file
|
||||
automatically before the invitation URL is passed to the invitee. Here is an
|
||||
example shell script that aproximately recreates the default invitation file:
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
cat >$INVITATION_FILE <<EOF
|
||||
Name = $NODE
|
||||
Netname = $NETNAME
|
||||
ConnectTo = $NAME
|
||||
#----------------#
|
||||
EOF
|
||||
|
||||
tinc export >>$INVITATION_FILE
|
||||
|
||||
You can add more ConnectTo statements, and change `tinc export` to `tinc
|
||||
export-all` for example. But you can also use the script to automatically hand
|
||||
out a Subnet to the invitee. Note that the script doesn't have to be a shell script,
|
||||
you can use any language, it just has to be executable.
|
Loading…
Reference in a new issue