VirtualBox - komputer nie może się połączyć z konsolą ActiveMQ na drugim komputerze

Dla specjalistów Sieci komputerowe
#1

Mam na komputerze dwie maszyny, postawione na wirtualbox: Linux Mint i CentOS8 jako serwer.
Na CentOS uruchomiłem activeMQ, niestety z poziomu Minta nie mogę połączyć się z jego konsolą.
Z Minta na CentOS bez problemu robię ssh, ping działa, zrobiłem nawet tunel do tej usługi:
ssh -nNT -L 8161:localhost:8161 admin@10.0.2.20
I to zadziałało. Udało mi się dobić na adres:
http://localhost:8161/admin/topics.jsp

Gdzie mogłem zrobić błąd w konfiguracji? Wyłączyłem firewall na centos, maszyny znajdują się w sieci NAT.

#2

Zgaduję. Jest firewall na CentOS8 z otwartym jedynie portem SSH? W takiej sytuacji można tunelować dowolny port po tak naprawdę wszystko idzie przez 22, dlatego przez tunel działa. Zobacz czy tak systemctl status firewalld i ewentualnie wyłącz systemctl stop firewalld, zobacz czy coś zmieni. Jak tak to dodaj port activeMQ do dozwolonych.

Jeżeli nie firewall to może activeMQ (akurat nie znam) ma gdzieś ustawione, że można łączyć się tylko z localhost. Tunelowany port przychodzi z localhost.

#3

Moim zdaniem firewall jest wyłączony:
[root@localhost bin]# systemctl status firewalld

● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

Spróbuje jeszcze zainstalować Debiana/Ubuntu i zobaczyć czy na nich uruchomię i połączę z ActiveMQ.

#4

Sprawdziłbym jeszcze netstat’em czy ActiveMQ nasłuchuje na karcie sieciowej czy może jedynie na localhost.

#5

Nie widzę tu nic złego. Nawet zmieniłem z tcp6 na tcp, ale nie pomogło:

[activemq@localhost bin]$ netstat -an | grep 8161
tcp6 0 0 127.0.0.1:8161 :::* LISTEN
[activemq@localhost bin]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:77:fc:51 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.20/24 brd 10.0.2.255 scope global dynamic noprefixroute enp0s3
valid_lft 572sec preferred_lft 572sec
inet6 fe80::2c2b:a375:59d8:6f45/64 scope link noprefixroute
valid_lft forever preferred_lft forever

#6

Z tego co widzę, to usługa nasłuchuje jedynie na loopback tj 127.0.0.1 (w tym przypadku tylko na IPv6, więc dobrze że zmieniłeś na tcp i tak zostaw, chyba że łączysz się po IPv6)

[activemq@localhost bin]$ netstat -an | grep 8161
tcp6 0 0 127.0.0.1:8161 :::* LISTEN

Dlatego gdy tunelujesz port przez SSH to działa, bo połączenie nawiązuje się lokalnie za pośrednictwem lokalnie uruchomionego SSH. Natomiast gdy starasz się połączyć poprzez swój interfejs sieciowy tj enp0s3 na IP 10.0.2.20 to nie działa, ponieważ usługa nie nasłuchuje na tym interfejsie.

Prosty test. Zrób na CentOS nmap 127.0.0.1 -p 8161 oraz nmap 10.0.2.20 -p 8161. Ten pierwszy zwróci działającą usługę a ten drugi powie, że na tym porcie nic nie ma. Musisz poczytać dokumentację activeMQ i dowiedzieć się jak zrobić, żeby ten nasłuchiwał np na wszystkich interfejsach (0.0.0.0:port w netstat).

Możesz to zobaczyć na przykładzie np SSH. Możesz do CentOS zalogować się po SSH tylko dlatrego że SSH słucha domyślnie na wszystkim, w tym Twoim enp0s3/10.0.2.20

Zrób test z powyższymi przykładami nmap ale sprawdź SSH (port 22). Zobacz też jak SSH prezentuje się w netstat.

#7

Dzięki wielkie za pomoc. Nie znałem nmap- czegoś nowego się dowiedziałem i bardzo przydatnego.

Tak wygląda, po wykonaniu twoich komend. Chyba miałeś racje.

[activemq@localhost bin]$ nmap 127.0.0.1 -p 8161
Starting Nmap 7.70 ( https://nmap.org ) at 2020-11-01 14:19 CET
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00022s latency).

PORT STATE SERVICE
8161/tcp open patrol-snmp

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
[activemq@localhost bin]$ nmap 10.0.2.20 -p 8161
Starting Nmap 7.70 ( https://nmap.org ) at 2020-11-01 14:19 CET
Nmap scan report for 10.0.2.20
Host is up (0.00015s latency).

PORT STATE SERVICE
8161/tcp closed patrol-snmp

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

#8

Proszę bardzo :slight_smile: myślę ze to będzie rozwiązanie Twojego problemu:

#9

Dokładnie, to jest rozwiązanie.
Wcześniej była warość

Nie wiem czy jest to rozwiązanie “koszerne”, ale na moje zabawy wystarczające. Dzięki jeszcze raz za pomoc.

#10

Cieszę się, że problem rozwiązany :slight_smile: Z tego co widzę to jest jeszcze kilka narzędzi, które tu nazywają się “External Web Consoles” https://activemq.apache.org/web-console (na dole strony). One pewnie łączą się do portu 61616 ActiveMQ, który zakładam, że domyślnie słucha na wszystkich interfejsach https://activemq.apache.org/getting-started -> Listenport.

To co robiłeś na początku, czyli tunelowanie portu przez SSH to też bardzo dobre rozwiązanie w przypadku gdy serwer wystawiony jest do Internetu. Gdyby ktoś chciał wykorzystać jakąś lukę w konsoli i się włamać, to nie będzie mógł. Nawet nie rozpocznie połączenia bo konsola nie słucha na interfejsie przez który serwer podłączony jest do świata. Za to dla Ciebie konsola będzie dostępna poprzez przetunelowany port. Wszystko dzięki temu, że słucha ona tylko na 127.0.0.1.

Miłej zabawy.

#11

Masz racje, ten port nasłuchuje wszędzie:

[admin@localhost ~]$ netstat -an | grep 61616
tcp6 0 0 :::61616 :::* LISTEN

Myślałem że to jakiś problem z konfiguracją os’a itp, ponieważ kiedyś jak zainstalowałem activemq na innej maszynie, to bez problemu połączyłem się webgui- widać w między czasie zmienili to :slight_smile: .