On 05/22/13 15:35, Samuraiii wrote: > The only result I got was a script which every 5 minutes checked all > possible addresses of given machine (my "network" is not big at all - > only eight machines and one network printer). So checking around 20 > addreses is not big deal - but this approach feels clumsy and not > scalable to bigger networks (as have other users from list to deal with). > > Script was just checking (by sftp with public ssh keys for unprivileged > account) if LAN (eth or wifi) address is up and if not it just assigned > address to hostname from vpn range (it did not accounted if machine is > up or down). And the just write new /etc/hosts. > Central dns is possible only in one part of network - only one machine > runs 24/7.
Can't this be changed? If you're running a script to update 20 hosts files regularly, you're reinventing what DNS already does. > > Routers on both sides are just simple boxes which support only built-in > dhcp. > Central DNS and/or routed VPN does not solve problem of compute not in > any of "known" networks. Both would solve the problem. If the routers are the VPN gateways as well, you could decide e.g. that a certain chunk of the VPN space belongs to location 1, and then have the router at location 1 do the appropriate thing (all packets travel through it, after all). This can be done directly with some VPN software, or you can translate the addresses on the fly with iptables. With a DNS server at each physical location, you just have the DNS server at location 1 return the local (location 1) address instead of the VPN address for any hostnames physically located at location 1.
