rejetto forum
Software => Other languages => HFS ~ HTTP File Server => Italiano => Topic started by: dragon on August 31, 2007, 03:36:45 AM
-
Ciao rejetto, carino il nuovo forum (non me lo ricordavo così almeno)
Ad ogni modo ti volevo chiedere se hai intenzione di supportare ipv6 con le prossime versioni di HFS.
Personalmente ho necessità di un server http (magari file sharing come il tuo) in ipv6, e mi scoccia dover mettere apache ... :(
Fammi sapere se la cosa è in programma! Grazie e ciao.
-
ciao, non ho idea di cosa bisogna fare per supportare IPv6.
di preciso che limitazione incontri?
-
In pratica non risponde ...
Vede l'ipv4 (preferenziale, credo sia falso o al massimo l'ipv6 convertito in ipv4) come interfaccia, ma anche se la seleziono (in ascolto sulla porta 80) oppure se gli dico di rispondere a tutte le interfacce HFS cmq non risponde. Mentre con hamachi oppure ip diretto funziona. Hamachi usa i tunnel proprio come i tunnel broker ipv6, il che appunto mi fa capire che il problema sta nell'ipv6. Oltretutto ho provato con HFS due tipo di broker, sia sixxs.net che go6.net (molto meglio il secondo) e non funziona in ogni caso. Mentre conosco persone che con apache hanno messo su un server raggiungibile da ipv6 ....
Cmq credo sia più facile parlarne su MSN, se ce l'hai, ho provato ad aggiungerti ma non rispondi.
Ad ogni modo fammi sapere !!!
Sono online come te.
-
Scheda Ethernet IPV6 GO6:
Suffisso DNS specifico per connessione:
Descrizione . . . . . . . . . . . . . : Hexago Virtual Multi-Tunnel Adapter
Indirizzo fisico. . . . . . . . . . . : 02-50-F2-00-00-01
DHCP abilitato. . . . . . . . . . . . : Sì
Configurazione automatica abilitata : Sì
Indirizzo IPv6 . . . . . . . . . . . . . . . . . : 2001:5c0:8fff:fffe::6f7f(Preferenziale)
Indirizzo IPv6 locale rispetto al collegamento . : fe80::e41d:a7bc:21ed:471d%20(Preferenziale)
Indirizzo IPv4 configurazione automatica : 169.254.71.29(Preferenziale)
Subnet mask . . . . . . . . . . . . . : 255.255.0.0
Gateway predefinito . . . . . . . . . : ::
IAID DHCPv6 . . . . . . . . . . . : 436359410
Server DNS . . . . . . . . . . . . . : 1.253.128.30
213.156.54.81
NetBIOS su TCP/IP . . . . . . . . . . : Attivato
Questa è la scheda di rete virtuale con la quale dovrebbe lavorare HFS, ma non ci riesce. Premetto che l'IPV6 funziona benissimo, navigo in ipv6 e riesco a farmi pingare da altri utenti ipv6.
teoricamente il mio sito dovrebbe essere visibile per
utenti ipv6 con
1) http://[2001:05c0:8fff:fffe:0000:0000:0000:6f7f] (usate firefox, non sono sicuro di IE6 o 7)
2) dragon.dragonsoldier.com
utenti ipv4 con
http://dragon.dragonsoldier.com.ipv4.sixxs.org
Purtroppo non funzionano, riesco a essere pingato ma HFS non funziona :(
HELP !!
-
io chiaramente non uso i socket di windows direttamente, ma una lib che sta su www.overbyte.be
devo vedere se ha il supporto, sennò mi sa che sono fregato.
su msn non ricordo di essere stato contattato da un italiano oggi.
-
Guarda io ho aggiungo rejetto@email.it , cmq il mio è dragone@unrealworld.it
aggiungimi tu, io non riesco nemmeno a mandarmi un messaggio offline
ci sentiamo su msn, a presto !!
-
Allora ipv6 è il nuovo protocollo di strato network con 128 bit di indirizzamento. Questo significa che ci saranno svariati milioni di indirizzi ipv6 per metro quadro di superficie terrestre risolvendo tutti i problemi attuali sul numero di ipv4. Attualmente gli ipv6 vengono dati gratuitamente da quei servizi (sixxs, go6 e altri) che vengono chiamati tunnel broker. Su cosa si basano esattamente?
Ricordiamo che attualmente in italia nessun provider offre connettività nè assoluta nè ibridia ipv6, dunque come possiamo navigare sulla rete ipv6 ?
I tunnel broker dispongono di diverse macchine ibride (non centrano niente con il tuo provider) che possono dialogare usando sia ipv4 che ipv6, chiamati gateway ipv4 o ipv6 a seconda del verso in cui vengono usati. Ora solitamente un tunnel broker vi mette a disposizione un piccolo software che permette di fare un tunnel tramite VPN tra la tua macchina e il loro gateway ipv4/ipv6. Questo permette (grazie al port forwarding) di essere raggiunti (pingabili) anche se usate provider nattati come fastweb oppure la 3 con umts di ultima generazione. Voglio precisare che questo funziona SOLAMENTE PERCHè sia fastweb che la 3 che qualsiasi altro provider SUPPORTANO il VPN e company, ovvero il server NAT fa portforwarding quando viene instaurata una VPN, ovvero ti riserva una porta del server NAT. Se disabilitassero tale opzione non ci sarebbe di modo di essere raggiunti , nemmeno hamachi funzionerebbe :) . Ecco perchè secondo me la VPN non è un modo per aggirare la sicurezza dei una rete, perchè funziona per concessione della rete stessa.
Tornando al programmino del tunnel broker, oltre ad instaurare il tunnel crea un device di rete virtuale. Questo , quando usato, incapsulerà normali pacchetti ipv6 dentro pacchetti ipv4 , questi ultimi indirizzati al gateway ipv4/ipv6. Una volta arrivati al gateway questo pacchetti vengono sgusciati, e il contenuto ipv6 viaggia tranquillamente su rete ipv6. La mia macchina e il gateway associatomi dal tunnel broker vengono detti end points del tunnel, entrambi dotati di indirizzo ipv6 dal tunnel broker stesso.
La stra-mega-figatissima di tutto questo discorso è che quando una richiesta ipv6 viene indirizzata verso il mio ipv6 (e potrebbe essere benissimo una richiesta generata da un altro utente tunnel broker come me), questa raggiunge il mio gateway end point che può inoltrarmela tranquillamente grazie al tunnel instaurato.
Questo procedimento è MOLTO SIMILE a ciò che accade se due utenti usano hamachi, con la differenza che gli ipv4 hamachi sono falsi, e valgono solo per una vpn di 16 persone, mentre gli ipv6 dei tunnel broker sono autentici e valgono per TUTTA LE RETE reale ipv6 :)
Ora arriva la parte interessante. Grazie a dei servizi di DNS gratuiti come afraid.org (e molti altri) possiamo acquisire gratuitamente un DNS che punti al nostro caro (E LUNGHISSIMO) ipv6. Nel mio caso è dragon.dragonsoldier.com. Ora se scriviamo dragon.dragonsoldier.com nel browser equivarrà a fare una richiesta ipv6 verso il mio ipv6 :). Dunque funziona solo se avete ipv6 (tunnel broker o nativo) , e solo se io ho abilitato qualcosa in ricezione sulla porta 80 capace di rispondere a richieste ipv6 :D .
Ora esistono dei gateway particolari che permettono a utenti ipv4 di navigare (e solo quello però) nella rete ipv6, in pratica svolgono il lavoro di traduzione automaticamente e ti inoltrano il contenuto su ipv4 senza che tu abbia installato nulla.
basta prendere un indirizzo che si vuole visitare, e attaccarci subito dopo .ipv4.sixxs.org
nel mio caso il risultato è http://dragon.dragonsoldier.com.ipv4.sixxs.org
Abbiamo raggiunto l'apice :) un utente ipv4 normalissimo, scrivendo quell'indirizzo nel browser farà una richiesta di visualizzazione di http://dragon.dragonsoldier.com a sixxs.org, che tramite ipv6 e il tunnel caricherà la pagina sul mio PC (NATTATO!) e la manderà a chi la aveva richiesta. In altre parole anche noi fastweb potremmo ospitare un server http :) senza dover far installare agli utenti client di alcun tipo.
Figo eh? :P
Ora tocca a rejetto fare una bella modifica a HFS per farcelo funzionare su ipv6 :D
Spero di essere stato chiaro :) se ci sono domande scrivete.
Se volete iscrivervi a qualche tunnel broker usate www.go6.net NON USATE www.sixxs.net , benchè la qualità di entrambi sia ottima, il secondo è molto più macchinoso, l'iscrizione richiede UNA SETTIMANA o + oltre ad essere complicatissima e per la metà delle volte BOCCIATA. Se usate www.go6.net otterrete connettività gratuita ipv6 nel giro di 30 minuti e completamente gratuita. La banda passante è enorme, parliamo di svariate centinaia di kbyte/s :) sixxs.net l'ho testato fino alla bellezza di 660 kbyte/s passanti , mentre go6.net fino a 300 e rotti (ma solo perchè non avevo chi mi fa da server, sono sicuro che arriva a 600-700 anche lui). SIXXS NON FUNZIONA SU WINDOWS VISTA, ALMENO FINO AD ORA, AGOSTO 2007 :P
Per il dns infine l'indirizzo completo è http://freedns.afraid.org/
-
Allora ho risolto io il problema :)
Il problema sta nel fatto che sia apache che HFS non riescono a fare i listen sulle interfacce ipv6, non riescono a impostare i socket ...
avevo sentito parlare di alcuni programmi BOUNCER usati per far funzionare client IRC su ipv6 anche se non lo supportano, il che mi ha incuriosito
ho scoperto che il bouncer è solo un'applicazione che prende i pacchetti di un certo socket e li ributta su un altro socket
quindi l'idea che mi è venuta in mente è che se HFS è in grado di ascoltare solo il socket IPFASTWEB:80 , bastava mettere un bouncer che portasse i pacchetti da IP6Go6:80 -> IPFASTWEB:80 (in realtà al posto dell'ipfastweb potete usare un qualsiasi altro ip valido con cui hfs lavora, anche quello locale o hamachi).
Il bouncer Relay6
http://www.unrealworld.it/R6Frontend-0.3-win32-bin+src.zip
se volete lanciare Relay6 da console in maniera nascosta avrete bisogno di
hstart
http://www.unrealworld.it/hstart2.zip
Relay6 che vi ho linkato è la versione che comprende anche il FrontEnd, una GUI molto intuitiva ... però ha il bug di non riuscire a caricare e salvare le configurazione, l'ho provato sia su XP che su VISTA
io personalmente ho creato un file start.bat con cui eseguivo relay6 da cosole (facendo il bind tra il mio ipv6 e il mio iphamachi entrambi sulla porta 80) e poi ho creato un altro file relay.bat nel quale eseguo hstart passandogli il start.bat di prima, e poi ho messo un collegamento a relay.bat in esecuzione automatica :)
buahahah sono il primo utente nel mondo a usare HFS da ipv6 ... forse :P
LOL
-
Ciao sono French, ma per capire il sistema che hai usato, se non hai installato hamachi o ipv6 non funziona?
-
se usi il gateway di sixxs.org funziona anche senza installare niente
prova tu stesso ...
dragon.dragonsoldier.com.ipv4.sixxs.org
-
quindi devo prima collegarmi a "sixxs.org" e registrarmi? mi dai l'indirizzo preciso?
-
mi dispiace ma non riesco a collegarmi a te in nessuna maniera. sicuro che HFS non ti si apre in locale? cioè sei visibile solo da te stesso, sul tuo PC, e non da internet?
-
devi scrivere tutto quell'indirizzo nel browser, ti chiederà user e pass che non hai ma non è quello l'importante, se ti chiede la pass significa che mi hai raggiunto ....
non ti devi iscrivere da nessuna parte
-
Funge ;)
Cmq è meglio che mi rilegga molto bene tutto il post che è proprio very interesting.
Mi conforta il fatto che qualche stringa in italiano è ancora la mia ;D
f.
-
certo che funge :P se lo dico io è una garanzia buahahah :P
magari mi dirai che non è tutta sta gran velocità di trasferimento ... non tanto l'ipv6 , quanto il gateway sixxs.org :(
-
OK, adesso funziona, prima avevo già digitato sul browser il tuo indirizzo, ma non funzionava, forse non eri collegato o non avevi HFS aperto, comunque se hai fastweb, e funziona cosi' hai risolto un bel problema, bisogna solamente vedere la velocità effettiva dei down e upload.
N.B. per fabnos, certo che ho lasciato le tue stringhe in italiano, anche il tuo lavoro è importante e ti ringrazio. ciao.
-
Un problemino col testing delle prestazioni ce l'avrei ...
Sixxs.net non funziona con vista, per colpa di aiccu che non supporta i TAP driver nuovi
go6.net funziona bene, però limitano la banda a 50 kbyte a download/upload
oddio, per un server http retto da una dsl con 1 mbit in uscita va benissimo però sixxs era un pochino meglio per le prestazioni :)
-
mica male 50k/s se il servizio è gratis ... :-X
-
ora ho letto la tua spiegazione per intero. è interessante che offrano questo servizio gratis.
solo su una cosa non sono sicuro:
Questo permette (grazie al port forwarding) di essere raggiunti (pingabili) anche se usate provider nattati come fastweb oppure la 3 con umts di ultima generazione. Voglio precisare che questo funziona SOLAMENTE PERCHè sia fastweb che la 3 che qualsiasi altro provider SUPPORTANO il VPN e company, ovvero il server NAT fa portforwarding quando viene instaurata una VPN, ovvero ti riserva una porta del server NAT.
non credo che stiano così le cose, ma correggimi se sbaglio.
ho utilizzato un servizio simile in passato, proprio per "uscire" da fastweb.
la VPN può comunicare su diversi tipi di canali, ma una di queste possibilità è aprire una connessione TCP dal computer connesso a fastweb --> verso il server che fa da tunnel.
tutto il traffico della VPN è incapsulato dentro questo TCP. Quando arriva una richiesta connessione, questa arriva "fisicamente" al server, che la incapsula e la fa viaggiare nella VPN, e all'end point viene riprodotta la connect (il SYN).
con un procedimento di questo tipo non c'è nessun bisogno di forwardare porte, e se il firewall permettesse solo traffico HTTP, si potrebbe usare l'HTTP come canale (il protocollo, non semplicemente la porta 80), senza che il router sappia che c'è una VPN in corso.
ti ringrazio per aver pubblicato i risultati della tua ricerca. a questo punto l'unico limite è la destrezza dell'utente nel seguire le tue istruzioni. sarebbe bello se ci fosse un sistema automatico per rendere HFS pienamente funzionante con fastweb. :)
-
Quello che dici tu è normale funzionamento della SOURCE NAT :) e ci siamo
il problema infatti non è quando tu devi uscire dalla nat e andare su ipv6 per navigare, il problema è quando gli altri SENZA PREAVVISO vogliono entrare :)
basta che ti fermi a rifletterci un attimo, da fuori una nat tu non puoi dire NULLA di ciò che vi è contenuto. è vero che se ti iscrivi ad un tunnel broker hai un tuo indirizzo ipv6 ... ma continui a non avere un indirizzo ipv4, e continui ad essere dietro un server nat :)
in altre parole vedendola dal punto di vista dell'end point IPV6 , lui a chi manda la roba che è indirizzata verso il tuo ipv6??? Lui non ti conosce direttamente, conosce solo il nat ... dietro alla stessa nat potrebbero aver richiesto ipv6 centinaia di persone, come fa a dire al server nat di indirizzare la roba proprio a te?? Ci riesce grazie al tunneling , e questo si basa proprio su port forwarding :)
cito wikipedia "Port forwarding (sometimes referred to as tunneling) is the act of forwarding a network port from one network node to another. This technique can allow an external user to reach a port on a private IP address (inside a LAN) from the outside via a NAT-enabled router."
è vero, si può fare VPN senza tunnelling (VPN significa solo rete virtuale, non necessariamente deve fare tunnelling), ma in questo caso non funzionerebbe con noi di fastweb :)
forse sono stato poco preciso prima, credo di aver detto per sbaglio che è la VPN a dire al router di fare portforwarding, magari quello era poco preciso , è il tunneling a farlo
cmq l'importante è che sia chiaro a tutti è che i tunnel-broker , hamachi , e gli http-tunnel funzionano con noi fastweb perchè fanno tunneling e il tunneling viene supportato dai router nat.
cmq per chi non avesse niente da fare
Source Nat, Destination Nat : http://it.wikipedia.org/wiki/Network_address_translation
Port Forwarding : http://en.wikipedia.org/wiki/Port_forwarding
Tunneling : http://en.wikipedia.org/wiki/Tunneling_protocol
VPN : http://en.wikipedia.org/wiki/VPN
-
mica male 50k/s se il servizio è gratis ... :-X
sixxis su singolo download andava a 600-700 :)
appena supporta vista lo rimetto
-
Cmq ho sperto che il gateway sixxs non supporta lo scambio di file grandi :(
quindi ipv4-> fastweb senza installare niente purtroppo non sarà gran che, potrete solo navigare su pagine web :(
mi spiace
-
fino a che dimensione si arriva?
-
in altre parole vedendola dal punto di vista dell'end point IPV6 , lui a chi manda la roba che è indirizzata verso il tuo ipv6???
Lui non ti conosce direttamente, conosce solo il nat ... dietro alla stessa nat potrebbero aver richiesto ipv6 centinaia di persone, come fa a dire al server nat di indirizzare la roba proprio a te?? Ci riesce grazie al tunneling , e questo si basa proprio su port forwarding :)
no, calma.
sono le 4AM e spero di non dire cazzate, sennò perdonami. :D
il VPN è tunneling. lo dice anche la pagina di wikipedia che hai citato
Tunneling protocols may use data encryption to transport insecure payload protocols over a public network such as the Internet thereby providing VPN functionality
a distribuire i dati ci pensa il router tramite il NATting. come?
mettiamo che A è dentro fastweb e B no.
A apre una connessione TCP verso B.
B non sa davvero di A, potrebbe star dialogando con il router per quanto ne sa.
il router di fastweb che sta in mezzo ha una tabella in cui associa ad ogni comunicazione TCP un indirizzo IP locale. grazie a questa tabella non ha nessun problema a inoltrare i dati al corretto destinario, indipendentemente dalla direzione in cui viaggiano i dati. Questo su wikipedia è spiegato dove dice
The router tracks basic data about each active connection (particularly the destination address and port). When a reply returns to the router, it uses the connection tracking data it stored during the outbound phase to determine where on the internal network to forward the reply
Quindi il server col NAT sta offrendo un corretto funzionamento del TCP attraverso le 2 reti. Non sta offrendo spontaneamente VPN, ICQ, o altro. Giusto il TCP, su cui poi tante cose si basano. Se la connessione è crittata con SSL, potrà magari capire che è appunto crittata, se proprio ci tiene. Una volta stabilita la connessione crittata, i dati viaggiano, e che siano VPN, o una connessione a un sito sicuro (HTTPS), o un protocollo che si è inventato un nostro amico, il router non può saperlo.
Tutto il protocollo VPN può viaggiare dentro il transport crittato, senza malfunzionamenti.
il Tunneling non è una cosa precisa, è praticamente un concetto, come rimorchiare una ragazza, si può fare in tanti modi. alcuni di questi modi sono citati su wikipedia nella sezione "Common tunneling protocols".
Fare VPN significa fare tunneling, xkè i tuoi dati che viaggiano sulla VPN invece di usare il normale stack TCP/IP offerto dal sistema, usano un layer transport ulteriore che si POGGIA su quello appena citato per offrire gli stessi servizi e spesso altri ulteriori.
Se io apro una connessione TCP da A verso B, e su quella ci gira una VPN, allora i dati di quella VPN viaggeranno senza ulteriori difficoltà di indirizzi etc. Il problema è che stiamo parlando di una VPN, è come se fossimo in una rete locale. Ci vuole un altro mattone a questo punto, su B, che faccia da tramite tra internet e la VPN. Ma questo mattone non ha niente a che spartire col router di fastweb, è interamente demandato a B e il router non ne sa niente. Se la connessione è crittata non lo può sapere nemmeno se piange che quei dati vengono dal resto di internet. Sa solo di A e di B.
Ora non sono sicuro tu a chi ti riferisci quando dici tunnel. Può essere che ti riferisci alla VPN stessa, ma volendo, per estensione del concetto, anche al "mattone". Non conosco il suo nome specifico, ma è sostanzialmente un gateway (http://en.wikipedia.org/wiki/Gateway_(computer_networking)).
E così funziona per esempio fast-ip. Si crea una VPN tra l'utente fastweb e il loro server, e poi il loro server forwarda il traffico tra la VPN e internet.
Perchè è necessaria la VPN? Serve xkè il NAT permette alle connessioni TCP (e l'HTTP si basa sul TCP) di essere stabilite solo da dentro verso fuori. HFS funziona che riceve le connessioni dai client, non le apre spontaneamente egli stesso. Funziona solo se gli arriva una richiesta, e le richieste (chiamate CONNECT, o anche dette SYN) il router di fastweb non le fa passare. (passano quando si fa forwardare la porta, e non è un servizio offerto da fastweb)
La VPN serve a permettere che sul nostro computer arrivi una normale chiamata CONNECT da fuori fastweb. Può arrivare perchè la chiamata CONNECT è tunnelizzata dalla VPN. Nel tunnel passa qualsiasi cosa, anche la connect.
Ma la VPN da sola fa sì che ci possa arrivare solo dall'altro end-point, e noi vorremmo poter ricevere connessioni da chiunque. E qui che entra in gioco il gateway di prima.
Cribbio quanto ho scritto. Spero serva almeno a qualcuno.
-
Serve, serve, stai tranquillo, quello che invece servirebbe a me è un semplice screenshot, fatto con CurrPorts, da qualcuno che è utente fastweb ed abbia installato HFS, e mi faccia da "cavia", devo provare la mia soluzione. :)
-
sul mio pc funziona, ma io non sono un utente fastweb, domani, anzi oggi proverò a cercare mio nipote, che ha fw, e se è veramente come credo, è una cosa semplicissima da risolvere.
-
sul mio pc funziona, ma io non sono un utente fastweb, domani, anzi oggi proverò a cercare mio nipote, che ha fw, e se è veramente come credo, è una cosa semplicissima da risolvere.
Sarebbe veramente cosa buona e giusta ;D
f.
-
in altre parole vedendola dal punto di vista dell'end point IPV6 , lui a chi manda la roba che è indirizzata verso il tuo ipv6???
Lui non ti conosce direttamente, conosce solo il nat ... dietro alla stessa nat potrebbero aver richiesto ipv6 centinaia di persone, come fa a dire al server nat di indirizzare la roba proprio a te?? Ci riesce grazie al tunneling , e questo si basa proprio su port forwarding :)
no, calma.
sono le 4AM e spero di non dire cazzate, sennò perdonami. :D
il VPN è tunneling. lo dice anche la pagina di wikipedia che hai citato
Tunneling protocols may use data encryption to transport insecure payload protocols over a public network such as the Internet thereby providing VPN functionality
eheh le 4am
cmq se traduci bene la frase di wikipedia significa altro
I protocolli di tunneling POSSONO usare criptaggio dati per trasportare protocolli di carico insicuri su una rete pubblica come internet o fornendo funzionalità VPN
ovvero che il tunneling può offrire connettività di tipo rete virtuale privata, ovvero che è il tunneling a far funzionare la vpn :)
vpn non è esattamente la stessa cosa di tunneling, sono due cose diverse
a distribuire i dati ci pensa il router tramite il NATting. come?
mettiamo che A è dentro fastweb e B no.
A apre una connessione TCP verso B.
B non sa davvero di A, potrebbe star dialogando con il router per quanto ne sa.
il router di fastweb che sta in mezzo ha una tabella in cui associa ad ogni comunicazione TCP un indirizzo IP locale. grazie a questa tabella non ha nessun problema a inoltrare i dati al corretto destinario, indipendentemente dalla direzione in cui viaggiano i dati. Questo su wikipedia è spiegato dove dice
The router tracks basic data about each active connection (particularly the destination address and port). When a reply returns to the router, it uses the connection tracking data it stored during the outbound phase to determine where on the internal network to forward the reply
Quindi il server col NAT sta offrendo un corretto funzionamento del TCP attraverso le 2 reti. Non sta offrendo spontaneamente VPN, ICQ, o altro. Giusto il TCP, su cui poi tante cose si basano. Se la connessione è crittata con SSL, potrà magari capire che è appunto crittata, se proprio ci tiene. Una volta stabilita la connessione crittata, i dati viaggiano, e che siano VPN, o una connessione a un sito sicuro (HTTPS), o un protocollo che si è inventato un nostro amico, il router non può saperlo.
Tutto il protocollo VPN può viaggiare dentro il transport crittato, senza malfunzionamenti.
Il problema non è instaurare una connessione TCP da dentro a fuori e poi farci viaggiare sopra i dati di una vpn o quel che sia. La vpn è vero, essendo virtuale si basa su una struttura sottostante necessariamente reale , ma non io non stavo parlando di questo stavo dicendo altro :)
Giusto per essere precisi cmq la nat funziona così
IPFASTWEB:PORTAPP fa una richiesta verso internet, la richiesta arriva al server NAT FW che memorizza in una tabella, come dicevi tu, il socket IPFASTWEB:PORTAPP , poi genera un numero casuale che chiameremo PORT2 , lo associa al cocket che ha appena memorizzato in tabela e poi modifica il pacchetto da inoltrare sostituendo il suo IPNAT e PORT2 in modo che il sochet diventi IPNAT:PORT2. Ora il servente su internet a cui arriva la richiesta risponde al socket IPNAT:PORT2. In realtà non esiste nessuna connessione diretta tra utente fastweb e il servente su internet, ma sono due connessioni TCP o UDP spezzate. Il server nat è tutti gli effetti un reverse proxy. Il servente su internet non stabilisce NULLA con l'utente fw e non sa nemmeno che esista e riesce a comunicare con lui solo perchè la nat sa che la roba che ora arriverà su PORT2 è da forwardare al socket nella tabella corrispondente a PORT2. Ma un minuto dopo quel PORT2 potrebbe essere assegnato ad un altro utente se tu chiudi la connessione. Ovviamente ciò non significa che tutta la roba che arriva su PORT2 viene forwardata verso l'utente di questo esempio, ma solo quella appartenente alla connessione (coppia di socket)
il Tunneling non è una cosa precisa, è praticamente un concetto, come rimorchiare una ragazza, si può fare in tanti modi. alcuni di questi modi sono citati su wikipedia nella sezione "Common tunneling protocols".
Fare VPN significa fare tunneling, xkè i tuoi dati che viaggiano sulla VPN invece di usare il normale stack TCP/IP offerto dal sistema, usano un layer transport ulteriore che si POGGIA su quello appena citato per offrire gli stessi servizi e spesso altri ulteriori.
esatto, il tunneling è un concetto astratto, è un qualcosa che si stabilisce tra due terminali e ti assicura che qualsiasi informazione che entra da una sua estremità esce dall'altra, spesso dotato ovviamente con cripting e cose del genere orientate alla sicurezza
e sono daccordo anche sullo strato TCP virtuale soprastante
Se io apro una connessione TCP da A verso B, e su quella ci gira una VPN, allora i dati di quella VPN viaggeranno senza ulteriori difficoltà di indirizzi etc. Il problema è che stiamo parlando di una VPN, è come se fossimo in una rete locale. Ci vuole un altro mattone a questo punto, su B, che faccia da tramite tra internet e la VPN. Ma questo mattone non ha niente a che spartire col router di fastweb, è interamente demandato a B e il router non ne sa niente. Se la connessione è crittata non lo può sapere nemmeno se piange che quei dati vengono dal resto di internet. Sa solo di A e di B.
Si, quello che stai dicendo è giusto, ma non contraddice ciò che dico io
Prima di tutto io parlavo due utenti nattati contemporaneamente :) è un caso molto più difficile da trattare di quello che stai dicendo tu.
Quello che dici tu è diverso, significa solo che un utente nattato A instaura una connessione con B fuori dalla nat. E i dati vengono trasmessi sulla vpn tra A e B come se fossero in lan senza curarsi di come vengono trasmessi a livello inferiore. Ovviamente in termini pratici funziona esattamente come ho descritto prima, ovvero tramite il forwarding della porta che il server nat ha aperto per la connessione[e che deallocherà appena butti la butti giù].
Ma se B fosse dentro un'altra nat il tuo meccanismo non funzionerebbe. Almeno non senza una modifica. Tu instauri una vpn con il server hamachi, ma poi i dati non passano per questo server , ma vengono da B che ha un altro IP. Quindi il router deve poter capire che la roba proveniente da B deve essere inoltrata nonostante non provenga dal server hamachi. Ricordati che per definizione la connessione è una coppia di socket e che solo il TCP usa le connessioni, UDP è connectionless. La roba proveniente da altri socket viene ignorata. Il problema poi è che hamachi si basa su UDP. Dunque come fa l'udp hamachi a riuscire a creare una "connessione TCP virtuale" tra A e B ???
Il mio professore di Reti di calcolatori asseriesce che deve esserci un qualche tipo di supporto da parte del router. Non deve aver per forza ragione eh? Però appunto se tu lo sai spiegacelo perchè non l'abbiamo ben capito :)
Ora non sono sicuro tu a chi ti riferisci quando dici tunnel. Può essere che ti riferisci alla VPN stessa, ma volendo, per estensione del concetto, anche al "mattone". Non conosco il suo nome specifico, ma è sostanzialmente un gateway (http://en.wikipedia.org/wiki/Gateway_(computer_networking)).
E così funziona per esempio fast-ip. Si crea una VPN tra l'utente fastweb e il loro server, e poi il loro server forwarda il traffico tra la VPN e internet.
Perchè è necessaria la VPN? Serve xkè il NAT permette alle connessioni TCP (e l'HTTP si basa sul TCP) di essere stabilite solo da dentro verso fuori. HFS funziona che riceve le connessioni dai client, non le apre spontaneamente egli stesso. Funziona solo se gli arriva una richiesta, e le richieste (chiamate CONNECT, o anche dette SYN) il router di fastweb non le fa passare. (passano quando si fa forwardare la porta, e non è un servizio offerto da fastweb)
La VPN serve a permettere che sul nostro computer arrivi una normale chiamata CONNECT da fuori fastweb. Può arrivare perchè la chiamata CONNECT è tunnelizzata dalla VPN. Nel tunnel passa qualsiasi cosa, anche la connect.
Ma la VPN da sola fa sì che ci possa arrivare solo dall'altro end-point, e noi vorremmo poter ricevere connessioni da chiunque. E qui che entra in gioco il gateway di prima.
Cribbio quanto ho scritto. Spero serva almeno a qualcuno.
Esatto, e ci riesci perchè la nat ha instaurato una connessione per te con la tua destinazione. Nat = network address traslation , il nat traduce, B la roba la stava mandando a fastweb, non a te. é una profonda violazione del modello osi e non è come una banale connessione tra A e B. E la nat sa , ed è normale che sia così poichè è così che funziona, che tutta la roba appartenente alla connessione tra B e lei deve essere poi rimandata a te.
Questo è sicuro :)
In pratica b fa una connect con il server nat, che poi la reinoltra a te e tu rispondi etc etc.
La differenza tra questo è un portforwarding è che il portforwarding funziona sempre sulla stessa porta, mentre questo procedimento è un portforwarding che vale solo per la durata della singola connessione.
Fare tunneling tra due end points (accantonando il problema hamachi per ora, che è complicato da capire) è in pratica tenere aperta una connessione TCP COSTANTE, senza mai abbatterla, sopra la quale far passare tutto il resto, e nel caso della NAT in pratica è come avere un portforwarding costante perchè le connessioni virtuali vengono instaurate indifferentemente a partire da entrambi i lati basandosi sulla connessione tcp già stabilita (e sul port forwarding già stabilito) usando quel famoso MATTONCINO o strato virtuale in più di cui parlavi anche tu. In pratica se hai creato 10 connessioni tramite VPN, queste in realtà passano sulla connessione TCP stabilita prima.
strato applicativo 10 applicazioni client o server 10 applicazioni client o server
/\ /\
| |
\/ \/
strato trasporto 10 connessioni tramite VPN 10 connessioni VPN
/\ /\
| |
\/ \/
strato di rete virtuale scheda di rete virtuale (#incanala le connessioni virtuali scheda di rete virtuale
/\ sulla singola connessione fisica)
| /\
\/ |
strato di rete,internet scheda di rete fisica connessione TCP \/
con connessione TCP instaurata <--------------------------> scheda di rete fisica2
se c'è NAT si
usa port-forwarding
Ma in realtà tutto questo era chiaro, non so perchè ti spaventi davanti al termine port forwarding che in pratica altro non è che creare una connessione virtuale a livello superiore tramite due connessioni reali in serie. Quando tu parli di connessione tcp equivale a parlare di portforwarding se l'utente è connesso tramite nat :)
L'unica cosa sulla quale ancora ho dubbi è la questione hamachi....
Bisogna capire come fa il server hamachi ad aiutare i due endpoints nattati a instaurare una connessione tra di loro sopra la quale poi creare le varie connessioni virtuali.
-
con "VPN è tunneling", intendevo la relazione "is a", cioè VPN è un caso particolare di tunneling, che è diverso appunto dal dire che sono la stessa cosa. ambiguità dell'italiano. ;)
-
L'unica cosa sulla quale ancora ho dubbi è la questione hamachi....
Bisogna capire come fa il server hamachi ad aiutare i due endpoints nattati a instaurare una connessione tra di loro sopra la quale poi creare le varie connessioni virtuali.
Assegna a tutti e due un indirizzo ip DIFFERENTE, e li fa comunicare tramite i propri server, (sono diversi).
-
french can gli indirizzi hamachi sono virtuali, logici, funzionano solo a livello alto , ciò che dici non ha senso ....
le tabelle di routing su internet non gestiscono gli ip di hamachi, e se lo fanno di sicuro non portano i pacchetti all'utente hamachi ma al VERO possessore dell' ip 5.xxx.xxx.xxx
nessuno di questi servizi ti da un ipv4 vero, e dunque devono basare le loro connessioni su una connessione VERA, il tunneling appunto, stabilita precedentemente.
il problema è che se entrambi gli utenti sono nattati la connessione non si può instaurare a partire di nessuno degli end points.
sicuramente un modo c'è, perchè funziona, ma la risposta non è certo che hamachi assegna gli ip ....
-
Non ha nessuna importanza che gli indirizzi sono virtuali, vedi hamachi per instaurare le varie connessioni utilizza anche, a mio avviso il più vulnerabile dei servizi di windows (ma necessario per fare funzionare le connessioni internet), è cioè il "Netbios", infatti crea anche un "Netbios" falso a cui assegna i diversi numeri ip falsi su tutti i pc connessi, ma se non ci fosse uno dei server di hamachi, che memorizza le "impostazioni" delle varie connessioni, hamachi non funzionerebbe, quindi realizzando una vpn e un tunneling, senza l'aiuto di un server esterno, che fa questa funzione, la cosa non puo' funzionare.
-
Mi spiace ma non credo tu abbia capito molto ciò di cui sto parlando ... :(
Cosa centra il netbios e le schede di rete virtuali??? Internet è fatto di router che sanno gestire solo gli ip veri, i pacchetti con l'ip hamachi sono contenuti ("tunnellati") su normali pacchetti contenenti IP VERI, che devono essere trattati normalmente come tutti gli altri. I router in mezzo ad internet non processano e non sarebbero in grado di processare gli ip virtuali hamachi che non vengono proprio letti perchè sono campo DATI del vero pacchetto che sta passando. E quindi allo strato network vero deve essere inserito un ip sorgente VERO e un ip destinazione VERO. L'ip hamachi serve solo ed è usabile solo dagli end points del tunnel, ovvero coloro che installano hamahi. Come spiegato già altre N volte, il tunnel si basa su una connessione TCP già aperta. Se non puoi instaurare quella il tunnel non lo puoi fare e quindi i tuoi pacchetti con l'ip virtuale non vanno da nessuna parte. Se tu stai usando hamachi per accedere ad un utente fastweb, i tuoi pacchetti hamachi hanno come ip mittente il tuo ip virtuale, ip destinatario l'ip virtuale dell'utente fastweb... ma tale pacchetto è incapsulato in un pacchetto VERO che ha come dato il pacchetto di prima, come ip mittente il tuo ipv4, e come ip destinatario l'ip della NAT fastweb dal quale esce il tuo amico e come porta una porta della nat stabilita precedentemente. Questo pacchetto arriva al server nat e appartiene al socket della connessione IPNAT:PORTANAT - IPTUO:PORTATUA e quindi lui lo reinoltra all'utente interno che aveva in tabella corrispondente a IPNAT:PORTANAT ....
Questo è stato possibile perchè l'utente nat ha creato una connessione tcp con te (lo fa hamachi in automatico quando fa il login), scomposta in realtà in due come spiegato precedentemente.
Ma se entrambi sono nattati non ho ancora capitolo il protocollo che usa hamachi per creare la prima connessione iniziale.
Con la speranza CHE tu abbia capito quanto non centrino nulla gli ip virtuali aggiungo anche che hamachi non sfrutta nessuna vulnerabilità di windows ... ma stiamo scherzando? Senza dilungarmi in spiegazioni ulteriori dico solo che hamachi funziona anche su LINUX e le due versioni sono equivalenti, non usano altro che una normalissima connessione TCP e i driver per creare schede di rete virtuali e di sicuro non usano alcun baco o altro. Esistono programmi equivalenti come ad esempio DynGate che creano tunneling SENZA utilizzare ipvirtuali, ma solamente degli identificatori di alto livello. Questo per sottolineare quanto lo strato virtuale non centri nulla, centra solo il modo in cui fai tunneling.
Per favore se ti accingi a rispondere leggi prima attentamente ... :(
-
Credo che in sostanza diciamo entrambi la stessa cosa, anche se tu usi termini diversi, sei impreciso su un fatto, hamachi non usa connessione TCP, ma UDP, e ti assicuro che crea anche il netbios falso, a cui assegna i suoi ip falsi, se hai ancora ulteriori dubbi sulla cosa, ti posso dimostrare che quanto dico e vero, il netbios falso servirà in qualche maniera a fare funzionare hamachi, altrimenti non avrebbe senso che il programma lo crei. Se vuoi ti spiego come verificare la cosa. ???
-
Non lo so se le interfacce virtuali si chiamano anche netbios, quello che so è che i diver TAP non sono una vulnerabilità nè di windows nè di linux
Hexego, Aiccu, Hamachi sono tutti software che sfruttano tunneling su interfacce virtuali e funzionano anche su linux e non si basano su vulnerabiltà di alcun tipo.
Che netbios falso == interfaccia virtuale ripeto che non lo so, ma di sicuro non sfruttano alcun bug o vulnerabilità.
Per concludere per quanto riguarda hamachi il punto è proprio quello ... non si riesce a capire cosa fa esattamente, l'avevo scritto anche io 5 reply fa che hamachi non usa connessione TCP, ma il punto è che loro stessi sono molto ambigui :
2. Which ports / protocols does LogMeIn Hamachi use?
Hamachi connects to a central server on ports 12975 and 32976 over your Internet connection using TCP. These are destination ports on our server. Since Microsoft uses random outgoing ports to connect to specified target ports, you need to configure your firewall accordingly.
The first port is used for an initial contact, and the second is used for an actual session. You can set a static UDP listening port by configuring it in Preferences > Detailed Configuration, but note that this will require you to forward that port's UDP traffic from your router to the machine, if you are behind a router. Also note that if you have multiple machines to do this on, you will need to choose different ports for each to avoid conflicts.
It also uses dynamic local and remote UDP ports for communicating with other Hamachi peers.
If the methods above fail in connecting the the Mediation Server (bibi.hamachi.cc), Hamachi will try to use standard SSL connectivity (TCP port 443) to connect to it. This will not, however, affect the UDP parts.
Hamachi also support http proxy servers, which can be configured in Hamachi Preferences > Detailed Configuration.
-
Io non intendevo dirti che hamachi sfrutta vulnerabilità, ti indevo dire che a mio avviso, il servizio netbios, è tra le vulnerabilità di windows, ma visto che non sai nemmeno che cosa è il netbios, non riesco a capire come fai a parlare di reti, se non conosci la "testa" di qualcuno, come fai a capire come funziona?
-
hamachi per instaurare le varie connessioni utilizza anche, a mio avviso il più vulnerabile dei servizi di windows
-----------------------
Io non intendevo dirti che hamachi sfrutta vulnerabilità, ti indevo dire che a mio avviso, il servizio netbios, è tra le vulnerabilità di windows, ma visto che non sai nemmeno che cosa è il netbios, non riesco a capire come fai a parlare di reti, se non conosci la "testa" di qualcuno, come fai a capire come funziona?
io non ho detto di non sapere cosa è un netbios , ho detto che non so se corrisponde a quello che hai in testa tu, visto che non sai distinguere il concetto di java virtual machine dal concetto di applet java
-
so cosa è un applet java, ma quello a cui ti riferisci tu non funziona come dici tu. So per esperienza che molte cose che si danno per scontate, in effetti non lo sono, e comunque non voglio fare polemica inutile, o precisazione su qualche frase scritta male, quello che credo che interessi agli utenti di questo forum è il fatto che la cosa funzioni realmente è in maniera semplice, perciò per quanto mi riguarda, cercherò di evitare discorsi inutili, amici come prima, almeno per me. :) ;)
-
Mi spiace ma funziona esattamente come ho descritto sopra. Io non ho litigato con nessuno.
-
Probabilmente ci capiamo male, ma diciamo entrambi la stessa cosa, su questo ne sono convinto, il male di non riuscire a confrontarsi direttamente, ma non volermene. ;)
-
bene , alla fine era come avevo supposto io nell'altro topic
Questo è la spiegazione scritta in maniera formale
http://en.wikipedia.org/wiki/UDP_hole_punching
Riassumendo , ho utilizzato WireShark per confermarlo , hamachi crea delle connessioni TCP con dei server esterni visibili da tutti , con hostname tipo alpha.hamachi.cc, delta.hamachi.cc , charly.hamachi.cc sono tutti diversi e intervengono in fasi diverse della sincronizzazione iniziale. Una volta stabilita la connessione TCP con i server , che probabilmente viene usata per avere una connessione affidabile e su cui trasmettere le informazioni sui peer appartenenti sulla tua stessa VPN , il tuo client comincia a mandare segmenti UDP verso charly.hamachi.cc (almeno così ho visto). Il server NAT fastweb a questo punto apre temporaneamente la solita porta qualsiasi (UDP questa volta) . Ora da questo momento in poi i due client hamachi cominciano a mandare segmenti UDP verso l'ip dei due NAT servers diversi usando la porta comunicata loro dal server hamachi esterno tramite la connessione TCP. Come dice wikipedia i primi frammenti verranno rifiutati, ma una volta che NAT-A avrà memorizzato il fatto che A ha cercato di mandare un frammento UDP a NAT-B , allora reinoltrerà ad A anche i frammenti provenienti da NAT-B e viceversa.
Cmq sulla pagina di wikipedia trovate l'algoritmo come ve l'ho descritto io ma in maniera più sintetica.
Quì http://en.wikipedia.org/wiki/Hamachi invece trovate scritto chiaramente che hamachi usa una tecnica basata su questo principio.
come vedete era quasi la cosa che avevo supposto io
mi riautoquoto
normalmente tra due utenti NATTATI (diverse nat) non potrebbero in nessun caso comunicare tra loro perchè nessuno può INSTAURARE nulla ...
Usando hamachi invece il primo utente joina una certa VPN hamachi, e si mette in comunicazione con il server hamachi tramite tunneling. Questo lo aggiunge alla liste dei membri della VPN e tiene in memoria le caratteristiche dell'utente , tra cui il socket da cui si è connesso (che nel nostro caso corrisponde all' IPNAT:PORTA di prima). Quando il secondo utente joina la VPN accade la stessa cosa di prima. Ora l'utente uno e due possono dialogare sulla stessa VPN direttamente tra di loro senza passare per il server intermediario, perchè questo comunica a entrambi i socket con cui raggiungere l'altro utente. Ovviamente accade lo stesso nelle VPN hamachi da 16 o 256 utenti
Usando questo algoritmo tra le varie nat e i vari server hamachi vengono scambiati solo frammenti TCP e UDP aventi a strato network i loro IP reali, come è normale che sia. Gli ip fastweb esistono solo tra il vostro pc e la vostra nat dopo di che vengono sostituiti. Gli ip virtuali esistono solo nel pacchetto ip virtuale contenuto nel campo dati dei frammenti UDP mandati come sopra descritto, e non servono minimamente durante l'instaurazione e non vengono letti durante il routing. Servono assieme all'interfaccia virtuale a creare uno strato cuscinetto che renda trasparente il discorso fatto sopra alle varie applicazioni come poi la connessione viene veramente implementata.
-
è buffo aver passato ore a impelagarci quando stava scritto tutto bello bello su wikipedia :D
cmq alla fine s'è capito: un risultato non da poco.
-
Scusate il disturbo, sono anch'io molto interessato all'utilizzo di ipv6 e hfs dato che ho un pc fastweb a cui posso accedre solo tramite hamachi e/o logmein. Da un po' sto provando a configurare il client go6 (anche se da configurare c'è ben poco) e relay6 senza risultati purtroppo. Premetto che con entrambi i client attivi riesco a pingare in ipv6 entrambe le macchine reciprocamente. Che ne direste di spiegare come impostare relay6?
-
personalmente non posso aiutarti.
spero gli altri siano ancora all'ascolto, perché il topic è vecchiotto.
-
niente sembra che ormai questo 3d sia finito nel dimenticatoio. peccato :(