Che cosa c'è di così difficile nella perforatura con p2p?

Question

Sto provando a sperimentare con alcune reti p2p. Dopo aver fatto qualche ricerca, uno dei maggiori ostacoli che ho imparato è "Cosa succede se un cliente è dietro un NAT/Firewall", in seguito ho scoperto di Hole Punching ma non è sempre garantito il funzionamento.

Per quanto un ho capito, non capisco il motivo per cui potrebbe non riuscire, questo è quello che so finora:

---

Sulla base del diagramma qui sopra, questo è come ho capito come una connessione può essere stabilito

1. Alice si unisce alla rete (1) creando il collegamento a una directory server. Quando ciò accade, il NAT di Alice crea una mappatura dal suo IP pubblico al suo ip locale.
2. Il server di directory riceve la connessione e negozio di Alice pubblico ip:port nella directory
3. Bob fa la stessa (2), si unisce alla rete e pubblica il suo ip:port nella directory
4. Alice vuole comunicare con bob. Quindi cerca di Bobip:port dalla directory. (3)
5. Alice invia i dati relativi Bobip:port, che ha ottenuto dal server. (5)
6. Dal Bob ha anche una mappatura da è ip:port al suo locale ip:port, il NAT inoltra semplicemente i dati ricevuti su di Bob pubblico ip:port al suo computer.
7. stesse opere per Alice

   ---

   Spero di essere stato chiaro nella mia spiegazione di quello che ho capito. La mia domanda è, cosa c'è di così difficile o inaffidabile a riguardo? mi deve essere chiaramente manca qualcosa. Puoi spiegarmi di cosa si tratta?

Answer 1

Un problema è che i mapping NAT nel server NAT di Alice scadono, sia dopo un determinato periodo di tempo, sia dopo un periodo di inattività.

Un secondo problema potenziale è che il server NAT potrebbe limitare la mappatura del NAT di Alice solo "buono" per le connessioni TCP stabilite da Alice, o le connessioni tra Alice e l'IP iniziale "lei" connessa. (In altre parole, la comunicazione diretta tra Alice & Bob potrebbe essere bloccata.)

E così via.

Il problema è che il comportamento di di un server NAT dipende in larga misura da come le decisioni di configurazione/politica dell'organizzazione di gestione. Molte di queste decisioni potrebbero significare che il tuo particolare modello di utilizzo del P2P non funzionerà in modo affidabile ... o del tutto.

---

Allora è tutta la mia idea circa la perforazione di sbagliato?

No. Significa solo che non funzionerà sempre.

Answer 2

I firewall sono in genere stateful. Bob (2) che stabilisce le comunicazioni con il server di directory esterno imposta una regola nel proprio server NAT che consente a Bob e al server di directory di comunicare. Quando il server NAT vede pacchetti da Alice, li rifiuta/li elimina perché non ha visto Bob stabilire comunicazioni con Alice.

Answer 3

Probabilmente il problema più grande nel holepunching NAT è la mancanza della consistenza della porta . Affinché la tua implementazione funzioni, almeno uno dei due NAT deve supportarlo.

La coerenza di porta è dove lo stesso (local ip, local port) è mappato allo stesso (external ip, external port) indipendentemente dallo (destination ip, destination port). Senza questo, la porta vista dal server di directory non è utile per il cliesince che non sarà la stessa porta che i client dovranno comunicare tra loro.

(Si noti che questo è un requisito più debole di port preservation, dove external port == local port.)

Purtroppo per la comunicazione P2P, la maggior parte dei NATs sono un certo sapore di Symmetric NAT e fare non hanno mapping delle porte coerenti.

Answer 4

Innanzitutto ci sono 2 tipi di perforatura 1.UDP perforatura 2.TCP perforatura

foro UDP tasso di successo punzonatura è 82% TCP perforatura tasso di successo è del 64% Ho fatto molti esperimenti di punzonatura UDP e sono stati per lo più tutti di successo, ma non lo stesso nel caso di perforazione del foro TCP.

Il motivo alla base dell'errore della perforatura TCP è solo la tabella NAT del router. Cercherò di spiegare il mio meglio: client

1 -> connect (client2) --Internet-- collegare (client1) < - client 2

Ora, se Client1 ** pacchetto SYN * *** raggiunge il client2 e ** client2 ** Il pacchetto SYN non è stato rilasciato **, il ROUTER del client2 può fare 2 cose: 1. inviare il pacchetto RST come connessione rifiutata a client1. 2. rilascia immediatamente il pacchetto e nessuna risposta viene inviata al client1.

Se ciò accade, non verrà stabilita alcuna connessione.

Posso solo suggerire una soluzione che la differenza di tempo tra la chiamata di connessione da entrambi i client dovrebbe essere molto inferiore.La differenza Call Connect dovrebbe essere in millisecondi

SUGGERIMENTO: se si è in rete locale, mettere disabilitare il firewall

per l'utente ubuntu: sudo ufw disattivare