OpenVPN vs Hamachi

[RICCARDO]

Mi sono letto un bel po' di doc. su OpenVPN e qualcosa su Hamachi,
evrei intenzione di utilizzare per OpenVPN creare un tunnel host-to-
host tra il pc di casa (Alice ADSL con IP dinamico)
e un server a lavoro (rete Fastweb residential con NAT condiviso).
Ho necessita' di questa vpn per monitorare da casa il mio server di
lavoro
utilizzando i protocolli SSH, HTTPS ed eventualmente il sw VNC.
Pero' mi sorgono dei dubbi:

1 - Il tunnel si puo' stabilire solo se la connessione inizia prima
dall'endpoint lato Fastweb ?

Sto' valutando anche il fatto di utilizzare Hamachi ma anche qui'
certi concetti mi sfuggono

2 - Con Hamachi e' possibile iniziare la connessione per primo dal
lato Fastweb ?
3 - Hamachi gestisce il Nat2Nat, ma OpenVPN ?

4 - TRIP65 (un iscritto alla ML) ha affermato che OPenVPN ha il
rovescio della medaglia
nell'impegno di banda sulla connessione con ip pubblico , fatto che
invece si puo' evitare con hamachi che utilizza
solo la banda fastweb. NON HO CHIARO QUESTO DISCORSO chi puo'
spiegarmelo ?
Di seguito descrivo il testo completo di questa affermazione:
(vedi: VPN verso Fastweb, risposta TRIP65, 1 Gen 2008 10:09)

<< OpenVPN e' il sistema , tra i tanti provati, è quello che assicura
piu' stabilità su
connessioni fastweb residential che usano un nat condiviso.
Inoltre possono essere aperte varie vpn con altrettanti host in modo
da
realizzare una struttura sicur e porotetta da occhi indiscreti.
Difatti la connessione risulta cifrata e protetta con certificati che
potrai
creare ad hoc .
In questo modo si superano tutte le problematiche di ip privato , il
rovescio della medaglia sta nell'impegno di banda sulla connessione
con ip pubblico , fatto che invece si puo' evitare con hamachi che
utilizza
solo la banda fastweb. >>

[Hozomeen]

Ciao,

Mi sono letto un bel po' di doc. su OpenVPN e qualcosa su Hamachi,
evrei intenzione di utilizzare per OpenVPN creare un tunnel host-to-
host tra il pc di casa (Alice ADSL con IP dinamico)
e un server a lavoro (rete Fastweb residential con NAT condiviso).

non puoi prendere un ip pubblico sul server dell'ufficio? Altrimenti non
sara' per niente semplice.

1 - Il tunnel si puo' stabilire solo se la connessione inizia prima
dall'endpoint lato Fastweb ?

eh si.

Sto' valutando anche il fatto di utilizzare Hamachi ma anche qui'
certi concetti mi sfuggono
2 - Con Hamachi e' possibile iniziare la connessione per primo dal
lato Fastweb ?

hamaci non fa magie. Praticamente devi mantenere un tunnel sempre attivo tra
il tuo server dell'ufficio (iniziato dall'ufficio) e quello di hamaci.
Quando sei a casa apri un secondo tunnel verso hamaci, e hamaci girera'
verso di te quello che proviene dal tuo ufficio.

Ci sono un sacco di post sulle vpn e sembra che alcuni sistemi facciano cose
mai viste...il problema del nat di fw in realta' non si puo' risolvere, ma
solo aggirare se il server e' interno alla rete fw. Il motivo in effetti e'
molto semplice se pensate cosa fa il NAT di fastweb e come funziona un
tunnel.
Provo a farvi un bigino...vediamo se riesco a spiegarmi.

Allora...un tunnel cifrato o vpn (come volete chiamarlo) e' una sessione tra
due sistemi in cui uno contatta l'altro tramite il suo indirizzo IP. I due
sistemi, non sono simmetrici, ovvero non partecipano in modo paritetico alla
creazione di questa sessione: non fanno le stesse cose. Uno si chiama server
e puo' solo accettare connessioni, l'altro si chiama client e puo' solo
iniziare connessioni.
E' evidente quindi che il client deve sapere l'indirizzo del server per
poterlo contattare, mentre il server scopre l'indirizzo del client nel
momento stesso in cui riceve la richiesta del client.
Detto questo, il NAT di Fastweb nasconde decine di indirizzi privati dietro
ad uno solo pubblico mutliplando dinamicamente molte sessioni sulle porte
TCP/UDP (cercate PAT per capire come funziona). Quindi un eventuale server
all'interno di fastweb condivide il proprio indirizzo pubblico con altre
decine di apparati. Se dall'esterno provo a contattare questo indirizzo
pubblico, non sono in grado di capire a quale apparato mi riferisco.
Al contrario un client puo' raggiungere un server all'esterno con ip
pubblico e il server puo' rispondere esattamente a lui perche' riceve tutti
i dati necessari per disambiguare il NAT all'interno della sessione TCP o
UDP (cioe un pacchetto TCP/UDP contiene oltre all'indirizzo anche la porta
che il server deve contattare per poterlo raggiungere) che riceve dal
client.
Quindi....se non mi sono aggrovigliato troppo...il problema del NAT di fw
non e' risolvibile, ma solo aggirabile. L' obbiettivo di Hamaci e' di
simulare la condizione "server interno client esterno" utilizzando in
realta' due connessioni: una "client interno server esterno" e una "client
esterno server esterno". In pratica fa da server sia per il sistema
all'interno della rete fw sia per quello esterno, che diventano quindi due
clients verso di lui. Per questo funziona. Pero' il sistema interno a fw
deve avere una sessione sempre attiva verso questo sistema e questo potrebbe
non essere desiderabile.

solo la banda fastweb. NON HO CHIARO QUESTO DISCORSO chi puo'
spiegarmelo ?

non ho capito neache io quello che dice Trip65...ma credo che anche il suo
discorso sia intorno a questo problema. Cioe' se attivi l'IP pubblico sul
tuo sistema interno FW ecco che diventa raggiungibile dall'esterno di fw e
quindi puoi utilizzare tutti i sistemi di vpn tradizionali, come OpenVPN e
lasciare perdere hamaci.

Ciao
Marco

[Marc Serafino]

Post by RICCARDO
Mi sono letto un bel po' di doc. su OpenVPN e qualcosa su Hamachi,
evrei intenzione di utilizzare per OpenVPN creare un tunnel host-to-
host tra il pc di casa (Alice ADSL con IP dinamico)
e un server a lavoro (rete Fastweb residential con NAT condiviso).
non puoi prendere un ip pubblico sul server dell'ufficio? Altrimenti non
sara' per niente semplice.

Ma come? Le VPN non funzionano perfettamente come dicono altri qui con la
vista web di Fastweb? E ora tu dici che non sara' per niente semplice?

[Hozomeen]

Ciao,

Post by Marc Serafino

Post by RICCARDO
Mi sono letto un bel po' di doc. su OpenVPN e qualcosa su Hamachi,
evrei intenzione di utilizzare per OpenVPN creare un tunnel host-to-
host tra il pc di casa (Alice ADSL con IP dinamico)
e un server a lavoro (rete Fastweb residential con NAT condiviso).
non puoi prendere un ip pubblico sul server dell'ufficio? Altrimenti non
sara' per niente semplice.

Ma come? Le VPN non funzionano perfettamente come dicono altri qui con la
vista web di Fastweb? E ora tu dici che non sara' per niente semplice?

eh si...la direzione e' fondamentale. Da esterno verso interno non c'e'
verso a meno di usare meccanismi piu' o meno accrocchiosi che cmq cambiano
il sistema client/server. Pero' e' anche vero che dall'interno verso
l'esterno di problemi non ce ne sono.
Come sempre la verita' dipende dal punto di vista....ah che grande lezione
di vita questo NAT di Fastweb ;-)

Ciao
Marco

[Trip65]

Post by Marc Serafino
Ma come? Le VPN non funzionano perfettamente come dicono altri qui con la
vista web di Fastweb? E ora tu dici che non sara' per niente semplice?

Installa openvpn da entrambi le parti il che non è difficile in se stesso.
Il bello è invece dare servizi, qui bisogna darsi da fare :) e conoscere
basilari regole di routing e port forwarding.
Ben inteso che in una giornata di lettura manuali e prove ci riesce anche un
non-esperto,ma un po' di lavoro c'è specialemente di fine-tuning e
ottimizzazione ; dai certificati per la cifratura, alle tecniche di
richiamata in caso di caduta tunnel senza avere incartamenti ecc ecc.
Probabilmente un commercialista o un medico con poco tempo bene farebbero a
scegliere altra strada/fornitore , ma se uno si diverte a smanettare il
risultato è appagante = funziona come si deve

[Trip65]

Post by Hozomeen
non ho capito neache io quello che dice Trip65...ma credo che anche il suo
discorso sia intorno a questo problema. Cioe' se attivi l'IP pubblico sul
tuo sistema interno FW ecco che diventa raggiungibile dall'esterno di fw e
quindi puoi utilizzare tutti i sistemi di vpn tradizionali, come OpenVPN e
lasciare perdere hamaci.
Ciao
Marco

No : intendevo che puoi rendere raggiungibile il tuo pc interno alla
rete fastweb a queste condizioni (senza scomodare ip pubblico fastweb ippd)

1) Possedere un ip pubblico ad esempio su connessione alice-telecom
meglio se statico e con una connessione aziendale a banda garantita onde
evitare grane sul tunnel upd

2) Possedere una connessione residential fastweb nattata e da tale far
partire la richiesta di vpn tramite openvpn che risulta installato anche
sulla macchina su ip pubblico telecom

3) eseguire operazioni di pubblicazioni porte ad esempio con un server
linux installato sull'endpoint con i pubblico quali ad esempio
80-21-110-443 ecc ecc. facendole puntare alla macchina su fastweb che
avrà servizi in ascolto su tali porte..

Va tutto bene ed è stabile ma chiariamo che :
a) LA BANDA UTILIZZATA E' QUELLA DI ALICE/TELECOM e non quella di fastweb
b) se si possiede un solo ip pubblico e non una subnet , le porte
"passate" alla macchina interna fastweb te le sei giocate.
c) in virtu' del punto a , considerare anche che la banda è
ulteriormente minore in quanto il tunnel stesso di "ritorno" occupa banda

Ribadisco che ho questo sistema attivo da settembre 2007 ed è solido
come una roccia (tunnel tra fastweb e interbusiness multigroup)
E ne ho in CONTEMPORANEA un'altra con tunnel fastweb-itgate dal 2003 e
non ci sono strozzamenti imputabili all'ip di nat fastweb = la banda mi
basta e regge (ho fibra pero').

HAMACHI invece è un server di negoziazione che permette una cosa
differente che non è comunque la raggiungibilità TUTTO IL MONDO>PC
INTERNO FASTWEB ma solo PC sui quali è installato detto software.

Il sistema che dico io invece permette a chiunque di digitare ad es
http://pippo.it e puntare al web server installato sul pc interno
fastweb risolvendo sull'ip pubblico dell'altro endpoint esterno (nel mio
caso interbusinness-telecom) e usando in toto la sua banda

[Hozomeen]

Ciao,

Post by Trip65
1) Possedere un ip pubblico ad esempio

<cut>

Post by Trip65
2) Possedere una connessione residential fastweb

<cut>

Post by Trip65
Il sistema che dico io invece permette a chiunque di digitare ad es
http://pippo.it e puntare al web server installato sul pc interno fastweb
risolvendo sull'ip pubblico dell'altro endpoint esterno (nel mio caso
interbusinness-telecom) e usando in toto la sua banda

eh siamo sempre li...l'architettura e' sempre quella...che sia hamaci o una
connessione aziendale tua o l'adsl di un amico. Ci vuole un terzo semrpe
attivo all'esterno che faccia da ponte.

Ciao
Marco

[Trip65]

Post by Hozomeen
eh siamo sempre li...l'architettura e' sempre quella...che sia hamaci o una
connessione aziendale tua o l'adsl di un amico. Ci vuole un terzo semrpe
attivo all'esterno che faccia da ponte.

Certamente , difatti sino ad oggi non ho mai conosciuto e non esistono
possibilità di driblare il nat fastweb nel senso che intendiamo noi ,
l'unico sistema "rozzo" che lo faceva provoconado danni ai server ftp usati
come bounce era il noto MOZZARELLA e/o POMODORO , soluzione tra l'altro non
piu' funzionante da molto tempo.

In realtà ci sarebbe un altro metodo ma occorre disporre sempre di una
connessione di appoggio (stavolta basta in loco) ed effettuare delle
complesse manipolazioni sui pacchetti (spoofing) ed è sicuramente un abuso
di utilizzo delle connessioni.

[Macs]

Ciao

sino ad oggi non ho mai conosciuto e non esistono possibilità di
driblare il nat fastweb nel senso che intendiamo noi

Esistono soluzioni che consentano la comunicazione diretta dall'esterno
con l'interfaccia MSFC di NAT e quindi con l'host su IP MAN FW senza
appoggi terzi, ma sono comunque destinate a comunicazioni private con
gruppi ristretti di utenti esterni piu' che alla pubblicazione estesa di
servizi -> vedasi p.es. NAT-Traverse :
==
- http://linide.sourceforge.net/nat-traverse/
==
soluzione portabile anche in ambito Windows, ma che comunque richiede un
certo affinamento (ved. comunicazioni tra i 2 peer degli IP esterni e
dei range di porte alte su UDP per stabilire il tunnel).

In ogni caso se si vuole pubblicare su IPv4 [1] un servizio X in
esecuzione su un host con indirizzamento IP MAN FW (cioe' renderlo
accessibile in modo esteso a utenti esterni) e' comunque necessaria la
scelta di una soluzione terza d'appoggio (relay, tunneling host/shell
pubblico con/senza svincolamento della banda di controllo/traffico,
associazione IP Pubblico IPPD/Personal-IP Mc-Link/FastLand IP, etc.).

l'unico sistema "rozzo" che lo faceva provoconado danni ai server ftp
usati come bounce era il noto MOZZARELLA e/o POMODORO , soluzione tra
l'altro non piu' funzionante da molto tempo.

Mozzarella richiedeva pero' comunque un sistema esterno (a differenza di
NAT-Traverse) per "aprire il varco" sull'interfaccia MSFC di NAT, cioe'
almeno un server FTP su IP Pubblico.

I problemi legati a questa soluzione erano quindi di duplice natura :

A. Rilevazione di porte libere su interfaccia MSFC
--------------------------------------------------
Alcuni software che sfruttano tale soluzione provvedono ad eseguire un
portscan (scansione delle porte TCP/UDP in ascolto) sull'interfaccia
MSFC. Dato il numero elevato di porte (65536) una scansione totale ad
ampio raggio comporta un aumento esponenziale delle transazioni NAT/PAT
con conseguente proporzionale aumento del carico per la gestione delle
NAT entries -> una tale situazione e' assimilabile ad un guasto, ed e'
peraltro in linea con certi passati interventi di blocco linea operati
da FW su utenze che eseguivano portscan ad ampio raggio.

B. Abusi su server FTP esterni
------------------------------
Piu' utenti avevano eseguito connessioni a server FTP pubblici (e non in
ascolto su altre loro connessioni o su propri host esterni) senza avere
l'autorizzazione degli amministratori che, considerata l'occupazione di
banda per ogni singola sessione port FTP (0.2/2 Kbyte/s), ravvisavano un
abuso e quindi bloccavano l'accesso all'indirizzo IP pubblico MSFC -> il
risultato era il divieto d'accesso per utenze che avevano la sola colpa
di essere attestate sul medesimo POP/miniPOP. Situazione che e' divenuta
eclatante con l'uso scorretto di certi porting per OS Windows (ved.
Pomodoro) ed i conseguenti ban da parte di alcuni ISP italiani.

Quando anni fa la problematica A acquisi' un certo peso (considerando
allora il numero/rapporto di interfacce MSFC) FW incorporo' nei processi
di migrazione di Agosto 2003 (ved. piattaforma IPPU) anche l'adeguamento
dei timeout sulle NAT table e del ftp conntrack helper.

In realtà ci sarebbe un altro metodo ma occorre disporre sempre di una
connessione di appoggio (stavolta basta in loco) ed effettuare delle
complesse manipolazioni sui pacchetti (spoofing) ed è sicuramente un
abuso di utilizzo delle connessioni.

Oltre ad essere un abuso, non e' comunque utilizzabile come prima del
2003 in virtu' proprio delle modifiche sull'inoltro dei pacchetti sulla
rete FW, in seguito ad introduzione/evoluzione della piattaforma IPPU di
autenticazione manuale/automatica delle sessioni di rete.


Nota a margine :
----------------
[1] Gli utenti su linee FW in architettura base, pur essendo dietro NAT
Hidden/Dynamic M-1 (NON modificabile a meno di attivare IP Pubblico IPPD
in ambito Residenziale/SOHO o Opzioni Address per Business/Aziende),
possono usufruire di connettivita' piena end-to-end IPv6, scegliendo
p.es. tra i seguenti servizi *free* :
==
------------------------------------------------------------------------
* TB Fast-Labs
--------------
- http://www.fast-labs.net/tb/

Servizio TunnelBroker fornito free da Fast-Labs previa registrazione
su http://www.fast-labs.net/home/signup.php .

------------------------------------------------------------------------
* Teredo
--------
- http://en.wikipedia.org/wiki/Teredo_tunneling
- http://www.microsoft.com/technet/network/ipv6/teredo.mspx
- http://www.simphalempin.com/dev/miredo/
- http://www.progsoc.org/~wildfire/debian/miredo/

Teredo e' un protocollo di tunneling che consente connettivita' IPv6 a
sistemi IPv4 dietro NAT non modificabile, tramite l'UDP Encapsulation su
IPv4 dei pacchetti IPv6.

Ad inizio Aprile 2006 Marco d'Itri ha attivato un relay Teredo, che
consente di avere un indirizzo IPv6 -> non e' necessaria alcuna
registrazione o configurazione particolare = e' sufficiente attivare il
client Teredo ed appoggiarsi p.es. ad uno dei seguenti server pubblici :
==
- debian-miredo.progsoc.org
- teredo.remlab.net

Nota : gli utenti con Windows XP devono aver installato, oltre al
Service Pack 2, anche l'ultima versione dello stack TCP/IPv6 disponibile
su WindowsUpdate (che supporta il nuovo prefisso 2001::/32 allocato
dallo IANA per Teredo) -> inoltre e' necessario che siano installati gli
aggiornamenti KB922819 e/o KB920342.

------------------------------------------------------------------------
* AYIYA
-------
- http://en.wikipedia.org/wiki/AYIYA
- http://www.sixxs.net/main/
- http://www.sixxs.net/tools/aiccu/

Sistema di tunnel UDP IPv4 su cui vengono incapsulati i pacchetti IPv6
-> una volta approvata la registrazione gratuita a SixXS (che va
effettuata su http://www.sixxs.net/signup/ ) e' sufficiente usare il
client automatico AICCU per configurare/utilizzare un tunnel AYIYA.

------------------------------------------------------------------------
* Freenet6
----------
- http://www.go6.net/4105/freenet.asp
- http://www.go6.net/4105/register.asp

Servizio gratuito (previa registrazione) per l'accesso a connettivita'
IPv6 & utilizzabile anche da utenze dietro NAT non modificabile ->
prevede sia la modalita' tramite tunnel autenticato con assegnazione
statica di prefisso/indirizzo IPv6 che quella su tunnel anonimo con
assegnazione dinamica.
------------------------------------------------------------------------

[Trip65]

Post by Macs
Esistono soluzioni che consentano la comunicazione diretta dall'esterno
con l'interfaccia MSFC di NAT e quindi con l'host su IP MAN FW senza
appoggi terzi, ma sono comunque destinate a comunicazioni private con
gruppi ristretti di utenti esterni piu' che alla pubblicazione estesa di
==
- http://linide.sourceforge.net/nat-traverse/

Si' fuiziona ..
Allegano anche un esempio su come utilizzare questo programma, che crea
solo un semplice
socket UDP, per trasportare ad esempio ppp (Setup of a small VPN with PPP)
oppure openvpn (Setup of a VPN with OpenVPN).

In pratica questo programma sfrutta le porte che vengono normalmente aperte
in ricezione da un nat per creare un socket udp sul quale trasmettere i
dati.
Questo socket può essere usato per fare vpn con protocollo PPP

[RICCARDO]

Post by Trip65

Post by Hozomeen
non ho capito neache io quello che dice Trip65...ma credo che anche il suo
discorso sia intorno a questo problema. Cioe' se attivi l'IP pubblico sul
tuo sistema interno FW ecco che diventa raggiungibile dall'esterno di fw e
quindi puoi utilizzare tutti i sistemi di vpn tradizionali, come OpenVPN e
lasciare perdere hamaci.
Ciao
Marco

No : intendevo che puoi rendere raggiungibile il tuo pc interno alla
rete fastweb a queste condizioni (senza scomodare ip pubblico fastweb ippd)
1) Possedere un ip pubblico ad esempio su connessione alice-telecom
meglio se statico e con una connessione aziendale a banda garantita onde
evitare grane sul tunnel upd
2) Possedere una connessione residential fastweb nattata e da tale far
partire la richiesta di vpn tramite openvpn che risulta installato anche
sulla macchina su ip pubblico telecom
3) eseguire operazioni di pubblicazioni porte ad esempio con un server
linux installato sull'endpoint con i pubblico quali ad esempio
80-21-110-443 ecc ecc. facendole puntare alla macchina su fastweb che
avrà servizi in ascolto su tali porte..
a) LA BANDA UTILIZZATA E' QUELLA DI ALICE/TELECOM e non quella di fastweb
b) se si possiede un solo ip pubblico e non una subnet , le porte
"passate" alla macchina interna fastweb te le sei giocate.
c) in virtu' del punto a , considerare anche che la banda è
ulteriormente minore in quanto il tunnel stesso di "ritorno" occupa banda
Ribadisco che ho questo sistema attivo da settembre 2007 ed è solido
come una roccia (tunnel tra fastweb e interbusiness multigroup)
E ne ho in CONTEMPORANEA un'altra con tunnel fastweb-itgate dal 2003 e
non ci sono strozzamenti imputabili all'ip di nat fastweb = la banda mi
basta e regge (ho fibra pero').
HAMACHI invece è un server di negoziazione che permette una cosa
differente che non è comunque la raggiungibilità TUTTO IL MONDO>PC
INTERNO FASTWEB ma solo PC sui quali è installato detto software.
Il sistema che dico io invece permette a chiunque di digitare ad eshttp://pippo.ite puntare al web server installato sul pc interno
fastweb risolvendo sull'ip pubblico dell'altro endpoint esterno (nel mio
caso interbusinness-telecom) e usando in toto la sua banda

In merito l'ultima tua affermazione riguardo Hamachi vorrei fare
qualche commento:

<< risolvendo sull'ip pubblico dell'altro endpoint esterno
(nel mio caso interbusinness-telecom) e usando in toto la sua banda >>

A - Correggetemi se sbaglio ma se stabilisco un tunnel con Hamachi tra
Interbusiness-Fastweb
nel 1° tratto (tra il pc di casa e il server Hamachi di negoziazione)
la banda dovrebbe essere a carico di Alice mentre
nel 2° tratto (tra il server di negoziazione Hamachi e il client
fastweb)
dovrebbe essere a carico di Fastweb,
pertanto siamo sempre vincolati dall'utilizzo di banda del tratto
interbusiness;
ma perche' dovrebbe essere sfruttata meglio la banda in questa
modalita' ?
Ci sono diversi fattori da valutare:
il server Hamachi dove sta ? Su Alice o Fastweb ?
Che banda gli e' riservata ?
che carico di lavoro ha il server ?

B - nel punto 'a' che espone Trip65 dice che :
<< LA BANDA UTILIZZATA E' QUELLA DI ALICE/TELECOM e non quella di
fastweb >>
il client fastweb dovra' pur rivolgersi al suo router di riferimento,
quindi utilizzera'
una porzione di banda Fastweb (anche se pur minima) ma perche'
dovrebbe essere tutta sbilanciata a carico di Telecom ?!

[Trip65]

Se tu collegassi con hamachi la macchina fastweb a qella alice , si'
otteresti che il traffico di "tunnel" passi solo sulla banda fastweb
risparmiando il famoso "ritorno" di cui parlo.
Il traffico che invece provoca l'eventuale visitatore del tuo spazio web
interesserebbe sempre la connessione alice.
Per evitare cio' e usare sempre la banda fastweb occorre che TUTTI i client
usino hamachi compreso l'utente che ti visita, allora si', tutto passa su
fastweb. I server hamachi difatti sono solo mediatori e non passa il flusso
dati ma solo i dati (cifrati) per stabilire il tunnel vpn.

[Macs]

Ciao

se sbaglio ma se stabilisco un tunnel con Hamachi tra Interbusiness
-Fastweb nel 1° tratto (tra il pc di casa e il server Hamachi di
negoziazione) la banda dovrebbe essere a carico di Alice mentre
nel 2° tratto (tra il server di negoziazione Hamachi e il client
fastweb) dovrebbe essere a carico di Fastweb, pertanto siamo sempre
vincolati dall'utilizzo di banda del tratto interbusiness;
ma perche' dovrebbe essere sfruttata meglio la banda in questa
modalita' ?

Il server Hamachi assolve solo alle funzioni di mediation/rendez-vous,
cioe' serve per le operazioni di autenticazione dei client Hamachi = le
comunicazioni dati tra i diversi peer con client Hamachi si svolgono
invece tra tunnel diretti endpoint-to-endpoint, per cui non vi e' un
inoltro/relay del traffico attraverso il server [1].

In caso di collegamento diretto tra 2 soli peer l'utilizzo di Hamachi
al posto di OpenVPN (o altre soluzioni tunnel/VPN) non comporta pero'
vantaggi in termini di banda disponibile al tunnel.

I vantaggi di una soluzione decentralizzata come Hamachi [2] per il
traffico privato vi possono essere semmai in condizioni di rete
multipoint con almeno 3 peer, confrontandola con una soluzione relayed
(cioe' con inoltro/routing del traffico dei peer attraverso un server).

Consideriamo ad esempio di voler stabilire una rete privata tra 3 peer
A B C e confrontare uno scenario Hamachi/relayless per il traffico dati
con una soluzione relayed.

A. Hamachi/relayless
--------------------

A
/ \
/ \
B ----- C

In questo caso si hanno 3 tunnel A-B/A-C/B-C dove la banda disponibile
in DL/UL su ciascun tunnel e' definita solo dalla banda disponibile ai
peer = la banda disponibile al mediation server non influisce in merito,
tant'e' che nel caso specifico il server Hamachi potrebbe essere
benissimo associato ad una linea su modem analogico.

Se p.es. A e B fossero su linee FW fibra residenziali e C su linea ADSL1
InterBusiness, il tunnel A-B potrebbe disporre anche nominalmente della
banda piena di 10Mbit Half Duplex (considerando peraltro che il traffico
sarebbe tra 2 nodi interni alla rete FW), mentre la banda sui tunnel A-C
e B-C sarebbe ovviamente vincolata dalla banda in DL/UL della linea
ADSL1 InterBusiness.


B. Relayed
----------

A
|
Relay Server
/ \
B C

In questo caso si hanno 3 tunnel A-RS/B-RS/C-RS dove la banda su ciascun
tunnel e' vincolata anche dalla banda a disposizione del relay server, e
non solo da quella sui peer.


L'analisi dei vantaggi puo essere fatta inoltre anche in termini di
affidabilita'/disponibilita' della rete privata tra i peer. Nel caso
della soluzione B relayed e' infatti sufficiente un'eventuale condizione
di offline del relay server per avere tutte le comunicazioni in KO.

Nella soluzione A e' invece possibile definire una serie di misure di
failover su routed-tunneling, che consentano di mantenere comunque le
comunicazioni dati anche in caso di KO su tunnel singoli = qualora p.es.
il tunnel A-B non fosse disponibile, ma fossero ancora up A-C e B-C, il
sistema potrebbe rigirare temporaneamente il traffico sul percorso
A-C-B.


Ecco perche' in scenari di reti private di grandi dimensioni si puo
incontrare anche una soluzione di tipo C magliata/ridondata per gestire
le comunicazioni tra i peer, derivata dalla combinazione di A e B in
modo da sfruttare i vantaggi di entrambe (ved. A in termini di banda sui
singoli tunnel e B in termini di controllo del traffico).

____ A ____
/ | \
/ | \
B -- Central -- C
\ /
\___________/

il server Hamachi dove sta ? Su Alice o Fastweb ?

Su nessuna delle 2, visto che di base per gli account Free e Premium
sono usati i backend mediation server pubblici di Hamachi (cioe'
bibi.hamachi.cc e my.hamachi.cc), che sono a Vancouver (mentre i sistemi
di rilevamento NAT sono invece ad Amsterdam).

Chi vuole realizzare una rete P2P VPN relayless (anche per peer dietro
NAT) con un proprio server per le funzioni di mediation/rendezvous puo
usare Wippien (che e' Open Source a differenza di Hamachi) sia per il
client che per il mediation link oppure STUN/STUNT + OpenVPN o Tinc :
==
- http://www.wippien.com
- http://www.tinc-vpn.org/documentation/tinc_6.html#SEC58
- http://nutss.gforge.cis.cornell.edu/jstunt-faq.php#q7


Note a margine :
----------------
[1] Hamachi supporta anche una funzione di relay/repeating attraverso i
propri server pubblici in caso di problemi di comunicazione sui
tunnel diretti tra peer = di base tale funzione e' disponibile solo
a banda stretta/limitata per le utenze Free, mentre quelle Premium
(a pagamento) possono disporre di un canale a banda larga.

[2] Altre soluzioni decentralizzate per le comunicazioni tra peer (che
consentano anche il traffico con peer posti dietro a hidden/dynamic
NAT) sono (oltre a Wippien e STUN/STUNT+VPN) anche p.es.:
==
- CSpace http://www.cspace.in/
- UltraVNC NAT2NAT http://www.uvnc.com/addons/nat2nat.html