I have a problem with the ip address of the mosquitto Broker. Currently I'm trying to get mosquitto Broker running locally. I used Siemens PLCSIM Virtual Ethernet Adapter as connection and set its ip address to 192.168.0.10. The version of mosquitto Broker I am using is 2.0.15. I added the following two lines of code in mosquitto.conf
listener 1883
allow_anonymous true
and enter the following command in command prompt
mosquitto.exe -c mosquitto.conf -v
After that when I tested the local connection, everything worked fine. The ip address of mosquitto Broker is the ip address of Siemens PLCSIM Virtual Ethernet Adapter, which is 192.168.0.10 I set before.
For example, I now have an actual plc and want to pass data through mosquitto Broker. Suppose the ip address of the network I am connected to is 192.168.0.103. I would like to ask, what should I do if I want to make mosquitto Broker run online instead of locally? Do I need to make any changes to the mosquitto.conf file? And if mosquitto Broker is running on the network, is the ip address of mosquitto Broker 192.168.0.103?
As configured mosquitto will bind to ALL the IP addresses on the machine it is running on, there is no need to change it's configuration at all.
You need to configure any MQTT clients that want to connect to the broker to user the IP address of what ever interface the machine running the broker is connected to the same subnet as the client device (assuming no routing is taking place)
Related
I would like to install a DHCP server in a container to provide the devices (some raspberry pis and network switches) connected to the host system with IP addresses.
I start the container with "--net=host" flag in order to listen on broadcast traffic. It is working as expected. All devices get their IP address from the DHCP server.
However, the "--net=host" option represents an increased security risk. Do you know if there is a better option to acchieve the same? I could install both docker and podman on my system.
If there is no other option, how could I restrict the visibility of the network from the container so that it can only see the specific network interface where all devices are connected?
Can I publish and subscribe message in mosquitto broker using ESP8266?? Mosquitto is used mainly for local host?
My requirement is , i have ESP 8266 and STM32 board. Can I use mosquitto as broker ??
Mosquitto is a fully functional MQTT broker.
The default configuration will bind to all available interfaces on the host so it can be reached from any host on the network that knows the correct address.
I have a Docker container, which I would like to be able to interact with a database trough a SSH tunnel.
My Docker image is built on an alpine image and in the Dockerfile I have installed openssh-client and exposed port 27017
When I spin up my Docker image and try to forward the ports with:
ssh -i /.ssh/ssh_key user#remote_ip -L 27017:localhost:27017 -Nf
I get an error:
bind: Address not available
It is not a problem to ssh into the remote server, but I am not able to forward the ports.
Thanks
I manage to create a ssh tunnel from a docker-compose using this entrypoint:
ssh -4 -i /.ssh/ssh_key -NL *:27017:0.0.0.0:27017 user#remote_ip
and then i was able to use the ssh tunnel from an another container by using the network created with the docker-compose
docker run --network=tunnel_default image nmap -p 27027 service_name
tunnel_default is the name of the network
image is a docker image where nmap is installed (it allows you to check open ports)
service_name is the name i gave to the service inside the docker-compose
You can get a "bind address not available" if you don't specify which interface you want to use. By default it will use all of them, including IPV6. In my case, it was binding on IPV4 but the "address not available" was actually for IPV6 e.g. bind [::1]:2001: Address not available. If you use the -4 option, this will use IPV4 only and if you were getting an IPV6 type error, then this will resolve that for you, which it was for me on Arch Linux.
-4 Forces ssh to use IPv4 addresses only.
-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding. This works by allocating a
socket to listen to port on the local side, optionally bound to the specified
bind_address. Whenever a connection is made to this port, the connection is forwarded
over the secure channel, and the application protocol is then used to determine where to
connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are sup‐
ported, and ssh will act as a SOCKS server. Only root can forward privileged ports.
Dynamic port forwardings can also be specified in the configuration file.
IPv6 addresses can be specified by enclosing the address in square brackets. Only the
superuser can forward privileged ports. By default, the local port is bound in accordance
with the GatewayPorts setting. However, an explicit bind_address may be used to bind the
connection to a specific address. The bind_address of “localhost” indicates that the lis‐
tening port be bound for local use only, while an empty address or ‘*’ indicates that the
port should be available from all interfaces.
Few days ago I tried to configure Kafka Docker container with Docker Compose and port mapping and discover interesting behavior which I do not fully understand:
Kafka broker seems to connect to itself. Why ?
My set up is:
Ubuntu 14.04, Docker 1.13.1, Docker-Compose 1.5.2
Kafka 0.10 listens on port 9092, this port is exposed by container.
In Docker Compose I have port mapping from container port 9092 to local port 4005.
I configured host name of my Docker Host machine and local port from Compose in advertised.listeners (docker-host:4005) since broker should be visible from my company network.
With this set up when I try to send/fetch data to/from Kafka, all attempts end up with:
Topic metadata fetch included errors: {topic_name=LEADER_NOT_AVAILABLE}
After trying various combinations of ports and host names in advertised.listeners, I discovered that sole working combination is localhost:9092. Any attempt to change hostname or port led to the error mentioned above.
This made me think that Kafka tries to connect to address configured in advertised.listeners and this is somehow related to topic metadata.
So inside Docker container I did:
redirect traffic to "docker-host" to loopback
echo "127.0.0.1 $ADVERTISED_HOST" >> /etc/hosts
configure Kafka to listen on all interfaces and port (exact as advertised)
sed -r -i "s/#(listeners)=(.*)/\1=PLAINTEXT:\/\/0.0.0.0:4005/g" $KAFKA_HOME/config/server.properties
advertise "docker-host" and external port
sed -r -i "s/#(advertised.listeners)=(.*)/\1=PLAINTEXT:\/\/$ADVERTISED_HOST:4005/g" $KAFKA_HOME/config/server.properties
And now it works like a charm.
However I still do not understand:
Why Kafka broker might need to connect to itself via address configured in advertised.listeners ?
Is there a way to disable this or at least configure it to use address from 'listeners' property (with default Kafka port) ?
UPD
Worth to mention, following setup does not work: Kafka listens on 0.0.0.0:9092, advertised listener is configured to docker-host:4005.
In this case whenever consumer or producer connects to kafka it receives LEADER_NOT_AVAILABLE.
There is also connection shown by netstat (within container) to docker-host:4005 in state SYN_SENT.
UPD 2
Looks like there is similar problem with Kafka but inside AWS described here.
Difference is that in my case I want to use different Kafka port.
UPD 3
Ok, the reason why setup mentioned in the first UPD paragraph does not work is - UFW, for some reasons it blocks traffic which goes from docker container to itself via host machine.
Why Kafka broker might need to connect to itself via address
configured in advertised.listeners ?
When a Kafka broker is first connected by a client, it replies back with the address that it expects that client to use in the future to talk to the broker. This is what is set in the advertised.listeners property. If you don't set this property, the value from listeners will be used instead (which answers your second question).
So your "issue" is, that remote clients connect to yourhost:9092, reach the Kafka broker, because you forwarded the port, the broker then responds with "you can reach me at localhost:9092" and when the client sends the next packet there it just connects back to itself.
The metadata is not really related here, its just the first request that gets made.
Your solution is correct for this setup I think, have Kafka listen on local interfaces and set the advertised.listeners to the host that someone from your company network would connect to.
I don't 100% know if the broker needs to connect to itself as well, pretty sure thats not the case though. I think your setup would also work without the entry of the external hostname in your /etc/hosts file.
Is there a way to disable this or at least configure it to use address
from 'listeners' property (with default Kafka port) ?
see above
I am currently using Ubuntu 10.04 for some rails development. It is installed as a guest machine using VirtualBox on a Windows 7 x64 host.
Within Ubuntu, I am trying to port tunnel several ports from a remote server directly to the Guest OS in order to avoid having to download a remote database.
Let's say I want to forward port 5000 on the remote server to port 5000 on the guest os.
I have set up a forwarder for the port on the Windows side, using VBoxManage.exe. This forwards HostPort 5000 to GuestPort 5000.
Then within ubuntu I run, ssh -L5000:127.0.0.1:5000. However, whenever I try to access "127.0.0.1:5000", I receive the message "channel 7: open failed: connect failed: Connection refused"
Am I missing something?
Thanks for the help!
connect failed: Connection refused
This means that you'r not able to connect to 5000 on the remote end.
If you'r only using this connection from within your guest through your SSH tunnel then you don't need the forward from VBoxManager, as this will open op so that outside computers can connect directly to your guest, it won't help your guest connect to the outside.
Are you sure the server you connect (SSH) to is the same server that runs your database? And is the database running on that server?
When you've connected (SSH) to the server, you can try to list what ports are listening for connections or you could try to connect to the database with telnet. To list listeners you can run "netstat -lnt" (-l shows listening, -n is numeric (show IP and port number) and -t is tcp). You should have a line like "tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN" if you have a service listening for TCP on port 5000. To try and connect you can simply do "telnet 127.0.0.1 5000", if you can't connect with telnet from the server then the database ain't listening/allowing your connection, or the server is running on another port or server.
SSH uses TCP traffic by default, right?
Just to verify, NAT in VirtualBox does have these limitations (per the User Manual):
There are four limitations of NAT mode which users should be aware of:
ICMP protocol limitations: Some frequently used network debugging tools (e.g. ping or tracerouting) rely on the ICMP protocol for sending/receiving messages. While ICMP support has been improved with VirtualBox 2.1 (ping should now work), some other tools may not work reliably.
Receiving of UDP broadcasts is not reliable: The guest does not reliably receive broadcasts, since, in order to save resources, it only listens for a certain amount of time after the guest has sent UDP data on a particular port. As a consequence, NetBios name resolution based on broadcasts does not always work (but WINS always works). As a workaround, you can use the numeric IP of the desired server in the \server\share notation.
Protocols such as GRE are unsupported: Protocols other than TCP and UDP are not supported. This means some VPN products (e.g. PPTP from Microsoft) cannot be used. There are other VPN products which use simply TCP and UDP.
Forwarding host ports lower than 1024 impossible: On Unix-based hosts (e.g. Linux, Solaris, Mac OS X) it is not possible to bind to ports below 1024 from applications that are not run by root. As a result, if you try to configure such a port forwarding, the VM will refuse to start.
Try ssh -L5000:0.0.0.0:5000 instead of ssh -L5000:127.0.0.1:5000
There is something called a "loopback" that is tangled up with 127.0.0.1 that will cause you grief if trying to access ports from a different machine. I.e. your host machine.