jflyup / nat_traversal

travel across kinds of NATs, including symmetric NATs
257 stars 84 forks source link

how to run it? #1

Closed imagec closed 7 years ago

imagec commented 7 years ago

is there any doc for explain how to run it?

jenokizm commented 7 years ago

I join the question) especially if I have a Windows

jenokizm commented 7 years ago

login as: root root's password: Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 2.6.32-042stab123.1 x86_64)

root@37148:~/folder1/nat_traversal-master# make gcc -g -Wall -c main.c gcc -g -Wall -c nat_traversal.c gcc -g -Wall -c nat_type.c gcc -g -Wall -o nat_traversal main.o nat_traversal.o nat_type.o nat_traversal.o: In function `init': /root/folder1/nat_traversal-master/nat_traversal.c:313: undefined reference to 'pthread_create' /root/folder1/nat_traversal-master/nat_traversal.c:315: undefined reference to 'pthread_join' collect2: error: ld returned 1 exit status Makefile:7: recipe for target 'nat_traversal' failed make: *** [nat_traversal] Error 1

jflyup commented 7 years ago

it's a experience project, I just wanna test whether UDP punching is possible if both nodes are behind symmetric NAT. To run it, you should run punch_server.go (I should compile a binary file as most users didn't have Go installed)in a machine with public IP, so both nodes can connect to it to exchange info. Then run nat_traversal [-s punch server] [-d id] on both nodes.

jflyup commented 7 years ago

@jenokizm sorry, I forget to link with pthread, you can add -pthread to $(CC) $(CFLAGS) -o nat_traversal main.o nat_traversal.o nat_type.o in the Makefile.

jenokizm commented 7 years ago

Thanks for the answer! In fact, I guessed about -pthread little later. Another problem. 1 client is working on Debian (Successfully connects to the server and waiting for notification...) but 2 client on Ubuntu constantly gives an error after run:

$ ./nat_traversal -s XX.XXX.XXX.XX -d 2 failed to send request to alterative server stack smashing detected : ./nat_traversal terminated Emergency stop (memory dump done)

So I can not test on both clients. What can be wrong? Both clients are virtual machines in Oracle VM VirtualBox

jenokizm commented 7 years ago

I understand what's the matter. Your code does not work with the latest compilers. I just took a compiled program from Debian to Ubuntu and it worked. But apparently the traversal method itself does not work, computers did not communicate with each other (I waited half an hour of time), screen: https://1drv.ms/i/s!Aq6ZQkyoPcuMgZIV8g8u5irXTVXTiQ What should I do to make it work? Can not be tested on virtual machines with a common NAT?

jflyup commented 7 years ago

Seems you can't connect to the STUN server, so the program can't get NAT type. I'd suggest this project to do NAT traversal because mine is just a test for symmetric NAT, if your nodes are not behind symmetric NAT, use some easy solutions.

jenokizm commented 7 years ago

My nodes are for symmetric Nat. I tried laike9m/PyPunchP2p it does not work for me. Because it is not for a symmetrical... The fact is that your implementation of the stun does not work correctly. In fact, the connections with the servers that you specified as constants in the code work correctly. Screen: https://1drv.ms/i/s!Aq6ZQkyoPcuMgZIW6jUBGbl8N9Gm9g (here i use https://github.com/jtriley/pystun)

jenokizm commented 7 years ago

Online test result screen: https://1drv.ms/i/s!Aq6ZQkyoPcuMgZIXgRDQgTfbj-MMYQ (from here http://nattest.net.in.tum.de/test.php)

jflyup commented 7 years ago

I got it, I'll try to fix it.

jflyup commented 7 years ago

@jenokizm git pull and try it again :)

jenokizm commented 7 years ago

Thank you for efficiency! I checked, now the type is definite. BUT jumps out a connection error, and it jumps out immediately, even before the launch of the second client. those. Where that is a bug, you need to fix it again ( screen: https://1drv.ms/i/s!Aq6ZQkyoPcuMgZIYrz_JVYNDJ3crAg

jflyup commented 7 years ago

This experimental program works this way: A peer got its own NAT info(external ip/port, NAT type ), then registers to server, the server replies to the peer with a unique peer ID. if you specify -d peer ID option, the the node tries to get the info of that specified peer from the server, then uses the method of this paper to connect to remote peer directly. So when you specify '-d' option, make sure that peer is connected with server.

jflyup commented 7 years ago

@jenokizm And this program is not 100% guaranteed to make 2 peers behind symmetric NATs connect to each other directly, actually, I just happen to succeed only once because the behavior of symmetric NAT is too tricky.

jenokizm commented 7 years ago

Aaa. I understood. Parameter -d is the partner's id and not his own. Now I've got it right! After the launch of both clients, the load level of my CPU soared to 100 % (Comp strongly braked! But I managed to shoot a screenshot, unfortunately as far as I understood the method of communication did not work ( screen: https://1drv.ms/i/s!Aq6ZQkyoPcuMgZIZaZ18uAp8MKyFkg

jenokizm commented 7 years ago

And this program is not 100% guaranteed to make 2 peers behind symmetric NATs connect to each other directly, actually, I just happen to succeed only once because the behavior of symmetric NAT is too tricky.

This is very distressing (How then to be? And the article wei-apan-v10.pdf says 100% effectiveness of the method. Do you have any relation to the authors of the article?

jflyup commented 7 years ago

No. This method depends on the allocation rule of NAT device and luck heavily, so it doesn't always work.

jenokizm commented 7 years ago

And what is the probability that the router will open the external port when the client initializes the drying of one of the internal ports? It seems to me that the port opens when the package exits. And it will be available only to the person to whom it sent the package. But if the second customer is also for the symmetric NAT, then he can not directly accept the package, and can not send it. Does not know where. The circle is closed ...

jenokizm commented 7 years ago

Aaa I understood. The next step is an attack low TTL value packets. An ICMP time exceeded message... still difficult to understand what the author hoped) He likelihood of punching 100%.

jflyup commented 7 years ago

100% is not possible. The low TTL value packets is to punch some holes on the NAT of sender.

jflyup commented 7 years ago

@jenokizm I fixed a giant bug, you can try your luck again.

jenokizm commented 7 years ago

Unfortunately

timout, not connected