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