Newsgroup: it.tlc.gestori.fastweb
Titolo: OpenVPN vs Hamachi

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. >>

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 

 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?

Ciao,

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 

 
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

 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 

 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 ?!

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.

 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.

 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
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|
|_|  |_/_/ \_\___|___/<|> *FAQ ITGF 
http://plany.fasthosting.it
 <|
|>- RST - Plany/MACS -<|> *FAQ GCN  
http://faq.news.nic.it/
 ____<|

 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. 
------------------------------------------------------------------------
-- 
|¯ \/¯ | /¯\ /¯__/¯__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|¯|\/|¯|/¯_¯\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|


 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

 - 
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