Welcome to my first question on stack overflow.
I've looked around, and I haven't found this question asked yet. However, that may be because I don't know how to ask the question that I need answered.
THE INFORMATION:
I'm a programmer who left the public sector that had a, surprisingly, well-managed IT department that had all this crap working for me. I now work for a private company that needs a bit of network systems help.
We have:
A SQL Server
An Application Server
A File Server
A Web Server
multiple web services
team foundation server
share point services
5 desktops
all on our internal network.
We also have:
- No domain controller
- No Internal DNS / NAT / DHCP Server.
We're currently using a router for DHCP and Port Forwarding. We are getting a static IP assigned today.
THE QUESTION:
What do I need to setup in order to point our external domains / subdomains to our new static IP and have those requests routed (by the hostname used) to hit a specific server?
Current Configuration (Port Forwarding)
ourdomain.com:1234 -> router/port-forwarding -> SQL Server:1433
ourdomain.com:1235 -> router/port-forwarding -> Web Service 1:8081
ourdomain.com:1236 -> router/port-forwarding -> Web Service 2:8082
ourdomain.com:1237 -> router/port-forwarding -> Application Server:5410
What I think I want:
sql.ourdomain.com:80 -> ??? -> SQL Server:1433
svc1.ourdomain.com:80 -> ??? -> Web Service 1:80 (host: svc1.ourdomain.com)
svc2.ourdomain.com:80 -> ??? -> Web Service 2:80 (host: svc2.ourdomain.com)
app.ourdomain.com:80 -> ??? -> Application Server:5410
The (host: xxx) is where I would specify the host in the IIS website configuration.
There will be some instances where port-forwarding is necessary, but it's not ideal for every instance. I want to remember meaningful names, not arbitrary port numbers.
If what I'm asking here is completely ridiculous, well, thanks for reading. I'm just looking for some direction.
Thanks!
<edit>
12:01 am PDT 4/19/2012
Sorry, let me clarify a few things.
We only have a single static public IP address.
Assume that we can acquire / setup the necessary hardware / software to achieve this.
If what it comes down to is that we need to buy some enterprise level routing hardware, that's just what it takes. I know this has to be possible because at my last job, we had 40 or 50 domains all pointed to the same IP that routed to different servers once inside the internal network. :/ Or at least that's what happened to the best of my knowledge.
I actually called them up today and asked them, but the main dude who set it all up quit.
I'm really pushing for us to just get our crap out into the cloud, since no one wants to hire a network engineer or systems analyst, much less build a data center.
</edit>
An easy way that this could work if each subdomain resolves into different public ip addresses (e.g. if your DNS was configured such that sql.ourdomain.com resolves to 1.1.1.1 and svc1.ourdomain.com resolves to 1.1.1.2).
sql.ourdomain.com IN A 1.1.1.1
svc1.ourdomain.com IN A 1.1.1.2
Your router can only make decisions based on limited information contained inside of the ip packets. Commonly, routers can look at the ip or port information. In the case where your router is configured with port forwarding, the router looks at the port number and makes address translation decisions using that the port.
rule: incoming port 1000, forward to 192.168.1.100:1433
rule: incoming port 1001, forward to 192.168.1.101:80
However, if the port is the same, the router needs other information to decide how to perform the translation. Most low-end routers (e.g. Cisco ASA series, Juniper SRX series) can use the ip to make this address translation decision. The downside is that that you'll need to purchase multiple ip addresses from your ISP.
rule: incoming ip 1.1.1.1, forward to 192.168.1.100:1443
rule: incoming ip 1.1.1.2, forward to 192.168.1.101:80
IIS, which operates on a much higher layer on the network stack, can make this differentiation by looking at the HTTP headers. This works for multiplexing a single ip and single port to multiple websites. In this case, since SQL and your web server speak different protocols, you won't be able to leverage this.
Another technology that you may want to consider is IPsec tunneling (VPN) if your device supports IPsec passthrough. The downside is that your coworkers (who I assume are using this) needs to perform additional configuration.
Related
I have two applications (diy container type) which have to be connected via TCP. Let's take as example application clusternode1 and clusternode2.
Each one has TCP listener set up for $OPENSHIFT_DIY_IP:$OPENSHIFT_DIY_PORT.
For some reason clusternode1 fails to connect to any of the following options for clusternode2:
$OPENSHIFT_DIY_IP:$OPENSHIFT_DIY_PORT
$OPENSHIFT_APP_DNS
Can you please help in understanding what should be url for external TCP connection?
You might check the logs to see if the OPENSHIFT_DIY_IP for both apps are within the same subnet. If one, say, is...
1.2.3.4
...and the other is...
1.5.6.7
...for example, then you might not expect Amazon's firewalls to just arbitrarily allow TCP traffic from one subnet to another. If this were allowed by default then one person's app might try to hack another's.
I know that when you're dealing directly with Amazon AWS and you spin up multiple virtual servers you have to create virtual zones to allow traffic between them. This might be something that's necessary.
Proxy Ports I don't know if this is useful but it's possible that a private IP address is being bound to your application(s) and then a NAT server is translating that into a public IP address.
I have an application that relies on IP addresses for communication (Domain names simply does not work. :(... )
Its function is to connect to its peer on the other machine and send data over after establishing trust. During the "trust establishing" phase they both exchange their IPs for future communication. They both are behind the two different firewalls and are NATted. One is in our NATted office network and other is in the cloud NATted behind their firewall. The applications knows their respective private IPs and exchange that (the 10.x.xxx.xxx range), when they try to connect back to each other (using the private IPs with range 10.x.xxx.xxx) for transferring data they fail. The connection is TCP and the port range is pretty varied.
I am curious if there is anyway I can hard code (for this one time) a rule (at may be firewall level or some place outside my application) that says if there is a connection being initiated for IP address 10.x.xxx.xxx then redirect it to 205.x.xxx.xxx?
Private IP address ranges like 10.x.y.z are, by their very nature, private.
You can't do any meaningful resolution unless each node in between the endpoints has rules in place to translate these.
Translation is tricky, all the main tools you would use cater for static translation (port forwarding, e.g. where a particular port is forwarded to a particular IP). This is one avenue, but it is a hacky one (it requires you to open lots of ports, procedurally update your router and probably have some sort of broker server to maintain mappings).
Alternatively, you could run the isolated networks over a VPN, which would give your endpoints mutual private IPs which you can use to connect to eachother. It would simply be a case of binding to this new address and communicating across the VPN. This would also potentially encrypt your communication over the internet.
Other possibilities are to use NAT/TCP punchthrough techniques which can allow traversal, but these are really a patch to a broken network topology (Read up on IPv6 to see how this can be alleviated).
Alternatively, you could route all the connections over a proxy, but this will complicate matters compared to a VPN.
To answer the question about hardcoding a rule, port forwarding is the solution here. It will obviously depend on your router configuration for the peer accepting the connection, but this client should have the port target port forwarded to the machine. This will obviously not scale very well and is really shifting to a server/client architecture for one connection!
Depending on your hardware, you may be able to forward a range of ports (if a single port cannot be established) and limit the port forwarding to certain incoming connections (the external IPs).
Information on port forwarding can be found at http://portforward.com/
This sounds a lot like what you'd want out of a VPN. Is there anyway that you could set one up? Basically the Site-To-Site VPN between you and the cloud would say 'oh hey, here is an ip located on the remote network, go ahead and connect through the link'. Would this kind of solution work in your case?
Something along these lines: http://i.msdn.microsoft.com/dynimg/IC589512.jpg
I'm writing a P2P application. Peers regularly ping a main server to update their current IP/port, so when a peer wants to reach another one it can ask the server for that information. For now peers use UPnP to configure the NAT (for classic home setups) to be accessible from outside.
So everything works, except when a peer's client tries to reach another (or the same) peer's server and both are behind the same NAT. Since in that case the client is trying to reach its own "external" (public) IP address from behind the NAT, the NAT doesn't do the port forwarding and is unable to route the IP packet.
For now I'm thinking of two solutions:
query the NAT with UPnP to see to which local IP the port is forwarded
store on the main server the internal IPs of the peers
Can you think of other solutions? What strategies do mainstream P2P applications implement to solve this problem?
Since in that case the client is trying to reach its own "external"
(public) IP address from behind the NAT, the NAT doesn't do the port
forwarding and is unable to route the IP packet.
This is known as the hairpin condition. Not all router/NAT solve this properly. The solutions are:
a) Check whether your router/NAT can be configured to enable 'hairpining'. This solution works iff you control all router/NATs in your deployment.
b) Buy another router/node allowing this. Just like a), it works iff your control all router/NATs in your deployment.
c) If you can get obtain the port information for from UPnP, this is a solution too, but not all Router/NAT know or support UPnP. It does not cover for all cases in large deployment.
d) Using multicasting to 'discover' other nodes on the LAN and even communicate with them is a common solution to this problem. You need to agree on an IP address and have peers listen to it.
e) Storing the private IP address on the server is a solution too, but it requires more storage capacity on the server than solution d. There is a timeout (i.e., expiration of data validity) to handle too.
f) Use a TURN like communication between peers (i.e., communication between nodes pass through central server). This solution is rock solid, but not the most efficient in terms of bandwidth consumption.
Hope this helps.
Interactive Connectivity Establishment (ICE) was specifically developed for solving that type of NAT problems. It uses STUN and TURN to achieve the result and is used in modern p2p applications. (e.g. Voicechat)
The PJNATH library has a document explaining
unlike standalone STUN solution, it (ICE) solves the hairpinning issue, since it also offers host candidates.
We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?
Last but not least, our web site is built with ASP.NET.
Thanks.
In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.
If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface.
wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.
If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.
If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.
As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.
I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:
Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.
Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.
Server[1.2.3.4/0] <---> Client[x.x.x.x/0]
But please bear with me. I haven't tested this, so I could be wrong :-)
If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.
Server-----Router----Internet
/
Test_PC----/
Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.
Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2 Change SCR:6.6.6.6 to 4.2.2.2 6.6.6.6
But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.
Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.
That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.
The best way is to use proxies. See also this question on serverfault.
If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.
You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.