O Nginx está ganhando popularidade rapidamente, passando de apenas um acelerador de servidor estático para Apache para um servidor Web avançado e com recursos completos que está sendo cada vez mais usado isoladamente. Neste artigo, falaremos sobre cenários interessantes e fora do padrão de uso do nginx, que permitirão que você aproveite ao máximo o servidor web.

Proxy de e-mail

Vamos começar com o mais óbvio - a capacidade do nginx de atuar como um proxy de email. Esta função está no nginx inicialmente, mas por algum motivo é usada em produção extremamente raramente, alguns nem sabem da sua existência. Seja como for, o nginx suporta os protocolos de proxy POP3, IMAP e SMTP com vários métodos de autenticação, incluindo SSL e StartTLS, e faz isso muito rapidamente.

Por que isso é necessário? Há pelo menos dois usos para essa funcionalidade. Primeiro, use o nginx como um escudo contra spammers irritantes que tentam enviar lixo eletrônico através do nosso servidor SMTP. Normalmente, os spammers não criam muitos problemas, pois são rapidamente rejeitados no estágio de autenticação, no entanto, quando há muitos deles, o nginx ajudará a economizar recursos da CPU. Segundo, use o nginx para redirecionar os usuários para vários servidores de correio POP3/IMAP. Claro, outro proxy de e-mail também poderia lidar com isso, mas por que cercar o jardim do servidor se o nginx já está instalado no frontend para servir estático via HTTP, por exemplo?

O proxy de correio no nginx não é bem padrão. Ele usa uma camada de autenticação adicional implementada por meio de HTTP, e somente se o usuário ultrapassar essa barreira, ele será repassado. Essa funcionalidade é fornecida pela criação de uma página/script, para a qual o nginx fornece os dados do usuário, e ele retorna uma resposta na forma de OK padrão ou um motivo de recusa (como “Login ou senha inválida”). O script é executado com os seguintes cabeçalhos:

Entrada do script de autenticação HTTP_AUTH_USER: usuário HTTP_AUTH_PASS: senha HTTP_AUTH_PROTOCOL: protocolo de correio (IMAP, POP3 ou SMTP)

E retorna assim:

Saída do script de autenticação HTTP_AUTH_STATUS: OK ou motivo da falha HTTP_AUTH_SERVER: servidor de email real para redirecionar HTTP_AUTH_PORT: porta do servidor

Uma característica notável dessa abordagem é que ela pode ser usada não para autenticação em si, mas para distribuir usuários em diferentes servidores internos, dependendo do nome de usuário, dados sobre cargas atuais em servidores de correio ou até mesmo organizando o balanceamento de carga mais simples usando rodízio. No entanto, se você precisar apenas transferir usuários para um servidor de e-mail interno, poderá usar um stub implementado pelo próprio nginx em vez de um script real. Por exemplo, o proxy SMTP e IMAP mais simples na configuração do nginx ficará assim:

# vi /etc/nginx/nginx.conf mail ( # Endereço do script de autenticação auth_http localhost:8080/auth; # Desabilite o comando XCLIENT, alguns servidores de e-mail não entendem xclient off; # servidor servidor IMAP ( listen 143; protocol imap; proxy ativado; ) # servidor do servidor SMTP ( escuta 25; protocolo smtp; proxy ativado; ) )

# vi /etc/nginx/nginx.conf http ( # Mapeamento para a porta correta do servidor de correio dependendo da porta enviada no mapa de cabeçalho HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport ( default 25; smtp 25; imap 143; ) # Implementando a autenticação " script" - sempre retorna OK e redireciona o usuário para o servidor de email interno, configurando a porta correta usando o servidor de mapeamento acima ( listen 8080; location/auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" " 192.168.0.1" ; add_header "Auth-Port" $mailport; return 200; ) ) )

É tudo. Essa configuração permite redirecionar os usuários de forma transparente para o servidor de correio interno sem criar uma sobrecarga na forma de um script desnecessário neste caso. Usando um script, essa configuração pode ser expandida significativamente: configure o balanceamento de carga, verifique os usuários no banco de dados LDAP e execute outras operações. Escrever um script está além do escopo deste artigo, mas é muito fácil de implementar mesmo com apenas um conhecimento rudimentar de PHP e Python.

Transmissão de vídeo

Configurar uma hospedagem de vídeo regular baseada em nginx é fácil. Tudo o que você precisa fazer é enviar o vídeo transcodificado para um diretório acessível ao servidor, adicioná-lo à configuração e configurar o flash ou o player HTML5 para que ele capture o vídeo desse diretório. No entanto, se você deseja configurar a transmissão de vídeo contínua de alguma fonte externa ou webcam, esse esquema não funcionará e você terá que procurar protocolos especiais de streaming.

Existem vários protocolos que resolvem esse problema, o mais eficiente e suportado deles é o RTMP. O único problema é que quase todas as implementações de servidor RTMP sofrem de problemas. O Adobe Flash Media Server oficial é pago. Red5 e Wowza são escritos em Java e, portanto, não fornecem o desempenho desejado, outra implementação, Erlyvideo, é escrita em Erlang, o que é bom no caso de configuração em cluster, mas não tão eficiente para um único servidor.

Sugiro outra abordagem - use o módulo RTMP para nginx. Possui excelente desempenho e também permite que você use um servidor para servir tanto a interface web do site quanto o fluxo de vídeo. O único problema é que este módulo não é oficial, então você mesmo terá que construir o nginx com seu suporte. Felizmente, a montagem é realizada de maneira padrão:

$ sudo apt-get remove nginx $ cd /tmp $ wget http://bit.ly/VyK0lU -O nginx-rtmp.zip $ unzip nginx-rtmp.zip $ wget http://nginx.org/download/nginx- 1.2.6.tar.gz $ tar -xzf nginx-1.2.6.tar.gz $ cd nginx-1.2.6 $ ./configure --add-module=/tmp/nginx-rtmp-module-master $ make $ sudo make install

Agora o módulo precisa ser configurado. Isso é feito, como de costume, através da configuração do nginx:

Rtmp (# Ativa o servidor de broadcast na porta 1935 no site/servidor rtmp ( listen 1935; application rtmp ( live on ; ) ) )

O módulo RTMP não funciona em uma configuração multi-thread, portanto, o número de processos de trabalho do nginx terá que ser reduzido a um (mais tarde, direi como contornar esse problema):

trabalhadores_processos 1;

Agora podemos salvar o arquivo e fazer com que o nginx releia a configuração. A configuração do nginx está completa, mas ainda não temos o fluxo de vídeo, então precisamos levá-lo a algum lugar. Por exemplo, seja o arquivo video.avi do diretório atual. Para transformá-lo em um stream e envolvê-lo em nosso transmissor RTMP, vamos usar o bom e velho FFmpeg:

# ffmpeg -re -i ~/video.avi -c copy -f flv rtmp://localhost/rtmp/stream

Se o arquivo de vídeo não estiver no formato H264, ele deve ser recodificado. Isso pode ser feito em tempo real usando o mesmo FFmpeg:

# ffmpeg -re -i ~/video.avi -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream

O fluxo também pode ser capturado diretamente da webcam:

# ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an -f flv rtmp://localhost/rtmp/stream

Para visualizar o fluxo no lado do cliente, você pode usar qualquer player habilitado para RTMP, como mplayer:

$ mplayer rmtp://example.com/rtmp/stream

Ou incorpore o player diretamente na página da web, que é atendida pelo mesmo nginx (um exemplo da documentação oficial):

O reprodutor web RTMP mais simples

Existem apenas duas linhas importantes aqui: “file: “stream””, indicando o stream RTMP, e “streamer: “rtmp://localhost/rtmp””, que especifica o endereço do streamer RTMP. Para a maioria das tarefas, essas configurações serão suficientes. Vários fluxos diferentes podem ser lançados em um endereço, e o nginx os multiplexará efetivamente entre os clientes. Mas isso não é tudo o que o módulo RTMP é capaz. Com sua ajuda, por exemplo, você pode organizar a retransmissão de um fluxo de vídeo de outro servidor. O servidor FFmpeg não é necessário para isso, basta adicionar as seguintes linhas à configuração:

# vi /etc/nginx/nginx.conf application rtmp ( live on; pull rtmp://rtmp.example.com; )

Se você precisar criar vários fluxos em diferentes qualidades, poderá chamar o transcodificador FFmpeg diretamente do nginx:

# vi /etc/nginx/nginx.conf application rtmp ( live on; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) application rtmp-320x240 ( ao vivo; )

Com esta configuração, teremos duas emissoras ao mesmo tempo, sendo que uma estará disponível em rtmp://site/rtmp, e a segunda, transmitindo em qualidade 320 x 240, em rtmp://site/rtmp–320x240. Mais adiante no site, você pode pendurar um flash player e botões de seleção de qualidade que vão deslizar o player de um ou outro endereço da emissora.

E por fim, um exemplo de transmissão de música para a rede:

enquanto verdadeiro; do ffmpeg -re -i "`find /var/music -type f -name "*.mp3"|sort -R|head -n 1`" -vn -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream; feito

git proxy

O sistema de controle de versão Git é capaz de fornecer acesso a repositórios não apenas por meio dos protocolos Git e SSH, mas também por HTTP. Antigamente, a implementação do acesso HTTP era primitiva e incapaz de fornecer um trabalho completo com o repositório. Desde a versão 1.6.6, a situação mudou, e hoje esse protocolo pode ser usado para, por exemplo, contornar restrições de firewall em ambos os lados da conexão ou para criar sua própria hospedagem Git com uma interface web.

Infelizmente, a documentação oficial fala apenas sobre como organizar o acesso ao Git usando o servidor web Apache, mas como a implementação em si é uma aplicação externa com uma interface CGI padrão, ela pode ser anexada a praticamente qualquer outro servidor, incluindo lighttpd e, claro, nginx. Isso não requer nada além do próprio servidor, Git instalado e um pequeno servidor FastCGI fcgiwrap, que é necessário porque o nginx não sabe trabalhar com CGI diretamente, mas pode chamar scripts usando o protocolo FastCGI.

Todo o esquema de trabalho ficará assim. O servidor fcgiwrap irá travar em segundo plano e aguardar uma solicitação para executar um aplicativo CGI. O Nginx, por sua vez, será configurado para solicitar a execução do binário CGI git-http-backend através da interface FastCGI toda vez que o endereço especificado for acessado. Ao receber uma solicitação, o fcgiwrap executa o git-http-backend com os argumentos CGI especificados passados ​​pelo cliente GIT e retorna o resultado.

Para implementar tal esquema, primeiro instalamos o fcgiwrap:

$ sudo apt-get install fcgiwrap

Você não precisa configurá-lo, todos os parâmetros são passados ​​através do protocolo FastCGI. Ele também será iniciado automaticamente. Portanto, resta apenas configurar o nginx. Para fazer isso, crie o arquivo /etc/nginx/sites-enabled/git (se não houver tal diretório, você pode escrever na configuração principal) e escreva o seguinte nele:

# vi /etc/nginx/sites-enabled/git server ( # Hang on port 8080 listen 8080; # Endereço do nosso servidor (não esqueça de adicionar uma entrada DNS) server_name git.example.ru; # Logs access_log /var /log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Endereço principal para local de acesso anônimo / ( # Ao tentar fazer upload, envie o usuário para um endereço privado if ($ arg_service ~* "git-receive-pack") ( reescrever ^ /private$uri last; ) incluir /etc/nginx/fastcgi_params; # Endereço do nosso git-http-backend fastcgi_param SCRIPT_FILENAME /usr /lib/git-core/git-http-backend; # Endereço do repositório Git fastcgi_param GIT_PROJECT_ROOT /srv/git; # Endereço do arquivo fastcgi_param PATH_INFO $uri; # Endereço do servidor fcgiwrap fastcgi_pass 127.0.0.1:9001; ) # Endereço para local de acesso de gravação ~/private(/.* )$ ( # permissões do usuário auth_basic "git anônimo somente leitura, escrita autenticada"; # autenticação HTTP baseada em htpasswd auth_basic_user_file /etc/nginx/htpasswd; # configurações FastCGI i nclude /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git-http-backend; fastcgi_param GIT_PROJECT_ROOT /srv/git; fastcgi_param PATH_INFO $1; fastcgi_pass 127.0.0.1:9001; ) )

Esta configuração assume três coisas importantes:

1. O endereço do repositório será /srv/git, então defina as permissões apropriadas: $ sudo chown -R www-data:www-data /srv/git
2. O repositório em si deve ser legível por Anonymous e permitir upload via HTTP: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true
3. A autenticação é feita usando o arquivo htpasswd, você precisa criá-lo e adicionar usuários a ele: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 .. .

Isso é tudo, reinicie o nginx:

Microcaching

Vamos imaginar uma situação com um site dinâmico, atualizado com frequência, que de repente começa a receber cargas muito grandes (bom, entrou na página de um dos maiores sites de notícias) e deixa de dar conta do retorno de conteúdo. A otimização competente e a implementação do esquema de cache correto levará muito tempo e os problemas precisam ser resolvidos agora. O que podemos fazer?

Existem várias maneiras de sair dessa situação com perdas mínimas, mas a ideia mais interessante veio de Fenn Bailey (fennb.com). A ideia é simplesmente colocar o nginx na frente do servidor e forçá-lo a armazenar em cache todo o conteúdo transmitido, mas não apenas o cache, mas apenas por um segundo. O destaque aqui é que centenas e milhares de visitantes do site por segundo, na verdade, gerarão apenas uma chamada para o back-end, a maioria deles recebendo uma página em cache. Ao mesmo tempo, quase ninguém notará a diferença, porque mesmo em um site dinâmico, um segundo geralmente não significa nada.

A configuração com a implementação desta ideia não parecerá tão complicada:

# vi /etc/nginx/sites-enabled/cache-proxy # Configure o cache proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m; server ( listen 80; server_name example.com; # Cache address location / ( # Cache habilitado por padrão set $no_cache ""; # Desabilite o cache para todos os métodos exceto GET e HEAD if ($request_method !~ ^(GET|HEAD) $ ) ( set $no_cache "1"; ) # Se o cliente enviar conteúdo para o site (no_cache = 1), garantimos que os dados fornecidos a ele não sejam armazenados em cache por dois segundos e ele possa ver o resultado do download se ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1"; ) # Habilita/desabilita o cache dependendo do estado da variável no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Solicitações de proxy para o servidor real proxy_pass http://appserver.example.ru; proxy_cache microcache; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Proteção contra problema de Thundering Herd proxy_cache_use_stale update; # Adiciona cabeçalhos padrão proxy_set_h cabeçalho Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Não armazene em cache arquivos maiores que 1 MB proxy_max_temp_file_size 1M; ) )

Um lugar especial nesta configuração é ocupado pela linha "proxy_cache_use_stale update;", sem a qual teríamos recebido rajadas periódicas de carga no servidor backend devido a solicitações que vieram durante a atualização do cache. Caso contrário, tudo é padrão e deve ser claro sem maiores explicações.

Aproximação do proxy ao público-alvo

Apesar do aumento global generalizado nas velocidades da Internet, o afastamento físico do servidor do público-alvo ainda continua a desempenhar um papel. Isso significa que, se um site russo estiver sendo executado em um servidor localizado em algum lugar da América, a velocidade de acesso a ele será a priori mais lenta do que em um servidor russo com a mesma largura de banda (claro, se você fechar os olhos para todos os outros fatores ). Outra coisa é que muitas vezes é mais lucrativo hospedar servidores no exterior, inclusive em termos de manutenção. Portanto, para obter lucro, na forma de taxas de retorno mais altas, você terá que fazer um truque.

Uma das opções possíveis: colocar o principal servidor produtivo no Ocidente e implantar o front-end, que não exige muito de recursos, dando estática, na Rússia. Isso permitirá que você ganhe em velocidade sem custos sérios. A configuração do nginx para o frontend neste caso será uma implementação de proxy simples que é familiar para todos nós:

# vi /etc/nginx/sites-enabled/proxy # Armazena o cache por 30 dias em 100 GB de armazenamento proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static:32m inactive=30d max_size=100g; server ( listen 80; server_name example.com; # Na verdade, nosso local de proxy ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ (# endereço de backend proxy_pass back.example.com:80; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_cache estático; proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Expira"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock on; ) )

conclusões

Hoje, com a ajuda do nginx, você pode resolver muitas tarefas diferentes, muitas das quais não estão relacionadas ao servidor web e ao protocolo HTTP. Um proxy de correio, um servidor de streaming e uma interface Git são apenas algumas das tarefas.

Este artigo explicará como configurar o NGINX Plus ou NGINX Open Source como um proxy para um servidor de correio ou um serviço de correio externo.

Introdução

O NGINX pode fazer proxy de protocolos IMAP, POP3 e SMTP para um dos servidores de e-mail upstream que hospedam contas de e-mail e, portanto, pode ser usado como um único ponto de extremidade para clientes de e-mail. Isso pode trazer vários benefícios, como:

• fácil dimensionamento do número de servidores de e-mail
• escolher um servidor de e-mail com base em regras diferentes, por exemplo, escolher o servidor mais próximo com base no endereço IP de um cliente
• distribuindo a carga entre os servidores de correio

Pré-requisitos

O NGINX Plus (já inclui os módulos Mail necessários para o tráfego de e-mail proxy) ou o NGINX Open Source compilou os módulos Mail usando o parâmetro --with-mail para funcionalidade de proxy de e-mail e o parâmetro --with-mail_ssl_module para suporte SSL/TLS:

$ ./configure --with-mail --with-mail_ssl_module --with-openssl=[ DIR] /openssl-1.1.1

Servidores de correio IMAP, POP3 e/ou SMTP ou um serviço de correio externo

Configurando Servidores Proxy de Correio SMTP/IMAP/POP3

No arquivo de configuração do NGINX:

correspondência(#...)

mail ( server_name mail.example.com ; #... )

mail ( server_name mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; #... )

Como alternativa, especifique se deseja informar um usuário sobre erros do servidor de autenticação especificando a diretiva proxy_pass_error_message. Isso pode ser útil quando uma caixa de correio fica sem memória:

mail ( server_name mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; #... )

Configure cada servidor SMTP, IMAP ou POP3 com os blocos de servidor. Para cada servidor, especifique:

• a número da porta que correspondem ao protocolo especificado com a diretiva listen
• a protocolo com a diretiva de protocolo (se não for especificada, será detectada automaticamente a partir da porta especificada na diretiva de escuta)
• permitido métodos de autenticação com as diretivas imap_auth , pop3_auth e smtp_auth:

server ( listen 25 ; protocol smtp ; smtp_auth login plain cram-md5 ; ) server ( listen 110 ; protocol pop3 ; pop3_auth plain apop cram-md5 ; ) server ( listen 143 ; protocol imap ; )

Configurando a autenticação para um proxy de email

Cada solicitação POP3/IMAP/SMTP do cliente será autenticada primeiro em um servidor de autenticação HTTP externo ou por um script de autenticação. Ter um servidor de autenticação é obrigatório para o proxy do servidor de correio NGINX. O servidor pode ser criado por você de acordo com o protocolo de autenticação NGINX que é baseado no protocolo HTTP.

Se a autenticação for bem-sucedida, o servidor de autenticação escolherá um servidor upstream e redirecionará a solicitação. Nesse caso, a resposta do servidor conterá as seguintes linhas:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # o nome do servidor ou endereço IP do servidor upstream que será usado para processamento de correio Porta de autenticação: # a porta do servidor upstream

Se a autenticação falhar, o servidor de autenticação retornará uma mensagem de erro. Nesse caso, a resposta do servidor conterá as seguintes linhas:

Status de autenticação HTTP/1.0 200 OK: # uma mensagem de erro a ser retornada ao cliente, por exemplo “Login ou senha inválida” Auth-Wait: # o número de tentativas de autenticação restantes até que a conexão seja fechada

Observe que em ambos os casos a resposta conterá HTTP/1.0 200 OK o que pode ser confuso.

Para obter mais exemplos de solicitações e respostas do servidor de autenticação, consulte o ngx_mail_auth_http_module na documentação de referência do NGINX.

Configurando SSL/TLS para um proxy de email

Usando POP3/SMTP/IMAP sobre SSL/TLS, você garante que os dados transmitidos entre um cliente e um servidor de e-mail estejam protegidos.

Para habilitar SSL/TLS para o proxy de e-mail:

Certifique-se de que seu NGINX esteja configurado com suporte a SSL/TLS digitando o comando nginx -V na linha de comando e procurando a linha with --mail_ssl_module na saída:

$ nginx -V configura argumentos: ... with--mail_ssl_module

Certifique-se de obter certificados de servidor e uma chave privada e coloque-os no servidor. Um certificado pode ser obtido de uma autoridade de certificação (CA) confiável ou gerado usando uma biblioteca SSL, como OpenSSL.

ssl ligado;

sobressalta-se;

Adicionar certificados SSL: especifique o caminho para os certificados (que devem estar no formato PEM) com a diretiva ssl_certificate e especifique o caminho para a chave privada na diretiva ssl_certificate_key:

mail ( #... ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server.key ; )

Você pode usar apenas versões e cifras fortes de SSL/TLS com as diretivas ssl_protocols e ssl_ciphers, ou pode definir seus próprios protocolos e cifras preferenciais:

mail ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )

Otimizando SSL/TLS para Mail Proxy

Essas dicas ajudarão você a tornar seu proxy de e-mail NGINX mais rápido e seguro:

Defina o número de processos de trabalho igual ao número de processadores com a diretiva worker_processes definida no mesmo nível do contexto de correio:

worker_processes auto ; correspondência(#...)

Habilite o cache de sessão compartilhado e desabilite o cache de sessão integrado com o auto ; mail ( server_name mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; ssl on ; ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server. key ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache shared:SSL:10m ; ssl_session_timeout 10m ; server ( listen 25 ; protocol smtp ; smtp_auth login plain cram-md5 ; ) server ( listen 11 ; ) ; protocolo pop3 ; pop3_auth simples apop cram-md5 ; ) server ( listen 143 ; protocol imap ; ) )

Neste exemplo, existem três servidores proxy de e-mail: SMTP, POP3 e IMAP. Cada um dos servidores é configurado com suporte a SSL e STARTTLS. Os parâmetros da sessão SSL serão armazenados em cache.

O servidor proxy usa o servidor de autenticação HTTP – sua configuração está além do escopo deste artigo. Todas as mensagens de erro do servidor serão devolvidas aos clientes.

Nginx- pequeno em tamanho, muito rápido, servidor web bastante funcional e servidor proxy de e-mail, desenvolvedor Igor Sysoev (rambler.ru). Devido ao consumo muito baixo de recursos do sistema e velocidade, bem como flexibilidade de configuração, web servidor nginx frequentemente usado como front-end para servidores mais pesados, como Apache, em projetos de alta carga. A opção clássica é um monte, Nginx - Apache - FastCGI. Trabalhando em tal esquema, servidor nginx, aceita todas as solicitações vindas via HTTP e, dependendo da configuração e da solicitação em si, decide se processa a solicitação em si e dá ao cliente uma resposta pronta ou envia uma solicitação de processamento para um dos backends ( Apache ou FastCGI).

Como você sabe, o servidor Apache processa cada solicitação em um processo separado (thread), que, deve ser dito, consome uma quantidade NÃO pequena de recursos do sistema, se houver 10 a 20 desses processos, não faz sentido, e se houver são 100-500 ou mais deles, o sistema não se torna divertido.

Vamos tentar imaginar tal situação. Suponha em Apache 300 solicitações HTTP vêm de clientes, 150 clientes ficam em linhas dedicadas rápidas e os outros 150 em canais de Internet relativamente lentos, mesmo que não em modems. O que acontece nesta situação? E acontece o seguinte, o servidor web Apache, para processar essas 300 conexões, cria para cada processo (thread), ele vai gerar conteúdo rapidamente, e 150 clientes rápidos vão pegar imediatamente o resultado de suas requisições, os processos que os atenderam serão eliminados e os recursos serão liberados, e 150 são lentos, e levará os resultados de suas consultas lentamente, devido a um canal estreito da Internet, como resultado do qual 150 processos ficarão travados no sistema Apache, esperando que os clientes peguem o conteúdo gerado pelo servidor web, devorando muitos recursos do sistema. Naturalmente, a situação é hipotética, mas acho que a essência é clara. Para corrigir a situação acima e o pacote ajuda. Depois de ler todo o pedido do cliente, ele o repassa para processamento Apache, que por sua vez gera conteúdo e retorna a resposta pronta ao Nginx o mais rápido possível, após o que pode encerrar o processo com a consciência limpa e liberar os recursos do sistema que ocupa. servidor web Nginx, recebendo o resultado da requisição de Apache, grava-o em um buffer ou mesmo em um arquivo em disco e pode entregá-lo a clientes lentos por um tempo arbitrariamente longo, enquanto seus processos de trabalho consomem tão poucos recursos que .. "é até ridículo falar sobre isso" ©. :) Esse esquema economiza recursos do sistema significativamente, repito, mas os processos de trabalho do Nginx consomem uma quantidade escassa de recursos, isso é ainda mais relevante para grandes projetos.

E isso é apenas uma pequena parte do que o servidor Nginx pode fazer, não se esqueça da possibilidade de armazenar dados em cache e trabalhar com memcached. Aqui está uma lista dos principais recursos do servidor web Nginx.

Funcionalidade do servidor Nginx como servidor HTTP

• Manipulação de conteúdo estático, arquivos de índice, listagem de diretórios, cache de descritor de arquivo aberto;
• Proxy acelerado com cache, balanceamento de carga e failover;
• Suporte Acelerado FastCGI servidores com cache, balanceamento de carga e tolerância a falhas;
• Estrutura modular, suporte para vários filtros (SSI, XSLT, GZIP, currículo, respostas em pedaços);
• Suporte para extensões SSL e TLS SNI;
• baseado em IP ou baseado em nome Servidores virtuais;
• Trabalhando com conexões KeepAlive e pipeline;
• A capacidade de configurar quaisquer tempos limite, bem como o número e o tamanho dos buffers, no nível servidor Apache;
• Realização de várias ações dependendo do endereço do cliente;
• Alterando o URI usando expressões regulares;
• Páginas de erro especiais para 4xx e 5xx;
• Restrição de acesso com base no endereço ou senha do cliente;
• Configurando formatos de arquivo de log, rotação de log;
• Limitar a velocidade de resposta ao cliente;
• Limitar o número de conexões e solicitações simultâneas;
• Suporte para os métodos PUT, DELETE, MKCOL, COPY e MOVE;
• Alterar configurações e atualizar o servidor sem interromper o trabalho;
• construídas em Perl;

A funcionalidade do servidor Nginx, como servidor proxy de correio

• Encaminhamento para back-end IMAP/POP3 usando um servidor de autenticação HTTP externo;
• Verificação do usuário SMTP em um servidor de autenticação HTTP externo e encaminhamento para um servidor SMTP interno;
• Suporte para os seguintes métodos de autenticação:
  • POP3 - USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI / PLAIN / CRAM-MD5;
• Suporte SSL;
• suporte para STARTTLS e STLS;

Sistemas operacionais e plataformas suportados pelo servidor web Nginx

• FreeBSD, plataformas 3 a 8, i386 e amd64;
• Linux, de 2.2 a 2.6 - plataforma i386; Linux 2.6 - amd64;
• Solaris 9 - plataformas i386 e sun4u; Solaris 10 - plataformas i386, amd64 e sun4v;
• plataformas MacOS X ppc, i386;
• Windows XP, Windows Server 2003; (Atualmente em teste beta)

Arquitetura e escalabilidade do servidor Nginx

• O processo principal (mestre), vários processos de trabalho (configurados no arquivo de configuração) rodando sob um usuário sem privilégios;
• Suporte para os seguintes métodos de manipulação de conexão:
  • selecionaré o método padrão. O módulo Nginx correspondente é construído automaticamente se um método mais eficiente não for encontrado em uma determinada plataforma. Você pode forçar a construção deste módulo a ser ativada ou desativada usando as opções de configuração --with-select_module ou --without-select_module.
  • votaçãoé o método padrão. O módulo Nginx correspondente é construído automaticamente se um método mais eficiente não for encontrado em uma determinada plataforma. Você pode forçar a construção deste módulo a ser ativada ou desativada usando as opções de configuração --with-poll_module ou --without-poll_module.
  • kqueueé um método eficaz usado nos sistemas operacionais FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 e MacOS X. Quando usado em máquinas MacOS X de processador duplo, pode causar um kernel panic.
  • epollé um método eficiente usado no Linux 2.6+. Algumas distribuições, como o SuSE 8.2, possuem patches para suportar epoll no kernel 2.4.
  • rtsig - sinais em tempo real, um método eficiente usado no Linux 2.2.19+. Por padrão, não pode haver mais de 1024 sinais na fila para todo o sistema. Isso não é suficiente para servidores com carga alta, o tamanho da fila deve ser aumentado usando o parâmetro do kernel /proc/sys/kernel/rtsig-max. No entanto, a partir do Linux 2.6.6-mm2, esta opção foi removida, em vez disso, cada processo possui uma fila de sinal separada, cujo tamanho é determinado por RLIMIT_SIGPENDING.
  • Quando a fila está cheia, servidor nginx redefine-o e trata das conexões com o método poll até que a situação volte ao normal.
  • /dev/enquete- método eficaz, suportado em sistemas operacionais Solaris 7 11/99+, HP/UX 11.22+ (porta de evento), IRIX 6.5.15+ e Tru64 UNIX 5.1A+.
  • eventport - portas de eventos, um método eficaz usado no Solaris 10. Antes de usar, um patch deve ser instalado para evitar pânico no kernel.
• Usando os recursos do método kqueue, como EV_CLEAR, EV_DISABLE (para desabilitar temporariamente o evento), NOTE_LOWAT, EV_EOF, o número de dados disponíveis, códigos de erro;
• Trabalhe com sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) e sendfilev (Solaris 8 7/01+);
• Suporte para filtros de aceitação (FreeBSD 4.1+) e TCP_DEFER_ACCEPT (Linux 2.4+);
• 10.000 conexões keep-alive HTTP ociosas consomem aproximadamente 2,5 M de memória;
• O número mínimo de operações de cópia de dados;

iRedMail é uma construção de servidor de e-mail de código aberto. O assembly é baseado no servidor SMTP Postfix (Mail Transfer Agent, MTA para abreviar). A montagem também inclui: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData e NGINX.

Pombal- Servidor IMAP/POP3.

Spamassassin- ferramenta de filtragem de spam.

Lista cinza- ferramenta anti-spam baseada em listas cinzas.

ClamAV- antivírus.

cubo redondo e Entao vai- Clientes Web para trabalhar com e-mail.

Dados líquidos- um programa para monitorar a operação do servidor em tempo real.

Nginx- servidor web.

Suporta sistemas operacionais: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 e OpenBSD 6.4.

O iRedMail possui versões pagas e gratuitas, que diferem umas das outras pela funcionalidade da própria interface web do conjunto de correio do iRedAdmin. Na versão gratuita, você só pode criar domínios, caixas de correio de usuário e administrador. Se você precisar criar um alias, não poderá fazê-lo na versão gratuita via iRedAdmin. Felizmente, existe uma solução gratuita chamada PostfixAdmin que permite fazer isso. O PostfixAdmin se integra facilmente ao iRedMail e funciona muito bem com ele.

Instalação

Para instalar, precisamos de um dos sistemas operacionais listados acima. Eu estarei usando o Ubuntu Server 18.04. Você também deve ter um nome de domínio adquirido e uma zona DNS configurada. Se você usar o servidor DNS do seu registrador de domínio, precisará fazer dois registros na seção de gerenciamento de zona de domínio: A e MX. Você também pode usar seu próprio DNS configurando a delegação na conta pessoal do seu registrador de nomes de domínio.

Configurando uma zona de domínio ao usar um registrador DNS

Observação! As configurações de DNS têm efeito de várias horas a uma semana. Até que as configurações entrem em vigor, o servidor de e-mail não funcionará corretamente.

Para instalar, baixe a versão atual do site iRedMail. No momento é 0.9.9.

# wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.9.tar.bz2

Em seguida, descompacte o arquivo baixado.

# tar xjf iRedMail-0.9.9.tar.bz2

Descompactando o arquivo

E vá para a pasta criada.

# cd iRedMail-0.9.9

Pasta com o instalador do iRedMail

Verificando o conteúdo de uma pasta

Conteúdo da pasta

E execute o script de instalação do iRedMail.

# bash iRedMail.sh

A instalação do sistema de correio será iniciada. Durante o processo de instalação, você precisará responder a várias perguntas. Concordamos em iniciar a instalação.

Início da instalação

Selecionando um diretório de instalação

Agora você precisa selecionar um servidor web. A escolha não é grande, então escolhemos NGINX.

Selecionando um servidor web

Agora você precisa selecionar o servidor de banco de dados que será instalado e configurado para trabalhar com o sistema de correio. Escolha MariaDB.

Selecionando um servidor de banco de dados

Defina a senha de root para o banco de dados.

Criando uma senha raiz do banco de dados

Agora especificamos nosso domínio de email.

Criando um domínio de e-mail

Em seguida, crie uma senha para a caixa de administração [e-mail protegido] domain.ru.

Criar uma senha de administrador de e-mail

Selecionando Componentes da Web

Confirmamos as configurações especificadas.

Confirmação de configurações

A instalação começou.

Instalação

Após a conclusão da instalação, confirme a criação da regra iptables por SSH e reinicie o firewall. iRedMail trabalha com iptables. No Ubuntu, o utilitário de gerenciamento de firewall mais usado UVW. Se por um motivo ou outro você tiver essa necessidade, instale UVW (apt instalar ufw) e adicione regras para UVW(exemplo: ufw permite "nginx completo" ou ufw permitir Postfix) não bloqueou o servidor de email. Você pode visualizar a lista de regras disponíveis executando o comando: lista de aplicativos ufw. Então ligue UVW: ufw habilitar.

Criar uma regra do iptables

Reinicialização do firewall

Isso conclui a instalação do iRedMail. O sistema nos forneceu endereços de interface web e credenciais de login. Para ativar todos os componentes do sistema de correio, você deve reiniciar o servidor.

Fim da instalação

Nós reiniciamos.

# reinício

Contexto

Primeiro você precisa ter certeza de que tudo funciona. Tentamos entrar no painel de controle do iReadAdmin em https://domínio/iredadmin. Conecte-se [e-mail protegido] domain.ru, a senha foi criada durante a instalação. Há uma interface em russo.

Como você pode ver tudo funciona. Ao fazer login no iRedAdmin, você provavelmente recebeu um erro de segurança relacionado ao certificado. Isso ocorre porque o iRedMail possui um certificado autoassinado, que o navegador jura. Para corrigir esse problema, você precisa instalar um certificado SSL válido. Se você comprou um, você pode instalá-lo. No exemplo, instalarei o SSL gratuito da Let's Encrypt.

Instalando um Certificado SSL Let's Encrypt

Instalaremos o certificado usando o utilitário certbot. Vamos adicionar um repositório primeiro.

# add-apt-repository ppa:certbot/certbot

Em seguida, instalamos o próprio certboot com os componentes necessários.

# apt install python-certbot-nginx

Recebemos um certificado.

# certbot --nginx -d domain.ru

Depois de executar o comando, o sistema solicitará que você insira um endereço de e-mail, digite. Depois disso, você provavelmente receberá um erro informando que não é possível encontrar o bloco de servidor para o qual o certificado foi gerado. Nesse caso, isso é normal, pois não temos nenhum bloco de servidor. Para nós, o principal é obter um certificado.

Obtenção de um certificado

Como você pode ver, o certificado foi recebido com sucesso e o sistema nos mostrou os caminhos para o próprio certificado e para a chave. Eles são exatamente o que precisamos. Em geral, recebemos 4 arquivos que serão armazenados na pasta "/etc/letsencrypt/live/domain". Agora precisamos informar ao servidor web sobre nosso certificado, ou seja, substituir o certificado incorporado pelo que acabamos de receber. Para fazer isso, precisamos editar apenas um arquivo.

# nano /etc/nginx/templates/ssl.tmpl

E altere as duas últimas linhas nele.

Substituindo o certificado SSL

Alteramos os caminhos no arquivo para os caminhos que o sistema nos informou quando recebemos o certificado.

Substituindo um certificado SSL

E reinicie o NGINX.

# serviço nginx reinicie

Agora vamos tentar fazer login novamente. iRedAdmin.

Verificação de certificado SSL

Não há mais erro de certificado. O certificado é válido. Você pode clicar no cadeado e ver suas propriedades. Quando o certificado expirar, o certboot deverá renová-lo automaticamente.

Agora vamos falar sobre o certificado Dovecot e Postfix. Para fazer isso, vamos editar dois arquivos de configuração. Nós fazemos:

# nano /etc/dovecot/dovecot.conf

Encontrando um bloco:

#SSL: configurações globais.

E nós mudamos o certificado registrado lá para o nosso.

Substituição do certificado para Dovecot

Preste atenção também na linha "ssl_protocols". Seu valor deve ser "!SSLv3", caso contrário você receberá um erro "Aviso: SSLv2 não suportado pelo OpenSSL. Considere removê-lo de ssl_protocols" ao reiniciar o Dovecot.

# nano /etc/postfix/main.cf

Encontrando um bloco:

# Chave SSL, certificado, CA

E alteramos os caminhos nele para os caminhos dos arquivos do nosso certificado.

Substituição de certificado para Postfix

Isso conclui a instalação do certificado. É necessário reiniciar o Dovecot e o Postfix, mas é melhor reiniciar o servidor.

# reinicio do pombal de serviço

# reinício

Instalando o PHPMyAdmin

Este item é opcional, mas recomendo que você o complete e instale o PHPMyAdmin para sua experiência com banco de dados.

# apt instala o phpmyadmin

O instalador solicitará que você trabalhe com qual servidor web configurar o PHPMyAdmin, já que o NGINX não está nesta lista, basta pressionar TAB e seguir em frente.

Instalando o PHPMyAdmin

Após a conclusão da instalação, para que o phpmyadmin funcione, você precisa criar um link simbólico para o diretório com o qual o NGINX funciona por padrão.

# ln -s /usr/share/phpmyadmin /var/www/html

E tente ir para https://domínio/phpmyadmin/

PHPMyAdmin está funcionando. A conexão é protegida por um certificado, não há erros. Vá em frente. Vamos criar um administrador de banco de dados MySQL (MariaDB).

#mysql

E entramos no console de gerenciamento do MariaDB. Em seguida, executamos os comandos um por um:

MariaDB > CRIAR USUÁRIO "admin"@"localhost" IDENTIFICADO POR "senha";
MariaDB > CONCEDER TODOS OS PRIVILÉGIOS EM *.* PARA "admin"@"localhost" COM OPÇÃO DE CONCESSÃO;
MariaDB > PRIVILÉGIOS FLUSH;

Criando um usuário MySQL

Está tudo certo, você está logado. PHPMyAdmin está pronto para ser usado.

Instalando o PostfixAdmin

Em princípio, PostfixAdmin, como PHPMyAdmin, não pode ser instalado. O servidor de e-mail funcionará bem sem esses componentes. Mas você não poderá criar aliases de e-mail. Se você não precisar disso, sinta-se à vontade para pular essas seções. Se você ainda precisar de aliases, terá duas opções: comprar uma versão paga do iReaAdmin ou instalar o PostfixAdmin. Claro, você pode fazer isso sem software adicional escrevendo manualmente aliases no banco de dados, mas isso nem sempre é conveniente e não é adequado para todos. Eu recomendo usar o PostfixAdmin, agora consideraremos sua instalação e integração com o iRedMail. Iniciamos a instalação:

# apt instala o postfixadmin

Concordamos e criamos uma senha para o banco de dados do sistema do programa.

Instalando o PostfixAdmin

Instalando o PostfixAdmin

Fazemos um link simbólico por analogia com a instalação do PHPMyAdmin.

# ln -s /usr/share/postfixadmin /var/www/html

Tornamos o usuário em nome de quem o servidor web é lançado o proprietário do diretório. No nosso caso, o NGINX é executado como o usuário www-data.

# chown -R www-data /usr/share/postfixadmin

Agora precisamos editar o arquivo de configuração do PostfixAdmin e adicionar informações sobre o banco de dados que o iRedAdmin usa. Por padrão, esse banco de dados é chamado vmail. Se você for ao PHPMyAdmin, poderá vê-lo lá. E assim, para que o PostfixAdmin faça alterações no banco de dados, prescrevemos isso na configuração do PostfixAdmin.

# nano /etc/postfixadmin/config.inc.php

Encontrando as linhas:

$CONF["database_type"] = $dbtype;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["database_password"] = $dbpass;
$CONF["database_name"] = $dbname;

E lembre-se:

$CONF["database_type"] = "mysqli"; # Tipo de banco de dados
$CONF["database_host"] = "localhost"; # Host do servidor de banco de dados
$CONF["database_user"] = "admin"; # Login com acesso de gravação ao banco de dados vmail. Você pode usar o administrador criado anteriormente
$CONF["database_password"] = "senha"; # Senha do usuário especificado acima
$CONF["database_name"] = "vmail"; # nome do banco de dados iRedMail

Inserindo informações do banco de dados

Se você planeja usar o cliente de email da Web SOGo, precisará executar mais uma etapa adicional, ou seja, alterar a criptografia PostfixAdmin no parágrafo $CONF["criptografar"] Com "md5crypt" no "pombal:SHA512-CRYPT". Se você não fizer isso, ao tentar autorizar no SOGo por um usuário criado no PostfixAdmin, você receberá um erro com login ou senha incorretos.

Alterando o Tipo de Criptografia

Agora, para concluir a instalação com sucesso e não obter erros, você precisa consultar o banco de dados. É conveniente fazer isso através do PHPMyAdmin. Selecione o banco de dados vmail e vá para a guia SQL. Na janela digite:

DROP INDEX domínio na caixa de correio;
DROP INDEX domínio no alias;
ALTER TABLE alias ADD COLUMN `goto` texto NOT NULL;

Consulta de banco de dados

E pressione "Avançar". Agora que está tudo pronto, você pode ir para a interface web do PostfixAdmin e concluir a instalação. Para fazer isso, no navegador, você precisa digitar: https://domain/postfixadmin/setup.php.

Deve aparecer o seguinte:

Instalando o PostfixAdmin

Se tudo for feito de acordo com as instruções, não deverá haver erros. Se ainda estiverem, serão traídos para serem eliminados, caso contrário, o sistema não permitirá que você continue. Defina a senha de instalação e clique em " Gerar hash de senha". O sistema irá gerar um hash da senha, que deve ser inserido no parâmetro $CONF["setup_password"].

Concluindo a instalação do PostfixAdmin

Alterando as configurações do arquivo de configuração

Agora inserimos a senha que acabamos de criar e criamos o administrador do PostfixAdmin. É melhor não criar um administrador com login de postmaster, pois pode haver problemas ao fazer login no painel de administração do iRedAdmin.

Criando um Administrador PostfixAdmin

Tudo, o administrador é criado. Você pode fazer login.

Observe que, do ponto de vista da segurança, o arquivo setup.php no diretório postfixadmin deve ser renomeado ou excluído.

Vamos lá: https://domínio/postfixadmin/ e insira as credenciais recém-criadas. No PostfixAdmin, assim como no iRedAdmin, o idioma russo está disponível. Pode ser selecionado durante a autorização.

Estamos tentando criar uma caixa de correio de usuário.

Habilitar/Desabilitar Módulos do iRedMail

Os módulos do iRedMail são gerenciados pelo iRedAPD. Possui um arquivo de configuração que contém módulos de trabalho. Se você não precisar de um módulo específico, você pode removê-lo do arquivo de configuração e ele parará de funcionar. Nós fazemos:

# nano /opt/iredapd/settings.py

Encontre a linha plug-ins" e remova os componentes que você não precisa dele. Vou remover o componente "lista cinza". Claro, protege contra spam de forma bastante eficaz, mas as letras necessárias muitas vezes não chegam.

Greylist (lista cinza) é uma tecnologia de proteção automática contra spam baseada na análise do comportamento do servidor do remetente. Quando a "lista cinza" está habilitada, o servidor se recusa a aceitar uma carta de um endereço desconhecido pela primeira vez, relatando um erro temporário. Nesse caso, o servidor remetente deve tentar novamente o envio mais tarde. Spammers geralmente não fazem isso. Se a carta for enviada novamente, ela é adicionada à lista por 30 dias e a correspondência já é trocada desde a primeira vez. Use este módulo ou não decida por si mesmo.

Habilitando/Desabilitando módulos de e-mail

Você deve reiniciar depois de fazer as alterações. iRedAPD.

# serviço iredapd reinicie

Teste do servidor de correio

Isso conclui a configuração do servidor de correio iRedMail. Você pode prosseguir para o estágio final - teste. Vamos criar duas caixas de correio. Para verificar um pelo iRedAdmin, o segundo pelo PostfixAdmin e enviar uma carta de uma caixa postal para outra e vice-versa. Crie uma caixa de correio no iRedAdmin [e-mail protegido] domain.ru. No PostfixAdmin - [e-mail protegido] domain.ru

Criando um usuário no iRedAdmin

Criando um usuário no PostfixAdmin

Verifique se os usuários foram criados.

Se você prestar atenção à coluna "Para" na lista de caixas de correio PostfixAdmin, poderá ver a diferença entre as caixas de correio criadas em iRedAdmin e PostfixAdmin. As caixas de correio criadas no iRedAdmin são marcadas como " apenas para a frente", e aqueles criados no PostfixAdmin como - " Caixa de correio". No começo, por muito tempo eu não conseguia entender por que isso acontece e qual é a diferença entre eles, e finalmente notei uma coisa. As caixas de correio no iRedAdmin são criadas sem aliases e as caixas de correio no PostfixAdmin com um alias para si mesmo.

E se esses aliases forem excluídos, as caixas de correio serão exibidas como aquelas criadas no iRedAdmin" apenas para a frente".

Removendo aliases

Os aliases foram removidos. Verifique PostfixAdmin.

Como você pode ver, todas as caixas se tornaram "Somente encaminhamento". Da mesma forma, se você criar um alias para si mesmo na caixa de correio criada no iRedAdmin, ela se tornará "Caixa de Correio". Em princípio, isso não afeta o desempenho do correio. A única coisa é que você não poderá criar um alias em uma caixa de correio criada no PostfixAdmin. Em vez de criar um alias, você precisará editar um existente. Falando em aliases, na nova versão do iRedMail, você precisa fazer uma alteração em um dos cartões Postfix que é responsável pelos aliases. E se você não fizer isso, os aliases criados não funcionarão. Para isso é necessário no arquivo /etc/postfix/mysql/virtual_alias_maps.cf corrigir:

Nós fazemos:

# nano /etc/postfix/mysql/virtual_alias_maps.cf

E nós corrigimos.

Configurando aliases

Reinicie o Postfix:

# reinicialização do postfix do serviço

Depois disso tudo deve funcionar.

E assim, vamos começar a verificar o correio. Em uma caixa usuário1 passaremos pelo Roundcube e entraremos na caixa usuário2- via SOGo e envie uma carta da caixa de correio usuário1 no usuário2 e volta.

Enviando um e-mail com Roundcube

Recebendo um e-mail no SOGo

Enviando um e-mail para SOGo

Recebendo e-mail no Roundcube

Tudo funciona sem problemas. A entrega da carta leva de dois a cinco segundos. Da mesma forma, as cartas são perfeitamente entregues aos servidores Yandex e mail.ru (marcados).

Agora vamos verificar os aliases. Vamos criar uma caixa usuário3 e faça um alias da caixa de correio usuário1 na caixa usuário2. E enviar uma carta da caixa usuário3 na caixa usuário1. Neste caso, a carta terá que vir para a caixa usuário2.

Criar um alias

Enviando um email da caixa de correio do user3 para a caixa de correio do user1

Recebendo uma carta na caixa postal do usuário2

Com o trabalho de aliases, também, tudo está em ordem.

Vamos testar o trabalho do servidor de correio através do cliente de correio local. Por exemplo, considere o Mozilla Thunderbird. Vamos criar mais dois usuários: cliente1 e cliente2. Conectaremos uma caixa postal via IMAP, a outra via POP3 e enviaremos uma carta de uma caixa postal para outra.

Conectando-se por IMAP

Conexão POP3

Enviamos uma carta do Cliente 1 para o Cliente 2.

Despacho do Cliente 1

Receber no Cliente 2

E na ordem inversa.

Enviando do Cliente 2

Receber no Cliente 1

Tudo está funcionando.

Se você vai para: https://domain/netdata, então você pode observar os gráficos do estado do sistema.

Conclusão

Isso conclui a instalação, configuração e teste do sistema de correio iRedMail. Como resultado, obtivemos um servidor de e-mail completo totalmente gratuito com um certificado SSL válido, dois clientes de e-mail baseados na Web diferentes, dois painéis de controle, bem como anti-spam e antivírus integrados ao e-mail. Se desejar, em vez de clientes de e-mail da Web, você pode usar clientes de e-mail locais, como Microsoft Outlook ou Mozilla Thunderbird. Se você não planeja usar clientes de webmail, não pode instalá-los para não sobrecarregar o servidor ou instalar algo que você goste mais. Pessoalmente, gosto mais do SOGo porque sua interface é otimizada para dispositivos móveis, o que torna muito conveniente visualizar e-mails de um smartphone. O mesmo se aplica ao NetData e ao iRedAdmin, se você não planeja usá-lo, é melhor não instalá-lo. Este sistema de correio não é muito exigente em recursos. Tudo isso roda em um servidor VPS com 1024 MB de RAM e um processador virtual. Se você tiver alguma dúvida sobre este sistema de correio, escreva nos comentários.

P.S. Durante o teste deste produto em vários sistemas operacionais com 1 GB de RAM (Ubuntu, Debian, CentOS), descobriu-se que 1 GB não é suficiente para o ClamAV funcionar. Em quase todos os casos, ao usar 1 GB de memória, o antivírus referia-se a um erro de banco de dados. Ao mesmo tempo, nos sistemas operacionais Debian e Ubuntu, o antivírus simplesmente não verificava o e-mail que passava pelo servidor, caso contrário, tudo funcionava bem. No CentOS, a situação era um pouco diferente. O serviço clamd desligou completamente o sistema, impossibilitando o funcionamento normal do servidor. Ao tentar fazer login nas interfaces da web, o NGINX periodicamente dava erros 502 e 504. O correio também foi enviado através do tempo. Ao mesmo tempo, se você adicionar até 2 GB de RAM, em todos os casos não haverá problemas com a operação do antivírus e do servidor como um todo. O ClamAV escaneou o e-mail que passava pelo servidor de e-mail e escreveu sobre isso nos logs. Ao tentar enviar um vírus em um anexo, o envio foi bloqueado. O consumo de memória foi de aproximadamente 1,2 - 1,7 GB.

O NGINX pode ser usado não apenas como servidor web ou proxy http, mas também para proxy de e-mail via protocolos SMTP, IMAP, POP3. Isso configurará:

• Um único ponto de entrada para um sistema de correio escalável.
• Balanceamento de carga entre todos os servidores de correio.

Este artigo é instalado em um sistema operacional Linux. Como um serviço de correio para o qual as solicitações são enviadas, você pode usar postfix, exim, dovecot, exchange, iredmail assembly e muito mais.

Princípio da Operação

O NGINX aceita solicitações e se autentica no servidor web. Dependendo do resultado da verificação de login e senha, o proxy retornará uma resposta com vários cabeçalhos.

Em caso de sucesso:

Assim, determinamos o servidor e a porta do servidor de correio com base na autenticação. Isso dá muitas oportunidades com o conhecimento adequado de linguagens de programação.

Em caso de falha:

Dependendo do resultado da autenticação e do cabeçalho, o cliente é redirecionado para o servidor de email que precisamos.

Preparação do servidor

Vamos fazer algumas alterações nas configurações de segurança do servidor.

SELinux

Desative o SELinux se estiver usando o CentOS ou se estiver usando este sistema de segurança no Ubuntu:

vi /etc/selinux/config

SELINUX=desativado

Firewall

Se usarmos firewalld(padrão no CentOS):

firewall-cmd --permanent --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp

firewall-cmd --reload

Se usarmos o iptables(padrão no Ubuntu):

iptables -A INPUT -p tcp --dport 25 -j ACCEPT

iptables -A INPUT -p tcp --dport 110 -j ACEITAR

iptables -A INPUT -p tcp --dport 143 -j ACEITAR

apt-get install iptables-persistent

iptables-save > /etc/iptables/rules.v4

* neste exemplo, permitimos SMTP (25), POP3 (110), IMAP (143).

Instalando o NGINX

Dependendo do sistema operacional, a instalação do NGINX é um pouco diferente.

ou Linux centos:

yum instale o nginx

ou Linux Ubuntu:

apt instalar nginx

Permitimos o início automático do serviço e o iniciamos:

systemctl habilitar nginx

systemctl iniciar nginx

Se o NGINX já estiver instalado no sistema, verifique com quais módulos ele trabalha:

Obteremos uma lista de opções com as quais o servidor web é construído - entre elas devemos ver --com-mail. Se o módulo necessário não estiver presente, você precisa atualizar o nginx

Configurando o NGINX

Abra o arquivo de configuração do nginx e adicione a opção correspondência:

vi /etc/nginx/nginx.conf

correspondência (

auth_http localhost:80/auth.php;

Servidor(
ouça 25;
protocolo smtp;
smtp_auth login simples cram-md5;
}

Servidor(
ouça 110;
protocolo pop3;

}

Servidor(
ouça 143;
protocolimap;
}
}

* Onde:

• nome do servidor— o nome do servidor de correio que será exibido durante a saudação SMTP.
• aut_http— servidor web e URL para solicitação de autenticação.
• proxy_pass_error_message— permite ou nega a exibição de uma mensagem em caso de autenticação malsucedida.
• ouço- a porta na qual os pedidos são ouvidos.
• protocoloé o protocolo de aplicativo para o qual a porta correspondente está escutando.
• smtp_auth— métodos de autenticação disponíveis para SMTP.
• pop3_auth— métodos de autenticação disponíveis para POP3.

Na seção http - server adicione:

Servidor(
escute 80 default_server;
escute [::]:80 default_server;
...

Localização ~ \.php$ (
defina $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
inclua fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

Reinicie o servidor nginx:

systemctl reinicie o nginx

Instalando e configurando o PHP

Para realizar a autenticação usando PHP, os seguintes pacotes devem ser instalados no sistema.

Se CentOS:

yum instalar php php-fpm

Se Ubuntu:

apt-get install php php-fpm

Inicie o PHP-FPM:

systemctl habilita php-fpm

systemctl iniciar php-fpm

Autenticação

A verificação de login e senha é realizada por um script, cujo caminho é definido pela opção auth_http. Em nosso exemplo, este é um script PHP.

Um exemplo de um modelo oficial para um script de verificação de login e senha:

vi /usr/share/nginx/html/auth.php

* este script aceita qualquer login e senha e redireciona solicitações para servidores 192.168.1.22 e 192.168.1.33 . Para definir o algoritmo de autenticação, editamos as linhas 61 - 64. As linhas 73 - 77 são responsáveis ​​por retornar os servidores para os quais o redirecionamento está em andamento - neste exemplo, se o login começar com caracteres "a", "c", "f", "g", então o redirecionamento será para o servidor mailhost01, caso contrário, em mailhost02. O mapeamento de nomes de servidores para endereços IP pode ser configurado nas linhas 31, 32, caso contrário, a chamada será feita pelo nome de domínio.

Configuração do servidor de correio

A troca de dados entre o proxy NGINX e o servidor de email está clara. É necessário adicionar à exceção a possibilidade de autenticação pelo mecanismo PLAIN. Por exemplo, para configurar o pombal, faça o seguinte:

vi /etc/dovecot/conf.d/10-auth.conf

Adicione linhas:

remoto 192.168.1.11 (
disable_plaintext_auth = não
}

* neste exemplo, permitimos solicitações PLAIN para autenticação do servidor 192.168.1.11 .

Verificamos também:

* E se SSL importará requeridos, a verificação não funcionará, pois, por um lado, o servidor permite solicitações claras, mas requer criptografia SSL.

Reinicie o serviço Dovecot:

systemctl reiniciar pombal

Configuração do cliente

Você pode continuar verificando nossas configurações de proxy. Para fazer isso, nas configurações do cliente, especifique o endereço ou nome do servidor nginx como IMAP/POP2/SMTP, por exemplo:

* neste exemplo, o cliente de email está configurado para se conectar ao servidor 192.168.1.11 por portas abertas 143 (IMAP) e 25 (SMTP).

Criptografia

Agora vamos configurar uma conexão SSL. Nginx deve ser construído com um módulo mail_ssl_module- verifique com o comando:

Na ausência do módulo necessário, reconstruímos o nginx.

Após editar nosso arquivo de configuração:

vi /etc/nginx/nginx.conf

correspondência (
server_name mail.domain.local;
auth_http localhost/auth.php;

proxy_pass_error_message ativado;

SSL ativado;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache compartilhado:SSL:10m;
ssl_session_timeout 10m;

Servidor(
ouça 110;
protocolo pop3;
pop3_auth simples apop cram-md5;
}

Servidor(
ouça 143;
protocolimap;
}

Motivo: O sistema de segurança SELinux é acionado.

Solução: desative ou configure o SELinux.