What's so hard about p2p Hole Punching?

|▌冷眼眸甩不掉的悲伤 提交于 2019-12-03 11:39:57

问题


I am trying to experiment with some p2p networking. Upon doing some research, one of the biggest obstacle I learnt is "What if a client is behind a NAT/Firewall", later on I discovered about Hole Punching but that it is not always guaranteed to work.

As far a I understand, I don't understand why it might fail, This is what I know so far:



Based on the diagram above, this is how I understand how a successful connection can be established.
  1. Alice joins the network (1) by creating connection to a directory-server. When this happens, Alice's NAT creates a mapping from her public ip to her local ip.
  2. The directory server receives the connection and store Alice's public ip:port in the directory
  3. Bob does the same (2), Joins the network and publishes his ip:port in the directory
  4. Alice wants to communicate with bob. So she looks up Bob's ip:port from the directory. (3)
  5. Alice sends data on Bob's ip:port which she got from the server. (5)
  6. Since Bob also has a mapping from is ip:port to his local ip:port, the NAT simply forwards any data received on Bob's public ip:port to his computer.
  7. Same works for Alice
    I hope I was clear in my explanation of what I understand. My question is, what is so hard or unreliable about this? i must be clearly missing something. Can you explain me what it is?

回答1:


One problem is that the NAT mappings in Alice's NAT server will time out, either after a fixed time, or after a period of inactivity.

A second potential problem is that the NAT server could make the restriction that Alice's NAT mapping is only "good" for TCP connections established by Alice, or connections between Alice and the initial IP "she" connected to. (In other words, direct communication between Alice & Bob may be blocked.)

And so on.

The problem is that the behaviour of a NAT server is highly dependent on how the managing organization's configuration / policy decisions. Many of these decisions could mean that your particular P2P usage pattern won't work reliably ... or at all.


So then is my whole idea about hole punching wrong?

No. It just means that it won't always work.




回答2:


Firewalls are typically stateful. Bob (2) establishing communications with the outside directory server sets up a rule in his NAT server that allows Bob and the directory server to communicate. When the NAT server sees packets from Alice, it rejects/drops them because it hasn't seen Bob establish communications with Alice.




回答3:


Possibly the biggest problem in NAT holepunching is lack of port consistency. For your implementation to work, at least one of the two NATs must support it.

Port consistency is where the same (local ip, local port) is mapped to the same (external ip, external port) regardless of the target (destination ip, destination port). Without this, the port seen by the directory server is not helpful to the client since it will not be the same port the clients will need to talk to each other.

(Note that this is a weaker requirement than port preservation, where external port == local port.)

Unfortunately for P2P communication, most NATs are some flavor of Symmetric NAT and do not have consistent port mappings.




回答4:


First of all there are 2 types of hole punching 1.UDP hole punching 2.TCP hole punching

UDP hole punching success rate is 82% TCP hole punching success rate is 64% I have done many UDP hole punching experiments and they were mostly all successful but not same in the case of TCP hole punching.

The reason behind the failure of TCP hole punching is only the router NAT table. I will try to explain my best:

Client 1 --> connect(client2) --Internet-- connect(client1)<-- Client 2

Now if Client1 **SYN Packet**** reaches to the client2 and **client2 **SYN packet wasn't released** , the ROUTER of client2 can do 2 things: 1. send RST packet back as connection refused to client1. 2. drop packet immediately and no reply send to client1.

If this happens no connection will be established.

I can only suggest a solution that time difference between connect call from both the client should be very less. The connect call difference should be in milli-seconds

TIP: if you are in local network , put disable your firewall

for ubuntu user : sudo ufw disable



来源:https://stackoverflow.com/questions/23176800/whats-so-hard-about-p2p-hole-punching

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!