Is there a way to configure dnsmasq so that it only serves DNS requests from remote systems? What I want is that ('internet' means outside my network):
Any DNS request from a program on the dnsmasq machine just uses the internet DNS servers and ignores dnsmasq
A DNS request from a remote system directed to the dnsmasq machine receives a response from dnsmasq, which could be a locally configured response or one that dnsmasq has relayed on to the internet DNS servers
Optionally restrict the IP addresses of remote servers permitted to query the dnsmasq system.
FYI my use case is needing to patch/respond locally to requests from an embedded system to add resilience with a remote server is down; I can't change the queried hostname so I want to be able to locally spoof the IP address, but only affecting specific queries from this embedded system which I've manually directed to my local dnsmasq server.
After much digging, I stumbled across the answer. The magic incantation required to achieve this is:
$ echo DNSMASQ_EXCEPT=lo | sudo tee --append /etc/default/dnsmasq
$ sudo systemctl restart dnsmasq
Look up DNSMASQ_EXCEPT for details but basically this stops dnsmasq providing DNS services to the lo interface.
Related
I have been learning some network and system administration and encountered a puzzling problem.
SETUP:
I setup a small local offline network with a Windows Server 2019 and a Ubuntu server hosting gitea. In the Windows Server I have assigned a static IP of 169.254.0.2 and installed DNS and DHCP roles. In the Ubuntu server I have assigned a static IP of 169.254.0.3.
DNS has been configured with a primary zone funlab.abc. I created a single A record for gitea.funlab.abc. to point to 169.254.0.3. DHCP has been configured to lease addresses from 169.254.0.100 to 169.254.255.254. Subnet mask is 255.255.0.0.
PROBLEM:
With this setup, I successfully got client machines to connect to the local LAN network, transparently get a dynamic IP address, and access gitea.funlab.abc through the browser.
But in windows 10 client machines, I am unable to run ping gitea.funlab.abc in command prompt. I get an error message :
Ping request could not find host gitea.funlab.abc. Please check the name and try again
Git clone/push operations involving the URL gitea.funlab.abc also does not work.
However I can run ping -4 gitea.funlab.abc successfully. Git clone/push operations can also work if I replace the URL with the static IP. nslookup gitea.funlab.abc works correctly as well.
QUESTION:
Why is this happening? What did I misconfigure such that ping and git commands do not work?
Turns out ping and git commands works just fine when I change the IP address to 192.168.X.X. I guess windows treat the 169.254.X.X addresses differently.
I've created SSH tunnels in the past, but I'm having trouble on OSX. I'm looking to take a website's port 80, and direct it to my localhost:8080. When I run this command
ssh -L 8080:<cloud_ip_address>:80 root#<cloud_ip_address> -N
I get the default apache 'it works!' page.
Why am I not getting the port 80 of the remote machine (which is running a web app)?
UPDATE
I still do not have a solution yet, but I have some more information. The page I am getting is the default page in /var/www/html but I am serving a Flask app which does not have static pages.
Because HTTP protocol contains not only the IP address, but also the hostname (the URL you type into your browser), which differs between the <cloud_hostname> and localhost. The easiest way to trick it is to create /etc/hosts (there will be some OSX alternative -- search ...) entry redirecting the hostname of your remote machine to localhost.
127.0.0.1 <cloud_hostname>
But note that in this case you will not be able to access the remote machine using the hostname!
I am in the process of setting up a Hadoop cluster of virtual machines on my LAN and a process on one of the vms (the ResourceManager) provides a Web UI which is exhibiting strange behavior. All vms run from my desktop and have been assigned ips.
The URL I am targeting is resourcemanager:8088 and here is the behavior.
From other vms running on my desktop:
curl -v resourcemanager:8088
returns an HTTP 302 Found response with Location: http://resourcemanager:8088/cluster. Looking this up I saw this is a redirect, and curl -L resourcemanager:8088 successfully retrieves the HTML.
From the desktop running the vms:
Trying to reach the URL from (Chrome) browser gives net::ERR_CONNECTION_REFUSED. Also
curl resourcemanager:8088
returns curl: (7) Failed to connect to resourcemanager port 8088: Connection refused.
Each vm has the same /etc/hosts:
::1 localhost
127.0.0.1 localhost
10.0.0.3 namenode
10.0.0.4 resourcemanager
10.0.0.5 datanode1
and the .../drivers/etc/hosts file on my (Windows) desktop looks the same minus the localhost lines.
To make matters more complicated, a second process (the NameNode) also provides a web ui, call it namenode:50070, and I am able to curl it from both the desktop and vms, and I can get to it via browser from my desktop.
Any ideas?
EDIT
Specs:
Desktop OS: Windows 10
VMs OS: Arch Linux latest (Linux kernel 4.5.4)
An initial Arch+hadoop VM was created with Hyper-V, then cloned to create the three "cluster" vms listed above. After cloning, each vm was given a unique hostname (listed above) and assigned a reserved IP address from my router (also listed above). All VMs use an "external vm switch".
I cannot comment, because I do not have 50 reputation yet, but that might have to do with the configuration of the service behind port 8088: The VM probably got a 'small' netmask from the virtual dhcp server, which presumably covered the IP range of all other VMs, not including the host machine. If that had happened and the service was configured like many others -to listen on all interfaces- it would not react on requests and your connection would reach a closed port, causing a 'connection refused' error. How is that?
I have my Single node Hadoop installed on Google Compute Engine instance and i want to open port 50070 on that machine to access the hadoop dashboard. i configured in the firewall rule as tcp:50070 in compute engine networks. but still i am unable to access my port outside the network (ie . via internet). I tried nmap for the public ip of my GCE instance and i got a result which has only ssh port got opened all other ports are filtered .
Note: i am using debian 7.5 image
Make sure your daemon is listening on port 50070. If you have more than one networks in you project make sure the port is opened on the right network. You can run the following commands to check the information about your instance and network.
lsof -i
gcutil --project= getinstance
gcutil --project= listnetworks
gcutil --project= listfirewalls
gcutil --project= getfirewall
Check if IP/Port is allowed in iptables or not.
iptables -L
would show you all the records.
To allow port in iptables you can do the following:
sudo iptables -A INPUT -p tcp -m tcp --dport 50070 -j ACCEPT
sudo iptables-save -c
Short answer
In addition to configure the firewall rule at GCE web console make sure that your server is listening at 0.0.0.0 instead of 127.0.0.1
Long answer
In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs - Source
In contrast 127.0.0.1 is the IP address used to stablish a connection to the same machine used by the user this address is usually referred as the localhost.
It's often used when you want a network-capable application to only serve clients on the same host. A process that is listening on 127.0.0.1 for connections will only receive local connections on that socket. - Source
Hence, if you try to stablish a connection to your server from internet and your server is listening at 127.0.0.1 at your GCE machine, then, from the server point of view a request has never been received and as a consequence Goocle Cloud Firewall will refuse the connection because there is no server listening at the opened port (in your case 50070).
I hope this answer helps to solve your problem. Best regards.
This is a very basic Amazon EC2 question, but I'm stumped so here goes.
I want to launch an Amazon EC2 instance and allow access to HTTP on ports 80 and 8888
from anywhere. So far I can't even allow the instance to connect to on those ports using
its own IP address (but it will connect to localhost).
I configured the "default" security group for HTTP using the standard HTTP option on the management console (and also SSH).
I launched my instance in the default security group.
I connected to the instance on SSH port 22 twice and in one window launch an HTTP server
on port 80. In the other window I verify that I can connect to HTTP using the "localhost".
However when I try to access HTTP from the instance (or anywhere else) using either the public DNS or the Private IP address I het "connection refused".
What am I doing wrong, please?
Below is a console fragment showing the wget that succeeds and the two that fail run from the instance itself.
--2012-03-07 15:43:31-- http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: /__whiff_directory_listing__ [following]
--2012-03-07 15:43:31-- http://localhost/__whiff_directory_listing__
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “__whiff_directory_listing__”
[ <=>
] 7,512 --.-K/s in 0.03s
2012-03-07 15:43:31 (263 KB/s) - “__whiff_directory_listing__” saved [7512]
[ec2-user#ip-10-195-205-30 tmp]$ wget http://ec2-50-17-2-174.compute-1.amazonaws.com/
--2012-03-07 15:44:17-- http://ec2-50-17-2-174.compute-1.amazonaws.com/
Resolving ec2-50-17-2-174.compute-1.amazonaws.com... 10.195.205.30
Connecting to ec2-50-17-2-174.compute-1.amazonaws.com|10.195.205.30|:80... failed:
Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$ wget http://10.195.205.30/
--2012-03-07 15:46:08-- http://10.195.205.30/
Connecting to 10.195.205.30:80... failed: Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$
The standard tcp sockets interface requires that you bind to a particular IP address when you send or listen. There are a couple of somewhat special addresses: localhost (which you're probably familiar with) which is 127.0.0.1. There's also a special address, 0.0.0.0 or INADDR_ANY (internet protocol, special shorthand for ANY ADDRESS). It's a way to listen on ANY or more commonly, ALL addresses on the host. This is a way to tell the kernel/stack that you're not interested in a particular IP address.
So, when you're setting up a server that listens to "localhost" you're telling the service that you want to use the special reserved address that can only be reached by users of this host, and while it exists on every host, making a connection to localhost will only ever reach the host you're making the request from.
When you want a service to be reachable everywhere (on a local host, on all interfaces, etc.) you can specify 0.0.0.0.
(0) It's silly but the first thing you need to do is to make sure that your web server is running.
(1) You need to edit your Security Group to let incoming HTTP packets access your website. If your website is listening on port 80, you need to edit the Security Group to open access to port 80 as mentioned above. If your website is listening on some other port, then you need to edit the Security Group to access that other port.
(2) If you are running a Linux instance, the iptables firewall may be running by default. You can check that this firewall is active by running
sudo service iptables status
on the command line. If you get output, then the iptables firewall is running. If you get a message "Firewall not running", that's pretty self-explanatory. In general, the iptables firewall is running by default.
You have two options: knock out the firewall or edit the firewall's configuration to let HTTP traffic through. I opted to knock out the firewall as the simpler option (for me).
sudo service iptables stop
There is no real security risk in shutting down iptables because iptables, if active, merely duplicates the functionality of Amazon's firewall, which is using the Security Group to generate its configuration file. We are assuming here that Amazon AWS doesn't misconfigure its firewalls - a very safe assumption.
(3) Now, you can access the URL from your browser.
(4) The Microsoft Windows Servers also run their personal firewalls by default and you'll need to fix the Windows Server's personal firewall, too.
Correction: by AWS default, AWS does not fire up server firewalls such iptables (Centos) or UAF (Ubuntu) when you are ordering the creation of new EC2 instances - That's why EC2 instances that are in the same VPC can ssh into each other and you can "see" the web server that you fired up from another EC2 instance in the same VPC.
Just make sure that your RESTful API is listening on all interfaces i.e. 0.0.0.0:portID
As you are getting connection refused (packets are being rejected) I bet it is iptables causing the problem. Try to run
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
and test the connection.
You will also need to add those rules permanently which you can do by adding the above lines into ie. /etc/sysconfig/iptables if you are running Red Hat.
Apparently I was "binding to localhost" whereas I needed to bind to 0.0.0.0 to respond to port 80 for the all incoming TCP interfaces (?). This is a subtlety of TCP/IP that I don't fully understand yet, but it fixed the problem.
Had to do the following:
1) Enable HTTP access on the instance config, it wasn't on by default only SSH
2) Tried to do nodejs server, so port was bound to 80 -> 3000 did the following commands to fix that
iptables -F
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo service iptables-persistent flush
Amazon support answered it and it worked instantly:
I replicated the issue on my end on a test Ubuntu instance and was able to solve it. The issue was that in order to run Tomcat on a port below 1024 in Ubuntu/Unix, the service needs root privileges which is generally not recommended as running a process on port 80 with root privileges is an unnecessary security risk.
What we recommend is to use a port redirection via iptables :-
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
I hope the above information helps.