Per host key authentication

[Naemr .]

If I am understanding correctly, you have a central node, 3 sub nodes, and
3 techs that should be able to access only the node assigned to them?

and the current issue is that tinc of course tries to help everyone play
nice, thus letting tech A access the site C subnet for example.

simple solution I think.

each site connects to admin, each site does NOT have the keys or
information to connect to each other (note this will cause admin to handle
all routing for each site, desired or undesired?)
also set

IndirectData = no

Forwarding = kernel

in each tinc.conf

You will then need to handle all forwarding rules in the firewall
setup on admin. and thus admin becomes a single point, you run into a
bad actor and you can cut there client off at the firewall, giving you
ample time to rotate out their

public key from their site, if for any reason they hamper this, you
can even close there site off via the firewall or by the admin tinc
config, by temporarily blanking the offending site's public key until
said bad actor is dealt with.

This setup will give you more fine grained control over how tinc
behaves, at the cost of slight increase to kernel cpu overhead, and
requiring direct firewall configuration to handle packet flow.

Setting the above config options in each tinc.conf also ensures that
if a bad actor attempts to bypass those settings by changing them,
they will give themselves away. they will only be able to change the
ones on their own site,

admin being the central point will still have it set for all sites,
and force it to be honored, and the other sites will have it set, thus
ignoring any attempts the bad site makes to talk to them directly.


Forwarding = kernel

 can also be replaced with
Forwarding = off

on each site, leaving admin "holding the bag" for literally all vpn
packet movement










On Tue, Oct 2, 2018 at 2:59 PM Parke <parke.nexus at gmail.com> wrote:

> On Tue, Oct 2, 2018 at 2:41 PM, Michael Munger <mj at hph.io> wrote:
> > It would be nice to just disable the key at some central point and then
> > authentication / encryption / decryption just *break* for that bad actor.
>
> Depending on your specific network topology, 4 separate VPNs might
> very well give you the single break point you want.
>
> If I was going to try to use Tinc to solve your problem, I would start
> by trying the 4 separate VPN approach.
>
> -Parke
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20181004/4fdc5ecd/attachment.html>