search

DexterWoo / EasyTalk

0 stars 0 forks source link

TCP hole punching #1

Open ghost opened 6 years ago

ghost commented 6 years ago

According to https://en.wikipedia.org/wiki/UDP_hole_punching Section overview mentioned:

The same technique is sometimes extended to Transmission Control Protocol (TCP) connections, though with less success because TCP connection streams are controlled by the host OS, not the application, and sequence numbers are selected randomly; thus any NAT device that performs sequence-number checking will not consider the packets to be associated with an existing connection and drop them.

ghost commented 6 years ago

https://en.wikipedia.org/wiki/TCP_hole_punching mentions port prediction. I don't think port prediction is a good idea, not gonna work as you predicted.

According the part below, this depends too much on the NAT strategy! Maybe we need to investigate what NAT type/strategy is mostly used, and do something according to them. If most of the strategies are similar, we try TCP hold punching, if fail, we try another hole punching tech.

For the TCP simultaneous open to work, the NAT should:

  • not send an RST as a response to an incoming SYN packet that is not part of any mapping
  • accept an incoming SYN for a public endpoint when the NAT has previously seen an outgoing SYN for the same endpoint