I would like to use my AWS instance to exchange UDP packets with various client applications.
When I run the server-side code locally, everything works as expected. However, when the code is run from AWS, I can only receive packets, not send. The logs tell me that, at least, the server-side send() is being invoked, but nothing else can be discerned.
Edit:
I'm not using a load balancer; I only have one instance [SO post]
I've enabled all UDP inbound/outbound traffic [AWS post]
I created a second AWS instance, and I am able to exchange packets between my, now, two instances.
Wireshark doesn't detect incoming packets on my client, even when its firewall is disabled.
I've successfully sent UDP packets to my instance (where they've been detected). The problem of outbound traffic remains.
Advice?
The issue was that I was sending from a private IP. This explains why I could contact the server, but it could not contact me; various application logic prevented this. In order for this to work, you must use the server to reply to the non-private IP.
Related
I am making a multiplayer game that is UDP with node.js (dgram for UDP) and unity as the client (uses c#'s sockets). I originally had a web-socket server, but remade it to be UDP for more competitive response times.
It works perfectly at my house and between my and my friends, but when I try it at school it doesn't work (both LAN and WAN). With non-local hosting nothing works (expected because my school has a whitelist), but with LAN (not localhost) The client sends and initial join packet (exactly the same way of sending as everything else) but then just doesn't send any more packets. My server logs the join message but then the client gets timed out from not sending any more messages after that.
Additionally, the client freezes during the second message and has to be shut down from task manager, which gives me the idea that it's message is being blocked over the network.
Is there a way around my school wifi blocking my server messages, and if there isn't what should I ask my school's tech person for (probably won't work but worth a shot)
Thanks in advance (:
Well, there is nothing you can do to solve certain situations like this by bypassing alone.
If your school remotely controls what protocols (TCP, UDP) that is allowed or blocked, it is better and the right thing to ask them to lift the ban up for traffic between UDP connections.
Also, the firewall can be the main one to blame. By default, many firewalls block UDP traffic because essentially, it is an unsolicited network traffic and may be used to do malicious exploitation since it doesn't care whether or not it has the server's permission to communicated in between and it can't do it doesn't support ACK (Can even cause DDOS in that manner).
More information and references about UDP: Link
However it is more of an overstatement but know that firewall in general do block all incoming traffics by default. TCP is usually accepted, and maybe your school blocked all UDP connections because of the details said above.
I want to build a DSR load balancer for an application I am writing. I wont go into the application because it is irrelevant for this discussion. My goal is to create a simple load balancer that does direct server response for TCP packets. The idea is to receive all packets at the load balancer, then using something like round robin, select a server from a list of available servers which are defined in some config file. The next step would be to alter the packer received and change the destination ip to be equal to the chosen backend server. Finally, the packet will be sent over to the backend server using normal system calls for sending packets. Theoretically the backend server should receive the packet, and send one back to the original requester, and then the requester can communicate directly with the backend server rather than going through the load balancer.
I am concerned that this design will not work as I expect it to. The main question is, what happens when computer A send a packet to IP Y, but receives a packet back in the same TCP stream from a computer at IP X? Will it continue to send packets to IP Y? Or will it switch over to IP X?
So it turns out this is possible, but only halfway so, and I will explain what I mean by this. I have three processes, one which is netcat, used to initiate an tcp request, a second process, the dsr-lb, which receives packets on a certain port, changes the destination ip to a backend server(passed in via command line arg), and forwards it off using raw sockets, and a third process which is a basic echo server. I got this working on a local setup. The local setup consists of netcat running on my desktop, and dsr-lb and echo servers running on two different linux VMs on the desktop as well. The path of the packets was like this:
nc -> dsr-lb -> echo -> nc
When I said it only half works, what I meant was that outgoing traffic has to always go through the dsr-lb, but returning traffic can go directly to the client. The client does not send further traffic directly to the backend server, but still goes through the dsr-lb. This makes sense since the client opened a socket to the dsr-lb ip, and internally still remembers this ip, regardless of where the packet came from.
The comment saying "if its from a different IP, it's not the same stream. tcp is connection-based" is incorrect. I read through the linux source code, specifically the receive tcp packet portion, and it turns out that linux uses source ip, source port, destination ip, and destination port to calculate a hash which is uses to find the socket that should receive the traffic. However, if no such socket matches the hash, it tries again using only the destination ip and destination port and that is how this "magic" works. I have no idea if this would work on a windows machine though.
One caveat to this answer is that I also spun up two remote VMs and tried the same experiment, and it did not work. I am guessing it worked while all the machines were on the same switch, but there might be a little more work to do to get it to work if it goes through different routers. I am still trying to figure this out, but from using tcpdump to analyze the traffic, for some reason the dsr-lb is forwarding to the wrong port on the echo server. I am not sure if something is corrupted, or if the checksum is wrong after changing the destination ip and some router along the way is dropping it or changing it somehow(I suspect this might be the case) but hopefully I can get it working over an actual network.
The theory should still hold though. The IP layer is basically a packet forwarding layer and routers should not care about the contents of the packets, they should just forward packets based on their routing tables, so changing the destination of the packet while leaving the source the same should result in the source receiving any answer. The fact that the linux kernel ultimately resolves packets to sockets just using destination ip and port means the only real roadblock to this working does not really exist.
Also, if anyone is wondering why bother doing this, it may be useful for a loadbalancer in front of websocket servers. Its not as great as a direct connection from client to websocket server, but it is better than a loadbalancer that handles both requests and responses, which makes it more scalable, and more able to run on less resources.
I'm just wondering if we could send HTTP request to API / Web Server anonymously? right now after some googling. i cannot find any answer if it is possible.
i'm writing a code that will scrape the data from its server but i think they might have an API monitoring feature for their Data.
right now i am using node with Axios and the script i am using is fetching almost ~10k requests per minute, which i think is bad because their server could blew up.
i tried googling but i didn't find any answer to my problem.
Sending http request to servers anonymously
The HTTP protocol uses TCP as the underlying transport protocol. The TCP protocol uses the three-way handshake to establish connections. In theory you could send packets without your source address, or with someone else's address - just like you could write someone else's address as a sender on an envelope in traditional mail.
Now, the three-way handshake works like this: You send the first SYN packet, then the server sends a SYN-ACK packet - to whom? If your address was not in the first SYN packet then the server cannot send you the second packet. And if you cannot get the SYN-ACK packet then you cannot even establish the connection. This is all before you can even think about sending the HTTP request on the TCP connection because there is no connection.
So, the answer is: No. You cannot send HTTP requests anonymously because you cannot establish a TCP connection anonymously.
Of course you could use a proxy, VPN, a tunnel, NAT or something like that so that the requests appear as not originating from you but keep in mind that the proxy needs to know your address to pass responses to you so you are not completely anonymous, just someone else knows who you are and that someone else will not hesitate to reveal your identity as soon as you cause any trouble.
Introduction
I am currently trying to build up a networking layer for Unity from scratch. Currently I am testing the communication via UDP using Node.js for the server and the client. However I guess the language of the implementation will not matter for what I am asking for.
Current approach
The current approach using Node.js for the server and the client is pretty basic. I simply send a packet from a client to my server while the client and the server are not in the same local network. Both are behind a router and therefore also behind a NAT.
The server then sends back an answer to the IP and port received within the UDP packet that was sent from the client.
Problem
I am curious about the security on the client side regarding to ports being opened on the client machines and routers. So far I assumed that I don't need to do anything to secure the client from attackers or anything else that can do something with the ports that are used by my application. The following assumption shows why I think that I don't need to do anything to secure the clients.
Assumption
Server is setting up callbacks.
Server starts listening to a specific port which is also forwarded to the servers machine within the router.
Server now will call a callback when a UDP message was received. The server then will send a UDP message to the address and the port of the client obtained by the message received.
Client is setting up callbacks.
Client starts listening to port 0 which for Node.js's dgram means:
For UDP sockets, causes the dgram.Socket to listen for datagram messages on a named port and optional address. If port is not specified or is 0, the operating system will attempt to bind to a random port. - https://nodejs.org/api/dgram.html#dgram_socket_bind_port_address_callback
So the operating system now knows that packets sent to this port belong to my application.
Nobody can use this for something malicious.
Client, which knows the servers address and port, starts the process of sending a UDP message to the server.
Clients router receives the UDP message. NAT creates a random port (used on the public side) and maps it to the clients (local) address and port.
So the router now knows that packets sent to the public address and the newly generated port belong to the local address and port.
Nobody can use this for something malicious.
Clients router sends UDP message containing the public address and the NAT generated port to the server.
The worst thing that can happen is that a man-in-the-middle attacker can read the data the client is sending. Due to it is only gamedata like positions and so on that is sent this is not a big problem while developing the basics.
Nobody can use this for something malicious.
Server receives the message and calls the callback described in 3. So the server sends to the public address and the NAT generated port of the client.
The worst thing that can happen is that a man-in-the-middle attacker can read the data the server is sending. Due to it is only gamedata like positions and so on that is sent this is not a big problem while developing the basics.
Nobody can use this for something malicious.
Same as 7. with the servers router and the servers local address and port.
Same as 8. with the servers router.
Client receives the UDP message of the server and calls a callback which processes the message contents.
Due to the local port of the client is bound to my application only nobody can use this for something malicious due to I simply ignore the contents if they are not from the real server.
Question
So is my assumption correct and I really don't need to secure the client from any attacks that will harm the clients in any way?
I'm writing a piece of P2P software, which requires a direct connection to the Internet. It is decentralized, so there is no always-on server that it can contact with a request for the server to attempt to connect back to it in order to observe if the connection attempt arrives.
Is there a way to test the connection for firewall status?
I'm thinking in my dream land where wishes were horses, there would be some sort of 3rd-party, public, already existent servers to whom I could send some sort of simple command, and they would send a special ping back. Then I could simply listen to see if that arrives and know whether I'm behind a firewall.
Even if such a thing does not exist, are there any alternative routes available?
Nantucket - does your service listen on UDP or TCP?
For UDP - what you are sort of describing is something the STUN protocol was designed for. It matches your definition of "some sort of simple command, and they would send a special ping back"
STUN is a very "ping like" (UDP) protocol for a server to echo back to a client what IP and port it sees the client as. The client can then use the response from the server and compare the result with what it thinks its locally enumerated IP address is. If the server's response matches the locally enumerated IP address, the client host can self determinte that it is directly connected to the Internet. Otherwise, the client must assume it is behind a NAT - but for the majority of routers, you have just created a port mapping that can be used for other P2P connection scenarios.
Further, you can you use the RESPONSE-PORT attribute in the STUN binding request for the server to respond back to a different port. This will effectively allow you to detect if you are firewalled or not.
TCP - this gets a little tricky. STUN can partially be used to determine if you are behind a NAT. Or simply making an http request to whatismyip.com and parsing the result to see if there's a NAT. But it gets tricky, as there's no service on the internet that I know of that will test a TCP connection back to you.
With all the above in mind, the vast majority of broadband users are likely behind a NAT that also acts as a firewall. Either given by their ISP or their own wireless router device. And even if they are not, most operating systems have some sort of minimal firewall to block unsolicited traffic. So it's very limiting to have a P2P client out there than can only work on direct connections.
With that said, on Windows (and likely others), you can program your app's install package can register with the Windows firewall so your it is not blocked. But if you aren't targeting Windows, you may have to ask the user to manually fix his firewall software.
Oh shameless plug. You can use this open source STUN server and client library which supports all of the semantics described above. Follow up with me offline if you need access to a stun service.
You might find this article useful
http://msdn.microsoft.com/en-us/library/aa364726%28v=VS.85%29.aspx
I would start with each os and ask if firewall services are turned on. Secondly, I would attempt the socket connections and determine from the error codes if connections are being reset or timeout. I'm only familiar with winsock coding, so I can't really say much for Linux or mac os.