I'm working on a system with three parts that communicate over HTTP. The parts are the Service, the ServiceRegistry, and the Client. The Service and the ServiceRegistry are self-hosted OWIN applications. The nature of the client doesn't matter.
In my design, the Service POSTs to the ServiceRegistry to "register" itself. The ServiceRegistry reads Request.GetOwinContext().Request.RemoteIpAddress to determine where the Service is located and GETs back to the Service to perform some handshaking (the port for this GET is supplied in the original POST). Finally, the Client comes along and performs a GET to the ServiceRegistry asking for the location of the Service and receives back the IP address and port on which it can directly interact with the Service.
This works well when all three parts are running on different machines.
However, when the configuration is that the Service and the ServiceManager are running on MACHINE01 and the Client is running on MACHINE02 the system fails. What appears to be happening is (when both parts are located on one machine) RemoteIpAddress receives a link-local version of the IPV6 address. I strip off the Scope ID from the IPV6 address and return the address and port to the Client. But, to the Client running on a different machine, this is an unreachable address.
Can anybody suggest how I can read the remote IP address from the OWIN request in such a way that it will be reachable from another machine on my network?
When you are connected with any address, I don't think there is a way to get other addresses of the peer.
You could either implement and use some registry of address mappings between link locale addresses and global addresses. (Always in the hope the peer accepts requests on its global address as well.)
Or if you have access to it I'd propose to modify the requesting peer to send the request originating from its global address. This can normally achieved with source address selection. But I have no idea how you do this on the .NET platform as I am working on Unix systems.
Related
I'm trying to follow the code given here to implement NAT hole punching in Node.js. I'd like to know if the server is strictly necessary. Having read about hole punching, I am under the impression that the purpose of the server is to allow the clients to exchange some information (including but not limited to their addresses and ports they want to communicate on) so that they can proceed to talk directly. Assuming the clients already had each other's information (again, including but not limited to their addresses and ports), would the server still be necessary? If so why and if not, how could this be implemented?
For instance, say one were to build an application where client_A prints out all information that would have been transmitted to the server for user_A to read, who then sends this to user_B, who then submits this info to client_B (this could be done via email for example). Wouldn't this avoid the need for a server?
Here is another explanation of why I think it might be possible to remove the server in the middle:
In NAT hole punching (assuming I understand it correctly), the communications begin when client_A sends a message to the server. The message contains some information that the server then passes on to client_B when client_B contacts the server. After this point, client_A and client_B are able to communicate directly without the need for the server. I am under the impression that once a direct connection between client_A and client_B has been established, the server could go offline and the two clients would still be able to communicate directly with one another. If this is the case, then I would imagine that any information that is being used to maintain this connection (be that addresses, ports, or any other kind of info) could be exchanged through any other channel (eg: email, a handwritten letter, a voice call, etc) at the beginning of the protocol, and then the connection could be established without ever needing the server.
Regarding 'tricking' the router
As manishig pointed out to me in a comment (thanks), NAT hole punching also requires tricking the router. If I understand correctly (please correct me if not) the router is tricked by having the router store the info for directing incoming packets from the server to client_A, however, these packets are actually coming from client_B after the initial phase of the protocol. If this is a correct description of the problem, is there a way to trick the router that doesn't require using a server?
There are ways to communicate between two remote computers over the internet without an intermidiate server, but IMO it is not the preferred way.
Why an intermidiate server is needed?
If client_A and client_B are both in the same LAN (e.g your home/office network) you can make sure (configure on the clients side and/or the router) that they will have a static ip address over this LAN and they can just talk freely.
E.G: If client_A is listening on port 8080, client_B can create a connection to client_A_ip on port 8080
Over the internet any packet sent is passed through NAT usually at least twice. One time after going through your LAN (e.g your home/office router) and at least once over an ISP endpoint. Which means you have no controll over the public ip and port assigned to your packet.
Now not only that you don't have controll over your packet's assigned public ip and port, these are also not static. They won't change while you have an active TCP connection, but you don't have any other guarantee from your ISP regarding your assigned public ip and port.
The intermediate server`s purpose is to dynamically update each client with it's peer info and also keeping the tcp connection open, so that peer to peer comunication will be available.
Alternative solution to an intermidiate server (Not recommended)
If you want your clients to communicate without an intermidiate server you can buy a public static ip from your ISP (if they support it) and then there are ways you can make (with some config) that one of your clients have a public static ip and port that the other client can connect to.
But I wouldn't recommend it, since it requires some understanding in IT and security risks.
Also if both client's are portable and connect to different networks all the time it's not a valid solution
I am using the ip library of npm.
I have two config files, one for React and one for Node, for the same application.
const ip = require('ip');
console.log(ip.address());
This returns different ip addresses for the React config file(inside the src folder-127.0.0.1) and Node server file(outside the src folder - IPv4 address).
The issue is that I am pretty sure that I ran the exact same code earlier and it gave me the same ip addresses for both as then I was able to access my webpages. I need the same ip to make requests to my node backend, I cannot afford it in production. Are there other definite methods of doing this?
You get different ip results because 2 method call ip.address() are using different network interfaces.
To make ip.address() return identical result, you can pass network interface name as the first parameter, such as en0:
const ip = require('ip');
console.log(ip.address('en0'));
p.s. To get all current networks interface names, os.networkInterfaces() can be used.
Update: OP try to get IP address in React code, in browser side. This is mission impossible. Otherwise, it would bring huge security problem.
Update 2: OP don't want to store endpoint IP address in frontend code for security reason, neither want to retrieve the IP address first (network overhead issue). In this case, you can make a proxy in server. All frontend know is interacting with current server, the data exchange is delivered by server as:
Browser <--> Server <--> Various endpoint IP
The steps are:
The server (that host the frontend code) get request from browser
Server check which endpoint would be used for that client
Server send the request to specific endpoint
Server get response from endpoint
Server return the response in above step to browser
I deployed my .NET CORE solution in AZURE environment (PAAS).I used following code snippet there to get client's ip address
dtoItem.LogIP = HttpContext.Connection.RemoteIpAddress.ToString();
I used standard .net core libraries and did necessary changes into Startup.cs as well
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto,
RequireHeaderSymmetry = false,
});
I believe I have implemented everything in correct manner. But still I haven't got accurate client IP address. I am always getting client's public IP instead of his private IP. Since this can be repeated (Same office 2 users have same public IP) I need client's private IP instead of his public IP.
Is it possible to get private IP address in PAAS solution. If it is not possible, is there a way to track client's PC information. (Such as IP Address, MAC address).
Is it possible to get private IP address in PAAS solution?
No it is not possible as shared in this SO post and this answer address this about MACAddress
On the client side javascript, there is no API exposed to get the IPAddress(obviously due to security consideration) .Then you can get the IPAddress on the server side but typically if you are accessing internet from your company,it would go through the corporate proxy and the Ipaddress seen by the server will never be the actual client IP but the proxy server's address. So this is limited on the server side as server only sees the proxy (public IP address).
If it is not possible, is there a way to track client's PC information. (Such as IP Address, MAC address) ?
What you can reliably track is the user agent. Breaking the user agent down, we get the some information about browser ,OS versions. But user agent can easily be spoofed with some browser extension .
If you are looking for browser finger printing or tracking ,have a
look at Panopticlick which shows some more information like
fonts > installed, screen resolution,plugins installed etc to track
any client. fingerprintjs2 javascript library helps to track
using 26 parameters as of today
There is no straight forward answer to this. The thread shared by Rob has some great insights. However, one needs to understand that a lot can happen to the request before it reaches the server. The intermediary networking devices can manipulate the TCP headers so it may not reflect the correct IP Address that you need.
From a solution perspective, this might be perfectly possible, if you develop your own client and log this information somewhere so that you can track it. Otherwise there is no reliable way to get this information.
I've configured Poptop (The PPTP Server for Linux) and it is working fine.
Clients are assigned different IP addresses which are visible publicly properly, e.g. on www.whatismyip.com.
But on the same server, all request from clients are recognized as coming from the original IP addresses.
How to make server, where pptdp is installed, see assigned IP addresses instead of original ones? I understand that somehow traffic should be routed out to the Internet and back, but not sure how.
I am writing an application for deployment on desktop computers and using ServiceStack to expose json services to a central application which will consume them. I'm using ServiceStack self hosting and I've pretty much just followed along with the ServiceStack wiki examples to get basic connectivity up and running.
This is used to start the server and bind it
appHost.Init();
appHost.Start("http://server_ip:port/");
Windows also needs to be configured so a non administrator can accept incoming requests; with this command from an administrator command prompt
netsh http add urlacl=http://server_ip:port/ user=desktopMachineName\desktopUserName listen=yes
note: this seems to be fragile. If the urlBase in the appHost.Start(urlBase) command is different to the urlacl parameter in the netsh command then connections are refused by Windows. btw I've only tried this with Windows 8.
Is there an alternate approach so that the application can withstand changes to the desktop computers ip address (e.g. caused by DHCP)?
This is a desktop environment so I don't expect users to have hostnames setup or static ip addresses for their computers. I'm also trying to not require them to type in commands at a command prompt.
It kinda depends on how the central application locates the apps on the desktop computers.
If you only have a list of static IP addresses, you will need the desktops to have static IP addresses.
If somehow your central app knows what the current IP address is (or maybe this is in a network and you can use the machine's name) then try urlacl=http://+:port.
This basically sets a wild card saying that anything coming in on this port via http goes to this app.
Then apphost.Start("http://locahost:port/") should work.