Other useful notes:
Using VirtualBox works like magic for testing your VPN configurations.
I was slightly distracted using vagrant to manage the VMs but I found
that using the command line for virtual box and the GUI VM manager in
Virtual box is just more obvious and provides greater control over the
network configurations.
Vagrant works nicely to download a OS image and get your first VM
started. But that is all I would recommend using vagrant for, creating
the first starter image.
Then use the VirtualBox GUI and the Headless command line to boot the
vms by name. I am using sshpass in a start script to gracefully shut
down the VMS.
My primary recommendation for each node to use NAT on your first adapter
and then HOST ONLY adapters for all the rest, that way you will have
internet access but the entire CLUSTER of VMs will be able to talk to
each other.
Cheers,
md
On 1/12/2015 6:17 AM, [email protected] wrote:
Hello Tinc users & Guss:
I was sleeping last night and I figured out how to accomplish everything
I ranted about below with no source code changes to TINC.
The first thing to do is create TEMPLATES for tinc.conf, tinc-up, and
the NODE files.
Then during the startup script, use the linux cp command and sed to copy
the template to the correct name and sed to text replace "variables"
with correct values.
For example, in the tinc.conf, have the line Name = [NAME] and sed can
find and replace that text with the proper value supplied in a single
configuration file, THE STARTUP script!
The public key can also be replaced by sed using [PUBLIC KEY]
Another script can run on a cron job and replace
Now all I have to do is every so often, upload a new public and private
key file to the nodes and then remotely call the reload script which
will use sed to manipulate the templates and copy the files to the right
locations with the right values.
Sorry for my earlier rant, only through frustration do we get inspiration!
Cheers all,
md
On 1/11/2015 10:47 PM, [email protected] wrote:
Oops, did I forget to mention how good a design the REST of tinc is,
operationally speaking.
Config files aside, it is a really good VPN.
md
On 1/11/2015 10:05 PM, [email protected] wrote:
I would say the weakest part of the TINC design is the configuration
file layout.
There is no way to split out the essentially static configuration for
all nodes in the cluster and isolate the node specific settings to one
configuration file.
So that means I have to keep an inventory of configuration files per
node so I can edit and deliver them and keep everything straight.
The private keys are in standalone files, but the public key is buried
in along with other node specific settings in the host identifer file.
So that makes it difficult to use a batch script and SSH and just update
all the nodes with a new public/private key pair.
Better yet, an option for a new key pair to autogenerate every N days or
hours and then self deliver the public keys across the net via VPN.
Also, in tinc-up script, I use the $INTERFACE for dynamic device name,
but I would love if more config files, tinc.conf and the host config
files could make more use of the $VARIABLE mechanism
and maybe have a variables config file per node.
That way my tinc-up file would be the same for every node. And my
tinc.conf file.
That way all per node specific settings would be in ONE file and all the
other config files would be static for all nodes in the cluster.
This message is part rant, part request, sorry if I offend anyone.
md
_______________________________________________
tinc mailing list
[email protected]
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
_______________________________________________
tinc mailing list
[email protected]
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
_______________________________________________
tinc mailing list
[email protected]
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
_______________________________________________
tinc mailing list
[email protected]
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
