Configuring and Administering Multi-site Installations: Difference between revisions
(New page: == Using Hamachi for a group of offices == Hamachi can be installed to ease interoffice networking to allow overnight backup/consolidation to a central server and/or remote user access esp...) |
|||
| Line 2: | Line 2: | ||
Hamachi can be installed to ease interoffice networking to allow overnight backup/consolidation to a central server and/or remote user access especially where static ips arent available. | Hamachi can be installed to ease interoffice networking to allow overnight backup/consolidation to a central server and/or remote user access especially where static ips arent available. | ||
The central office or central backup computer should create the hamachi network in order to assign the network joining password and retain the ability to evict other hamachi users when required. | The central office or central backup computer should create the hamachi network(s) in order to assign the network joining password and retain the ability to evict other hamachi users when required. | ||
Nightly backup/consolidation to the central office can be configured to try both direct ip and via hamachi in case either fails. | Nightly backup/consolidation to the central office can be configured to try both direct ip and via hamachi in case either fails. | ||
=== Security risks === | === Security risks === | ||
There is a potential security risk in granting users access to the hamachi network in that it by default grants them network access to all the | There is a potential security risk in granting users access to the hamachi network in that it by default grants them network access to all other members of the same hamachi network with the consequent risk of cross infection by malware and viruses. | ||
Hamachi bypasses hardware firewalls but software firewalls in the server are still effective since hamachi appears as another network adapter. | Hamachi bypasses hardware firewalls but software firewalls in the server are still effective since hamachi appears as another network adapter. | ||
Revision as of 15:19, 1 March 2009
Using Hamachi for a group of offices
Hamachi can be installed to ease interoffice networking to allow overnight backup/consolidation to a central server and/or remote user access especially where static ips arent available.
The central office or central backup computer should create the hamachi network(s) in order to assign the network joining password and retain the ability to evict other hamachi users when required.
Nightly backup/consolidation to the central office can be configured to try both direct ip and via hamachi in case either fails.
Security risks
There is a potential security risk in granting users access to the hamachi network in that it by default grants them network access to all other members of the same hamachi network with the consequent risk of cross infection by malware and viruses.
Hamachi bypasses hardware firewalls but software firewalls in the server are still effective since hamachi appears as another network adapter.
The well known Logmein company provides the software and a directory service so you need to trust them.
Central office router configuration
At least one side of a hamachi connection needs a port mapped on the router in order for full speed communication regardless of which side initiates the connection.
Hamachi can sometimes work at full speed even without the router being configured but it is not advisable to rely on this. The technique is called "udp hole punching".
NEOSYS' standard for the hamachi port is udp 19500 (or 19501 etc where there are multiple computers behind the router)
The port must be configured in hamachi "advanced" menu and mapped in the router.
Other offices router configuration
In a star configuration where most interoffice access is from the central office to the other offices the following is advisable but not required.
It is better to configure all offices hamachi to directly reach each other using the same port mapping as for the central server.
Having both the central and other offices configured in the same way will eliminate "single point of failure" type problem in case hamachi/mapping in the central office doesnt work properly at some point in time.
