Hamachi

Da Wikipedia, l'enciclopedia libera.
Logo di Hamachi

Hamachi è un sistema per la creazione e la gestione di VPN gestito centralmente; comprende il gruppo server gestito dal venditore e il software client, il quale dovrà essere installato sul computer dell’utente finale. Il software è disponibile in versione shareware e freeware (con delle limitazioni). Permette di stabilire un collegamento diretto tra due computer anche in presenza di NAT, in molti casi senza dover riconfigurare quest’ultimo. Attualmente è disponibile in versione beta per Windows, Mac OS X e Linux. È senza dubbio un modo facile e sicuro per accedere alle proprie cartelle condivise, realizzare reti per giocare via Internet, controllare il proprio computer tramite Desktop Remoto o programmi VNC. I computer che sono collegati tramite il software Hamachi risultano virtualmente collegati nella stessa LAN, per cui tutte le applicazioni progettate per lavorare in rete fisica funzionano perfettamente con esso. Inoltre, ogni computer può operare come server in questa rete LAN virtuale. Lo scambio di informazioni è isolato da Internet, e tutto il traffico che si scambiano i peer Hamachi è cifrato. Hamachi assicura la segretezza e la sicurezza di tutte le comunicazioni peer-to-peer, come se i computer fossero connessi direttamente senza attraversare un infrastruttura di rete pubblica. Possiede tutte le caratteristiche di un sistema di tunneling che può gestire l’arbitrario traffico di rete scambiato dai peer Hamachi in base alle loro impostazioni di routing; permette l’accesso a dispositivi di rete, come ad esempio stampanti, sui quali non è possibile eseguire il software ed è in grado di realizzare un accesso sicuro ad utenti che non si collegano da postazioni fisse.


Caratteristiche di sicurezza[modifica | modifica sorgente]

Il sistema Hamachi, come già detto, comprende i server di mediazione (mediation server) gestiti dal venditore e i peer client, cioè i nodi finali del sistema. L’unico compito dei server è quello di tracciare la locazione dei nodi client, e di fornire i servizi di mediazione necessari per stabilire una connessione diretta peer-to-peer tra due utenti. Una volta stabilito il tunnel tra i due client, nessun’altra informazione attraverserà i server, e i client comunicheranno unicamente tra di loro. Quando un peer è attivo, esso stabilisce una connessione TCP con uno dei server disponibili; una volta stabilita la connessione con il server, il peer inizia a scambiare informazioni con il server in base al protocollo Hamachi, per registrarsi e per sincronizzarsi con tutti gli altri peer client attivi e registrati nei server. Il client Hamachi è identificato dal suo indirizzo IP Hamachi (Hamachi network address). L’indirizzo viene assegnato quando il client si connette per la prima volta al server di mediazione, e rimane lo stesso fino a quando l’account del client esiste nel sistema Hamachi. Il client genera anche una coppia di chiavi RSA (RSA key pair), che userà per l’autenticazione durante la sequenza di registrazione. La chiave pubblica viene inviata al server una volta, durante la prima connessione quando viene creato il nuovo account. Per la registrazione nel sistema, il client spedisce il suo indirizzo IP Hamachi e usa la sua chiave privata per firmare il challange del server. Il server verifica la firma ricevuta dal client e autentica quest’ultimo.

Ogni server di mediazione possiede una coppia di chiavi RSA. La chiave pubblica è distribuita insieme al pacchetto di installazione, quindi il client ne è in possesso ancora prima di connettersi per la prima volta al sistema. Quando il client si connette al server di mediazione, annuncia quale identità il server dovrebbe avere. Se il server possiede l’identità richiesta dal client, la sequenza di registrazione inizia. Nell’ultimo messaggio di questa sequenza il server spedisce una firma dei dati del client e questo conferma l’identità del server al client. Non appena il client si connette al server di mediazione avviene uno scambio di chiavi. Questo scambio produce del materiale di codifica utilizzato per generare le chiavi per codificare e autenticare tutti i messaggi relativi agli altri protocolli. I messaggi sono cifrati con l’ algoritmo AES a chiave simmetrica e autenticati tramite MAC. Ogni messaggio è numerato con un identificatore unico, in modo da prevenire i replay-attack. La crypto suite specifica gli algoritmi impiegati e i relativi parametri utilizzati per lo scambio delle chiavi, per ottenere le chiavi e per la cifratura dei messaggi; la crypto suite predefinita di Hamachi è la seguente: Diffie-Hellman group 2048-bit MODP, AES-256 CBC mode e HMAC-SHA1-96. Hamachi utilizza il protocollo Diffie-Hellman per lo scambio delle chiavi con i seguenti parametri:


 ·  Il numero primo p=22048-21984-1+264x{[21918p]+124476}, e il
    corrispettivo valore in esadecimale è:
         FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 0DC1CD1
         29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
         EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
         E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
         EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
         C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
         83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
         670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
         E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
         DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
         15728E5A 8AACAA68 FFFFFFFF FFFFFFFF.
 ·  Il generatore g è 2.

L’algoritmo AES viene utilizzato con una chiave di cifratura di 256 bit per cifrare e proteggere la comunicazione tra i peer Hamachi. Per garantire l’integrità dei messaggi scambiati tra i peer, Hamachi utilizza l’algoritmo HMAC-SHA1-96.

Dettagli del protocollo[modifica | modifica sorgente]

Il client si connette al server di mediazione ed invia ad esso un messaggio HELO, nel quale saranno inseriti i parametri di sicurezza della connessione (crypto suite, fingerprint della chiave pubblica del server, valori Diffie-Hellman). A questo messaggio il server risponde HELO OK inviando i propri valori Diffie-Hellman. In seguito a questo scambio di messaggi il client e il server di mediazione generano il materiale per la cifratura. Per registrarsi nel sistema Hamachi, il client invia un messaggio AUTH al server di mediazione inserendo i parametri necessari per la sua autenticazione da parte del server di mediazione, che vedremo più nel dettaglio nei paragrafi seguenti. Se l’autenticazione va a buon fine il server risponde con AUTH OK. A questo punto, se l’autenticazione è andata a buone fine, il client è registrato nel sistema Hamachi e può comunicare con qualsiasi altro client Hamachi attivo che fa parte della stessa VPN.

HELO[modifica | modifica sorgente]

Il client si connette al server e invia il seguente messaggio:

               HELO CryptoSuite ServerKfp Ni Gi
 ·  CryptoSuite: contiene il valore 1 per la crypto suite predefinita;
 ·  SeverKfp: contiene il fingerprint esadecimale di tipo OpenSSH,
              ottenuto dall’hash calcolato con SHA1 della chiave pubblica del
              server di mediazione. Il fingerprint viene utilizzato per evitare che un
              attaccante si sostituisca al server di mediazione, prevenendo gli
              attacchi man-in-the-middle;
 ·  Ni: nonce di 1024 bit del client, ovvero una stringa di bit casuali, che
       contribuiscono alla generazione del materiale per la cifratura;  
 ·  Gi: contiene l’esponente pubblico Diffie-Hellman del client.

Una volta ricevuto il messaggio di HELO dal client, se il server possiede una chiave pubblica che combacia con il campo ServerKfp, esso risponde al client inviando il seguente messaggio:

               HELO OK Nr Gr
 ·  Nr: nonce di 1024 bit del server di mediazione;
 ·  Gr: contiene l’esponente pubblico di Diffie-Hellman del server di
       mediazione.

KEYMAT[modifica | modifica sorgente]

A questo punto sia il client che il server calcolano il valore riservato di Diffie-Hellman, e con esso generano il materiale per la cifratura:

KEYMAT=T1 | T2 | T3 |…
T1=prf(K, Ni | Nr | 0x01)
T2=prf(K, T1 | Ni | Nr | 0x02)
T3=prf(K, T2 | Ni | Nr | 0x03)
…
·  K: rappresenta il valore segreto di Diffie-Hellman condiviso;
·  prf: è l’algoritmo HMAC-SHA1.

Tutti i successivi messaggi sono cifrati con la chiave Ke e sono autenticati utilizzando la chiave Ka; entrambe le chiavi sono ottenute dalla KEYMAT. Nel caso in cui si utilizzi la cryptosuite predefinita, la chiave Ke utilizza i primi 256 bit della KEYMAT mentre la chiave Ka utilizza i seguenti 160 bit. Prima di cifrare un messaggio il mittente aggiunge il padding ad esso, in modo che la lunghezza del messaggio da cifrare e inviare sia multipla del blocco che l’algoritmo di cifratura utilizza; nel caso della cryptosuite predefinita la grandezza del blocco è di 128 bit. Successivamente un vettore di inizializzazione (IV) casuale viene generato e il messaggio da inviare viene cifrato. In coda al messaggio cifrato risultante viene aggiunto l’IV mentre in testa viene inserito un ID del messaggio, rappresentato da un numero di 32 bit monotonicamente crescente. Se il messaggio viene inviato utilizzando il protocollo TCP , sarà aggiunto ad esso anche un campo size di 32 bit, mentre se il messaggio viene inviato con UDP (figura 3.2) sarà aggiunto in testa un campo SPI di 32 bit. Infine viene calcolato un HMAC sull’intero messaggio e viene aggiunto ad esso. A questo punto il messaggio può essere inviato in rete.

Registrazione[modifica | modifica sorgente]

Dopo aver instaurato una connessione con il server remoto ed aver condiviso tutte le informazioni necessarie per la cifratura e l’autenticazione, il client necessita la registrazione all’interno del sistema. La registrazione avviene tramite l’invio del seguente messaggio:

        AUTH Identity Signature (CryptoSuite | Ni | Nr | Gi | Gr, Kpri_cli)
 ·  Identity: rappresenta l’indirizzo Hamachi a 32 bit che identifica
              univocamente il client; questo indirizzo viene assegnato al client
              quando si connette per la prima volta al sistema Hamachi;
 ·  Signature: rappresenta l’hash ottenuto con SHA1 della
               concatenazione del valore rappresentante la cryptosuite, dei nonce e
               degli esponenti Diffie-Hellman pubblici del client e del server, cifrato
               con Kpri_cli, cioè con la chiave privata del client.

Una volta ricevuto l’AUTH inviatogli dal client, il server utilizza il campo Identity per localizzare l’account del client, ottenendo in questo modo la sua chiave pubblica e verificando la signature ricevuta. Se la signature ricevuta è corretta il server di mediazione risponde con:

          AUTH OK Signature (Nr | Ni | Gr | Gi, Kpri_srv)
 ·  Signature: viene creata utilizzando la chiave privata del server
               Kpri_srv che corrisponde con il campo ServerKfp contenuto nel
               messaggio di HELO inviato dal client al momento della connessione;

Come abbiamo visto anche il campo CryptoSuite viene compreso nell’hash di autenticazione; questo avviene a partire dalla versione 1.0.0.52 del software client per Windows.


Traffico peer-to-peer[modifica | modifica sorgente]

Una volta che il server di mediazione realizza il tunnel tra i due peer Hamachi, esso genera un coppia di numeri casuali SPI di 32 bit. La coppia di numeri SPI sono utilizzati per etichettare il traffico in transito tra i due peer Hamachi; un SPI identifica il traffico in una direzione, mentre il secondo SPI identifica il traffico nella direzione opposta. Quando un client riceve un pacchetto UDP cifrato riconosce il peer tramite il valore SPI contenuto nel pacchetto, ottiene la chiavi crittografiche e procede con l’autenticazione e la decifratura. Le chiavi per la comunicazione peer-to-peer sono ottenute in maniera differente a seconda della versione del software client. Nelle versioni meno recenti, ovvero dalla versione 0.9.9.5 e versioni più vecchie, la KEYMAT veniva ricevuta direttamente dal server di mediazione, il quale la generava in modo casuale. Tutte le versioni più recenti, a partire dalla versione 0.9.9.6, eseguono in maniera autonoma lo scambio delle chiavi per generare la KEYMAT. Per prima cosa i peer scelgono chi dovrà iniziare lo scambio delle chiavi, confrontando i valori SPI del tunnel l’uno con l’altro. Il peer che possiede il valore SPI più basso di ritorno sarà l’iniziatore. L’iniziatore invierà:

                        KE1 Ni Gi
 ·  Ni: contiene il nonce di 1024 bit dell’iniziatore;
 ·  Gi: contiene l’esponente pubblico di Diffie-Hellman dell’iniziatore.

Il peer iniziatore continuerà ad inviare il messaggio KE1 con un intervallo di N millisecondi, fino a quando non riceverà una risposta. Il messaggio di risposta è il seguente:

             KE2 Nr Gr Signature(Nr | Ni | Gr | Gi, Kpri_r)
 ·  Nr: nonce di 1024 bit del rispondente;
 ·  Gr: esponente pubblico di Diffie-Hellman del rispondente;
 ·  Signature: viene realizzata con la chiave privata del rispondente.

Il rispondente invia solo i valori Nr e Gr, non deriva ancora la chiave peer-to-peer da Ni e Gi in quanto non può essere ancora certo dell’identità dell’iniziatore, poiché quest’ultimo non si è ancora autenticato. Ricevuto KE2 l’iniziatore verifica la Signature e deriva da questa le chiavi peer-to-peer con lo stesso meccanismo della generazione ed estensione della KEYMAT nel caso della comunicazione tra client e server. Quindi l’iniziatore replica con:

                KE3 Ni Gi Signature(Ni | Nr | Gi | Gr, Kpri_i)

Il rispondente verifica la Signature, deriva le sue chiavi peer-to-peer e risponde con un messaggio fittizio (dummy message) cifrato all’iniziatore per indicare che la fase di scambio delle chiavi è terminata con successo. Il messaggio fittizio è un messaggio vuoto il cui unico scopo è quello di segnalare che la fase di scambio è terminata. Come avviene per il messaggio KE1 l’iniziatore continua a reinviare il messaggio KE3 periodicamente finché non riceve una risposta. Per poter verificare la Signature dei nodi durante la fase di scambio delle chiavi, il client deve avere la chiave pubblica del nodo, che può essere ottenuta in due modi: o richiedendola dal server di mediazione, o ricevendola attraverso un altro canale e installandola manualmente. Per la sicurezza degli utenti è buona cosa sottoporre le chiavi pubbliche ad una verifica manuale per assicurarsi della loro autenticità.

Funzionamento[modifica | modifica sorgente]

L’installazione del software Hamachi (nel testo faremo riferimento alla versione 1.0.1.3 per windows) è molto semplice. Infatti è sufficiente avviare il setup e seguire le istruzioni che compaiono a video; il software installato è pronto per essere utilizzato, senza particolari configurazioni o settaggi. Durante il primo avvio, il client Hamachi si connette al server di mediazione che fornisce ad esso il suo indirizzo IP Hamachi. Questo indirizzo IP del tipo 5.xxx.xxx.xxx è l’ identificativo univoco del client all’interno del sistema Hamachi, e rimane tale fino a quando il client sarà registrato all’interno del sistema; questa classe di indirizzi è riservata dall’IANA, ma attualmente non è utilizzata nel dominio di indirizzamento di Internet. Ogni client stabilisce e mantiene una connessione di controllo tramite TCP con il gruppo dei server di mediazione. Se il tentativo di connessione tramite TCP dovesse fallire, il client Hamachi tenta una connessione al server tramite il protocollo SSL. Una volta stabilita la connessione con il server, il client inizia la sequenza di autenticazione, che autentica il client al server e viceversa, seguita da un processo di discovery e di sincronizzazione. Il discovery viene utilizzato per determinare la topologia della connessione ad internet del client, in particolare per verificare la presenza di NAT e dispositivi firewall sul percorso verso Internet. Il processo di sincrornizzazione fornisce al client una panoramica della propria rete privata in sincronia con gli altri membri della rete. Quando un membro della rete diventa online od offline, il server di mediazione avvisa gli altri membri della rete di questo evento e dà istruzione rispettivamente di stabilire un tunnel con il nuovo peer, oppure di eliminare il tunnel precedentemente creato. Quando tutti i membri della rete privata sono stati localizzati attraverso il server di mediazione, la comunicazione diventa completamente peer-topeer e avviene utilizzando UDP come protocollo di trasporto; da questo momento in poi nessun’altra informazione appartenente alla rete privata attraverserà i server di mediazione. Come abbiamo già visto i client Hamachi sono identificati mediante il loro indirizzo IP Hamachi; la traduzione di questo indirizzo in un indirizzo IP valido avviene quando il tunnel tra due peer viene realizzato. Solo a questo punto i due peer conoscono l’indirizzo IP reale del peer all’estremità opposta del tunnel; naturalmente questo avviene solamente sotto il controllo del server di mediazione, e solo se i peer fanno parte di almeno una rete comune. Per stabilire un tunnel tra una coppia di peer, Hamachi impiega una tecnica di NAT-traversal assistita dal server, simile alla tecnica UDP hole punching. I dettagli sul funzionamento della tecnica impiegata da Hamachi non sono stati resi pubblici, per cui ci limitiamo a descrivere brevemente l’UDP hole punching per capirne il funzionamento. Siano A e B due host, N1 e N2 sono i due dispositivi NAT e S è il server pubblico con un indirizzo IP globalmente raggiungibile. I passaggi svolti sono i seguenti:

  1. A e B iniziano una comunicazione con S; i dispositivi NAT N1 e N2
     creano le regole di traduzione UDP e assegnano dei numeri di porta
     temporanei;
  2. il server S ritrasmette questi numeri di porta agli host A e B;
  3. A e B connettono i loro rispettivi dispositivi NAT direttamente alla
     porta assegnata in precedenza; i dispositivi NAT utilizzano le regole
     di traduzione precedentemente create e scambiano pacchetti tra A e
     B.

Il client Hamachi crea una interfaccia di rete virtuale che è soggetta alle regole del firewall che protegge il computer. Questa interfaccia di rete virtuale è usata per intercettare il traffico VPN in uscita e per immettere il traffico in entrata. Il traffico in uscita spedito dal sistema operativo verso questa interfaccia viene consegnato al software client, il quale lo cifra, lo autentica e lo spedisce al peer di destinazione attraverso la comunicazione UDP stabilita tra i peer. Le stesse operazioni avvengono in senso opposto. Hamachi utilizza i driver TUN/TAP per creare l’interfaccia di rete virtuale. Questi driver permettono infatti di creare delle periferiche di rete virtuali, ma diversamente dalle periferiche di rete che sono controllate direttamente dalle schede di rete, i pacchetti spediti da o verso i dispositivi TUN/TAP vengono spediti da o verso programmi software, nel nostro caso verso il client Hamachi.

Connessioni alternative[modifica | modifica sorgente]

Il software Hamachi cerca sempre di stabilire una connessione diretta tra due peer. Il tempo impiegato per stabilire la maggior parte di queste connessioni è di solito al di sotto di pochi secondi, ma in alcuni rari casi il tempo impiegato può essere di alcuni minuti. Quando la connessione diretta è stata stabilita il traffico segue il percorso più breve possibile e con la migliore qualità di connessione, in termini di larghezza di banda e di latenza. Quando Hamachi non riesce a stabilire una connessione diretta, cercherà di stabilire una connessione attraverso uno dei relay Hamachi. Un relay è un computer dedicato connesso ad Internet, gestito dalla ditta Hamachi, il cui unico scopo è quello di inoltrare tutto il traffico di rete tra due peer, facendo da tramite nella comunicazione. Dal momento che il traffico viaggia attraverso un percorso lungo, la latenza delle connessioni tramite relay è maggiore delle connessioni dirette. La velocità della connessione invece dipende dal tipo di computer relay utilizzato; i due tipi di velocità sono le seguenti:

 ·  relay low-speed: connette una coppia di peer Hamachi sui quali è
                     installata la versione gratuita del software, che non sono in grado di
                     stabilire una connessione diretta. Tutte le versioni precedenti alla
                     1.0.0.62 richiedono che l’impiego dei computer relay sia scelto tramite
                     una opzione; in tutte le versioni successive questa funzionalità è
                     automatica;
 ·  relay high-speed: connette un peer Hamachi su cui è installata la
                      versione Premium, cioè la versione a pagamento, ad un altro
                      qualsiasi peer appartenente alla sua rete.

Poiché il traffico scambiato tra due peer attraversa i computer relay possono sorgere dei dubbi sulla riservatezza della comunicazione. Ricordiamo però che la comunicazione tra due client Hamachi viene protetta tramite cifratura, e che solo i client conoscono le chiavi di cifratura, per cui il relay non ha la possibilità di violare la segretezza delle informazioni che gestisce.


Differenze tra le versioni free e Premium[modifica | modifica sorgente]

Il software client Hamachi è disponibile in due versioni: versione free e versione Premium. La versione Premium richiede l’acquisto di una licenza Premium da installare sul computer, il cui costo varia da poco meno di 3$ a circa 5$ al mese. Le variazioni del costo della licenza Premium sono dovute alla durata della licenza, che può essere mensile, semestrale od annuale, e al numero di licenze che sono acquistate. Entrambe le versioni del client sono soggette ad un numero massimo di utenti per rete, ed ogni client può essere membro di un numero limitato di reti. Nel caso della versione free il numero massimo di utenti per rete è 16, ed il client può essere membro al massimo di 64 reti, incluse quelle di cui è proprietario. Per la versione Premium i limiti sono invece di 256 membri per rete, e lo stesso valore possiede il limite di reti a cui può appartenere un client, comprese le reti di cui è proprietario. Ogni client che vuole unirsi ad una rete deve inserire una password di rete valida, la quale deve essere non vuota è che può essere modificata dal proprietario della rete o da un amministratore. La versione Premium permette però ad un peer qualsiasi di unirsi ad una rete senza dover inserire alcuna password di rete, solamente conoscendone il nome. La versione Premium consente di bloccare la rete, cioè previene che nuovi client cerchino di unirsi alla rete; questo però non modifica tutti gli altri settaggi di controllo degli accessi. Inoltre ogni nuovo membro non disporrà di un accesso completo alle risorse della rete fino a che non riceverà l’approvazione da parte del proprietario o di uno degli amministratori. Un proprietario o un amministratore può espellere un client dalla rete di cui è membro, ma ciò non impedisce ai client rimossi dalla rete di riunirsi ad essa. La versione Premium aggiunge la possibilità di vietare ad un client di unirsi alla rete; la rete è in grado di preparare una lista, la lista di ban, che contiene l’elenco dei client Hamachi che non possono unirsi ad essa sotto alcune condizioni. La lista di ban è gestita dal proprietario della rete o da uno degli amministratori. Il proprietario di una rete può assegnare ad uno o a più membri della rete i privilegi di amministratore, inoltre il proprietario può gestire la lista dei privilegi assegnati agli amministratori di rete:

 ·  impostare la password di rete;
 ·  bloccare la rete e modificare le impostazioni di accesso;
 ·  approvare o respingere le richieste di client che intendono unirsi alla
    rete;
 ·  espellere membri dalla rete;
 ·  vietare o consentire l’accesso ai membri della rete;
 ·  impostare dei messaggi di benvenuto e di annuncio.

La possibilità di scegliere degli amministratori di rete è possibile solo con la versione Premium, ed inoltre un amministratore può essere scelto solo se possiede un account Premium. La versione Premium consente ad un proprietario o ad un amministratore di impostare dei messaggi di benvenuto e di annuncio per la rete. Un messaggio di benvenuto è spedito automaticamente ad un nuovo membro della rete quando esso si collega per la prima volta alla rete privata, ed è molto utile per diffondere le politiche e le norme di rete. Un messaggio di annuncio è inviato ad ogni membro di rete ed è utile per fare degli annunci, come per esempio la modifica della politica di rete. Come abbiamo più volte ripetuto la comunicazione tra i client Hamachi è cifrata; per migliorare il rendimento di una rete Hamachi la versione Premium permette di disabilitare la cifratura, rendendo lo scambio delle informazioni in chiaro. La comunicazione non cifrata può avvenire solo tra client Hamachi Premium, mentre la comunicazione tra un client Premium e un client free, e tra una coppia di client free rimarrà cifrata come sempre. Hamachi consente lo scambio di messaggi istantanei tra i peer che sono online, ovvero tra i peer che sono connessi alla rete di cui fanno parte. La versione Premium dà anche la possibilità di scambiare messaggi istantanei tramite server quando i client sono offline, e non sono connessi alla rete; per poter usufruire di questa funzionalità entrambi i client devono aver installata la versione Premium. Hamachi consente di scambiare messaggi istantanei di rete, ovvero permette a tutti i membri online di una rete di scambiarsi messaggi tra loro in una sorta di chat pubblica; la versione free del client limita questa funzionalità alla sola ricenzione di messaggi di rete, e non ne permette l’invio. Abbiamo già visto che nel caso in cui Hamachi non riesca a stabilire una connessione diretta tra due peer, questi vengono messi in comunicazione tramite un relay. La versione free supporta solo i relay low-speed, mentre la versione Premium supporta anche i relay highspeed, che permettono comunicazioni a velocità maggiore e con latenza inferiore ai relay low-speed. Hamachi può essere eseguito come servizio di sistema; questo è necessario quando Hamachi è in esecuzione su un server o in configurazioni che implicano l’autenticazione in un dominio Windows. La versione Premium consente di eseguire il client come servizio di sistema tramite una opzione, mentre per la versione free l’impostazione dovrà essere fatta manualmente. In aggiunta, per gestire il traffico tra due client, Hamachi può essere configurato per permettere l’accesso remoto a computer di una LAN su cui non è in esecuzione o su cui non può essere eseguito il client Hamachi. Questa caratteristica, disponibile sia con la versione free e Premium del client, essenzialmente permette il tunneling di qualsiasi traffico mediante una connessione peer-to-peer Hamachi. Un’applicazione possibile di Hamachi consiste nel suo impiego come web proxy. In questa configurazione un client Hamachi svolge la funzione di web proxy che fornirà l’accesso ad Internet agli altri client, che dovranno configurare il loro browser web per accedere ad Internet tramite il web proxy. In questo modo il traffico web sarà protetto tra il client e il web proxy. La versione free possiede un limite massimo di 2.5 MB di traffico che può attraversare il proxy; raggiunto il limite massimo, per azzerare il contatore è necessario riconnettere il client proxy al sistema.

Collegamenti esterni[modifica | modifica sorgente]