Zimbra Proxy Manual:Overview And Planning For Zimbra Proxy

Zimbra Proxy: Overview And Planning For Zimbra Proxy

   KB 21170        Last updated on 06/7/2016  




0.00
(0 votes)
Article-check.png  - This is certified documentation and is protected for editing by Zimbra Employees & Moderators only.
 - This article is a Work in Progress, and may be unfinished or missing sections.

Source: http://wiki.zimbra.com/wiki/Zimbra_Proxy_Guide

What Is Zimbra Proxy

Source:

* Needs to be proofed.

* Make references to pop,imap,http as IMAP[S]/POP[S]/HTTP[S]

Zimbra Proxy is a high-performance reverse proxy server for passing IMAP[S]/POP[S]/HTTP[S] client requests to other internal ZCS services. A reverse proxy server is an Internet-facing server that protects and manages client connections to your internal services. It can also provide functions like: GSSAPI authentication, throttle control, SSL connection with different certificates for different virtual host names, and other features described later below. When discussing reverse proxy topics, you'll see references to downstream and upstream. Downstream is in reference to the end-user client and the software/computer they are using. Upstream is in reference to the actual server or service that actually handles the request - often times this is the Zimbra mailstore or webapp server the users account resides on.


The Zimbra Proxy services allows other Zimbra services [mailbox, webapp, etc.] that can be hidden from the Internet by acting as a reverse proxy for the other services and allows end-users to access the mail system via a single Login URL [for example, userA and userB can both use mail.domain.com] instead of knowing their specific mailbox hostnames [for example, userA uses mail12.domain.com and userB is uses mail13.domain.com]. It acts as the first entry point for all the HTTP/IMAP/POP traffic and then intelligently routes all static UI (HTML/CSS/JS etc) and dynamic (SOAP/REST/IMAP/POP) requests to the appropriate upstream server. The proxy configuration options for POP/IMAP allows end users to configure their POP/IMAP clients to use this single mail server hostname. The proxy configuration options around HTTP[S] allows end-users to use this single hostname for ZWC, REST, CalDAV, Zimbra Connector for Outlook, Zimbra Connector for BES, Zimbra Mobile Sync connections and so forth. The Zimbra Proxy service will also do URL rewriting so these internal hostnames that are providing the various services aren't exposed to the public or end-clients. For example, a Zimbra briefcase share from userA on mail12.domain.com to userB on mail13.domain.com will simply have mail.domain.com [per our example above] within the url. [ see bug 82236 ]


With ZCS 8.5, the proxy components are installed by default and therefore would be enabled on a single ZCS server deployment. Normally though, the proxy services would be installed on Internet-facing servers and the other specific ZCS services [zimbra-store for example] would be on installed on internal servers. Generally, these packages are installed on dedicated Internet-facing servers intended to just do the proxy services or those that also run the zimbra-mta package. When the Zimbra Proxy package is installed, the proxy feature is enabled with default values that normally require no modification.


The Zimbra Proxy installation components consists of the zimbra-proxy and zimbra-memcached options during the installation package choice menu. The zimbra-proxy packages is Zimbra’s modified version of Nginx [1] (pronounced “engine-ex”). And the zimbra-memcached packages is our modified version of memcached [2], (pronounced “memcache-dee”). A third component needed for our proxy environment to work is the Zimbra Proxy Route Lookup Handler or called the “Nginx Lookup Extension” (NLE for short) if some other references. This is a java servlet that is installed from the zimbra-store package on the Zimbra mailbox servers. This servlet handles nginx queries for the user account route information (the server and port number where the user account resides).


In a typical use case, the proxy services extracts the user login details and then fetches the route to the upstream mail server or web servers’ address from the Zimbra Proxy Route Lookup Handler [the NLE servlet], and finally proxies the interactions between clients and upstream ZCS servers. To accelerate the speed of future route lookups for a user, memcached caches the lookup results. Therefore, the subsequent login with the same username will directly be proxied without calling to the Zimbra Proxy Route Lookup Handler.

Benefits And Reasons To Use

Source http://wiki.zimbra.com/wiki/Zimbra_Proxy_Guide#Benefits_and_reasons_to_use

* Needs to be proofed.

  1. Zimbra Proxy centralizes access to Mailbox servers
    • Zimbra Proxy allows mailbox servers to be hidden from public internet by acting as a reverse proxy & also allowing end users to access mail system via single Login URL instead of knowing their mailbox hostnames. It acts as the first entry point for all the IMAP[S]/POP[S]/HTTP[S] traffic and then intelligently routes all kind of static UI requests (HTML/CSS/JS etc) and Dynamic requests (SOAP/REST/IMAP/POP) to the appropriate upstream server. Here are some other benefits of using the proxy as well
  2. Load Balancing
    • This is the reverse proxy function that people are most familiar with. Here the proxy routes incoming HTTP requests to a number of identical mail servers. The upstream mail server selection can be based on a simple client IP hash or round-robin algorithm. It’s such a common function that load balancing reverse proxies are usually just referred to as ‘load balancers’. There are specialized load balancing products available, but many general purpose reverse proxies also provide load balancing functionality.
  3. Security
    • A reverse proxy can hide the topology and characteristics of your back-end servers by removing the need for direct internet access to them. You can place your reverse proxy in an internet facing DMZ, but hide your web servers inside a non-public subnet.
  4. Authentication
    • You can use your reverse proxy to provide a single point of authentication for all HTTP requests. Although in case of ZCS, the authentication is provided by upstream mailstores where the user accounts reside.
  5. SSL Termination
    • Here the reverse proxy handles incoming HTTPS connections, decrypting the requests and passing unencrypted requests on to the web servers.
  6. Caching
    • Currently we use the memcached module with proxy to achieve caching of upstream routes to mailstores on a per end-client basis. This significantly reduces the route lookup time thereby improving the total time required to process the request and boost performance.
  7. Centralized Logging and Auditing
    • Because all HTTP requests are routed through the reverse proxy, it makes an excellent point for logging and auditing.
  8. URL Rewriting
    • Sometimes the URL scheme that a legacy application presents is not ideal for discovery or search engine optimization. A reverse proxy can rewrite URLs before passing them on to your back-end servers. To an external customer it appears that they are simply navigating a single website, but internally the organisation is maintaining three entirely separate sites. This approach can work extremely well for web service APIs where the reverse proxy provides a consistent single public facade to an internal distributed component oriented architecture.

Zimbra Proxy Components

Source: http://wiki.zimbra.com/wiki/Zimbra_Proxy_Guide#Zimbra_Proxy_Components

* Needs to be proofed.

* Use style guide for hostname references.

Zimbra Proxy is designed to provide a HTTP/POP/IMAP proxy that is quick, reliable, and scalable. Zimbra Proxy includes the following:

  • Nginx. A high performance IMAP[S]/POP[S]/HTTP[S] proxy server which handles all incoming IMAP[S]/POP[S]/HTTP[S] requests.
  • Memcached. A high performance, distributed memory object caching system. Route information is cached for further use in order to increase performance.
  • Zimbra Proxy Route Lookup Handler. This is a servlet, Nginx Lookup Extension (NLE), located on the ZCS mailbox server - accessed by http://<host>:7072/service/extension/nginx-lookup . This servlet handles queries for the user account route information (the server and port number where the user account resides).

Architecture and Flow

Source: http://wiki.zimbra.com/wiki/Zimbra_Proxy_Guide#Architecture_and_Flow

* Needs to be proofed.

* Merge the two sources of information into one.

* Reference customer dependencies - Firewall, load-balancer , round-robin DNS to make single-zimbra-hostname use all the proxy servers in question either by ip or dns .

The following sequence shows the architecture and flow of Zimbra Proxy.

  1. End clients connect to Zimbra Proxy using IMAP[S]/POP[S]/HTTP[S] ports.
  2. When Zimbra Proxy receives an incoming connection, the Nginx component sends an HTTP request to Zimbra Proxy Route Lookup Handler component.
  3. Zimbra Proxy Route Lookup Handler locates the route information for the account being accessed and returns this to Nginx.
  4. The Memcached component stores the route information for the configured period of time (by default, this time is one hour). Nginx will use this route information instead of querying the Zimbra Proxy Route Lookup Handler until the default period of time has expired.
  5. Nginx uses the route information to connect to Zimbra Mailbox.
  6. Zimbra Proxy connects to Zimbra Mailbox and initiates the web/mail proxy session. The end client behaves as if it is connecting directly to Zimbra Mailbox.

Source : Admin Guide Draft , 'Configure Zimbra HTTP Proxy'

HTTP reverse proxy routes requests as follows:

  1. If the requesting URL can be examined to determine the user name, then the request is routed to the backend mailbox server of the user in the URL. REST, Ca lDAV, and Zimbra Mobile Sync are supported through this mechanism.
  2. If the request has an auth token cookie (ZM_AUTH_TOKEN), the request is routed to the backend mailbox server of the authenticated user.
  3. If the above methods do not work, the IP hash method is used to load balance the requests across the backend mailbox servers which are able to handle the request or do any necessary internal proxying.

Position In ZCS Runtime

Source: http://wiki.zimbra.com/wiki/Zimbra_Proxy_Guide#Position_in_ZCS_Runtime

* Needs to be proofed.

* Get graphic working.

* Reference customer dependencies - Firewall, load-balancer , round-robin DNS to make single-zimbra-hostname use all the proxy servers in question either by ip or dns . Expand graphic to include this reference.

The figure to the right show the positions of NZ and its relationships to other components of ZCS.
Proxy position in ZCS runtime. Click to see full sized : Proxy_position_in_ZCS-2.png
With Zimbra Proxy, a general workflow of login is like this. On a client login, NZ will attempt to contact a memcached server (the exact server will be elected from the available candidates, using an round-robin algorithm). The memcached server is expected to return the upstream route information for that particular client. If the information is not present in that memcached server, then this will be a cache-miss, so Zimbra Proxy will proceed to contact an available NLE (elected by Round-Robin), to look up the upstream server information.


Once the upstream server is known, Zimbra Proxy will immediately initiate the proxy session. And then, it will cache the upstream information into the memcached server. The next time the user logs in, the memcached server will have the upstream information available in its cache, and so Zimbra Proxy will not need to contact NLE.

Zimbra Proxy Ports

* Need reference to memcached port , admin ports , zimbraPublicServicePort .

* Do we clarify "open" ports on the firewall also? --Adam

* Rough Draft of new port layout https://wiki.zimbra.com/wiki/Ajcody-Proxy-Guide-Rewrite-Project#Ports_Scratchpad --Adam

Source: http://wiki.zimbra.com/wiki/Zimbra_Proxy_Guide#Zimbra_Proxy_Ports

The following ports are used either by Zimbra Proxy or by Zimbra Mailbox (if Proxy is not configured). If you have any other services running on these ports, turn them off.

End clients connect directly to Zimbra Proxy, using the Zimbra Proxy Ports. Zimbra Proxy connects to the Route Lookup Handler or Zimbra Mailbox using the Zimbra Mailbox Ports.


Zimbra Proxy Ports (External to ZCS) Port
HTTP 80
HTTPS 443
POP3 110
POP3S (Secure POP3) 995
IMAP 143
IMAPS (Secure IMAP) 993
Zimbra Mailbox Ports (Internal to ZCS) Port
Route Lookup Handler 7072
HTTP Backend (if Proxy configured) 8080
HTTPS Backend (if Proxy configured) 8443
POP3 Backend (if Proxy configured) 7110
POP3S Backend (if Proxy configured) 7995
IMAP Backend (if Proxy configured) 7143
IMAPS Backend (if Proxy configured) 7993

Confirming What Ports Are Active

As root, you can do either of the following:

For all ports:

netstat -anltp | egrep '^tcp' | grep LISTEN | awk '{print $4 " "$7}' | sed -e 's/.*://' | sort -n | uniq

For some specific ports:

netstat -anelpt | egrep ':25|:465|:389|:636|:7025|:7047|:80|:8080|:443|:8443|:110|:7110|:995|:7995|:143|:7143|:993|:7993|:3443|:9443|:7071|:9071|:7072|:7306|:7307|:7780|:10024|:10025|:11211'


lsof -P -n -i :25,465,389,636,7025,7047,80,8080,443,8443,110,7110,995,7995,143,7143,993,7993,3443,9443,7071,9071,7072,7306,7307,7780,10024,10025,11211

Deployment Strategies, Server Specifications, Impact To Other Non-Proxy Hosts

Source: http://wiki.zimbra.com/wiki/Zimbra_Proxy_Guide#Deployment_strategies.2C_server_specifications.2C_impact_to_other_non-proxy_hosts

* Needs more details, incomplete right now.


The deployment strategy Zimbra actively suggests is to use Zimbra Proxy on the edge with mailbox servers behind the firewall. Please note that the Zimbra Proxy package does not act as a firewall and needs to be behind the firewall in customer deployments.
Jump to: navigation, search