I have apache2 setup with several virtual hosts, but I have it setup so that if you visit the IP address in your browser you get an error 403. When I ping the domain name of one of my virtual hosts, it always just responds with request for timeout, never the latency, why is this?
Perhaps your hosting provider (or your Linux distro) has firewalled ICMP protocol which is necessary for ping to work correctly.
Note that Apache needs only TCP to work properly, and does not need ICMP, which is completely different protocol. In other words, ping may be completely firewalled, and yet, your website will respond correctly.
Some websites actively firewall ICMP, most notable example is microsoft.com.
Related
I have a device (esp32s2) which is IoT enabled and communicating with AWS server.
The device is connecting to the internet via router. I want to check from the device, if the router is connected to the internet or not. If not connected, I need to disconnect mqtt broker instantly.
I know there is aws_iot_yield happening, but it is taking too much of time to change the client state (~5-10 mins) after disconnection. So, is there is any other way in which I can come to know if the device is connected to the mqtt broker or not using AWS sdk?
I want to avoid using pinging to some address/server as it will increase the usage of resources.
Thanks in advance!
Since the connectivity to the AWS server trough internet depends on the network elements, the only reliable way to know if you are connected to internet is to send a package to a know address and receive the response. Simplest way to do this is to use ICMP (ping) protocol. Usually the most reliable destination to ping is the Google DNS server 8.8.8.8 or 8.8.4.4 which is a cluster service and it's always replying on the ping.
You can control the pause between two pings and how many pings you will send in one session in order to preserve the resources.
Alternative approach is to use a router that can send messages to a monitoring device that the link state was changed (by example SNMP trap). But this is not fully reliable method since the router can not detect all scenarios where the connectivity to your AWS server is lost.
This is probably going to be a stretch, but it seems worth asking. Let's say I have a static Angular web app on nginx-host (linux) along with the following /etc/hosts file, automatically generated for the host by some stringy configuration management tool:
127.0.0.1 localhost
10.0.0.1 internalhost
Next, I have a stock Nginx configuration for nginx-host, nothing fancy is happening with the server blocks - with this problematic location block:
location ^~ /app {
return 301 http://internalhost/end/point
}
The problem is that this block returns precisely the url listed in the location block without any sort of translation from internalhost to the appropriate IP, resulting in client-side errors - and I need it to resolve that IP before handing it back.
Please note, we can't use maps or upstreams here. The Immovable Wall here is that our configuration system handles all service discovery and host-dependency resolution by doing lookups and generating hostfiles, and it's entirely separated from our internal nginx configuration, so we can't connect the lookups to the nginx setup to allow for dynamic maps or upstreams. This is also happening across several isolated segments of network for varied testing environments, so it's a hard requirement that we reference the nginx host's /etc/hosts file to resolve the host name before passing back the redirect path, as internalhost can be anything from dev-internalhost to production-backup-internalhost, all of which have distinct IPs.
Note: proxy_pass is not a solution here, we need the redirect for SSO purposes, and when the request is made to the internalhost location, the request params need to carry on through to the internalhost machine from the nginx-host, and the client needs to see the redirect to know that it's now on speaking terms with the internalhost server.
Edit for clarity: the client has no way to resolve internalapp on its own: nginx-host has a static UI, a link on that UI hits the /app endpoint, and nginx needs to pass back an IP-based link derived from the generated local hosts file. internalapp has no DNS records at all aside from the local hosts file - but the IP address in the hosts file would resolve to something like dev-internalapp.example.com that could actually be reached
The hostname in the 301 redirect is just text that's sent to the webbrowser.
The vast majority of clients out there will use DNS to find the IP address from the hostname in the URL.
If you have browsers "out there" on the Internet, they will have to have a fully qualified domainname (e.g. www.example.com) as internal or something similar will never point back to you. In this case you will have to change the message sent back by nginx. It's trivial if you have control over the configuration to do that...
If you only have internal hosts, your internal DNS should be more than able to allow internal hosts to properly resolve "internalhost" to its internal IP address. In essence, make sure they send a searchdomain record along with the DHCP responses.
How to setup the DHCP and DNS inside a company is relatively easy if they have an internal network/IT team that knows what they are doing.
If they have a mess -that happens every so often- nothing will work properly, no matter what you do.
A lot depends on how they set things up, but in general to make names like "internalhost" resolv internally to an IP address, I'd use:
pick an internal domainname (if they have not already). e.g. .local is an option, or historically in.example.com (where example.com is their external name). It does not have to be known externally, it just must not be used externally. Having it known externally makes it slightly harder, so avoid that.
DHCP: I'd set DHCP to emit the optional "search domain". How to do that depends on what DHCP server they use, but e.g. https://serverfault.com/questions/481453/set-search-domain-on-dhcp-server-without-changing-domain-name shows an example. I typically make sure it emits in.example.com, example.com as that makes it easier on typing domain names.
Internal DNS: now just add on the internal DNS server(s) an A record for internalhost.in.example.com. and point that to your RFC1918 address.
Optional: I'd make sure the firewalls disallow internal clients from using external DNS servers - or (better?) redirect them transparently to the internal DNS server(s). that way you avoid users setting e.g. 8.8.8.8 and 8.8.4.4 as DNS servers, overruling what they get from the DHCP server, and hence not seeing your internal names.
That's it. http://internalhost/whatever will now go to the machine with the IP address given in step 3 above and browsers will send a Host: header (if you have virtual hosts!) of internalhost.
My question is, how to connect to socket on romote mechine?
I can only connect sockets on same network..
I wrote a simple code (in c), that simulate a server (open socket and listen for client). in Mac.
I'm trying to connect this socket as a client from iPhone (with simple objectiv-c code).
If my internet on both, server and client, is on the same network (WiFi) and in client I trying to connect to 192.168.1.x, it's working.
But when, in client, I'm trying to connect via external IP (with the same port) connection is failed.
I never did this bofore. Maybe I miss somthing.. I've tried to turn my FireWall off. It did not help.
Thanks.
Edit: If it's not clear.. my Mac is connected by router.
In a setting like this, the "external IP" would typically be the IP of the router. In all likelihood you'll need to configure the router to forward the relevant port to the internal IP address.
It could also be the case that for the port forwarding to work, the request has to come in on the external (WAN) interface. This depends on how the router is configured. If that's the case, you'll need to make sure that you're accessing the external IP via the cellular network and not the Wi-Fi connection on your iPhone.
If you're connecting to your server via a local IP address (i.e., you're connecting to another machine on the same local router via a delegated DHCP address), then your issue is on the network, not the IP-stack of the local machine.
You'll need to look into your router settings ... many routers will block a number of services, especially those on custom ports, in order to prevent malicious attacks from sources external to the local network.
We have a makeshift SOAP client written in C# connecting to a CXF service on a desktop from a windows mobile device. When this device is connected via ActiveSync, it creates a virtual adapter for the RNDIS connection. This virtual adapter assigns a gateway IP to the host, 169.254.2.2.
When we attempt to go through the connection with the hostname or the host's IP set as the address in the C# client, everything works perfectly. When we however set the IP to be the RNDIS gateway (169.254.2.2), the connection is periodically lost on the server side. The CXF service keeps trying to connect, and eventually succeeds, but this results in a massive slowdown of the connection. There are no errors reported in our logs on the mobile C# side, only on the CXF server.
Does anyone have any clues as to why this is happening? We need to assert that 169.254.2.2 cannot possibly be used as a valid endpoint before we rule it out.
Oh, and in case it helps, the C# client is granted the IP 169.254.2.1 through DHCP after the ActiveSync connection.
The first issue that comes to my head, especially once I saw that you are using DCHP, is that the lease time on the IP from the DHCP server is expiring and the CXF server is having to wait for the DCHP server to issue a new lease.
Try lengthening the DCHP lease if you know that the IP won't be changing and use a static IP if you are able. That will at least remove that point of failure.
I found out the cause of this, but I feel bad for answering because I doubt there was any way someone else could have guessed that this was the problem:
On our CXF server, we have a call to InetAddress.getHostName() which basically does a reverse DNS lookup on the request sent from the C# client.
When using the ActiveSync IP address, there was no entry in the DNS for 169.254.2.1 (of course), so the java class would hang until the method timed out (which took about 20 seconds before it would write a response to the C# client). At 20 seconds per request, this resulted in the massive slowdown and lost connection errors.
We fixed this by moving the call to an executor thread that force-finished after half a second. Because it was in another thread, the slowdown became nonexistent. Glad to have that over with!
I'm new to this forum (at least at asking questions), so please be patient. I'm trying to write simple client-server applications to communicate using datagram (UDP) sockets, with C and Windows.
The scenario is very simple, I want to be able to send/receive data from a machine in some local network (behind a GATEWAY/NAT) to some host having public IP. I can send the data, but it seems impossible to receive any data back, because the remote server can't see the client's local IP.
I don't want the user to perform manual port forwarding on the GATEWAY, and I also don't want to use UPnP because of security issues (though it also should be enabled by the user).
I think it is possible because applications like Skype or Browsers can do it, but how ?
Are there some automatically forwarded ports or things like that ? I'm exhausted of searching the web ... PLEASE HELP !
For UDP connections, most home NAT gateways will automatically create a temporary reverse mapping for each outbound packet.
Consider a scenario where your client is running on the internal machine with IP address 192.168.4.5, sending a UDP packet from port 65000 to the external address 64.34.119.12:6789, via a gateway with external IP address 192.0.43.10. When the gateway sees your internal client send a UDP packet from 192.168.4.5:65000 to the external address, it will NAT it to an external address and port, like 192.0.43.10:5500. Your server will see a packet with a source address of 192.0.43.10:5500 and destination address 64.34.119.12:6789. The router also sets up a reverse mapping, so that if it sees a packet arrive on the external interface with a source of 64.34.119.12:6789 and a destination of 192.0.43.10:5500, it will redirect it back to 192.168.4.5:65000. This mapping typically times out after a short while.
This means that in simple cases, all you need to do is:
On the client, use the same port to send to the server and listen for responses;
On the server, respond to the client at the address and port that the client's packet was receieved from, using the same server port that recieved the packet;
Have the client send the initial packet in the conversation;
Don't leave the "connection" idle for more than a few minutes at a time.