When there genuinely is no web server installed on a machine, and the user types in the machine's IP address or FQDN into the web browser, the user will get a genuine "can't connect to the server" message from the web browser.
However, after installing the Apache web server, the direct IP address and the FQDN (i.e. archimedes.example.com) will now show the default "It works!" page. How can I make my server act as if there is no server in these places (for the IP and the FQDN)?
Note that a 404 error does not qualify, because that makes it clear that a web server is available.
Is this even possible to do in the first place?
The goal of this is that I just want my regular websites, say genuinewebsite.com, that is genuinely supposed to be on this server to be recognized. All the other "default" addresses (the IP address and FQDN) that really have no connection to any websites should just act as if there is no web server there in the first place.
No, it is not possible, because to get the hostname the browser used for the request, the browser first has to connect successfully and send it in the request. By that time, you can't really refuse the connection; the best you can do is close it on them which will appear as a connection reset error.
Related
I'm trying to upgrade a websocket connection ws:// to wss:// using a nginx reverse proxy https://github.com/nicokaiser/nginx-websocket-proxy/blob/master/simple-wss.conf
but I seem to be having trouble with the certificate part. My server is located on the same network as the client. So Ideally I would want my users to log in to "https://example.com" and then the client makes a connection to "wss://192.168.1.xxx:xxxx".
As of now the browsers are blocking it because of NET::ERR_CERT_COMMON_NAME_INVALID. I don't really know to produce a self signed certificate that the browsers will trust on the local network. Googling only gives me answers on how to do it if my server would be accessed using a domain name but I will always connect to a local network IP. Help is appreciated!
To anyone coming across this I managed to solve it using this post outlining the architecture https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
What ended up happening was that we set up a url pointing to a server running nginx which parsed the subdomain and redirected the connection to that url. For example: wss://192-168-1-142.mydomain.com redirects to ws://192.168.1.142 which makes the browser trust the connection
Does this work?
Your post is a year old now and browsers have become stricter since then. Usually, a browser will produce 'mixed content' errors if you access HTTP content from a HTTPS page, and the only way to get round this is to change the site settings to allow insecure content, which is scary for users in the face of a big warning message.
If accessing an HTTPS web address redirects to an HTTP local IP address, won't the browser still complain about mixed content?
I have a similar situation to you. I am writing a Progressive Web Application (PWA) to control network music players on a home network. The players only support HTTP but a PWA requires HTTPS for services workers to work and to allow the app to be 'installed'.
My solution is to run a local server on the home network which can talk to the players over HTTP. Then I can access this server over HTTPS from my browser so that the browser itself is not making any HTTP calls.
This works fine if the server is on localhost because localhost is a special case where security rules are relaxed. But if the server is on another machine, how can I create an SSL certificate since (1) it seems that local IP addresses are not allowed in the Subject Alternative Name (SAN) section of the certificate, and (2) I won't know in advance what the IP address of the server will be.
If your workaround works, then the local server can use HTTP instead so I won't need a certificate. The local server can register itself with a web server, and then the browser can connect over HTTPS to the web server, which would redirect to the IP address of the local server over HTTP.
But does this trick work?
I'm having trouble connecting to an Active Directory server from my computer and server. I get "The server is not operational" error when trying to connect. The server I'm trying to connect to is in a different country than me.
LDAP Url is in the usual format:
LDAP://ip_address:389/CN=Users,DC=domain_name,DC=local
I've added the application that connects to the AD to the firewall (even disabled the firewall briefly to test) and added the IP to my hosts file but I can't seem to get past the error.
Now usually at this point, I would conclude that the issue is on the AD server side (or their server firewall) that is blocking requests from our server, however, the person in charge of the AD server has tested the same LDAP url using the same utility I'm using from an external network in their country and is able to authenticate without issues.
Any ideas on what we can try next?
Ok, it turns out the client's ISP was blocking international traffic over port 389. They had to write a letter to request the ISP to allow international traffic over that port. It is now working after they've done that.
Didn't know ISPs block traffic, but I suppose ISPs for corporate clients might as in this case.
I have a server running on my machine. I want to send a request to the server using different IP address to test a web application. I only have the machine on which the server is installed. I have been testing as a single user but now I would like to let the server think that the request is coming from a different ip address even though it is from the same machine. How can I do that?
Here are the 2 solutions that might be possible in your situation
1- To change the ip address :
Pick an ip from the free proxies here: http://www.freeproxylists.net/
And enter the info in firefox just like this page says:
http://www.wikihow.com/Enter-Proxy-Settings-in-Firefox
Note: You may pick a proxy with port 80.
Then you are good to go...
2- Or you might use a Virtual Machine installed on the same computer as the server and access the website right from it but beware not to use bridged connection.
First URL stands for Uniform Resource Locator. It will be very difficult to remember an IP address. Instead of remembering the IP addresses URL came like www.intrepidkarthi.com. Url normally contains three parts. For example http://intrepidkarthi.com/index.php. Here "http" refers to the protocol it uses. Then the server name and then the requested file name.
Here I have enlisted the flow of working mechanism behind your browser
The flow of work
Your browser communicates with a name server to translate the server name "www.intrepidkarthi.com" into an IP Address, which it uses to connect to the server machine. * So your browser will see if it already has the appropriate IP address cached away from previous visits to the site. If not, it will make a DNS query to your DNS server (might be your router or your ISP's DNS server). DNS stands for Domain Name Server - For exapmle if you want to get karthik's phone number then you will look into your telephone directory. Likewise your computer doesn't know intrepidkarthi.com's IP address . So it looks into DNS.
The browser then formed a connection to the server at that IP address on port 80. HTTP protocol uses port number 80
The browser sends a GET request to the server, asking for the file "http://www.google.com/karthikeyan.htm". The webserver then returns the requested page and your browser renders it to the screen.
The firewall will control connections to & from your computer. For the most part it will just be controlling who can connect to your computer and on what ports. For web browsing your firewall generally won't be doing a whole lot.
Your router essentially guides your request through the network, helping the packets get from computer to computer and potentially doing some NAT (Network Address Tranlator) to translate IP addresses along the way (so your internat LAN request can be transitioned onto the wider internet and back).
I don't know what I understood is correct or not. I need to understand it completely till the hardware level at the back.
browser has no DNS cache. your operating system's tcp stack has.
the server name in DNS may have many IP addresses. the browsers usually choose one at random.
DNS is a tree. to get www.google.com, you go to google.com name service and get IP of the computer www.
returned HTML page is a small part of the information. In turn, it points your browser to establish many connections to other servers, to bring scripts, pictures, etc.
otherwise okay.
To keep things simple, please allow the "assumption" that some code requires the use of a full URL, even though the domain is on the same server, i.e. a simple file path cannot be used.
TCP/IP?? Question:
If a form action target = "http://this-full-URL.com/postdata" (for example) and that URL is also on the same server, then which happens first?
A) Data is sent "out onto the web", and then returns to the same server,
or
B) Before sending any (possibly sensitive) data, the server (Linux, Apache, PHP), first "discovers" the target address is local, so (clearly) no data is sent over the net?
Thank you.
The correct answer is always A. :-)
It just happens that the case where the browser and the server are running on the same machine, "the web" will be short-circuited by the local TCP/IP stack. However, Apache and PHP are not involved in that decision; it's pure functionality of the OS networking stack.
However, if your server is behind a NAT gateway or firewall and the DNS name is resolving to the NAT gateway/firewall, the request will be routed to the NAT gateway/firewall and back to your machine. Thus, in order for the routing to stay on the same machine, the DNS name of the host of the target URL has to resolve to the actual IP address of the server machine, not be tunneled to it.
The network software will resolve the hostname to you machine, then the local TCP stack will route the request locally. Traffic won't ever leave the machine, it'll all be in memory on the server.