HFS e ipv6 [RISOLTO]

[dragon]

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

[FRENCH CAN CAN]

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.

[dragon]

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

[FRENCH CAN CAN]

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. 

[dragon]

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.

[FRENCH CAN CAN]

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?

[dragon]

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

[FRENCH CAN CAN]

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.   

[dragon]

Mi spiace ma funziona esattamente come ho descritto sopra. Io non ho litigato con nessuno.

[FRENCH CAN CAN]

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. 

[dragon]

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.

[rejetto]

è buffo aver passato ore a impelagarci quando stava scritto tutto bello bello su wikipedia
cmq alla fine s'è capito: un risultato non da poco.

[makno]

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?

[rejetto]

personalmente non posso aiutarti.
spero gli altri siano ancora all'ascolto, perché il topic è vecchiotto.

[makno]

niente sembra che ormai questo 3d sia finito nel dimenticatoio. peccato