*Problem I want to solve:*
We have 3 sites: A, B, and C.
Network admins should have access to all three. (this works as-is).
Desktop support should only have access to their site. (Tech A to site
A, Tech B to site B, Tech C to site C).
*How I think I can do it:*
Working with keys?
Admin's public key will be on all the client machines, and thus, the
client machines will always allow them in. But, technician's public
key will only be on the client machines that they are allowed to manage.
Problem: I cannot find any configs that would support this.
*Working with routes and subnetting?*
Admin would have the routes to get to all machines, techs would only
have routes to get to their local subnet.
Problem: 1) Mesh routing defeats this. 2)Technicians can easily
change their subnet
*Firewalls on the client machines*
Client machines would block traffic from all other subnets except
the admin subnet and the local subnet.
Problem: I cannot control this on a per-technician basis. It's an
all or nothing thing.
How can I do this? (Looking at the configs, I think it's not possible...
or at least not possible in the way I am thinking about it). I am open
to suggestions / alternate tactics.
--
Michael Munger, dCAP, MCPS, MCNPS, MBSS
*Microsoft Certified Professional*
*Microsoft Certified Small Business Specialist*
*Digium Certified Asterisk Professional*
*High Powered Help, Inc.*
p: 678-905-8569
w: hph.io <https://hph.io> e: mj at hph.io <mailto:mj at hph.io>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20181002/aa0ab9eb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bjejhfpfhafagdln.png
Type: image/png
Size: 738 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20181002/aa0ab9eb/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1757 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20181002/aa0ab9eb/attachment.key>
I don't believe tinc will support this level of access control. As far as I can tell, it's all or nothing with tinc. How you configure firewalls on the other hand is up to you. On Tue, Oct 2, 2018 at 4:40 PM Michael Munger <mj at hph.io> wrote:> > Problem I want to solve: > > We have 3 sites: A, B, and C. > > Network admins should have access to all three. (this works as-is). > > Desktop support should only have access to their site. (Tech A to site A, Tech B to site B, Tech C to site C). > > How I think I can do it: > > Working with keys? > > Admin's public key will be on all the client machines, and thus, the client machines will always allow them in. But, technician's public key will only be on the client machines that they are allowed to manage. > > Problem: I cannot find any configs that would support this. > > Working with routes and subnetting? > > Admin would have the routes to get to all machines, techs would only have routes to get to their local subnet. > > Problem: 1) Mesh routing defeats this. 2)Technicians can easily change their subnet > > Firewalls on the client machines > > Client machines would block traffic from all other subnets except the admin subnet and the local subnet. > > Problem: I cannot control this on a per-technician basis. It's an all or nothing thing. > > How can I do this? (Looking at the configs, I think it's not possible... or at least not possible in the way I am thinking about it). I am open to suggestions / alternate tactics. > -- > > Michael Munger, dCAP, MCPS, MCNPS, MBSS > Microsoft Certified Professional > Microsoft Certified Small Business Specialist > Digium Certified Asterisk Professional > High Powered Help, Inc. > p: 678-905-8569 > w: hph.io e: mj at hph.io > > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
On 10/02/2018 05:00 PM, Corey Boyle wrote:> I don't believe tinc will support this level of access control. > As far as I can tell, it's all or nothing with tinc.>From the docs and configs, this was the conclusion I came to as well,but it never hurts to ask. I could have missed something, OR there might be another way to skin that cat. Michael Munger, dCAP, MCPS, MCNPS, MBSS *Microsoft Certified Professional* *Microsoft Certified Small Business Specialist* *Digium Certified Asterisk Professional* *High Powered Help, Inc.* p: 678-905-8569 w: hph.io <https://hph.io> e: mj at hph.io <mailto:mj at hph.io> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20181002/9bec20dc/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: cdenfogpeibhhchf.png Type: image/png Size: 738 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20181002/9bec20dc/attachment-0001.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1757 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20181002/9bec20dc/attachment-0001.key>
On 02/10/2018 17:02, Michael Munger wrote: > there might be another way to skin that cat. Additional complexity, but you could set up *four* tinc VPNs: 1) admin VPN 2) site A VPN 3) site B VPN 4) site C VPN Each of your client machines would then participate in 2 VPNs: the admin VPN and the appropriate site VPN. Each site VPN is NOT a subnet of the admin VPN, but its own separate network. Or maybe I'm missing something...? Best regards, Frank
Definitely considered that. Running different VPNs and even running different instances of the daemon on different ports. But, as you rightly pointed out: *additional complexity*. It basically comes down to: what if you have a bad actor who needs credentials revoked immediately? We have a way of doing this already, but it can take up to 5 minutes to cycle through every machine on the network - and some machines, which are off, have a delay. It would be nice to just disable the key at some central point and then authentication / encryption / decryption just *break* for that bad actor. Michael Munger, dCAP, MCPS, MCNPS, MBSS *Microsoft Certified Professional* *Microsoft Certified Small Business Specialist* *Digium Certified Asterisk Professional* *High Powered Help, Inc.* p: 678-905-8569 w: hph.io <https://hph.io> e: mj at hph.io <mailto:mj at hph.io> On 10/02/2018 05:18 PM, Frank Myhr wrote:> On 02/10/2018 17:02, Michael Munger wrote: > > there might be another way to skin that cat. > > Additional complexity, but you could set up *four* tinc VPNs: > 1) admin VPN > 2) site A VPN > 3) site B VPN > 4) site C VPN > > Each of your client machines would then participate in 2 VPNs: the > admin VPN and the appropriate site VPN. Each site VPN is NOT a subnet > of the admin VPN, but its own separate network. > > Or maybe I'm missing something...? > > Best regards, > Frank > _______________________________________________ > 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/20181002/07aa9432/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgalbdniojcajhm.png Type: image/png Size: 738 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20181002/07aa9432/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1757 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20181002/07aa9432/attachment.key>