J. Greenlees wrote:
Brian Mearns wrote: ~snip~
Let me add another tip. Apologies if it was in the previous posts and I missed it. Your server is part of a local LAN, which has addresses like 192.168.2.x. Say your server is 192.168.2.100 there. When your server gets a TCP packet containing a HTTP request, the TCP packet contains the request of course, but also 2 IP addresses : - the address of the sender - the address of the receiver (your server, 192.168.2.100) Say the address of the sender is something like "192.168.2.20" (an internal LAN address). When you server processes the request, it is going to try to send back the response to the original sender. If the sender's address is 192.168.2.20, it has no problem. It knows this is the local LAN of which itself is a part, and it can just drop the response on the local ethernet wire, and the sender will get it. However, say the sender is "110.10.20.5" (an Internet address). Then your server also knows that this is not a local address, so it cannot just drop this reponse onto the local LAN. What it needs, is a "gateway". This gateway is a system on the local LAN, which is connected both to the local LAN (with an address like 192.168.2.x) AND to the external Internet (with the IP address given by your ISP). Your server, if it knows that this system exists and is a gateway, will then "wrap" the packet for 110.10.20.5, into a packet to the local gateway system's address (192.168.2.x), and send it on the local wire. The gateway will receive it, notice it is a packet to be forwarded, remove the wrapping, and send the packet out (on his external interface) to the sender.Who is this gateway ? it is your Internet router of course, which is the only one connected both to your internal LAN, and to the Internet.
Then there is the other side. An Internet computer cannot send a request directly to yourserver's internal IP address (192.168.2.100). Instead, it must send it to the external IP address of your router.
(For example, right now, I see that this is 174.100.124.104).When your router receives this packet, it must know what to do with it, because he is not the webserver.
So your router needs to know that if a packet comes in, addressed to himself, but for port #80, it is not really for himself, but for your internal server. So it must change the receiver's IP address to be the internal address of your server, and put the packet on the internal LAN for your server to pick up. This whole thing above requires a setup.Your webserver must "know" that the router's IP address can act as a gateway to all the IP addresses that are not in your local LAN.
And the router must "know" that your internal server "192.168.2.100" is the one that wants all packets for port 80.You say that you did the router part already, for VNC. That's good, because what you need to do on your router for HTTP is very much the same thing. The only thing that changes is that instead of port 5900 (VNC), you must put port 80 (HTTP). (Make this another line, do not change the line for VNC).
Then you have the other side, from your server to the router.Under Windows, that is also easy. Check your network settings, where you have your internal server's own IP address. There is a place there to put the "stabdard gateway" address. There, you need to enter the internal IP address of your router.
When I try to connect to your server address "http://www.jrubinic.us";, I did not immediately get a "connection refused". That means that /something/ at that address is listening to port 80.
But I do not get any answer.Which may mean that your webserver is getting the request, but does not know how to send the response back.
Or that something in the middle is blocking it.In that case, we may yet find another solution, like changing the port on your router.
--------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|