所需积分/C币:50 2014-09-06 19:21:04 982KB PDF
收藏 收藏

p2p网络中napt穿透原理(详细).pdf 看看
Server s Server s ( ( IIBE MITE Scssion a-s k Scssion B-S (2)Relayed 18.1810.31:1214 18.1810.31:1234 1559925.11:62000 138.76.297:31000 Request Main internet Main internet (1)ke NAT NAT NAT (15599.25.11) ( ( Session a Session b-s 18.181.031:1234 rivate 18.181031:1234 ()Reverse Client B 10001:4321、 Network Network 10.1.13:4321 Network Connection (138.76 29.7) Client 4 Client B Client A ( ( (100.0.1) Figure 2: NAT Traversal by Relayin Figure 3: NAT Traversal by Connection Reversal 2.2 Relaying known rendezvous server S and only one of the peers is The most reliable- but least efficient--method of p2p behind a nat. as shown in Figure 3. If a wants to ini communication across nat is simply to make the com- tiate a connection to B, then a direct connection attempt munication look to the network like standard client/server works automatically, because B is not behind a Nat and communication, through relaying. Suppose two client As NAT interprets the connection as an outgoing session hosts a and b have each initiated tcP or uDP connec- If B wants to initiate a connection to A, however, any tions to a well-known server s, at S's global IP address direct connection attempt to A is blocked by A's NAT and port number 1234. As shown in Figure 2, B can instead relay a connection request to A through the clients reside on separate private networks, and their a well-known server S, asking A to attempt a"reverse?"? respective Nats prevent either client from directly initiat connection back to B. Despite the obvious limitations of this technique the central idea of using a well-known ren- ing a connection to the other. Instead of attempting a di rect connection, the two clients can simply use the server dezvous server as an intermediary to help set up S to relay messages between them. For example to send peer-to-peer connections is fundamental to the more gen a message to client B, client A simply sends the message ral hole punching techniques described next tion and server s forwards the message on to client b 3 UDP Hole Punching using its existing client/server connection with B UDP hole punching enables two clients to set up a direct Relaying always works as long as both clients can con- peer-to-peer uDP session with the help of a well-known nect to the server Its disadvantages are that it consumes rendezvous server even if the clients are both behind the servers processing power and network bandwidth, NATs. This technique was mentioned in section 5.1 of and communication latency between the peering clients is RFC 3027[10], documented more thoroughly elsewhere likely increased even if the server is well-connected. Nev- on the Web [13], and used in recent experimental Internet ertheless, since there is no more efficient technique that protocols [17, 11]. Various proprietary protocols, such as works reliably on all existing NATs, relaying is a useful those for on-line gaming, also use UDP hole punching fall-back strategy if maximum robustness is desired. The TuRn protocol [18] defines a method of implementing 3.1 The Rendezvous server relaying in a relatively secure fashion Hole punching assumes that the two clients, A and b, al 2. 3 Connection reversal ready have active UDP sessions with a rendezvous server s. When a client registers with s, the server records two Some P2P applications use a straightforward but limited endpoints for that client: the(IP address, UDP port) pair technique, known as connection reversal, to enable com- that the client believes itself to be using to talk with s, munication when both hosts have connections to a well- and the (lp address, UDP port)pair that the server ob- USENIX ASSOCIation 2005 USENIX Annual Technical conference 181 Server s Server s Server s ( (2) Forward B's 18.1810.31) (181810.31) 10.1.13:4321 1000.L:4321 Session A-s Session B Session A-s Session B-S 181810.31:123418310.31:1234 18181031:12318.1810311234 50925.1::62000 1559925.11:62005 559925.11:62000155992511:6205 NAT i1559925,11 (1559925.11) (15599.25.11) Session bs Session a-s 8.1810.3:1234 8.1810.1:1234 000.14321 (1) Request(3)Send to B at 10.00.:4321 55925.11:52005(a15599.25.11:62000 1UUU1:421 Session A-B Client A Client B Client A Client B Client a 100.0.1: 4321 Client B 141..3:4321 (10.11.3) (100.0.1) ( ( Before hole punching The Hole Punching Process After Hole Punching Figure 4: UDP Hole Punching, Peers Behind a Common NAT serves the client to be using to talk with it We refer to the from S, A starts sending UDP packets to both first pair as the clients privale endpoint and the second of these endpoints, and subsequently locks ir as the clients public endpoint. The server might obtain whichever endpoint first elicits a valid response from the clients private endpoint from the client itself in a field B. Similarly, when B receives A's public and pri in the body of the clients registration message, and obtain vate endpoints in the forwarded connection request the clients public endpoint from the source IP address and B starts sending UDP packets to A at each of As source UDP port fields in the IP and UDP headers of that known endpoints, locking in the first endpoint that registration message. If the client is not behind a nat, works. The order and timing of these messages are then its private and public endpoints should be identical not critical as long as they are asynchronous a few poorly behaved NATs are known to scan the body of udP datagrams for 4-byte fields that look like IP addresses, and translate them as they would the Ip address We now consider how UDP hole punching handles each fields in the ip header To be robust against such behav of three specific network scenarios. In the first situation ior, applications may wish to obfuscate IP addresses in representing the"easy"case, the two clients actually re messages bodies slightly, for example by transmitting the side behind the same nat, on one private network. In the one's complement of the IP address instead of the IP ad. second, most common case, the clients reside behind di/c dress itself. Of course if the application is encrypting its ferent NATs. In the third scenario, the clients each reside messages, then this behavior is not likely to be a problem behind two levels of nat: a common"first-level"'nat de ployed by an ISP for example, and distinct " second-level 3.2 Establishing Peer-to-Peer Sessions NATs such as consumer nat routers for home networks rectly with client B. Hole punching proceeds as follows: tion isel general difficult or impossible for the applica- Suppose client A wants to establish a UDP session di- It is in to determine the exact physical layout of the network, and thus which of these scenarios(or the many 1. A initially does not know how to reach B, So A asks other possible ones)actually applies at a given time. Pro- S for help establishing a UDP session with B tocols such as stun [19 can provide some information 2. S replies to A with a message containing b's public about the NATs present on a communication path, but this and private endpoints. At the same time, S uses its information may not always be complete or reliable, espe- UDP Session with B to send B a connection request cially when multiple levels of NaT are involved. Never- message containing A's public and private endpoints theless, hole punching works automatically in all of these Once these messages are received. A and B know scenarios without the application having to know the spe each others public and private endpoints cific network organization, as long as the nats involved behave in a reasonable fashion. ("Reasonable?"behavior 3. When A receives B's public and private endpoints for NATs will be described later in Section 5. 182 2005 USENIX Annual Technical conference USENIX ASSOcIation Server s Server s 18.1810.31 ( 位2)F 18.181.031) m子 Endpoints to B mInEn 138.76297:31000 l113421 l101432 Session A-s Session B-s 18181031.1 18.1B10.31:1234 18181031.1234 1559925.11:62000 138.76.29731000 1.6200X 7:31000 NAT NAT NAT NAT NAT (155992511) 13876297) (155992511) (138.7629 (1559925.11) (13875297) Sess: on A-S ession b- (3)Send tob at et Session A S Session A-B 1R181n311234 8.18103::1234 1559925.11:6200 18181.0.31:1234 1000155.99.25.11:6200 0D..14321 1011.3432 b:10.L1.3:4321 tb10. 1000.:4321 10.0.01:4321 10.11.3:432L Connection 口-以 Client A Client B Client A Client B Client a Client B (10.0.C.1) (1).1.1.3 (10.00.1) ( (100.0.1) (10.1.13) Before Hole punching ng The hole punching process After Hole Punching Figure 5: UDP Hole Punching, Peers Behind Different NATs 3.3 Peers behind a Common nat behaviors. For now therefore applications may benefit substantially by using both public and private endpoints First consider the simple scenario in which the two clients (probably unknowingly) happen to reside behind the same 3.4 Peers behind Different nats NAT, and are therefore located in the same private Ip ad dress realm, as shown in Figure 4. Client A has estab- Suppose clients A and B have private IP addresses be lished a UDP session with server s to which the com- hind different NATs, as shown in Figure 5. A and B have mon nat has assigned its own public port number 62000. each initiated UDP communication sessions from their lo- Client b has similarly established a session with S, to cal port 432 1 to port 1234 on server S. In handling these which the nat has assigned public port number 62005 outbound sessions, nat A has assigned port 62000 at its Suppose that client A uses the hole punching technique own public IP address. for the use of A's outlined above to establish a UDP session with b using session with S, and NAT B has assigned port 3 1000 at its server S as an introducer. Client A sends S a message IP addreSs, 138. 76.29.7, to B's session with S requesting a connection to B. s responds to A with B's In A's registration message to S, A reports its private public and private endpoints, and also forwards A's pub- endpoint to S as 4321, where is A's IP lic and private endpoints to B. Both clients then attempt address on its own private network. S records A,'s re to send uDP datagrams to each other directly at each of ported private endpoint, along with A's public endpoint these endpoints. The messages directed to the public end- as observed by S itself. A,s public endpoint in this case points may or may not reach their destination, depending is 62000, the temporary endpoint assigned on whether or not the Nat supports hairpin translation as to the session by the nat. similarly, when client b regis- described below in Section 3.5. The messages directed at ters, S records B's private endpoint as 4321 and the private endpoints do reach their destinations, however. B's public endpoint as 138.. 29.7: 31000 and since this direct route through the private network is Now client A follows the hole punching procedure de- likely to be faster than an indirect route through the nat scribed above to establish a UDP communication session anyway, the clients are most likely to select the private directly with B. First, A sends a request message to S ask- endpoints for subsequent regular communication ing for help connecting with b. In response s sends bs By assuming that NATs support hairpin translation, the public and private endpoints to A, and sends A's public application might dispense with the complexity of trying and private endpoints to B. A and B each start trying to private as well as public endpoints, at the cost of making send uDP datagrams directly to each of these endpoints local communication behind a common NaT unnecessar- Since A and B are on different private networks and ily pass through the Nat. As our results in Section 6 show, their respective private IP addresses are not globally however, hairpin translation is still much less common routable, the messages sent to these endpoints will reach among existing NATs than are other "P2P-friendly'nat either the wrong host or no host at all. Because many USENIX ASSOCIation 2005 USENIX Annual Technical conference 83 Server s erv Server s (18181031 (18.1810.31) (2)Forward As 18.181.031) Endpoints to B 1559925.11:62005 1559925.11:62000 四m 11134321 nn143?1 Session A SSessionB S 18.181031.1234 181031.1234 181810.31123418181.0311234 99.25.11:62000 1559925.11:2005 5.9925.11:62000 NATO NATO NATO (15599.25.11) Session A-s Session b-s Session A-s Session b-s 18.1810.3l:123 18.1810.31:1234 Session A-B 100.1.145000 l.1.2:55m 10.01.:4500 1559925.11:6205 100.12:55000 lU1.1:45000 ssion A-B 155.9925.l1:620LU 100.L.2:55000 NATA nat B NATA nATB NATA nAt B (1C.0.L.1) (100.1.2) (00.L. casion B-s Send to l at Send toA a 1311031:1234 8,18L0.31:1234 55925.11:62005(3)1559925.10200 Session A-s Session A-B Session B-sS 0.3C.1:4321 18.18L031:1234 55992516205159510201181J31:1234 (b)10.113:1321 10.00.1:4321 1114321 -×x Client a Client b Client a Client B Client a Client B (10.11 ( Before Hole Punching The Hole Punching Process After Hole Punching Figure 6: UDP Hole Punching, Peers Behind Multiple Levels of NAT NATs also act as DHCP servers, handing out IP addresses If A' s message to B's public endpoint reaches B's NAT in a fairly deterministic way from a private address pool before B's first message to A has crossed B's own NAt, usually determined by the nat vendor by default, it is then Bs NAT may interpret A's inbound message as un- quite likely in practice that A's messages directed at B's solicited incoming traffic and drop it. Bs first message private endpoint will reach some(incorrect) host on A's to A's public address, however, similarly opens a hole in private network that happens to have the same private iP B's nat, for a new UDP session identified by the end- address as B does. Applications must therefore authen- points( 4321, 62000)on Bs pri ticate all messages in some way to filter out such stray vate network, and by the endpoints(138.76. 29.7: 31000 traffic robustly. The messages might include application- 62000)on the Internet. Once the first mes- specific names or cryptographic tokens, for example, or at sages from A and B have crossed their respective NAts least a random nonce pre-arranged through S holes are open in each direction and UdP communica tion can proceed normally. once the clients have verified Now consider As first message sent to B's public end that the public endpoints work, they can stop sending mes point, as shown in Figure 5. As this outbound message sages to the alternative private endpoints passes through As NaT, this NaT notices that this is the hirst UDP packet in a new outgoing session. The new ses- 3.5 Peers Behind Multiple Levels of NAT sion's source endpoint ( 4321) is the same as that of the existing session between A and S, but its desti- In some topologies involving multiple nat devices, two nation endpoint is different. If NAT A is well-behaved, it clients cannot establish an"optimal"P2P route between preserves the identity of As private endpoint, consistently them without specific knowledge of the topology. Con- translating all outbound sessions from private source end- sider a final scenario, depicted in Figure 6. Suppose naT point 432 1 to the corresponding public source C is a large industrial naT deployed by an internet ser- endpoint 62000. A's first outgoing mes- vice provider(Isp) to multiplex many customers onto a sage to B's public endpoint thus, in effect, "punches a few public IP addresses, and NATs A and B are small hole " in A,s NaT for a new udP session identified by the consumer nat routers deployed independently by two of endpoints( 4321, 3 1000)on A's pri- the ISP's customers to multiplex their private home net- vate network, and by the endpoints (155.99. 25.11: 62000, works onto their respective ISP-provided IP addresse 31000)on the main Internet Only server S and nat C have globally routable IP ad 184 2005 USENIX Annual Technical conference USENIX ASSOcIation dresses: the "public"IP addresses used by Nat A and is unfortunately no standard value for this timer: some NAT B are actually private to the isPs address realm, NATs have timeouts as short as 20 seconds. If the appli- while client As and B's addresses in turn are private to cation needs to keep an idle UDP session active after es the addressing realms of nat A and NAT B, respectively. tablishing the session via hole punching, the application Each client initiates an outgoing connection to server S as must send periodic keep-alive packets to ensure that the before, causing NATs A and B each to create a single pub- relevant translation state in the nats does not disappear. lic/private translation, and causing NAT C to establish a Unfortunately, many NATs associate UDP idle timers public/private translation for each session with individual UDp sessions defined by a particular pair Now suppose A and B attempt to establish a direct of endpoints, so sending keep-alives on one session will peer-to-peer UDP connection via hole punching. The not keep other sessions active even if all the sessions orig optimal routing strategy would be for client A to send inate from the same private endpoint. Instead of sending messages to client B's"semi-public endpoint at NAT keep-alives on many different P2P sessions, applications B, 55000 in the ISP's addressing realm, and can avoid excessive keep-alive traffic by detecting when a for client b to send messages to A's"semi-public"end- UDP session no longer works, and re-running the original point at NAT B, namely 10.0.1. 1: 45000. Unfortunately, hole punching procedure again"on demand a and b have no way to learn these addresses, because server S only sees the truly global public endpoints of the 4 TCP Hole punching clients,15599.25.11:62000and155.99.25.11:62005re spectively. Even if A and B had some way to learn these Establishing peer-to-peer TCP connections between hosts addresses, there is still no guarantee that they would be behind NATs is slightly more complex than for UDP, but usable, because the address assignments in the ISP's pri- TCP hole punching is remarkably similar at the protocol vate address realm might conflict with unrelated address level. Since it is not as well-understood, it is currently assignments in the clients' private realms. (NAT A's IP supported by fewer existing NATs. When the NATs in address in NAT C's realm might just as easily have been volved do support it, however, TCP hole punching Is Just, for example, the same as client B's private ad as fast and reliable as UDP hole punching. Peer-to-peer dress in NAT B's realm) TCP communication across well-behaved Nats may in The clients therefore have no choice but to use their fact be more robust than UDP communication, because global public addresses as seen by S for their P2P com unlike UDP, the TCP protocols state machine gives Nats munication,and rely on NAT C providing hairpin or loop on the path a standard way to determine the precise life- back translation. When A sends a UDP datagram to b,s time of a particular TCP session lobal endpoint, 1: 62005, NAT A first trans-4.1 Sockets and TCP Port Reuse lates the datagrams source endpoint from 4321 to 45000. The datagram now reaches nat C, The main practical challenge to applications wishing to which recognizes that the datagram's destination address implement TCP hole punching is not a protocol issue but is one of NAT Cs own translated public endpoints. If an application programming interface(APD) issue. Be naT C iS well-behaved it then translates both the source cause the standard Berkeley sockets API was designed and destination addresses in the datagram and"loops"around the client/server paradigm, the aPi allows a TCP the datagram back onto the private network, now with a stream socket to be used to initiate an outgoing connection source endpoint of 62000 and a destination via connect (), or to listen for incoming connections endpoint of 55000. NAT B finally translates the via listen ()and accept(), but not both. Further, datagram's destination address as the datagram enters B's TCP sockets usually have a one-to-one correspondence to private network, and the datagram reaches B. The path TCP port numbers on the local host: after the application back to A works similarly Many Nats do not yet support binds one socket to a particular local TCP port, attempts hairpin translation, but it is becoming more common as to bind a second socket to the same TCP port fail nat vendors become aware of this issue For TCP hole punching to work, however, we need to 3.6 UDP Idle Timeouts use a single local tCP port to listen for incoming TCP connections and to initiate multiple outgoing TCP con Since the UDP transport protocol provides Nats with nections concurrently. Fortunately, all major operating no reliable, application-independent way to determine the systems support a special TCP socket option, commonly lifetime of a session crossing the NAT, most NATs simply named SO_REUSEADDR, which allows the application to associate an idle timer with UDP translations, closing the bind multiple sockets to the same local endpoint as lon hole if no traffic has used it for some time period. There as this option is set on all of the sockets involved. BSD USENIX ASSOCIation 2005 USENIX Annual Technical Conference 185 systems haye introduced a so reuseport option that Connections to s controls port reuse separately from address reuse: on such systems both of these options must be set 4.2 Opening Peer-to-Peer TCP Streams Suppose that client A wishes to set up a TCP connection Peer-to-Peer with client B. We assume as usual that both a and Connections already have active TCP connections with a well-known rendezvous server s. The server records each registered client's public and private endpoints, just as for UDP. At the protocol level, tCP hole punching works almost ex Local actly as for UDP TCP Port TCP Port 1. Client A uses its active tcP session with s to ask s Listen Socket Lister: Socket for help connecting to B Connection to s Connection to s 2. S replies to A with B's public and private TCP Connection to Cornection to B's Public endpin .'s Public end points, and at the same time sends A's public and private endpoints to B Connectin Bs Private Endpoint A's Private Endpoint 3. From the same local tcp ports that a and b used to Client a Client b register with S, A and B cach asynchronously make outgoing connection attempts to the others public and private endpoints as reported by S, while simul- Figure 7: Sockets versus Ports for TCP Hole Punching taneously listening for incoming connections on their respective local TCP ports Figure 5, and assume that the port numbers shown in the 4.⊥andB wait for outgoing connection attempts to figure are now for TCP rather than UDP ports. The outgo- succeed, and/or for incoming connections to appear. ing connection attempts a and b make to each other's pri- If one of the outgoing connection attempts fails due vate endpoints cither fail or connect to the wrong host.As to a network error such as"connection reset or"host with UDP, it is important that TCP applications authenti unreachable, " the host simply re-tries that connection cate their peer-to-peer sessions, due of the likelihood of attempt after a short delay(e.g, one second), up to mistakenly connecting to a random host on the local net an application-defind maximum timeout period work that happens to have the same private IP address as 5. When a TcP connection is made, the hosts authen the desired host on a remote private network ticate each other to verify that they connected to the The clients'outgoing connection attempts to each intended host. If authentication fails, the clients close other's public en dpoints, however, cause the respective that connection and continue waiting for others to NATS to open up new holes"enabling direct TCP com- succeed. The clients use the first successfully au munication between A and b. If the nats are well thenticated TCP stream resulting from this process behaved, then a new peer-to-peer TCP stream automat ically forms between them. If As first syn packet to Unlike with UDP, where each client only needs one B reaches B's NAt before B's first SYN packet to A socket to communicate with both S and any number of reaches Bs NaT, for example, then B's NAT may in peers simultaneously, with TCP each client application terpret AS sYN as an unsolicited incoming connection must manage several sockets bound to a single local TCP attempt and drop it. B's first SYN packet to A should port on that client node, as shown in Figure 7. Each client subsequently get through, however, because A's NAT sees needs a stream socket representing its connection to s, this sYn as being part of the outbound session to b that a listen socket on which to accept incoming connections As first syn had already initiated from peers, and at least two additional stream sockets with which to initiate outgoing connections to the other peers 4.3 Behavior Observed by the application public and private TCP endpoints What the client applications observe to happen with their Consider the common-case scenario in which the sockets during tCp hole punching depends on the tim- clients A and B are behind different NATs, as shown in ing and the TCP implementations involved. suppose that 186 2005 USENIX Annual Technical Conference USENIX ASSOcIation As first outbound SYN packet to B's public endpoint is the initial outgoing sYn packets from both clients tra- dropped by NAT B, but B's first subsequent sYN packet verse their respective local NATS, opening new outbound to A's public endpoint gets through to A before A's TCP TCP sessions in each NAT, before reaching the remote retransmits its SYN. Depending on the operating system NAT. In this"lucky"case, the NAts do not reject either involved, one of two things may happen of the initial sYn packets, and the S YNs cross on the wire between the two nats. in this case. the clients ob As TCP implementation notices that the session serve an event known as a simultaneous TCP open: each endpoints for the incoming SYN match those of an peer's tCP receives a"raw"syn while waiting for a outbound session A was attempting to initiate A' s SYN-ACK. Each peers TCP responds with a SYN-ACK TCP stack therefore associates this new session with whose syn part essentially replays " the pecr's previous the socket that the local application on A was using outgoing SYN, and whose ack part acknowledges the to connect ()to B's public endpoint. The applica- SYN received from the other peer tion's asynchronous connect()call succeeds, and What the respective applications observe in this case nothing happens with the application's listen socket. again depends on the behavior of the TCP implementa Since the received syn packet did not include an tions involved, as described in the previous section. If ACK for As previous outbound nd SYN. A,s tcp both clients implement the second behavior above, it may replies to B's public endpoint with a SYN-ACK be that all of the asynchronous connect () calls made packet, the SYN part being merely a replay of a' s by the application ultimately fail, but the application run original outbound SYN, using the same sequence ning on each client nevertheless receives a new, working number. Once B's TCP receives A' s SYN-ACK, it peer-to-peer TCP stream socket via accept ()-as if responds with its own ACK for As sYN, and the this tCP stream had magically"created itself on the wire TCP session enters the connected state on both ends and was merely passively accepted at the endpoints! As long as the application does not care whether it ultimately Alternatively, As TCP implementation might in- receives its peer-to-peer ICP sockets via connect () stead notice that a has an active listen socket on or accept(), the process results in a working stream that port waiting for incoming connection attempts on any tcp implementation that properly implements the Since b's sYn looks like an incoming connection standard TCP state machine specificd in RFC 793 [23] attempt, As TCP creates a new stream socket with Each of the alternative network organization scenarios which to associate the new tCP session and hands discussed in Section 3 for UdP works in exactly the same this new socket to the application via the applica- way for TCP. For example, TCP hole punching works in tions next accept()call on its listen socket. A' s multi-level NaT scenarios such as the one in Figure 6 as TCP then responds to B with a SYN-aCK as above long as the Nats invol ved are well-behaved and TCP connection setup proceeds as usual for 4.5 Sequential Hole Punching client/server-style connections In a variant of the above tcp hole punching procedure Since A's prior outbound connect ()attempt to implemented by the Nat Trav library [4 the clients at B used a combination of source and destination tempt connections to each other sequentially rather than endpoints that is now in use by another socket, in parallel. For example:(1)A informs B via Of ItS namely the one just returned to the application desire to communicate, without simultaneously listening via accept(), A,s asynchronous connect () at- on its local port; (2)B makes a connect()attempt to tempt must fail at some point, typically with an"- A, which opens a hole in B's nat but then fails due to dress in use"error. The application nevertheless has a timeout or RST from a's nat or a rst from A itself: the working peer-to-peer stream socket it needs to (3)B closes its connection to S and does a listen ( communicate with B, so it ignores this failure on its local port;(4)S in turn closes its connection with A, signaling A to attempt a connect() directly to B The first behavior above appears to be usual for BSD- This sequential procedure may be particularly useful on based operating systems, whereas the second behavior ap- Windows hosts prior to XP Service Pack 2, which did pears more common under Linux and windows not correctly implement simultaneous TCP open, or on 4.4 Simultaneous TCP Open sockets APls that do not support the So REUSEADDR functionality. The sequential procedure is more timing Suppose that the timing of the various connection at- dependent, however, and may be slower in the common tempts during the hole punching process works out so that case and less robust in unusual situations. In step(2), for USENIX ASSOCIation 2005 USENIX Annual Technical conference 187 example, B must allow itsdoomed-to-fail" connect() ing public endpoint of 155.99.25 11: 62000, because that attempt enough time to ensure that at least one syn is the public endpoint for A to which B will be sending packet traverses all NATs on its side of the network. Too its corresponding messages little delay risks a lost syn derailing the process, whereas A naT that is only designed to support client/server too much delay increases the total time required for hole protocols will not necessarily preserve the identities of punching. The sequential hole punching procedure also private endpoints in this way. Such a NAT is a symmet effectively""both clients, connections to the ric NAT in RFC 3489 terminology. For example, after the server S, requiring the clients to open fresh connections to naT assigns the public endpoint 155.99.25 11: 62000 to S for each new P2P connection to be forged. The parallel client A's session with server S, the NAT might assign hole punching procedure, in contrast, typically completes a different public endpoint, such as 62001 as soon as both clients make their outgoing connect () to the P2P session that A tries to initiate with B. In this attempts, and allows each client to retain and re-use a sin- case, the hole punching process fails to provide connec le connection to s indefinitely tivity because the subsequent incoming messages from B reach nat A at the wrong port number 5 Properties of p2P-Friendly nats Many Symmetric NATs allocate port numbers for suc cessive sessions in a fairly predictable way. Exploiting his section describes the key behavioral properties Nats this fact, variants of hole punching algorithms [9, 1] can must have in order for the hole punching techniques de be made to work" much of the time"even over symmetric scribed above to work properly. Not all current NAT NATS by first probing the nat's behavior using a protocol implementations satisfy these properties, but many do, such aS STUN [19], and using the resulting information to and NATs are gradually becoming more"P2P-friendly as nat vendors recognize the demand for peer-to-peer predict the public port number the Nat will assign to a new session. Such prediction techniques amount to chas- protocols such as voice over IP and on-line gaming ing a moving target, however, and many things can go This section is not meant to be a complete or definitive wrong along the way. The predicted port number might specification for how NATs"should"behave; we provide it merely for information about the most commonly ob already be in use causing the NaT to jump to another port number for example or another client behind the same served behaviors that enable or break p2p hole punching. NAT might initiate an unrelated session at the wrong time The IETF has started a new working group, BEHAVE, to so as to allocate the predicted port number. while port define official"best current practices"for NAT behavior number prediction can be a useful trick for achieving max The behave group's initial drafts include the consider mum compatibility with badly-behaved existing NATs ations outlined in this section and others: nat vendors it does not represent a robust long-term solution. Since should of course follow the IETF working group directly symmetric NAT provides no greater security than a cone as official behavioral standards are formulated NAT with per-session traffic filtering, symmetric NAT is 5.1 Consistent Endpoint Translation becoming less common as NAT vendors adapt their algo- rithms to support P2P protocols The hole punching techniques described here only work automatically if the nat consistently maps a given tcp 5.2 Handling Unsolicited TCP Connections or UDP Source endpoint on the private network to a single When a nat receives a syn packet on its public side for corresponding public endpoint controlled by the nat. a what appears to be an unsolicited incoming connection NAT that behaves in this way is referred to as a cone NAT attempt, it is important that the nat just silently drop the in RFC 3489 [19] and elsewhere, because the NAt fo- SYN packet. Some NATs instead actively reject such in- cuses"all sessions originating from a single private end- coming connections by sending back a TCP RST packet point through the same public endpoint on the nat or even an ICMP error report, which interferes with the Consider again the scenario in Figure 5, for example. TCP hole punching process. Such behavior is not nec When client A initially contacted the well-known server essarily fatal, as long as the applications re-try outgoing S, NAT A chose to use port 62000 at its own public IP connection attempts as specified in step 4 of the process address, 155.99.25. 1l, as a temporary public endpoint to described in Section 4.2, but the resulting transient errors representing A,'s private endpoint 4321. When a can make hole punching take longer ater attempts to establish a peer-to-peer session with B by sending a message from the same local private endpoint to 5.3 Leaving Payloads Alone Bs public endpoint, A depends on Nat A preserving the A few existing NATs are known to scan"blindly"through dentity of this private endpoint, and re-using the exist- packet payloads for 4-byte values that look like IP ad 188 2005 USENIX Annual Technical conference USENIX ASSOcIation

试读 14P p2p网络中napt穿透原理(详细).pdf
限时抽奖 低至0.43元/次
身份认证后 购VIP低至7折
gisforgood 不错的资料,值得推荐
JackLiang2003 一直想了解相关的东西
Jacoffee 一直想了解相关的东西
cqupt_53 还没有详细看,应该挺有用的
xgcdd 很好,正是我想要的
  • 分享王者

关注 私信
p2p网络中napt穿透原理(详细).pdf 50积分/C币 立即下载

试读结束, 可继续读2页

50积分/C币 立即下载