Which software libraries does exist for such task for Linux, Windows OS?
Does it exist some info in RFC how people should do it?
I'm interesting how can I create functionality for my C++ project like presented here in that software: https://secure.logmein.com/ru/products/hamachi/download.aspx
There is not much difference if you want to make a connection through TURN relay server. The only difference is how TCP and UDP creates connection and nothing else.
There are some big differences if you want to make P2P connection.
If you are in same network(behind same NAT): In UDP you send a stun binding request to your peer candidate and then if you get a response back then you know you are connected. Same in TCP you have to create one active socket on one side and one passive socket on another. And then send syn from active socket and receive it from passive socket and then send syn ack to the active socket. And then active socket send an ack and the connection is established.
If you are in different Network(behind different NAT): You have to employ TCP hole punching technique for making a connection. Because your NAT won't allow a TCP syn packet through if previously no packet was sent to the address the syn is coming from.
TCP hole punching in details:
You have to use a TCP simultaneous open socket. This socket acts in both active and passive mode. Both end needs to know each others private and public IP:Port.
TCP simultaneous open will happen as follows:
Peer A keeps sending SYN to Peer B
Peer B keeps sending SYN to Peer A
When NAT-a receives the outgoing SYN from Peer A, it creates a mapping in its state machine.
When NAT-b receives the outgoing SYN from Peer B, it creates a mapping in its state machine.
Both SYN cross somewhere along the network path, then:
SYN from Peer A reaches NAT-b, SYN from Peer B reaches NAT-a
Depending on the timing of these events (where in the network the SYN cross),
at least one of the NAT will let the incoming SYN through, and map it to the internal destination peer
Upon receipt of the SYN, the peer sends a SYN+ACK back and the connection is established.
From WIKI.
Also to learn about TCP simultaneous open connection read from here. To learn about NAT filtering behavior see this answer.
Related
The idea is that two different machines (behind two different NATs) connect to public-server.
And they try to create TCP connection with such public server...
Then possible the magic can happens during proxing data stream!
Change source and dest address on whole tcp/ip stack during this session.
The goal - to exclude this third part as a proxy from further communication...
First you need a server to which Peer will send a data or something for letting it know that the server needs to send an syn-ack to it.
Then first Peer A send a packet to Peer B's address with low TTL value so that it is dropped in the middle and doesn't reach to B's NAT. It will keep sending this packet until a packet form the server reaches it with syn-ack containing source address of B's (source faking). And A will do the handshaking with the server but A will think he is doing the handshaking with B.
Exactly same thing happens with B. B will handshake with server but will think it is done with A. After the handshaking is complete on both end data transfer begins with between A and B as P2P connection.
This is source faking as server is handshaking with both peers pretending one of the peers. This is how both peers NAT is opened to each other.
I started to learn Linux Networking and packets filtering. In the iptables documentation it is stated that:
If a packet is destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it.
So, suppose there're 3 server apps on a host. Servers A and B are TCP servers, and C is UDP server.
Is it true, that if we receive an UDP packet, at IP level this packet is to be delivered for apps A, B, C? Or sockets of apps A & B wouldn't receive this packet at all?
TCP servers and UDP servers operate in very different ways.
At most one TCP server will listen on a given TCP port (corner cases ignored for the sake of simplicity). Connection requests (encapsulated in IP packets) destined for that port are "accepted" by exactly one process (more accurately, accepted by a process that has a file descriptor corresponding to exactly one listening endpoint). The combination of [remote_address,remote_port] and [local_address,local_port] is unique. A TCP server doesn't really receive "packets", it receives a stream of data that doesn't have any specific relationship to the underlying packets that carry the data (packet "boundaries" are not directly visible to the receiving process). And a TCP packet that is neither a connection request nor associated with any existing connection would simply be discarded.
With UDP, each UDP datagram is logically independent and may be received by multiple listening processes. That is, more than one process can bind to the same UDP endpoint and receive datagrams sent to it. Typically, each datagram corresponds to a single IP packet though it is possible for a datagram to be broken into multiple packets for transmission.
So, in your example: no, a server that is listening for TCP requests (a "TCP server") will never receive a UDP packet. The port namespaces for TCP and UDP are completely separate.
The delivery of the packet will depend on its destination port.
Lets assume that the servers A, B and C are listening on port 1111, 2222 and 3333 respectively, so when a packet with destination port 2222 is arrived, it will be delivered to server B.
My question wasn't well formulated, unfortunatelly. I understood it when I had seen the answers. Here is an explanation which I was looking for, it's from http://www.cs.unh.edu/cnrg/people/gherrin/linux-net.html#tth_chAp6: > When the process scheduler sees that there are networking tasks to do it runs the network bottom-half. This function pops packets off of the backlog queue, matches them to a known protocol (typically IP), and passes them to that protocol's receive function. The IP layer examines the packet for errors and routes it; the packet will go into an outgoing queue (if it is for another host) or up to the transport layer (such as TCP or UDP). This layer again checks for errors, looks up the socket associated with the port specified in the packet, and puts the packet at the end of that socket's receive queue.
I use raw socket to build a tcp client program and run it on machine A
and I run a regular tcp server program on machine B
the raw socket-based client program first send a SYN packet
and then it receives a SYN/ACK packet from the remote tcp server
then the kernel of machine A sends a RST to the remote tcp server
the sequence number and ack-sequence number is fine
what are potential reasons?
and how to deal with it? thanks!
BTW: I used tcpdump to capture packets on the remote machine B
and it shows "TCP port numbers reused" for the SYN packet from client,
actually before the client send the SYN, I used
netstat -tnp
to check on-going tcp sessions, and it shows nothing
This is perfectly normal. If a machine receives a SYN/ACK packet it doesn't expect, it should respond with a RST to let the other side know that it has no knowledge of or interest in that connection. The kernel sent a RST because that's what it's supposed to do -- it has no idea what your program is doing.
If you're trying to run your own TCP stack on a machine that already has a TCP stack, you'll have to prevent the regular TCP stack from responding to machines your stack is trying to talk to -- otherwise, they'll be talking to two TCP stacks which can't possibly work.
The SYN packet has the same source dest IP address & port with the established connection, so what will happen in this case?
The server will silently drop the packet since it already has a connection in the ESTABLISHED state, one of the four values from (client-ip, src-port, server-ip, dest-port) must be different for the new SYN to be accepted.
The server will attempt a new connection.
in tech terms it will send a syn,ack packet and wait for the client to finish the tcp handshake
and open the connection.
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
will explain the process alot better than me.
the server will send some information to identify the connection in its syn,ack packet.
and that information is used to keep that connection seperate from others.
Most the time, the ports will not be the same
but when it is, it can cause problems with low grade nat routers,
They try to rewrite that ports that are used, and can get the connections confused.
What is TCP response packets?
How to meet this requirement in access-list on a router?
You probably want to look up stateful firewalling for whatever router you're using.
TCP response packets are basically any related TCP packets that come back after an initial SYN has been sent. Typically this would be either a packet with SYN+ACK set, or one with RST if the connection was refused.
Stateful firewalls keep track of not just the source and destination of individual packets, but what connection the packets belong to. By doing this they are able to distinguish between expected, legitimate replies to SYN packets (and others) and random or malicious unrequested "replies".