I write a small game using socket in which multiple clients join the game, everything works in the LAN. Now I want to extend to clients outside LAN, what I wonder is: if I don't know the IP address of the client then will the program work?
Inside LAN I use:
char *ip = "127.0.0.1";
The client needs to know the server's IP in order to connect to it.
If the client and server run on the same machine, the server can listen on 127.0.0.1 and the client can connect to that IP.
If the client and server run on the same LAN, the server needs to listen on the NIC that is connected to the LAN, and the client can connect to the server's LAN IP.
If the client is running on a different network and wants to connect to the server over the Internet, the client must connect to the server's public Internet IP, as assigned by the server's ISP. And if the server is running behind a NAT router, the public IP is assigned to the router and not the server directly, so the router must have port forwarding configured to route incoming connections to the server machine on the router's LAN.
If the client doesn't know the IP to connect to, the server will need to publish its IP somewhere that the client can query it, such as via DNS, a website, a central public server that all clients connect to for relaying, etc.
Related
I am trying to open access to my SQL Server from outside my network, but while my ports are open in my Windows Firewall and routed from my router, telnet can't connect.
To explain a bit more I have opened both TCP 1433 and UDP 1434 ports in my Windows Firewall to allow remote access to my SQL Server.
Ports seems to be properly opened in my windows firewall as both a telnet [local_server_ip] 1433 and SSMS can connect from a different computer within my local network.
When trying to connect from outside my network (using my external IP) Telnet can't connect (Connect failed).
In my router, ports are redirected (TCP 1433 and UDP 1434) and I also tried setting my SQL Server IP as DMZ but it did not went through. My other port redirection works properly so I don't think it comes from the router (for instance I have Emby as a media server, and I can access it from outside my network or use telnet to connect to the port opened for this service).
Am I missing a configuration in SQL Server configuration manager? For instance I had to manually set the TCP port in SQL Server Network Configuration > TCP/IP properties > IP Adresses > IPAll and set TCP Port as 1433
Or can it come from either my Windows Firewall (even though the inbound rules has similar characteristics as the inbound rule for my Emby server) or my router?
So locally it all seems to work, but from outside it does not? This does indicate your router NAT setting being an issue.
Just to point out, exposing an SQL Server to public internet is relatively insecure. Ideally you add a VPN to your local network and use that to reach the SQL server instead. Just to point out, I can imagine it could work, but you might want to rethink the setup.
I want to connect to my server from another network, my server hasn't got an outside ip adress. I want to reach the sql server from where I host my website. I host my website somewhere else (not in my network).
Your SQL Server will have to be visible to the server from which you host your website.
I'm assuming you want to access the data in SQL Server to generate some content for your website.
There are 2 simple ways to do this:
Static IP - Ask your ISP for a static IP address for your local
network, you can use this in the connection string. This is preferable & more stable, since it will always be in sync.
Dynamic DNS - If your ISP won't give you a static address or you don't want to pay for it. You sign up with a DDNS service provider, they give you a domain name, like ferrysqlserver.ddns.org, and your network is visible to the internet via that name. Some routers support DDNS, otherwise you may have to run a service application that keeps your external ip address in sync with your DDNS provider.
Once you have either of those working, your network is now available to the internet, but nothing is likely accessible.
What you have done so far is to create a path from an internet name to your local router.
To make SQL Server accessible, you need to find out which ports your SQL Server uses (default is 1433). It's possible you may need to open other ports as well if you connect to SQL in a different way.
On your router, find the port forwarding options, and enable port forwarding to the local network ip address of your SQL Server, for port 1433.
This step maps connections from the internet to port 1433 of your router, and forwards those connections to port 1433 of your SQL Server.
Good luck.
How can I get the ip address of the client of which my server is connected to?
Here is how I accept incoming clients:
newsockfd = accept(sockfd, (struct sockaddr*)&clt_addr, &addrlen);
I tried the following:
printf("ip is: %s\n", inet_ntoa(clt_addr.sin_addr));
But I am getting 127.0.0.1 which is not my ip address. Could it have something to do with me using localhost to test my client and server?
Could it have something to do with me using localhost to test my client and server?
Yes. If you connect to a server on localhost the client will also be localhost. This connection is not happening over the Internet, there is no network hardware involved, the client packets will come from localhost. This is known as loopback and occurs entirely in software.
If the client were to connect to the server using the server's external IP address it will have to do a connection via external routing and thus require a routable IP address. For example, I can connect to a server on localhost, but I cannot using my routable IP address because my router blocks incoming connections.
i am working on a remote control program so i need to create connecting to the server(the remote pc) by MAC address (i cant go by ip because he is behind NAT)
It is not possible to connect to a TCP/UDP server by its MAC address, you must use its IP address. Every TCP/UDP server has an IP address, even behind a NAT. TCP/UDP are designed around IP and are transport-agnostic so they can run on networks that are not based on Ethernet/MAC to begin with.
Since your server is behind a NAT, you must connect to the NAT's IP address, and the NAT must be configured to forward that connection to the server's IP address. You cannot avoid that, that is simply how NATs work. If the NAT supports uPNP, the server can programmably configure a port forwarding rule on the NAT. Otherwise the NAT admin must configure it manually.
I'm attempting to access a SQL Server which is exposed through an IP NAT mapping. All the ports are open. I don't know the details of the NAT, if it's relevant, since that's somewhere else in the company hidden in a pile of red tape.
Here's what I figured out. When you attempt to access a named instance of SQL Server, the client asks what port the named instance is running on. If I RDP into the SQL Server I can use netstat to find out the port of that instance and can successfully connect through the firewall. However, connecting via the instance name doesn't work. My guess is that the server is responding at some point with it's internal IP address and the client is using that.
Does anyone know if this is true and if there's a way around it?
The instance listening port protocol discovery is subject to the SQL Server Browser Service. This uses UDP on 1434. With a NAT forwarding of UDP 1434 your client should be able to interact with the SQL Server Browser Service (if the SQL Server Browser's UDP response packet can reach back the client, a big if), but even a successful interaction will put your client in a tight spot: now that it knows the SQL Server dynamic listen port, how does it reach it? The NAT would have to dynamically forward the port picked by SQL Server, or it would have to forward all ports.
What I recommend is to have your SQL Server listen on a per-configured, statically assigned, port. See How to configure an instance of SQL Server to listen on a specific TCP port or dynamic port. Have your NAT forward that port. Then in your client use this port explicitly in the connection string. Do not use 1433, the standard port, since I assume that ahead of the NAT is the public internet and 1433 is subject to constant and frequent scans from all sort of bots and vile clusters.
Configure the named instance to run on a static port using SQL Server Configuration Manager. In configuration manager, SQL Server Network Configuration -> Protocols for <named instance> -> TCP/IP -> Properties.
Then supply the hostname and port for the named instance in the connection string. The hostname and port number are specified in the following format (assuming hostname is Test and listen port is 1492):
... Server='Test,1492'; ...