Hello, I have tried for days on end with no success on this, so I thought I would post it here and see if someone can help me at all. *Here's the scenario:* I have 1 PC with a Static IP/Domain (a dyndns.org account - myserver.homeip.net) connected to a router, which in turn is the gateway to the internet. It also has a static local IP (192.168.1.2). I will call this the "server" from now on. To this, I wish to connect multiple client machines. These clients do not have static local IP's and do not have static internet IP's either (various locations around the globe). When the clients connect to the VPN, I want them to get an address from the pool of 192.168.2.* - up to as many as is needed (up to 8 machines at once perhaps). These IP's could also be static. So, Client1 could have 192.168.2.1, Client 2 could have 192.168.2.2, Client 3 could have 192.168.2.3 for example. The clients will also be standalone machines, and should not grant access to any other services on their own local networks they reside on. What I would like to do is be able to use the server machine as a way of authenticating the other clients, but then have the clients only talk to each other in a big mesh - rather than using all the bandwidth of the server only. So, Client's 1, 2 and 3 would all have direct links with each other once they have authenticated against the main host. However, I understand this is difficult as their IPs will change at varying times. *The outcome:* Clients authenticate with their keys against the master set of keys on the server. Once logged in, they can then see all the services of the other clients also connected to the network. So, if Client1 was running Windows and has folder sharing enabled, and Client 2 has a folder shared, they should be able to see eachothers shares. If client 3 connects, but has no shares, it should still be able to see both Client1 and Client2's shares and use them accordingly - with traffic going only between the required clients and NOT the server (as it only has a limited pipe. *The problems:* The system will need to be key based. All the keys for all the clients will reside on the server inside /tinc/hosts/ and the each individual client will have that very same key. But the problem with having all the keys on all the clients is that their IP's change, so I need to find a centralized way of getting all the clients to find out where each other is. I believe the external IP's of the machines are normally stored inside this key file, but since they have dynamic keys, it causes problems. I assumed you would only need to have inside each client host file something like: "ConnectTo = server *KeyStuff*" And the server would do the rest for me perhaps? Can anyone help me with this scenario at all? I was led to believe Tinc was designed from the ground up to support this type of infrastructure. I read this in the man pages: TunnelServer = yes | no (no) [experimental] When this option is enabled tinc will no longer forward informa? tion between other tinc daemons, and will only allow nodes and subnets on the VPN which are present in the /etc/tinc/NETNAME/hosts/ directory. So, if this was set to No (which it is by fault for each client I guess), does this not suggest that Tinc forwards information about other clients, to other clients on the VPN? IndirectData = yes | no (no) This option specifies whether other tinc daemons besides the one you specified with ConnectTo can make a direct connection to you. This is especially useful if you are behind a firewall and it is impossible to make a connection from the outside to your tinc daemon. Otherwise, it is best to leave this option out or set it to no. And this option seems to suggest things related to my scenario. Anyway, I have said enough I think. Please let me know if I have explained this clearly enough and / or this is possible with Tinc. Any help regarding the above would be appreciated. Thank-you in advance! Andy Barlow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.tinc-vpn.org/pipermail/tinc/attachments/20090304/0a7ecc30/attachment.htm
On Wed, Mar 04, 2009 at 12:56:46PM +0000, Andrew Barlow wrote:> I have tried for days on end with no success on this, so I thought I would > post it here and see if someone can help me at all. > > *Here's the scenario:* >[1 server, multiple clients with changing IP addresses]> > I assumed you would only need to have inside each client host file something > like: > > "ConnectTo = server > *KeyStuff*" > > And the server would do the rest for me perhaps?Yes, that's basically the only thing you need with tinc. The only possible problem is with NAT. Tinc has no support (yet) to penetrate NATs, so clients behind a NAT will have problems talking to each other directly. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.tinc-vpn.org/pipermail/tinc/attachments/20090304/1fcb7416/attachment.pgp
Maybe I am missing something, but since each host already has a public & private key, then why is a 3rd party needed currently? But it is difficult to replicate the public host file to each machine. That is why I would welcome a modified myDns or modified djbdns that holds the public key for each dynamically updated hostname. Hamachi must use a special DNS server to accomplish this. On 3/6/09, Albi Rebmann <albi at life.de> wrote:>> For tinc 2.0> certificate based authorisation will be used that allows > clients to authenticate each other without the need for a third party to > be online. > > Are there news about tinc 2.0? > Release date ;) > > > ALBI... > > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >
The modified DNS server would also need to track the port numbers for hosts behind NAT along with: Table ( PublicKey, DynamicDNShostName, DynamicDNSipAddress (non static public routable), DynamicDNSipPortNumber, StaticTincIPaddress (5.0.0.0/8), StaticMacAddress 55:5dotIPaddress , MemberListOfTincNetworkNames, TTL, ??? ) On 3/6/09, Rob Townley <rob.townley at gmail.com> wrote:> Maybe I am missing something, but since each host already has a public > & private key, then why is a 3rd party needed currently? > > But it is difficult to replicate the public host file to each > machine. That is why I would welcome a modified myDns or modified > djbdns that holds the public key for each dynamically updated > hostname. Hamachi must use a special DNS server to accomplish this. > > > > On 3/6/09, Albi Rebmann <albi at life.de> wrote: >>> For tinc 2.0> certificate based authorisation will be used that allows >> clients to authenticate each other without the need for a third party to >> be online. >> >> Are there news about tinc 2.0? >> Release date ;) >> >> >> ALBI... >> >> >> _______________________________________________ >> tinc mailing list >> tinc at tinc-vpn.org >> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >> >
the keys are too big for .txt records? On Fri, Mar 6, 2009 at 8:19 AM, Rob Townley <rob.townley at gmail.com> wrote:> But it is difficult to replicate the public host file to ?each > machine. ?That is why I would welcome a modified myDns or modified > djbdns that holds the public key for each dynamically updated > hostname. ?Hamachi must use a special DNS server to accomplish this.
On Fri, Mar 6, 2009 at 1:54 PM, David Nicol <davidnicol at gmail.com> wrote:> the keys are too big for .txt records? > > On Fri, Mar 6, 2009 at 8:19 AM, Rob Townley <rob.townley at gmail.com> wrote: >> But it is difficult to replicate the public host file to ?each >> machine. ?That is why I would welcome a modified myDns or modified >> djbdns that holds the public key for each dynamically updated >> hostname. ?Hamachi must use a special DNS server to accomplish this. > - Show quoted text - > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >Have not had much experience with txt record actual vs theoretical restrictions, but would think text records could work fine. Section 6.1 and 6.3 of the DNS Service Discovery draft below recommend no more than 300 bytes even though the previous paragraph says a txt record can be 65535 bytes - probably for performance reasons. The length of the txt record has to be maintained and sent as well. DNS Extensions may work or TSIG and other DNSSEC means. But all of us can think in terms of db columns and leveraging myDNS / mySQL replication.. http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt
http://www.dyndns.com/support/kb/record_types_supported_in_custom_dns_standard_interface.html On Fri, Mar 6, 2009 at 2:34 PM, Rob Townley <rob.townley at gmail.com> wrote:> On Fri, Mar 6, 2009 at 1:54 PM, David Nicol <davidnicol at gmail.com> wrote: >> the keys are too big for .txt records? >> >> On Fri, Mar 6, 2009 at 8:19 AM, Rob Townley <rob.townley at gmail.com> wrote: >>> But it is difficult to replicate the public host file to ?each >>> machine. ?That is why I would welcome a modified myDns or modified >>> djbdns that holds the public key for each dynamically updated >>> hostname. ?Hamachi must use a special DNS server to accomplish this. >> - Show quoted text - >> _______________________________________________ >> tinc mailing list >> tinc at tinc-vpn.org >> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >> > > Have not had much experience with txt record actual vs theoretical > restrictions, but would think text records could work fine. ?Section > 6.1 and 6.3 of the DNS Service Discovery draft below recommend no more > than 300 bytes even though the previous paragraph says a txt record > can be 65535 bytes - probably for performance reasons. ?The length of > the txt record has to be maintained and sent as well. ? DNS Extensions > may work or TSIG and other DNSSEC means. ?But all of us can think in > terms of db columns and leveraging myDNS / mySQL replication.. > > http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >-- "Nah, we straight."