Thanks in advance.
In Azure. I created a container registry with marketplace image: RabbitMQ packaged by Bitnami.
Created an App Service from the container registry.
Add the WEBSITES_PORT: 15672 configuration.
I can open the RabbitMQ management from the App Service without problem.
But I can't connect the client to rabbitMQ I tried all ports, 5672 especially but it wont work.
Please help me.
Best regards
If the necessary ports are not open on the rabbitmq ,you get this "No route to host" error
when the client tries to connect, make sure the ports are open, if not, open them like below:
sudo iptables -I INPUT -p tcp --dport 5672 --syn -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 5673 --syn -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 15672 --syn -j ACCEPT
This is for temporarily, try to set it on permanently in your iptables
sudo vi /etc/sysconfig/iptables
Then restart:
sudo service iptables restart
Or try to stop and restart your rabbit as given below
sudo rabbitmqctl stop
sudo invoke-rc.d rabbitmq-server start
For more information in detail, please refer below links:
https://www.rabbitmq.com/management.html
https://www.rabbitmq.com/troubleshooting-networking.html
https://www.linkedin.com/pulse/how-set-up-rabbitmq-cluster-azure-akshay-kunila
RabbitMQ trigger for Azure Functions | Microsoft Docs
Related
Operating system : ubuntu 16.04 LTS ,here's my problem.
Recently I'm building a application rely on a Redis(Docker) offered data service. A customary way of creating new Redis service is kind of like this:
docker pull redis:latest
docker run -d --name redis -p 6379:6379 redis:latest
Assuming my WAN IP is 201.201.201.201 ,then it should just fine to access Redis via address:201.201.201.201:6379.
However this approach exposes a redis server's port to public network ,even though you can give a supper long password ,potential safety hazard remains.
Since docker do not support port mapping changing within a running container ,I need to shut down the whole docker service ,that takes a long time ,nearly impossible.
Then I'm trying to use IP table mapping instead of creating a docker map ,due to iptables 's flexibility ,theoretically it allows benefits from both sides -- uoload files from wherever else in the world(out side zz) ,but can also close this
iptables -t nat -A PREROUTING -d 172.245.210.199 -p tcp --dport 6379 -j DNAT --to-destination 172.17.0.5:6379
iptables -t nat -A POSTROUTING -d 172.17.0.5 -p tcp --dport 6379 -j SNAT --to 172.17.0.1
But it do not work ,I can't ping container 17.17.0.162
Does anyone knows resolution ,or could propose some other ways to implement this port mapping (such as nginx or caddy?)
Thanks!
What I suggest is to use an assistant container, in this container add port forward for your service container which did not do port mapping:
docker run -idt --link redis -p 6379:6379 alpine/socat TCP4-LISTEN:6379,fork,reuseaddr TCP4:redis:6379
Above container will use --link redis so it can resolve the name of your redis container, and when receive the traffic from host's 6379, it will first forward to assistant container's 6379, then will use socat to forward the traffic to the redis container's 6379, so it works although your service container did not port mapping 6379.
As --link was deprecated, you can also customize your network, as you like:
docker network create my_network
docker network connect my_network redis
docker run -idt --network my_network -p 6379:6379 alpine/socat TCP4-LISTEN:6379,fork,reuseaddr TCP4:redis:6379
I use docker-compose on ubuntu 18 on remote server.
How, with iptables, can i block access from the internet to the docker port and only allow access to it from the localhost of this server?
For instance, i want to block 4150 port for internet. Trying this:
iptables -A DOCKER-USER -p tcp --dport 4150 -j DROP does not block the port - still can access to it from the internet (not from server machine).
How can i block access from internet to all ports that are on the server, but allow only 22,80 ? And keep that ports available from localhost of the server (eg from the server itself) ?
Not the IPTables based solution you're looking for, but a much simpler solution is to only publish to a specific interface, instead of all interfaces. And when that interface is the loopback interface, e.g. 127.0.0.1, you'll only be able to access the port locally. To do this, add the interface to the beginning of the publish spec:
docker run -p 127.0.0.1:4150:4150 ...
Or a similar syntax in the compose file:
...
ports:
- 127.0.0.1:4150:4150
...
As for why the command you tried using didn't work, this needs conntrack to get the original port rather than the docker mapped port:
iptables -I DOCKER-USER -p tcp -m contrack --ctorigdstport 4150 -j DROP
This also changed from -A (append) to -I (insert) because there's a default rule to accept everything in that list.
I've setup a CentOS 6.3 Box in a VirtualBox Machine, installed node.js and npm and wrote an example 'Hello World' Application which listens on port 8080 and IP '192.168.10.132' (this is the IP of the CentOS machine). The server starts correctly, but under 192.168.10.132:8080 on my host machine (Mac OS X 10.0.7) I always get an error.
Did I something wrong?
Generally I run into issues like this because I have not opened the port in iptables.
The following command will add the port to iptables
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 8080 -j ACCEPT -m comment --comment "node.js port"
Then make sure to save your current config.
service iptables save
then you'll need to restart iptables
service iptables restart
For more info, check out the iptables docs here: http://wiki.centos.org/HowTos/Network/IPTables
I've booted up a CentOS server on rackspace and executed yum install httpd'd. Then services httpd start. So, just the barebones.
I can access its IP address remotely over ssh (22) no problem, so there's no problem with the DNS or anything (I think...), but when I try to connect on port 80 (via a browser or something) I get connection refused.
From localhost, however, I can use telnet (80), or even lynx on itself and get served with no problem. From outside (my house, my school, a local coffee shop, etc...), telnet connects on 22, but not 80.
I use netstat -tulpn (<- I'm not going to lie, I don't understand the -tulpn part, but that's what the internet told me to do...) and see
tcp 0 0 :::80 :::* LISTEN -
as I believe I should. The httpd.conf says Listen 80.
I have services httpd restart'd many a time.
Honestly I have no idea what to do. There is NO way that rackspace has a firewall on incoming port 80 requests. I feel like I'm missing something stupid, but I've booted up a barebones server twice now and have done the absolute minimum to get this functioning thinking I had mucked things up with my tinkering, but neither worked.
Any help is greatly appreciated! (And sorry for the long winded post...)
Edit
I was asked to post the output of iptables -L. So here it is:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
In case not solved yet. Your iptables say:
state RELATED,ESTABLISHED
Which means that it lets pass only connections already established... that's established by you, not by remote machines. Then you can see exceptions to this in the next rules:
state NEW tcp dpt:ssh
Which counts only for ssh, so you should add a similar rule/line for http, which you can do like this:
state NEW tcp dpt:80
Which you can do like this:
sudo iptables -I INPUT 4 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
(In this case I am choosing to add the new rule in the fourth line)
Remember that after editing the file you should save it like this:
sudo /etc/init.d/iptables save
CentOS 7 uses firewalld by default now. But all the answers focus on iptables. So I wanted to add an answer related to firewalld.
Since firewalld is a "wrapper" for iptables, using antonio-fornie's answer still seems to work but I was unable to "save" that new rule. So I wasn't able to connect to my apache server as soon as a restart of the firewall happened. Luckily it is actually much more straightforward to make an equivalent change with firewalld commands. First check if firewalld is running:
firewall-cmd --state
If it is running the response will simply be one line that says "running".
To allow http (port 80) connections temporarily on the public zone:
sudo firewall-cmd --zone=public --add-service=http
The above will not be "saved", next time the firewalld service is restarted it'll go back to default rules. You should use this temporary rule to test and make sure it solves your connection issue before moving on.
To permanently allow http connections on the public zone:
sudo firewall-cmd --zone=public --permanent --add-service=http
If you do the "permanent" command without doing the "temporary" command as well, you'll need to restart firewalld to get your new default rules (this might be different for non CentOS systems):
sudo systemctl restart firewalld.service
If this hasn't solved your connection issues it may be because your interface isn't in the "public zone". The following link is a great resource for learning about firewalld. It goes over in detail how to check, assign, and configure zones: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7
SELinux prevents Apache (and therefore all Apache modules) from making remote connections by default.
# setsebool -P httpd_can_network_connect=1
Try with below setting in iptables.config table
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
Run the below command to restart the iptable service
service iptables restart
change the httpd.config file to
Listen 192.170.2.1:80
re-start the apache.
Try now.
If you are using RHEL/CentOS 7 (the OP was not, but I thought I'd share the solution for my case), then you will need to use firewalld instead of the iptables service mentioned in other answers.
firewall-cmd --zone=public --add-port=80/tcp --permanent
firewall-cmd --reload
And then check that it is running with:
firewall-cmd --permanent --zone=public --list-all
It should list 80/tcp under ports
Search for LISTEN directive in the apache config files (httpd.conf, apache2.conf, listen.conf,...) and if you see localhost, or 127.0.0.1, then you need to overwrite with your public ip.
Try disabling iptables: service iptables stop
If this works, enable TCP port 80 to your firewall rules:
run system-config-selinux from root, and enable TCP port 80 (HTTP) on your firewall.
this would work:
-- for REDHAT
use : cat "/etc/sysconfig/iptables"
iptables -I RH-Firewall-1-INPUT -s 192.168.1.3 -p tcp -m tcp --dport 80 -j ACCEPT
followed by
sudo /etc/init.d/iptables save
this is what worked for us to get the apache accessible from outside:
sudo iptables -I INPUT 4 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
sudo service iptables restart
Set apache to list to a specific interface and port something like below:
Listen 192.170.2.1:80
Also check for Iptables and TCP Wrappers entries that might be interfering on the host with outside hosts accessing that port
Binding Docs For Apache
Disable SELinux
$ sudo setenforce 0
Has anyone installed OpenFire on Windows Azure before?
Is it easy to create another instance with the OpenFire in it?
Thanks!
Yes, I've installed openFire on both EC2 (Linux) and Azure. It is a painless as you could imagine.
get a VM
install java
install openfire
install openfire db to SQL azure (connection string syntax below)
jdbc:jtds:sqlserver://SQLAzInstance.database.windows.net:1433/OpenFireSqlDBName;ssl=require
be sure to allow proper ports through the endpoints tab of the virtual machine in the new azure management portal
TCP 5222/5223 (std/SSL client connectivity)
TCP 5269 (server-to-server)
TCP 9090 (default openfire web ui port, you could change this)
Log into your Windows Azure account.
Create a Machine running Ubuntu 14 LTS
Then go to your SSH client (for Mac and Linux users, you can use the terminal by typing
ssh username#servername e.g. ssh joel#chatserver.cloudapp.net ) and for Windows users, you can install PuTTy SSH client which comes with BitVise.
log in as an admin by typing
sudo su
then update the sever by typing
apt-get update
then check for any new releases by typing
apt-get upgrade
Then check if java is installed (it is usually not installed anyway) by typing
java -version
if it is not installed, install it by typing
apt-get install default-jre
accept it to install by typing y to mean yes
wait for it to install
then install openfire by first downloading it. You use the wget command to download it directly to your server as below. (at the time of writing, openfire 3.9.3 is the latest version)
wget -O openfire.deb http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire_3.9.3_all.deb
Then after it has finished downloading, install it by typing
dpkg --install openfire.deb
Before you go to the browser, go to your Windows Azure dashboard
Click on the Virtual Machine you have created
Then click on Endpoints
Add the following end points, they are all of TCP type
Public Port 5222, Private Port 5223 and this is for SSL connectivity
Public Port 5269 and Private port 5269 and this is for server to server connectivity
Public Port 9090 and private port 9090 and this is for openfire web UI
After all this, you are good to go,
Go to your browser and type in your server url and at the end put 9090 e.g.
chatserver.cloudapp.net:9090
Hope that helped and happy chatting!!
To user default port such as 80 and 443 (replace 5222 and 5223 with 80 and 443 ) use following commands to redirect traffic on linux machine.
iptables -A INPUT -i eth0 -p tcp --dport 5222 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 5222
iptables -A INPUT -i eth0 -p tcp --dport 5223 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 5223