I have an apache HTTP server set up in my computer. Can I access it from anywhere over the internet? I don't have a registered domain for my server.
You can access it if you tell your router to forward your HTTP port. If your router does not know to forward it, you will only be able to access it on your local network. You do have to buy a domain, unless you just access the network-wide IP, you can find this on whatsmypi. So, to summarize, you need to do 2 things: (1) tell your router to forward the HTTP port, and (2) access it via the internet by means of your IP (unless you buy a domain name).
UPDATE
Of course this is one of those "easier said than done" and "one size does not fit all" things. There will probably be a set of difficulties that come along with your attempts to access your HTTP server. I would suggest googling some tutorials.
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 set up DNS server using CloudFlare few days ago. After then I found that CloudFlare provides reverse proxy. In "off-the-orange" state, I can connect server through ssh but In "orange" state, it's not.
Now I know that I have to register other A-Record like "ssh.domain.com" In "off-the-orange" then I can get what I want. However I can't sure it's right.
Is there other way to connect server through other protocol?
No, there is no other way, that's exactly what Cloudflare expects you to do, see: How do I SSH? and DDoS Prevention: Protecting The Origin. Cloudflare doesn't offer reverse proxy without DDoS protection.
If you have only one domain, you add subdomain A record for actual server, pointing to the server IP. Then you add CNAME for protected website. Cloudflare uses CNAME flattening so it's possible to have CNAME like my-domain.com -> actual.my-domain.com.
That setup has security implications: If someone finds out the subdomain, it exposes the real IP address and attacker can bypass Cloudflare protection.
Cloudflare DNS is very strict on how they respond. They don't leak anything, you have to explicitly know domain and record type to get the answer. Ie. digmy-domain.com ANY does not give away anything, you have to ask for a record type: dig my-domain.com A which returns Cloudflare proxy IP. And obviously, they don't respond to AXFR request either so only way to get actual IP from Cloudflare DNS is brute-force. I have feeling Cloudflare might detect and block such attempt.
Of course, you don't want to rely on obscurity only. Some things you could do to protect your server in case IP/subdomain is exposed:
throttle ssh connections (ufw tutorial)
configure your HTTP server to respond only desired host names ie. my-domain.com and maybe www.my-domain.com (nginx example)
also, you could deny HTTP(s) connections coming outside of Cloudflare Network.
The "Orange Cloud" icon on the DNS tab of your CloudFlare Dashboard indicates that all HTTP/HTTPs requests sent to that address are going to be forwarded through CloudFlare's reverse proxy system. This means that all connections will actually hit CloudFlare's server, then CloudFlare will "proxy" the connection and pull the page from your webserver.
When you proxy connection through CloudFlare, no direct connections are created between the client and your actual web server. If you have an "A Record" in place for a purpose other than HTTP requests, you will need to create a new record without the "Orange Cloud" icon.
How to create a new record:
Select the website you would like to create a new record for.
Select the "DNS" tab.
Select the record type you would like to create.
Enter the subdomain or record name you would like to create.
Enter in the details or IP you would like to point this record to.
Example:
If you create a new record (Like sshdirect.example.com) and point it to your server's IP, and ensure that the cloud icon is grey. You can then attempt to connect to that hostname instead of your standard one.
I currently have Apache running as part of XAMPP and I am able to run the PHP scripts by accessing them at 127.0.0.1/<program_name>.php but when I try to access them as <my_ip>/<program_name>.php I get no response.
Am I doing something incorrectly or does my configuration need fixing?
assuming you are trying to access from an external ip address you need to setup your router (port forwarding) to send web traffic to the LAN ip of your machine.
you also may need to disable various firewalls at various points in your network.
In short there is not enough information given to provide you a definitive answer.
Newbie programmer here. I'm building an app for an API that requires an IP address for authentication. Basically, users have to send the API management their IPs and then each time a computer makes a request to their server, it verifies whether it's coming from a registered IP.
Since I work in a number of different places and thus end up with different IPs, I thought it would be easiest to use DynDNS to establish a URL that points to whatever my current IP is and then send that URL to the API management. So my first question is if this approach would in fact work?
Secondly, assuming this would work, I set up ben.dynalias.com and downloaded the DynDNS Updater client. It appears to be working: the updater says status: OK and displays my current IP. However, when I navigate to the URL (ben.dynalias.com) there's no response. Should this be the case? How can I tell if it's working?
I don't see any reason it shouldn't work as long as your updaters aren't overwriting each other by running at the same time automatically from different locations.
You can ping ben.dynalias.com and see if your current ip matches.
I just hosted ben.dynalias.com and it gave me your IP.
Since there is no web server running on that IP, then your browser will not be able to show you a page result.
You can use http://www.kloth.net/services/nslookup.php
to check and see if you get the correct IP from a host lookup.
Depending on how often your IP changes this might not be a great solution as the DNS will cache your hostname and will not try and resolve it again until the TTL expires normally minimum 1 hour.
whether the API management accepts a hostname instead of an IP address is a question only they can answer. Some will, many won't as it's "easier" to hijack a domain name than to hijack an ip address.
trying to browse to you-address.dynalias.com that points to your own public address rarely works, even if you opened up the right ports because your router will be highly confused. The best way to test such a setup is by using a phone or tablet with 3g/GPRS internet - of course after you set up port forwarding in the router to point the appropriate port to your computer.
I created an AMP web application that was originally going to be served from a traditional 3rd party host.
As we finished up, the client decided to host it internally, on a server in their office network. The application is only meant to be available to staff members, but those staff members will often be off-site. I had no involvement in setting up their network, which uses at least one server running windows server 2003. The client machines I saw were XP.
I set up Apache, MySQL and PHP on the server 2003 machine, and installed the application. The application is built on the CodeIgniter framework, so I set the base_url to the internal IP (192.168...), and we tested from within the network. Everything worked fine.
Next, we asked their network guy to open port 80 for apache. I set the base_url to the external IP, and tested from my home (using the external IP as the web address), and it works fine.
However, when attempting to access the application using the external IP from within the network, they're unable to connect. I can reset the base_url to the network IP, and they can access it using the network IP, but then it the application fails when connecting externally (since the base_url, used throughout the application, is pointing to the internal IP).
It suppose I could let CodeIgniter determine the base_url (by leaving the variable as an empty string), but would rather figure out why the external IP fails in-network, and try to correct that.
The server we're using is not dedicated to the AMP stack (in fact, it has at least one other application broadcasting to the internet that must have been using IIS, as well as an FTP server used for office scanners), so I suppose there might be some conflicts there.
I know very little about windows networking. A quick search suggested this might be because of NAT, but didn't offer a work-around.
Their network guy has no suggestions, and said that everything should be fine.
Is it possible to have users inside the network access the Apache server using the external IP, and if so, what needs to happen to enable that?
TYIA
Your client's NAT router is configured to forward packets arriving on its external interface for its external IP with port 80 to the internal machine, port 80, after re-writing the source and destination IP addresses in the packets.
From within the network, attempts to connect to the external IP address will be routed to the default route on the machines, the router's internal interface. This interface is not configured to forward packets back into the network.
Configure the application to listen on all IP addresses. Make sure that the server knows that the clients know it under several hostnames -- the internal IP address and the external IP address.
You might be able to re-write the NAT firewall rules on the router to perform the port forwarding for the internal interface as well, but off-the-shell equipment common in homes and small businesses do not make this task easy. More expensive gear (or home-built *BSD/Linux router machines) can do this without much effort, but it would needlessly add traffic to the router.
This isn't Apache related, nor is it CI related. It's often impossible to reach the external IP address from within the network.
Frankly, I don't know exactly why that is. I do know that it's related to how NAT (Network Address Translation) works or at least how it's implemented.
For a detailed overview of why this is, you should ask this question on serverfault. If you're simply a programmer who has to deal with it, accept that NAT usually works only from inside to outside and outside to inside, but not inside to inside.
You already mentioned one of the solutions in your question - don't use base_url. You could also simply run the server on an external IP address (not your company IP, but let's say a datacenter or something).