I am trying to get my head around Windows, Networks and Domains.
I currently have a server - svr. This is on my domain companyname.co.uk
I can connect to server and ping both svr and svr.companyname.co.uk.
On this server I have a number of applications with web access; TeamCity, Octopus etc. We currently connect to them by browsing to svr:xxxx where xxxx is the port of the web app host (http://svr:9090/ for TC)
I want to create friendly alias' - for example teamcity.companyname.co.uk would point at svr:9090, octopus.companyname.co.uk would point to svr:8090.
However, not being experienced in this area I can't seem to find relevant documents or sites that fully explain what I am looking for.
First, to make one thing clear: when you visit a web page like http://example.com, your web browser is actually making a request to example.com:80. This is done transparently because port 80 is the standard port for the HTTP protocol. As you know, you can request a non-standard port by appending it to the domain name in the URL: http://example.com:888/.
Unfortunately, you cannot have a domain name "alias" that somehow includes a non-standard port - your browser will always try to use port 80 if you don't specify a port.
One solution would be to use a proxy - nginx, apache, lighttpd, and others can all do this.
The idea is that you set up a proxy server that is listening on port 80 on your host. It waits for connections, then forwards those connections to a different server (on the same host, or on a different one) based on some rule. So, for example, you might have rules that look something like this:
IF host = teamcity.companyname.co.uk THEN forward to teamcity:9090
IF host = octopus.companyname.co.uk THEN forward to octopus:8090
The syntax for these rules vary widely between different proxy configurations, so this is just an example.
Note that this is not a redirect - the user's browser connects to teamcity.companyname.co.uk for all requests. It's the proxy that sends the request on to a different service and forwards any responses back to the client "behind the scenes".
These proxy configurations can get quite complex. For example, what if your teamcity application serves a page with a link on it that points to http://teamcity:9090/path/to/page? The user's browser is going to fail if they click on that link. Fortunately, proxies can be configured to rewrite URLs like this on the fly. You'll need to do some research to tailor this solution to your situation.
Related
I have 1 single machine with an IP 1.2.3.4. This machine has 2 web servers and an ftp server:
Web Server 1 listens to port 82; the domain for it: ws1.example.com
Web Server 2 listens to port 83; the domain for it: ws2.example.com
FTP Server listens to port 21; the domain for it: ftp.example.com
This is what the DNS mapping looks like:
ws1.example.com CNAME example.com
ws2.example.com CNAME example.com
ftp.example.com CNAME example.com
example.com A 1.2.3.4
Case 1: I make a request at the browser URL ws1.example.com:82 and the DNS redirects me to example.com but with the Host header: ws1.example.com.
Case 2: I make a request at the browser URL ws2.example.com:83 and the DNS redirects me to example.com but with the Host header: ws2.example.com.
In both the cases:
the request ultimately reaches the same physical machine
when the request arrives:
In Case 1, the request arrives at this machine and the request is attended to by the application that is listening on port 82 i.e. Web Server 1.
In Case 2, the request arrives at this machine and the request is attended to by the application that is listening on port 83 i.e. Web Server 2.
The Host header, as I understand, is used to inform the receiving host to identify which server (from the multiple servers that this IP has been hosting) is this request meant for and accordingly directs the request to the appropriate application.
My question is:
In this example, what is the purpose of the Host header as the same physical machine with the same IP has multiple applications listening at their corresponding ports. Once the request reaches this machine, the appropriate port will anyway pick up and the other applications will ignore the request as the port does not match the request. So, what purpose is the Host header serving here when apprpriate ports are anyway doing their job, right and well?
Can I infer that
CNAMES
Multiple Web Servers behind a single IP
subsequent resolution of a particular user request to the appropriate Web Server with the Host header
make sense only when you are using something like a Reverse Proxy e.g. 1 machine interfaces with the client and redirects user requests to the appropriate web server on separate machines all listening on the same port e.g. 80, each in the network behind the reverse proxy in which case you have ws1.example.com and ws2.exmple.com both be redirected to the reverse proxy example.com and this reverse proxy now forwards it to the appropriate host based on the Host header?
No DNS redirections
First an important terminology fix:
There are no "redirects" in the DNS. In your case, the DNS is just use to map a name to an IP. Sometimes, because of CNAME, a name is mapped to another name which is then mapped to an IP. It does not matter if there are intermediate steps like that, at the end a name maps to an IP (or there is a DNS resolution failure)
This also means that if the URL has a specific port, then that is not changed, the final IP will be queried over the port mentioned in the URL.
Redirections are an HTTP level feature: when querying a webserver for https://www.mygreatsite.example/foo it will reply with an HTTP return code of 301, 302, 303, 307 or 308 and giving you (the HTTP client, aka the browser) the new URL to go to.
HTTP virtual hosting
In the good old days, IP addresses were plenty. If you were hosting both www.site1.example and www.site2.example on the same physical box you could attach one different IP address to each.
Hence, in that specific case, in a way, the HTTP host header is useless, the mere fact of connecting either to 192.0.2.37 or 192.0.2.42 already lets you know which site you want.
In fact in HTTP/0.9 there was no host header, as there were no headers at all.
But then, with mass virtual hosting coming into play, and IPv4 addresses becoming scarce, you could not anymore attach one single IP address per site, since it was also a waste.
So you had, through the DNS, either directly or indirectly (CNAME records), both websites resolving to the same IP.
Hence when the HTTP client connected to the server, the server by default has no way to know which website do you want. That is why the HTTP host header filled by the client lets the server know which website you want to access, irrespective to its IP address, that was resolved earlier through the DNS.
By default HTTP uses port 80, so it is often not visible in the URLs.
Of course if you forced your clients to use http://www.site1.example:4569 on one side and http://www.anothersite2.com:9873 on another side, then you are right the host header would not be really needed.
Except that the plan falls down for many reasons:
Port numbers are not an infinite space either and many of them are already used typically for other things; so even if you extend this scheme at one point you could not attach new websites to the same IP
But more important than the previous technical point, for humans this will be a nightmare and many people will use forget the port number and then not coming to the appropriate website.
Hence typically it is not done like that, if you want to expose some given service over HTTP but in a non default port you typically install a reverse proxy in front of it. Or you do an HTTP redirection from http://www.coolpublicname.example/ to http://www.complicatedinternalname.example:9713, but then the client sees this naked truth.
HTTPS virtual hosting
In passing note that HTTPS added a level of complexity because the HTTPS webserver needs to send its certificate to the client, but since each website can have a different certificate it needs to know which website the client wants to use, which it could learn through the host HTTP header but then comes after the TLS handshake is finished, so in the early stage of the server sending a certificate this is not available yet.
So at the earliest times of HTTPS we were forced again to do IP-based virtual hosting and not name-based virtual hosting like it was possible in pure HTTP thanks to the host header.
The solution was found with a TLS extension, the Server Name Indication (SNI), something that the client sends early to the server and gives the website name, so that the server can send the appropriate certificate, and hence we are back in business in the name-based case where you can theoretically have an infinite number of names resolving to the same IP for them to be served by one given webserver.
I am trying to configure my IIS reverse proxy to route http connections to an internal server however I am not sure how to achieve what I need or even if it is possible.
I have a sub domain on my IIS server for example,
testing.contoso.com and externally I would like to have http://testing.contoso.com:8080 which will then map to my internal server http://server04.contoso.local:8080. So I do not want my internal site to appear as http://testing.contoso.com on port 80.
My reason for doing this is that I will have quite a few internal and external corresponding ports.
Is it possible to configure this with my IIS reverse proxy or does IIS only support ports 80 & 443 externally?
Thanks in advance, Neil
From what I see in your question, it should be fairly easy to make that work using IIS Application Request Routing: http://www.iis.net/downloads/microsoft/application-request-routing
That should let you use any ports or hostnames in a machine being exposed and then let that route to any other machines (or same) in any ports or combination. It also will allow you to offload cache of static files, and many other nice features. It uses URL Rewrite for the main engine on which server to route to, so you can literally add any logic you want, and if need be you could use extensibility of URL Rewrite to add custom code to define the logic (though the built-in configuration one should be rich enough).
I am trying to run a server on a different host to my website. How can I set it up so that if people connect to certain ports on my domain that they connect to my server, and so my website still works.
Ports exist on the level of TCP and UDP. There is nothing DNS can do to magically change what happens, at the client or your server, on that level.
For your web site, DNS provides translation of its name to a set of IP addresses. The client's browser will then try to talk to port 80 or 443 on one of those addresses. If you want the other server to use the same name as the web site, it must answer requests on other ports on the same set of IP addresses.
If your server is for a protocol that's new and smart enough to use SRV records, you can use that to actually run the server wherever is convenient but still tell the users to connect to the web server name. Check the documentation for details.
If you can't do that, another possibility is to run a small process on the web server machine that listens to the other server's port(s) and forwards all traffic to wherever the server is actually running. The feasibility and details of doing so depends a whole lot of what server it actually is, so I can't really say any more about that.
Or you could just tell the users to use www.tellusthesoddingname.com for the web site and server.tellusthesoddingname.com for the server and point those names at different IP addresses. Which is by far the simplest and most robust solution.
I have a server that runs different websites on different ports. All of them (but one) are Apache servers and thanks to webmin, I managed to have, for instance, example.com point to 123.123.123.123:80 and example.fr to 123.123.123.123:8000, somehow automatically
I am now running a nodejs server on the same machine, so the 80, 8000, and many other ports are already taken. My nodejs listens on 8008. I have another domain name, say example.org, and I want it to point to my nodejs website, but I simply don't know how to do that! I have updated the DNS and everything is pointing to 123.123.123.123 (my server's IP). I want to avoid using an ugly example.org:8008/ for everything on this node server. How can I make it point implicitly to the 8008 port?? I must add that I cannot afford to take down the apache servers ;)
DNS only provides name to ip address mapping. It cannot handle ports. What you can do instead is to set up a proxy server listening on port 80. The proxy server can then return data based on the host header.
Your best option is to just redirect the request from Apache. Otherwise you can use a reverse proxy like Nginx. Also, you can write a lightweight proxy in node... check out this page
I'm runnning IIS 7 on my local dev machine. My website is up and running. To access the website, I need to enter the url with the port number in the browser's address bar (www.ScoobyDoo.dev:91). What do I need to change so I only need to enter the www.ScoobyDoo.dev portion of the url? I've done this before but I'm drawing a blank. Port 80 is hosting a different website so I can't just move this one to the default http port.
Thanks!
If you want multiple sites to reside on the same IP address then you need to use HTTP Host Headers.
Provided that your existing website doesn't use SSL then you can use host headers. To configure host headers in IIS7 you modify the "Bindings" (there's a menu item for this in the right hand side Actions pane for the site):
You want to add/edit your bindings for each site that resides on the same IP address, for example for your scoobydoo.dev site:
The caveat here is that if you have users already browsing your first site by IP address then they will need to be redirected to the site using its domain name.
You can do this by adding a site bound to the raw IP address and creating a HTTP Redirect.
I'm not sure what you're expecting to do here. If something else is binding to port 80, and your web server is binding to port 91, then you'll need to specify port 91 in the web browser when making a request to the server. By default, without being explicitly given a port in the address, a web browser will make the request on port 80 (or 443 for SSL).
You might be able to add an entry to your hosts file (c:\windows\system32\drivers\etc\hosts) where you map the non-specified port version to the specified port version, but I don't think it'll work. That file is for DNS resolution, not port mapping. Worth a try though, I suppose.
Can you clarify a bit on what exactly you're expecting? Or what you think you may have done before? I wonder if you're not giving us the whole picture here.