jselbie / stunserver

Version 1.2. This is the source code to STUNTMAN - an open source STUN server and client code by john selbie. Compliant with the latest RFCs including 5389, 5769, and 5780. Also includes backwards compatibility for RFC 3489. Compiles on Linux, MacOS, BSD, Solaris, and Win32 with Cygwin. Windows binaries avaialble from www.stunprotocol.org.
http://www.stunprotocol.org
Apache License 2.0
1.41k stars 347 forks source link

How does the logic of judging the nat type have only one server address in the parameter of stunclient? #44

Closed gengfeipeng closed 2 years ago

gengfeipeng commented 2 years ago

https://blog.csdn.net/fivedoumi/article/details/8168882

I looked in the client source code and found that there is no other public network address.

gengfeipeng commented 2 years ago

Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 0.0.0.0:0 Sending message to 0.0.0.0:0 delete StunClient object Address and Port Dependent Filtering

All stun packets are sent to one ip, shouldn’t it be sent to the other, so that we can judge whether it will be a symmetric nat.

jselbie commented 2 years ago

Sstunclient sends a binding request to the server addresses specified on the command line. The server responds with both the "mapped address" of the local client as well as the "other address" of the service. When the behavior test is run, it will typically contact the "other address" after getting a binding response from the primary address.

Example:

C:\Users\jselbie\Downloads\stunserver_win64_1_2_16\release>stunclient.exe
stun.stunprotocol.org --verbosity 9 --mode behavior
Resolved stun.stunprotocol.org to 18.191.223.12:0
config.fBehaviorTest = true
config.fFilteringTest = false
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 18.191.223.12:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 18.191.223.12:3478
Got response (68 bytes) from 18.191.223.12:3478 on interface
192.168.1.14:50667
*Other address is 18.219.110.18:3479 <http://18.219.110.18:3479>*

Preparing message for behavior test #2 (destination=AP)
Sending message to *18.219.110.18:3478 <http://18.219.110.18:3478>*
Got response (68 bytes) from 18.219.110.18:3478 on interface
192.168.1.14:50667
Binding test: success
Local address: 192.168.1.14:50667
Mapped address: 11.22.33.44:50667
Behavior test: success
Nat behavior: Endpoint Independent Mapping

In the above run, the first server contacted was stun.stunprotocol.org (18.191.223.12). The response from the server provides the other IP address (and port) the cilent can connect to. In this case, 18.219.110.18. The second message of the behavior test is to make binding request to the alternate IP address without changing the port.

Everything you need to know about the tests for NAT classification is in RFC 5780 (sections 4.3 and 4.4) https://datatracker.ietf.org/doc/html/rfc5780#section-4.3

On Thu, Dec 16, 2021 at 7:25 PM gengfeipeng @.***> wrote:

https://blog.csdn.net/fivedoumi/article/details/8168882

I looked in the client source code and found that there is no other public network address.

— Reply to this email directly, view it on GitHub https://github.com/jselbie/stunserver/issues/44, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHNSF3NSWWQ2XSWRMD64BTURKUSVANCNFSM5KH3I6LQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

jselbie commented 2 years ago

The "behavior test" will typically send to he alternate IP address. The "filtering test", which is what's being shown above, doesn't actually involve the client sending to the alternate address. Instead, it sends a special header (CHANGE-REQUEST) to indicate it wants to receive the response from the other IP address (and/or port). With most NATs implementing "address and port dependent" filtering, the response from the alternate address is dropped by the NAT and never reaches the client. Hence, the unusual number of retry messages in the verbose output. I'm not sure why your client is sending to 0.0.0.0 in the above output, but that dump doesn't look complete. It would benefit from you sharing the entire trace, including the command line parameters itself.

On Thu, Dec 16, 2021 at 7:29 PM gengfeipeng @.***> wrote:

Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 0.0.0.0:0 Sending message to 0.0.0.0:0 delete StunClient object Address and Port Dependent Filtering

All stun packets are sent to one ip, shouldn’t it be sent to the other, so that we can judge whether it will be a symmetric nat.

— Reply to this email directly, view it on GitHub https://github.com/jselbie/stunserver/issues/44#issuecomment-996408344, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHNSF6MJO5XTZWHJXOG5QTURKVBLANCNFSM5KH3I6LQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

gengfeipeng commented 2 years ago

hello jselbie client: gengfeipeng@bogon stunserver % ./stunclient --mode full --localaddr 10.2.2.63 --localport 9999 --protocol udp --verbosity 2 117.50.10.29 Resolved 117.50.10.29 to 117.50.10.29:0 config.fBehaviorTest = true config.fFilteringTest = true config.timeoutSeconds = 0 config.uMaxAttempts = 0 config.addrServer = 117.50.10.29:3478 socketconfig.addrLocal = 10.2.2.63:9999 Sending message to 117.50.10.29:3478 Got response (68 bytes) from 117.50.10.29:3478 on interface 10.2.2.63:9999 Other address is 117.50.10.29:3479

Preparing message for filtering test #2 (ChangeRequest=AA) Sending message to 117.50.10.29:3478 Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Preparing message for filtering test #2 (ChangeRequest=AA) Sending message to 117.50.10.29:3478 Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Preparing message for filtering test #3 (ChangeRequest=PA) Sending message to 117.50.10.29:3478 Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Preparing message for filtering test #3 (ChangeRequest=PA) Sending message to 117.50.10.29:3478 Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Preparing message for behavior test #2 (destination=AP) Sending message to 117.50.10.29:3478 Got response (68 bytes) from 117.50.10.29:3478 on interface 10.2.2.63:9999 Binding test: success Local address: 10.2.2.63:9999 Mapped address: 106.120.244.138:32530 Behavior test: success Nat behavior: Endpoint Independent Mapping Filtering test: success Nat filtering: Address and Port Dependent Filtering

server: ./stunserver --mode full --primaryinterface 10.19.99.42 --altinterface 10.19.179.125 --primaryadvertised 117.50.10.29 --altadvertised 106.75.116.8 stunclient recieve len 800 stunclient recieve len 800 stunclient recieve len 800 stunclient recieve len 800 stunclient recieve len 800 stunclient recieve len 800

This is my entire process. What do you think is the reason why I can't send a message to the server's alternate ip?