mysterious proxy se...
 
Notifications
Clear all

mysterious proxy settings: proxying to the blind port 8742

3 Posts
2 Users
0 Likes
314 Views
 KAV
(@kav)
Joined: 1 year ago
Posts: 7
Topic starter  

Carbonio CE 23.3.0

Installation according to the instructions in the https://docs.zextras.com/carbonio-ce/html/multi-server-installation.html documentation

 

In Proxy server config file /opt/zextras/conf/nginx/includes/nginx.conf.web:

 

# Define the collection of upstream HTTP servers to dedicated zx port of jetty
upstream zx
{
server ip1:8742 fail_timeout=125s max_fails=5;
server ip2:8742 fail_timeout=125s max_fails=5;

zmauth_zx;
}

# Define the collection of upstream HTTPS servers to dedicated zx ssl port of jetty
upstream zx_ssl
{
server ip1:8743 fail_timeout=125s max_fails=5;
server ip2:8743 fail_timeout=125s max_fails=5;

zmauth_zx;
}

 

Accessing these upstream is specified in nginx.conf.web.https.default:

 

location ^~ /zx/ws-
{
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://zx;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $http_host;
proxy_http_version 1.1;
}

location ^~ /zx/
{
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header Host $http_host;
proxy_pass http://zx;
}

 

As a result, nginx.log:

 

[info] 314319#314319: *320 client closed connection while SSL handshaking, client: 127.0.0.1, server: 0.0.0.0:443
info] 314319#314319: *321 client closed connection while SSL handshaking, client: 127.0.0.1, server: 0.0.0.0:443

[error] 314319#314319: *306 upstream timed out (110: Connection timed out) while connecting to upstream, client: INTERNALIP, server: , request: "GET /zx/login/v3/config?domain=PROXY_INTERNAL_FQDN HTTP/1.1", upstream: "http://APPSERVER_INTERNAL_FQDN:8742/zx/login/v3/config?domain=PROXY_INTERNAL_FQDN", host: "PROXY_INTERNAL_FQDN:6071", referrer: "https://PROXY_INTERNAL_FQDN:6071/carbonioAdmin/dashboard"

[error] 314319#314319: *308 upstream timed out (110: Connection timed out) while connecting to upstream, client: INTERNALIP, server: , request: "GET /zx/auth/supported HTTP/1.1", upstream: "http://APPSERVER_INTERNAL_FQDN:8742/zx/auth/supported", host: "PROXY_INTERNAL_FQDN:6071", referrer: "https://PROXY_INTERNAL_FQDN:6071/carbonioAdmin/dashboard"

[info] 314319#314319: *324 client closed connection while SSL handshaking, client: 127.0.0.1, server: 0.0.0.0:443
[info] 314319#314319: *325 client closed connection while SSL handshaking, client: 127.0.0.1, server: 0.0.0.0:443

 

the specified ports 8742, 8743 are not listed in the documentation Requirements — Zextras Carbonio CE Documentation
no one is listening on these ports on the application servers
as a result -  opening the pages takes 40 seconds

 

commenting on these lines in nginx conf files  does not give a result, because after rebooting the proxy ("zmproxyctl restart") they are restored

 

The question is - why are they needed and how to disable this upstreams settings?

This topic was modified 1 year ago by KAV

   
Quote
(@stefanodavid)
Joined: 3 years ago
Posts: 153
 

@Kav

sorry for the late reply, we're busy with 23.4 docs.

 

You are right, these ports are not listed in the requirements. We are in the process of updating that list, which will be published later today as part of Carbonio release.

 

Ports 8742 and 8743 are used by mailboxd for internal HTTP and HTTPS communication (that's why they are in nginx configuration), respectively. mailboxd requires also other ports to be openend for its correct operativity. If you run from the cli command 

# netstat -pnlt|grep 874
tcp        0      0 0.0.0.0:8742            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:8743            0.0.0.0:*               LISTEN      624470/java     

The output will include also a PID (624470), if you grep on that number you can find the full list:

# netstat -pnlt|grep 624470
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:7025            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:7993            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 xx.xx.xx.xx:8730        0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:7995            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:8735            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:7071            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 xx.xx.xx.xx:8736        0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:7072            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:7073            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:8388            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:8742            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:7110            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:8743            0.0.0.0:*               LISTEN      624470/java         
tcp        0      0 0.0.0.0:7143            0.0.0.0:*               LISTEN      624470/java 

As mentioned in the docs, these ports are for internal communication only, so you can block access to them from any other IP using firewall rules, if you are on a Single-Server.

On a Multi-Server, though, you need to allow access to these ports (an to all other in the internal communication table) from all other nodes, because services needed by mailboxd may be running on other nodes (depending on your setup).


   
ReplyQuote
 KAV
(@kav)
Joined: 1 year ago
Posts: 7
Topic starter  

Yes thank you
I have a multi-server installation. Firewall blocking of ports on servers with AppServer installed helped.

I found yet another solution - using zmprov to set the zimbraChatServiceEnabled = False...

And when the chat is implemented in the future, the main thing is not to forget to turn this parameter back on))


   
ReplyQuote