Nginx câștigă rapid popularitate, transformându-se dintr-un simplu accelerator de livrare static pentru Apache într-un server web complet funcțional și dezvoltat, care este din ce în ce mai folosit izolat. În acest articol vom vorbi despre scenarii interesante și non-standard pentru utilizarea nginx care vă vor permite să profitați la maximum de serverul dvs. web.
Proxy de e-mailSă începem cu cel mai evident - cu capacitatea nginx de a acționa ca un proxy de e-mail. Această funcție este prezentă inițial în nginx, dar din anumite motive este folosită în producție extrem de rar; unii oameni nici măcar nu sunt conștienți de existența ei. Oricum ar fi, nginx acceptă proxy protocoale POP3, IMAP și SMTP cu metode diferite autentificare, inclusiv SSL și StartTLS, și o face foarte repede.
De ce este necesar acest lucru? Există cel puțin două utilizări pentru această funcționalitate. În primul rând: utilizați nginx ca scut împotriva spammerilor enervanti care încearcă să trimită e-mailuri nedorite prin serverul nostru SMTP. De obicei, spammerii nu creează multe probleme, deoarece sunt respinși rapid în etapa de autentificare, totuși, atunci când sunt într-adevăr foarte mulți, nginx va ajuta la economisirea resurselor procesorului. În al doilea rând: utilizați nginx pentru a redirecționa utilizatorii către mai multe servere de e-mail POP3/IMAP. Desigur, un alt proxy de e-mail ar putea gestiona acest lucru, dar de ce să îndepărtezi serverele dacă nginx este deja instalat pe front end pentru a servi conținut static prin HTTP, de exemplu?
Serverul proxy de e-mail din nginx nu este destul de standard. Utilizează un strat suplimentar de autentificare implementat folosind HTTP și numai dacă utilizatorul trece de această barieră i se permite să continue. Această funcționalitate este furnizată prin crearea unei pagini/script către care nginx trimite datele utilizatorului și returnează un răspuns sub formă de OK standard sau un motiv de refuz (cum ar fi „Autentificare sau parolă nevalidă”). Scriptul rulează cu următoarele antete:
Date de intrare din scriptul de autentificare HTTP_AUTH_USER: utilizator HTTP_AUTH_PASS: parolă HTTP_AUTH_PROTOCOL: protocol de e-mail (IMAP, POP3 sau SMTP)
Și returnează următoarele:
Ieșire script de autentificare HTTP_AUTH_STATUS: OK sau motivul eșecului HTTP_AUTH_SERVER: server de e-mail real pentru a redirecționa HTTP_AUTH_PORT: port server
O caracteristică remarcabilă a acestei abordări este că poate fi folosită nu deloc pentru autentificare în sine, ci pentru a împrăștia utilizatorii pe diferite servere interne, în funcție de numele utilizatorului, datele despre încărcarea curentă pe serverele de e-mail sau chiar prin organizarea unei simple echilibrări a încărcăturii. folosind round-robin . Cu toate acestea, dacă trebuie doar să transferați utilizatori pe un server de e-mail intern, puteți utiliza un stub implementat de nginx însuși în loc de un script real. De exemplu, cel mai simplu proxy SMTP și IMAP din configurația nginx va arăta astfel:
# vi /etc/nginx/nginx.conf mail ( # Adresa scriptului de autentificare auth_http localhost:8080/auth; # Dezactivează comanda XCLIENT, unele servere de e-mail nu o înțeleg xclient off; # Server server IMAP ( asculta 143; protocol imap; proxy activat; ) # Server server SMTP (ascultă 25; protocol smtp; proxy activat; ) )
# vi /etc/nginx/nginx.conf http ( # Maparea către portul dorit al serverului de e-mail în funcție de portul trimis în harta antetului HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport (implicit 25; smtp 25; imap 143; ) # Implementarea autentificării „script” - returnează întotdeauna OK și transferă utilizatorul la serverul de e-mail intern, setând portul dorit folosind serverul de mapare de mai sus ( asculta 8080; locație / auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" „192.168.0.1” ; add_header „Auth-Port” $mailport; returnează 200; ) ) )
Asta este tot. Această configurație vă permite să redirecționați în mod transparent utilizatorii către serverul de e-mail intern, fără a crea supraîncărcare inutile în în acest caz, scenariu. Prin utilizarea unui script, această configurație poate fi extinsă semnificativ: configurați echilibrarea sarcinii, verificați utilizatorii folosind baza de date LDAP și efectuați alte operațiuni. Scrierea scriptului depășește scopul acestui articol, dar este foarte ușor de implementat chiar și cu doar cunoștințe trecătoare de PHP și Python.
Streaming videoEste ușor să configurați găzduirea video obișnuită bazată pe nginx. Tot ce trebuie să faceți este să încărcați videoclipul transcodat într-un director accesibil serverului, să îl înregistrați în config și să configurați playerul Flash sau HTML5 astfel încât să preia videoclipul din acest director. Cu toate acestea, dacă trebuie să configurați difuzarea video continuă de la unii sursă externă sau o cameră web, această schemă nu va funcționa și va trebui să te uiți la protocoale speciale de streaming.
Există mai multe protocoale care rezolvă această problemă, cel mai eficient și suportat dintre ele este RTMP. Singura problemă este că aproape toate implementările de server RTMP suferă de probleme. Oficial Adobe Flash Media Server plătit. Red5 și Wowza sunt scrise în Java și, prin urmare, nu oferă performanța necesară, o altă implementare, Erlyvideo, este scrisă în Erlang, ceea ce este bun în cazul setării unui cluster, dar nu atât de eficient pentru un singur server.
Vă sugerez o abordare diferită - utilizați modulul RTMP pentru nginx. Are performanțe excelente și, de asemenea, vă va permite să utilizați un singur server pentru a servi atât interfața web a site-ului, cât și fluxul video. Singura problemă este că acest modul este neoficial, așa că va trebui să construiți singur nginx cu sprijinul său. Din fericire, asamblarea se realizează într-un mod standard:
$ 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
Acum modulul trebuie configurat. Acest lucru se face, ca de obicei, prin configurația nginx:
Rtmp ( # Activați serverul de difuzare pe portul 1935 la site-ul de adrese/serverul rtmp ( ascultați 1935; aplicația rtmp ( live on ; ) ) )
Modulul RTMP nu poate funcționa într-o configurație cu mai multe fire, așa că numărul de procese de lucru nginx va trebui redus la unul (mai târziu vă voi spune cum să ocoliți această problemă):
Lucrător_procese 1;
Acum puteți salva fișierul și puteți forța nginx să recitească configurația. Configurarea nginx este completă, dar nu avem încă fluxul video în sine, așa că trebuie să-l ducem undeva. De exemplu, să fie acesta fișierul video.avi din directorul curent. Pentru a-l transforma într-un flux și pentru a-l include în difuzorul nostru RTMP, vom folosi FFmpeg vechi:
# ffmpeg -re -i ~/video.avi -c copy -f flv rtmp://localhost/rtmp/stream
Dacă fișierul video nu este în format H264, trebuie să fie recodificat. Acest lucru se poate face din mers folosind același FFmpeg:
# ffmpeg -re -i ~/video.avi -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream
Fluxul poate fi, de asemenea, capturat direct de pe o cameră web:
# ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an -f flv rtmp://localhost/rtmp/stream
Pentru a vizualiza fluxul pe partea client, puteți utiliza orice player care acceptă RTMP, de exemplu mplayer:
$ mplayer rmtp://example.com/rtmp/stream
Sau încorporați playerul direct într-o pagină web, care este deservită de același nginx (exemplu din documentația oficială):
Cel mai simplu player web RTMP
jwplayer("container").setup(( moduri: [( tip: "flash", src: "/jwplayer/player.swf", config: ( lungime buffer: 1, fișier: "stream", streamer: "rtmp:/ /localhost/rtmp", furnizor: "rtmp", ) )] ));
Există doar două linii importante aici: „fișier: „stream””, care indică fluxul RTMP și „streamer: „rtmp://localhost/rtmp””, care indică adresa streamer-ului RTMP. Pentru majoritatea sarcinilor, astfel de setări vor fi destul de suficiente. Puteți trimite mai multe fluxuri diferite la o singură adresă, iar nginx le va multiplexa efectiv între clienți. Dar acest lucru nu este tot ceea ce este capabil modulul RTMP. Cu ajutorul acestuia, de exemplu, puteți organiza o retransmitere a unui flux video de pe un alt server. Serverul FFmpeg nu este deloc necesar pentru aceasta, trebuie doar să adăugați următoarele linii la config:
# vi /etc/nginx/nginx.conf aplicația rtmp (în direct; trageți rtmp://rtmp.example.com; )
Dacă trebuie să creați mai multe fluxuri de calitate diferită, puteți apela transcoderul FFmpeg direct de la nginx:
# vi /etc/nginx/nginx.conf aplicație rtmp ( live on; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) aplicație rtmp-320x240 ( live on; )
Cu această configurație, vom obține simultan doi radiodifuzori, dintre care unul va fi disponibil la adresa rtmp://site/rtmp, iar al doilea, difuzând la calitate 320 x 240, la adresa rtmp://site/rtmp –320x240. Apoi, puteți adăuga un flash player și butoane de selecție a calității pe site, care vor oferi jucătorului una sau alta adresă de difuzor.
Și, în sfârșit, un exemplu de difuzare a muzicii către rețea:
Deși adevărat; 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; Terminat
Git proxySistemul de control al versiunilor Git este capabil să ofere acces la depozite nu numai prin protocoalele Git și SSH, ci și prin HTTP. Pe vremuri, implementarea accesului HTTP era primitivă și incapabil să ofere o muncă cu drepturi depline cu depozitul. Cu versiunea 1.6.6, situația s-a schimbat, iar astăzi acest protocol poate fi folosit, de exemplu, pentru a ocoli restricțiile firewall de pe ambele părți ale conexiunii sau pentru a crea propria găzduire Git cu o interfață web.
Din păcate, documentația oficială vorbește doar despre organizarea accesului la Git folosind Server web Apache, dar deoarece implementarea în sine este o aplicație externă cu o interfață CGI standard, aceasta poate fi atașată la aproape orice alt server, inclusiv lighttpd și, desigur, nginx. Acest lucru nu necesită nimic în afară de serverul în sine, Git instalat și un mic server FastCGI fcgiwrap, care este necesar deoarece nginx nu știe cum să lucreze direct cu CGI, dar poate apela scripturi folosind protocolul FastCGI.
Întreaga schemă de lucru va arăta astfel. Serverul fcgiwrap se va bloca în fundal și va aștepta o solicitare pentru a executa aplicația CGI. Nginx, la rândul său, va fi configurat să solicite execuția binarului CGI git-http-backend prin interfața FastCGI de fiecare dată când este accesată adresa pe care o specificăm. La primirea unei cereri, fcgiwrap execută git-http-backend cu argumentele CGI specificate transmise de clientul GIT și returnează rezultatul.
Pentru a implementa o astfel de schemă, mai întâi instalați fcgiwrap:
$ sudo apt-get install fcgiwrap
Nu este nevoie să-l configurați; toți parametrii sunt transmisi prin protocolul FastCGI. De asemenea, se va lansa automat. Prin urmare, tot ce rămâne este să configurați nginx. Pentru a face acest lucru, creați un fișier /etc/nginx/sites-enabled/git (dacă nu există un astfel de director, puteți scrie în configurația principală) și scrieți următoarele în el:
# vi /etc/nginx/sites-enabled/git server ( # Suntem agățați de portul 8080, ascultați 8080; # Adresa serverului nostru (nu uitați să adăugați o intrare în 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; # Adresa principală pentru locația de acces anonimă / ( # Când încercați să descărcați, trimiteți utilizatorul la o adresă privată dacă ($ arg_service ~* "git-receive-pack") ( rescrie ^ /private$uri ultimul; ) include /etc/nginx/fastcgi_params; # Adresa git-http-backend-ul nostru fastcgi_param SCRIPT_FILENAME /usr/lib/git-core/git- http-backend; # adresa depozitului Git fastcgi_param GIT_PROJECT_ROOT /srv/git; # Adresa fișierului fastcgi_param PATH_INFO $uri; # adresa serverului fcgiwrap fastcgi_pass 127.0.0.1:9001; ) # adresa de acces la scriere locație ~/private(/.* )$ ( # Permisiuni utilizator auth_basic "git anonimă doar citire, scriere autentificată"; # Autentificare HTTP bazată pe htpasswd auth_basic_user_file /etc/nginx/htpasswd; # Setările FastCGI includ /etc/nginx/fastcgi_paramsscgi ; 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; ) )
Această configurație presupune trei lucruri importante:
Asta e tot, reporniți nginx:
MicrocachingSă ne imaginăm o situație cu un site web dinamic, actualizat frecvent, care brusc începe să primească încărcături foarte grele (ei bine, a ajuns pe pagina unuia dintre cele mai mari site-uri de știri) și încetează să facă față revenirii conținutului. Optimizarea și implementarea corectă a schemei corecte de cache va dura mult timp, iar problemele trebuie rezolvate acum. Ce putem face?
Există mai multe modalități de a ieși din această situație cu cele mai puține pierderi, dar cea mai interesantă idee a fost propusă de Fenn Bailey (fennb.com). Ideea este să puneți pur și simplu nginx în fața serverului și să îl forțați să memoreze în cache tot conținutul transmis, dar nu doar cache, ci doar pentru o secundă. Întorsătura aici este că sute și mii de vizitatori ai site-ului pe secundă vor genera, de fapt, o singură solicitare către backend, primind în mare parte o pagină în cache. În același timp, aproape nimeni nu va observa diferența, deoarece chiar și pe un site dinamic o secundă de obicei nu înseamnă nimic.
Configurația cu implementarea acestei idei nu va părea atât de complicată:
# vi /etc/nginx/sites-enabled/cache-proxy # Configurare cache proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m; server ( asculta 80; server_name example.com; # Locația adresei stocate în cache / ( # Cache-ul este activat în mod implicit setat $no_cache ""; # Dezactivează memoria cache pentru toate metodele, cu excepția GET și HEAD dacă ($request_method !~ ^(GET|HEAD) $) ( setați $no_cache „1”; ) # Dacă clientul încarcă conținut pe site (no_cache = 1), ne asigurăm că datele care i-au fost date nu sunt stocate în cache timp de două secunde și el poate vedea rezultatul descărcării if ($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 "; ) # Activați/dezactivați memoria cache în funcție de starea variabilei no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Solicitări proxy către serverul real proxy_pass http://appserver.example.ru; proxy_cache microcache ; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Protecție împotriva problemei turmei Thundering actualizare proxy_cache_use_stale; # Adăugați anteturi standard proxy_set_header Gazdă $gazdă; proxy_set_header X-Real-IP $adresă_la distanță; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Nu păstrăm în cache fișierele mai mari de 1 MB proxy_max_temp_file_size 1M; ) )
Un loc special în această configurație îl ocupă linia „proxy_cache_use_stale updating;”, fără de care am fi primit explozii periodice de încărcare pe serverul backend din cauza solicitărilor primite în timpul actualizării cache-ului. În caz contrar, totul este standard și ar trebui să fie clar, fără explicații inutile.
Aducerea proxy-urilor mai aproape de publicul țintăÎn ciuda creșterii globale pe scară largă a vitezei de internet, distanța fizică a serverului față de publicul țintă continuă să joace un rol. Aceasta înseamnă că, dacă un site rusesc rulează pe un server situat undeva în America, viteza de acces la acesta va fi a priori mai lentă decât cu server rusesc cu aceeași lățime a canalului (desigur, dacă închideți ochii la toți ceilalți factori). Un alt lucru este că plasarea serverelor în străinătate este adesea mai profitabilă, inclusiv în ceea ce privește întreținerea. Prin urmare, pentru a primi profit, sub formă de mai mult viteze mari recul, va trebui să folosești un truc.
Unul dintre opțiuni posibile: plasați principalul server productiv în Occident și implementați un frontend care nu necesită prea multe resurse și care produce statică în Rusia. Acest lucru vă va permite să câștigați viteză fără costuri serioase. Configurația nginx pentru frontend în acest caz va fi o implementare proxy simplă și familiară pentru noi toți:
# vi /etc/nginx/sites-enabled/proxy # Stocați memoria cache timp de 30 de zile într-un spațiu de stocare de 100 GB proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static:32m inactive=30d max_size=100g; server (ascultă 80; server_name example.com; # De fapt, locația noastră proxy ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Adresă backend proxy_pass back.example.com:80; proxy_redirect off; proxy_set_header Gazdă $gazdă; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffer_size; proxy_buffer_size;_16k_size 2_16ks; proxy 2_16k; proxy_cache_valid 30d; proxy_ignore_headers „Cache-Control” „Expiră”; proxy_cache_key „$uri$is_args$args”; proxy_cache_lock on; ) )
concluziiAstăzi, cu ajutorul nginx, puteți rezolva multe probleme diferite, dintre care multe nu au legătură cu serverul web și protocolul HTTP. Proxy-ul de e-mail, serverul de streaming și interfața Git sunt doar câteva dintre aceste sarcini.
Acest articol va explica cum să configurați NGINX Plus sau NGINX Open Source ca proxy pentru un server de e-mail sau un serviciu de e-mail extern.
IntroducereNGINX poate trimite protocoale IMAP, POP3 și SMTP la unul dintre serverele de e-mail din amonte care găzduiesc conturi de e-mail și, astfel, poate fi folosit ca un punct final unic pentru clienții de e-mail. Acest lucru poate aduce o serie de beneficii, cum ar fi:
- scalarea ușoară a numărului de servere de e-mail
- alegerea unui server de e-mail pe baza unor reguli diferite, de exemplu, alegerea celui mai apropiat server pe baza adresei IP a unui client
- distribuirea încărcăturii între serverele de e-mail
NGINX Plus (include deja modulele Mail necesare pentru traficul de e-mail prin proxy) sau NGINX Open Source au compilat modulele Mail folosind parametrul --with-mail pentru funcționalitatea proxy de e-mail și parametrul --with-mail_ssl_module pentru suport SSL/TLS:
$ ./configure --with-mail --with-mail_ssl_module --with-openssl=[ DIR] /openssl-1.1.1
IMAP, POP3 și/sau E-mail SMTP servere sau un serviciu de e-mail extern
În fișierul de configurare NGINX:
Poștă ( #... )
mail (nume_server mail.example.com; #...)
mail (nume_server mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; #...)
Alternativ, specificați dacă să informați un utilizator despre erorile de la serverul de autentificare specificând directiva proxy_pass_error_message. Acest lucru poate fi util atunci când o cutie poștală rămâne fără memorie:
mail (server_name mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message activat; #...)
Configurați fiecare server SMTP, IMAP sau POP3 cu blocurile de server. Pentru fiecare server, specificați:
- cel numarul portului care corespund protocolului specificat cu directiva listen
- cel protocol cu directiva de protocol (dacă nu este specificat, va fi detectat automat din portul specificat în directiva de ascultare)
- permis metode de autentificare cu directivele imap_auth , pop3_auth și 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 ; )
Configurarea autentificării pentru un proxy de e-mailFiecare cerere POP3/IMAP/SMTP de la client va fi mai întâi autentificată pe un server de autentificare HTTP extern sau printr-un script de autentificare. Deținerea unui server de autentificare este obligatorie pentru serverul de e-mail proxy NGINX. Serverul poate fi creat de dvs. în conformitate cu protocolul de autentificare NGINX care se bazează pe protocolul HTTP.
Dacă autentificarea are succes, serverul de autentificare va alege un server din amonte și va redirecționa cererea. În acest caz, răspunsul de la server va conține următoarele rânduri:
HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # numele serverului sau adresa IP a serverului upstream care va fi folosit pentru procesarea e-mailului Auth-Port: # portul serverului upstream
Dacă autentificarea eșuează, serverul de autentificare va returna un mesaj de eroare. În acest caz, răspunsul de la server va conține următoarele rânduri:
HTTP/1.0 200 OK Stare de autentificare: # un mesaj de eroare care trebuie returnat clientului, de exemplu „Autentificare sau parolă nevalidă” Așteptare de autentificare: # numărul de încercări de autentificare rămase până la închiderea conexiunii
Rețineți că în ambele cazuri răspunsul va conține HTTP/1.0 200 OK care ar putea fi confuz.
Pentru mai multe exemple de cereri și răspunsuri de la serverul de autentificare, consultați modulul ngx_mail_auth_http_ din documentația de referință NGINX.
Configurarea SSL/TLS pentru un proxy de e-mailFolosind POP3/SMTP/IMAP peste SSL/TLS, vă asigurați că datele transmise între un client și un server de e-mail sunt securizate.
Pentru a activa SSL/TLS pentru proxy-ul de e-mail:
Asigurați-vă că NGINX este configurat cu suport SSL/TLS tastând comanda nginx -V în linia de comandă și apoi căutând linia with --mail_ssl_module în rezultat:
$ nginx -V configurați argumente: ... cu--mail_ssl_module
Asigurați-vă că ați obținut certificate de server și o cheie privată și puneți-le pe server. Un certificat poate fi obținut de la o autoritate de certificare (CA) de încredere sau poate fi generat folosind o bibliotecă SSL, cum ar fi OpenSSL.
ssl activat;
starttls pe ;
Adăugați certificate SSL: specificați calea către certificate (care trebuie să fie în format PEM) cu directiva ssl_certificate și specificați calea către cheia privată în directiva ssl_certificate_key:
mail ( #... ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server.key ; )
Puteți utiliza numai versiuni și cifruri puternice ale SSL/TLS cu directivele ssl_protocols și ssl_ciphers sau vă puteți seta propriile protocoale și cifruri preferate:
mail ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )
Optimizarea SSL/TLS pentru Mail ProxyAceste sugestii vă vor ajuta să vă faceți proxy-ul de e-mail NGINX mai rapid și mai sigur:
Setați numărul de procese de lucru egal cu numărul de procesoare cu directiva worker_processes setată la același nivel cu contextul de e-mail:
worker_proceses auto ; Poștă ( #... )
Activați memoria cache de sesiune partajată și dezactivați memoria cache de sesiune încorporată cu auto ; e-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_certificat/ssl_certificat/ssl_certificat/ssl cheie ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache shared:SSL:10m ; ssl_session_timeout 10m ; server (ascultă 25 cratm; protocol; ;) server (ascultă 1 10 ; protocol pop3 ; pop3_auth plain apop cram-md5 ; ) server ( asculta 143 ; protocol imap ; ) )
În acest exemplu, există trei servere proxy de e-mail: SMTP, POP3 și IMAP. Fiecare dintre servere este configurat cu suport SSL și STARTTLS. Parametrii sesiunii SSL vor fi stocați în cache.
Serverul proxy folosește serverul de autentificare HTTP – configurația sa depășește domeniul de aplicare al acestui articol. Toate mesajele de eroare de la server vor fi returnate clienților.
Nginx este un server web mic, foarte rapid, destul de funcțional și server proxy de e-mail, dezvoltat de Igor Sysoev (rambler.ru). Datorită consumului foarte scăzut de resurse de sistem și vitezei de operare, precum și flexibilității de configurare, web Serverul Nginx adesea folosit ca interfață pentru servere mai grele, cum ar fi Apache, în proiecte cu sarcină mare. Opțiunea clasică este combinația, Nginx - Apache - FastCGI. Lucrând într-o astfel de schemă, Serverul Nginx, acceptă toate cererile care vin prin HTTP și, în funcție de configurație și de cererea în sine, decide dacă procesează cererea în sine și oferă clientului un răspuns gata sau trimite cererea de procesare către unul dintre backend-uri ( Apache sau FastCGI).
După cum știți, serverul Apache procesează fiecare cerere într-un proces separat (thread), care, trebuie spus, consumă o cantitate destul de mică de resurse de sistem, dacă există 10-20 de astfel de procese, este o prostie, iar dacă există 100-500 sau mai mult, sistemul devine deloc distractiv.
Să încercăm să ne imaginăm o situație similară. Să presupunem că pe Apache vine 300 solicitări HTTP de la clienți, 150 de clienți sunt pe linii închiriate rapide, iar ceilalți 150 sunt pe canale de Internet relativ lente, chiar dacă nu pe modemuri. Ce se întâmplă în această situație? Și se întâmplă următoarele: serverul web Apache, pentru a procesa aceste 300 de conexiuni, creează un proces (thread) pentru fiecare, va genera conținut rapid, iar 150 de clienți rapidi vor prelua imediat rezultatul solicitărilor lor, procesele servindu-le. vor fi ucise și resursele vor fi eliberate, iar 150 sunt lente și vor primi rezultatele cererilor lor încet, datorită canalului îngust de internet, ca urmare a căruia 150 de procese vor bloca în sistem Apache, așteptând ca clienții să preia conținutul generat de serverul web, devorând o mulțime de resurse de sistem. Desigur, situația este ipotetică, dar cred că esența este clară. Pachetul ajută la corectarea situației descrise mai sus. După citirea întregii cereri de la client, acesta o depune spre procesare Apache, care la rândul său generează conținut și returnează răspunsul gata lui Nginx cât mai repede posibil, după care poate ucide procesul cu conștiința curată și eliberează resursele de sistem pe care le ocupă. Serverul web Nginx, care primește rezultatul solicitării de la Apache, îl scrie într-un buffer sau chiar într-un fișier de pe disc și îl poate oferi clienților lenți atât timp cât se dorește, în timp ce procesele sale de lucru consumă atât de puține resurse încât .. „chiar e amuzant să vorbești despre asta” ©. :) Această schemă economisește semnificativ resursele sistemului, repet, dar procesele de lucru Nginx consumă o cantitate mică de resurse, acest lucru este valabil mai ales pentru proiectele mari.
Și aceasta este doar o mică parte din ceea ce poate face serverul Nginx; nu uitați de capabilitățile de stocare în cache a datelor și de lucru cu memcached. Voi da o listă cu principalele funcţionalitate Server web Nginx.
Funcționalitatea serverului Nginx ca server HTTP- Procesare de conținut static, fișiere index, listare directoare, cache de descriptor de fișier deschis;
- Proxy accelerat cu stocare în cache, distribuție a sarcinii și toleranță la erori;
- Suport accelerat FastCGI servere cu stocare în cache, distribuție de încărcare și toleranță la erori;
- Structură modulară, suport pentru diverse filtre (SSI, XSLT, GZIP, reluare, răspunsuri fragmentate);
- Suport pentru extensii SSL și TLS SNI;
- Bazat pe IP sau Pe bază de nume servere virtuale;
- Lucrul cu KeepAlive și conexiuni prin conducte;
- Abilitatea de a configura orice timeout-uri, precum și numărul și dimensiunea bufferelor, la nivel server Apache;
- Efectuarea diferitelor actiuni in functie de adresa clientului;
- Schimbarea URI-urilor folosind expresii regulate;
- Pagini de eroare speciale pentru 4xx și 5xx;
- Restricționarea accesului pe baza adresei clientului sau a parolei;
- Configurarea formatelor de fișiere jurnal, rotirea jurnalelor;
- Limitarea vitezei de răspuns către client;
- Limitarea numărului de conexiuni și solicitări simultane;
- Suportă metodele PUT, DELETE, MKCOL, COPY și MOVE;
- Modificarea setărilor și actualizarea serverului fără a opri munca;
- Incorporat Perl;
- Redirecționarea către backend IMAP/POP3 utilizând un server de autentificare HTTP extern;
- Verificarea SMTP-ului utilizatorului pe un server de autentificare HTTP extern și redirecționarea către un server SMTP intern;
- Acceptă următoarele metode de autentificare:
- POP3 - UTILIZATOR/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
- IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
- SMTP - AUTH LOGI/ PLAIN/CRAM-MD5;
- suport SSL;
- Suport STARTTLS și STLS;
- FreeBSD, de la 3 la 8 - platforme, i386 și amd64;
- Linux, de la 2.2 la 2.6 - platforma i386; Linux 2.6 - amd64;
- Solaris 9 - platforme i386 și sun4u; Solaris 10 - platforme i386, amd64 și sun4v;
- Platforme MacOS X ppc, i386;
- Windows XP, Windows Server 2003; (în prezent în testare beta)
- Procesul principal (master), mai multe procese de lucru (configurate în fișierul de configurare) care rulează sub un utilizator neprivilegiat;
- Suport pentru următoarele metode de procesare a conexiunii:
- Selectați - metoda standard. Modulul Nginx corespunzător este construit automat dacă nu se găsește o metodă mai eficientă pe o anumită platformă. Puteți forța construirea unui anumit modul să fie activată sau dezactivată folosind opțiunile de configurare --with-select_module sau --without-select_module.
- sondajul este metoda standard. Modulul Nginx corespunzător este construit automat dacă nu se găsește o metodă mai eficientă pe o anumită platformă. Puteți forța construirea unui anumit modul să fie activată sau dezactivată folosind opțiunile de configurare --with-poll_module sau --without-poll_module.
- kqueue este o metodă eficientă folosită pe sistemele de operare FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 și MacOS X. Când este utilizat pe mașini cu procesor dublu care rulează MacOS X, poate provoca o panică a nucleului.
- epoll este o metodă eficientă folosită în Linux 2.6+. Unele distribuții, cum ar fi SuSE 8.2, au patch-uri pentru a suporta epoll în nucleul 2.4.
- rtsig - semnale în timp real, o metodă eficientă folosită în Linux 2.2.19+. În mod implicit, nu pot exista mai mult de 1024 de semnale în coadă pentru întregul sistem. Acest lucru nu este suficient pentru serverele cu încărcare mare; dimensiunea cozii trebuie mărită folosind parametrul kernel /proc/sys/kernel/rtsig-max. Cu toate acestea, începând cu Linux 2.6.6-mm2, această opțiune nu mai este disponibilă, în schimb fiecare proces are o coadă de semnale separată, a cărei dimensiune este determinată folosind RLIMIT_SIGPENDING.
- Când coada este plină, server nginxîl resetează și procesează conexiunile folosind metoda sondajului până când situația revine la normal.
- /dev/poll este o metodă eficientă, acceptată pe sistemele de operare Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ și Tru64 UNIX 5.1A+.
- eventport - porturi de evenimente, o metodă eficientă utilizată în Solaris 10. Înainte de utilizare, trebuie să instalați un patch pentru a evita panica nucleului.
- Utilizarea capabilităților metodei kqueue, cum ar fi EV_CLEAR, EV_DISABLE (pentru a dezactiva temporar un eveniment), NOTE_LOWAT, EV_EOF, numărul de date disponibile, codurile de eroare;
- Funcționează cu sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) și sendfilev (Solaris 8 7/01+);
- Suport pentru accept filtre (FreeBSD 4.1+) și TCP_DEFER_ACCEPT (Linux 2.4+);
- 10.000 de conexiuni HTTP inactive de menținere în viață consumă aproximativ 2,5 milioane de memorie;
- Număr minim de operațiuni de copiere a datelor;
iRedMail este un server de e-mail open source gata făcut. Ansamblul se bazează pe serverul Postfix SMTP (Mail Transfer Agent, prescurtat ca MTA). Ansamblul include și: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData și NGINX.
Dovecot - server IMAP/POP3.
Spamassassin este un instrument de filtrare a spam-ului.
Greylist este un instrument anti-spam bazat pe liste gri.
ClamAV este un antivirus.
Roundcube și SOGo sunt clienți web pentru lucrul cu e-mailul.
NetData este un program de monitorizare a serverului în timp real.
Nginx este un server web.
Suportă sisteme de operare: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 și OpenBSD 6.4.
iRedMail are versiuni plătite și gratuite, care diferă unele de altele prin funcționalitatea propriei interfețe web a ansamblului de e-mail iRedAdmin. În demon versiunea platita Puteți crea doar domenii, căsuțe poștale de utilizator și administrator. Dacă trebuie să creați un alias, nu veți mai putea face acest lucru în versiunea gratuită prin iRedAdmin. Din fericire, există o soluție gratuită numită PostfixAdmin care vă permite să faceți acest lucru. PostfixAdmin se integrează cu ușurință în iRedMail și funcționează excelent cu acesta.
InstalarePentru a instala, vom avea nevoie de unul dintre sistemele de operare enumerate mai sus. Voi folosi Ubuntu Server 18.04. De asemenea, trebuie să aveți un nume de domeniu achiziționat și o zonă DNS configurată. Dacă utilizați serverul DNS al registratorului de domenii, atunci trebuie să faceți două înregistrări în secțiunea de gestionare a zonei de domeniu: A și MX. De asemenea, puteți utiliza propriul DNS prin configurarea delegării în contul personal al registratorului de nume de domeniu.
Configurarea unei zone de domeniu atunci când utilizați un registrator DNS
Notă! Ora de intrare Setări DNS care durează de la câteva ore până la o săptămână. Până la intrarea în vigoare a setărilor, serverul de e-mail nu va funcționa corect.
Pentru a instala, descărcați versiunea actuală de pe site-ul iRedMail. În prezent este 0.9.9.
# wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.9.tar.bz2
Apoi despachetați arhiva descărcată.
# tar xjf iRedMail-0.9.9.tar.bz2
Despachetarea arhivei
Și accesați folderul creat.
# cd iRedMail-0.9.9
folderul de instalare iRedMail
Verificarea conținutului folderului
Conținutul folderului
Și rulați scriptul de instalare iRedMail.
# bash iRedMail.sh
Instalarea sistemului de e-mail va începe. În timpul procesului de instalare, va trebui să răspundeți la o serie de întrebări. Suntem de acord să începem instalarea.
Începe instalarea
Selectarea directorului de instalare
Acum trebuie să selectați un server web. Nu există prea multe de ales, așa că alegem NGINX.
Selectarea unui server web
Acum trebuie să selectați un server de bază de date care va fi instalat și configurat pentru a funcționa cu sistemul de e-mail. Selectați MariaDB.
Selectarea unui server de baze de date
Setați parola root pentru baza de date.
Crearea unei parole de rădăcină a bazei de date
Acum indicăm domeniul nostru de e-mail.
Crearea unui domeniu de e-mail
Apoi creăm o parolă pentru căsuța poștală a administratorului [email protected].
Crearea unei parole de administrator de e-mail
Selectarea componentelor web
Confirmați setările specificate.
Confirmarea setărilor
Instalarea a început.
Instalare
Odată ce instalarea este finalizată, confirmați crearea regulii iptables pentru SSH și reporniți firewall-ul. iRedMail funcționează cu iptables. În Ubuntu, cel mai frecvent utilizat utilitar de gestionare a firewall-ului este UFW. Dacă dintr-un motiv sau altul aveți o astfel de nevoie, atunci instalați UFW (apt install ufw) și adăugați reguli pentru ca UFW (exemplu: ufw allow "Nginx Full" sau ufw allow Postfix) să nu blocheze activitatea serverului de e-mail. Puteți vizualiza lista de reguli disponibile executând comanda: ufw app list . Apoi activați UFW: activați ufw.
Crearea unei reguli iptables
Repornirea paravanului de protecție
Aceasta completează instalarea iRedMail. Sistemul ne-a furnizat adrese de interfață web și acreditări de conectare. Pentru a activa toate componentele sistemului de e-mail, trebuie să reporniți serverul.
Instalare finalizată
Să repornim.
# reporniți
Mai întâi trebuie să vă asigurați că totul funcționează. Să încercăm să ne logăm în panoul de control iReadAdmin la https://domain/iredadmin. Autentificare [email protected], parolă creată în timpul instalării. Există o interfață în limba rusă.
După cum puteți vedea, totul funcționează. Când vă conectați la iRedAdmin, cel mai probabil ați primit o eroare de securitate legată de certificat. Acest lucru se întâmplă deoarece iRedMail are încorporat un certificat autosemnat, despre care browserul se plânge. Pentru a rezolva această problemă, trebuie să instalați un certificat SSL valid. Dacă aveți unul achiziționat, îl puteți instala. În exemplu, voi instala SSL gratuit de la Let's Encrypt.
Instalarea unui certificat SSL Let's EncryptVom instala certificatul folosind utilitarul certbot. Mai întâi, să adăugăm un depozit.
# add-apt-repository ppa:certbot/certbot
Apoi vom instala certboot-ul propriu-zis cu componentele necesare.
# apt install python-certbot-nginx
Primim un certificat.
# certbot --nginx -d domain.ru
După rularea comenzii, sistemul vă va cere să introduceți adresa de e-mail, introduceți. Ulterior, cel mai probabil veți primi o eroare că nu este posibil să găsiți blocul de server pentru care a fost generat certificatul. În acest caz, acest lucru este normal, deoarece nu avem niciun bloc de server. Principalul lucru pentru noi este să obținem un certificat.
Obținerea unui certificat
După cum putem vedea, certificatul a fost primit cu succes, iar sistemul ne-a arătat căile către certificat în sine și către cheie. Sunt exact ceea ce avem nevoie. În general, am primit 4 fișiere care vor fi stocate în folderul „/etc/letsencrypt/live/domain”. Acum trebuie să informăm serverul web despre certificatul nostru, adică să înlocuim certificatul încorporat cu cel pe care tocmai l-am primit. Pentru a face acest lucru, trebuie să edităm un singur fișier.
# nano /etc/nginx/templates/ssl.tmpl
Și schimbăm ultimele două rânduri din el.
Înlocuirea certificatului SSL
Schimbăm căile din fișier în căile pe care ni le-a spus sistemul la primirea certificatului.
Înlocuirea unui certificat SSL
Și reporniți NGINX.
# service nginx restart
Acum să încercăm să ne conectăm din nou la iRedAdmin.
Se verifică certificatul SSL
Nu mai există nicio eroare de certificat. Certificatul este valabil. Puteți face clic pe lacăt și puteți vedea proprietățile acestuia. Când certificatul expiră, certboot ar trebui să-l reînnoiască automat.
Acum vom raporta despre certificatul Dovecot și Postfix. Pentru a face acest lucru, vom edita două fișiere de configurare. Noi facem:
# nano /etc/dovecot/dovecot.conf
Găsirea blocului:
#SSL: setări globale.
Și schimbăm certificatul înregistrat acolo cu al nostru.
Certificat de înlocuire pentru Dovecot
De asemenea, acordați atenție liniei „ssl_protocols”. Valoarea sa trebuie să fie „!SSLv3”, altfel veți primi eroarea „Avertisment: SSLv2 nu este acceptat de OpenSSL. Vă rugăm să luați în considerare eliminarea lui din ssl_protocols” când reporniți Dovecot.
# nano /etc/postfix/main.cf
Găsirea blocului:
# Cheie SSL, certificat, CA
Și schimbăm căile din acesta pe calea către fișierele certificatului nostru.
Înlocuirea unui certificat pentru Postfix
Aceasta completează instalarea certificatului. Este necesar să reporniți Dovecot și Postfix, dar este mai bine să reporniți serverul.
# service cot restart
# reporniți
Instalarea PHPMyAdminAcest pas este opțional, dar vă recomand să îl faceți și să instalați PHPMyAdmin pentru a lucra ușor cu bazele de date.
# apt install phpmyadmin
Programul de instalare va întreba cu ce server web să configureze PHPMyAdmin pentru a lucra, deoarece NGINX nu este în această listă, trebuie doar să apăsați TAB și să continuați.
Instalarea PHPMyAdmin
După finalizarea instalării, pentru ca phpmyadmin să funcționeze, trebuie să faceți un link simbolic către directorul cu care funcționează implicit NGINX.
# ln -s /usr/share/phpmyadmin /var/www/html
Și încercăm să mergem la https://domain/phpmyadmin/
PHPMyAdmin rulează. Conexiunea este protejată de un certificat, nu există erori. Daţi-i drumul. Să creăm un administrator de baze de date MySQL (MariaDB).
# mysql
Și ajungem la consola de management MariaDB. Apoi, rulăm comenzile una câte una:
MariaDB > CREAȚI UTILIZATOR „admin”@”localhost” IDENTIFICAT DE „parolă”;
MariaDB > ACORDĂ TOATE PRIVILEGIILE PE *.* CĂTRE „admin”@”localhost” CU OPȚIUNEA DE ACCORDARE;
MariaDB > PRIVILEGII FLUSH;
Crearea unui utilizator MySQL
Totul este în regulă, autentificarea este completă. PHPMyAdmin este gata de funcționare.
Instalarea PostfixAdminÎn principiu, PostfixAdmin, la fel ca PHPMyAdmin, nu trebuie să fie instalat. Serverul de e-mail va funcționa bine fără aceste componente. Dar atunci nu veți putea crea aliasuri de e-mail. Dacă nu aveți nevoie de acest lucru, atunci puteți sări peste aceste secțiuni în siguranță. Dacă mai aveți nevoie de aliasuri, atunci aveți două opțiuni: achiziționarea versiunii plătite a iReaAdmin sau instalarea PostfixAdmin. Desigur, puteți face acest lucru fără software suplimentar, înregistrând manual aliasuri în baza de date, dar acest lucru nu este întotdeauna convenabil și nu este potrivit pentru toată lumea. Recomand să folosiți PostfixAdmin; ne vom uita acum la instalarea și integrarea acestuia cu iRedMail. Să începem instalarea:
# apt install postfixadmin
Suntem de acord și creăm o parolă pentru baza de date de sistem a programului.
Instalarea PostfixAdmin
Instalarea PostfixAdmin
Creăm un link simbolic în același mod ca și instalarea PHPMyAdmin.
# ln -s /usr/share/postfixadmin /var/www/html
Facem utilizatorul în numele căruia este lansat serverul web proprietarul directorului. În cazul nostru, NGINX este lansat ca utilizator www-data.
# chown -R www-data /usr/share/postfixadmin
Acum trebuie să edităm fișierul de configurare PostfixAdmin și să adăugăm informații despre baza de date pe care o folosește iRedAdmin. În mod implicit, această bază de date se numește vmail. Dacă accesați PHPMyAdmin, îl puteți vedea acolo. Și astfel, pentru ca PostfixAdmin să poată face modificări în baza de date, o înregistrăm în configurația PostfixAdmin.
# nano /etc/postfixadmin/config.inc.php
Găsim liniile:
$CONF["database_type"] = $dbtype;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["database_password"] = $dbpass;
$CONF["database_name"] = $dbname;
Și să-l aducem în minte:
$CONF["database_type"] = "mysqli"; # Tipul bazei de date
$CONF["database_host"] = "localhost"; # Gazdă pentru serverul bazei de date
$CONF["database_user"] = "administrator"; # Conectați-vă cu drepturi de a scrie în baza de date vmail. Puteți folosi administratorul creat anterior
$CONF["database_password"] = "parola"; # Parola pentru utilizatorul specificat mai sus
$CONF["database_name"] = "vmail"; # Numele bazei de date iRedMail
Introducerea informațiilor despre baza de date
Dacă intenționați să utilizați clientul de e-mail web SOGo, atunci trebuie să faceți încă un pas suplimentar, și anume să schimbați criptarea PostfixAdmin în elementul $CONF["encrypt"] din "md5crypt" în "dovecot:SHA512-CRYPT" . Dacă nu faceți acest lucru, atunci când încercați să vă conectați la SOGo ca utilizator creat în PostfixAdmin, veți primi o eroare: autentificare sau parolă incorectă.
Schimbarea tipului de criptare
Acum, pentru a finaliza cu succes instalarea și a nu primi erori, trebuie să executați o interogare la baza de date. Este convenabil să faceți acest lucru prin PHPMyAdmin. Selectați baza de date vmail și accesați fila SQL. In fereastra intram:
DROP INDEX domeniul pe căsuța poștală;
DROP INDEX domeniul pe alias;
ALTER TABLE alias ADD COLUMN `goto` text NOT NULL;
Interogare baza de date
Și faceți clic pe „Înainte”. Acum suntem cu toții pregătiți, putem merge la interfața web PostfixAdmin și putem finaliza instalarea. Pentru a face acest lucru, trebuie să tastați în browser: https://domain/postfixadmin/setup.php.
Ar trebui să apară următoarele:
Instalarea PostfixAdmin
Dacă totul se face conform instrucțiunilor, atunci nu ar trebui să existe erori. Dacă există, atunci acestea trebuie eliminate, altfel sistemul nu vă va permite să continuați. Setați parola de instalare și faceți clic pe „Generează parola hash”. Sistemul va genera un hash al parolei, care trebuie inserat în parametrul $CONF["setup_password"].
Finalizarea instalării PostfixAdmin
Modificarea setărilor fișierului de configurare
Acum introduceți parola nou creată și creați administratorul PostfixAdmin. Este mai bine să nu creați un administrator cu autentificarea postmaster, deoarece pot apărea probleme de conectare la panoul de administrare iRedAdmin.
Crearea unui Administrator PostfixAdmin
Asta e, administratorul a fost creat. Vă puteți conecta.
Vă rugăm să rețineți că din punct de vedere al securității, este mai bine să redenumiți sau să ștergeți fișierul setup.php din directorul postfixadmin.
Accesați: https://domain/postfixadmin/ și introduceți acreditările nou create. În PostfixAdmin, precum și în iRedAdmin, este disponibilă limba rusă. Îl puteți selecta în timpul autorizării.
Încercăm să creăm o cutie poștală de utilizator.
iRedAPD este responsabil pentru gestionarea modulelor iRedMail. Are un fișier de configurare în care sunt înregistrate modulele de lucru. Dacă nu aveți nevoie de un anumit modul, îl puteți elimina din fișierul de configurare și nu va mai funcționa. Noi facem:
# nano /opt/iredapd/settings.py
Găsiți linia „plugin-uri” și eliminați componentele de care nu aveți nevoie. Voi elimina componenta „greylisting”. Desigur, protejează împotriva spam-ului destul de eficient, dar scrisorile necesare adesea nu ajung.
Greylist este o tehnologie automată de protecție împotriva spamului bazată pe analiza comportamentului serverului expeditorului de e-mail. Când „lista gri” este activată, serverul refuză pentru prima dată să accepte o scrisoare de la o adresă necunoscută, raportând o eroare temporară. În acest caz, serverul de trimitere trebuie să repete trimiterea mai târziu. Programele spammer de obicei nu fac acest lucru. Dacă scrisoarea este trimisă din nou, aceasta este adăugată pe listă timp de 30 de zile și schimbul de corespondență are loc prima dată. Decideți singur dacă utilizați acest modul sau nu.
Activarea/Dezactivarea modulelor de e-mail
După ce faceți modificări, trebuie să reporniți iRedAPD.
# service iredapd reporniți
Testarea serverului de mailAceasta completează configurarea serverului de e-mail iRedMail. Puteți trece la etapa finală - testare. Să creăm două cutii poștale. Pentru a verifica unul prin iRedAdmin, al doilea prin PostfixAdmin și trimite o scrisoare de la o cutie poștală la alta și invers. În iRedAdmin vom crea o cutie poștală [email protected]. În PostfixAdmin - [email protected]
Crearea unui utilizator în iRedAdmin
Crearea unui utilizator în PostfixAdmin
Verificăm dacă utilizatorii au fost creați.
Dacă acordați atenție coloanei „Către” din lista de cutii poștale PostfixAdmin, veți observa diferența dintre cutiile poștale create în iRedAdmin și PostfixAdmin. Cutiile poștale create în iRedAdmin sunt marcate ca „Numai Redirecționare”, iar cele create în PostfixAdmin sunt marcate ca „Cutie poștală”. La început nu am putut înțelege mult timp de ce se întâmpla asta și care era diferența dintre ei, iar în cele din urmă am observat un lucru. Cutiile poștale din iRedAdmin sunt create fără aliasuri, iar cutiile poștale din PostfixAdmin sunt create cu un alias propriu.
Și dacă aceste alias-uri sunt șterse, atunci cutiile poștale vor fi afișate ca cele create în iRedAdmin „Numai redirecționare”.
Eliminarea alias-urilor
Aliasurile au fost eliminate. Se verifică PostfixAdmin.
După cum puteți vedea, toate casetele au devenit „Doar înainte”. În același mod, dacă creați un alias pentru dvs. într-o cutie poștală creată în iRedAdmin, acesta va deveni „Mailbox”. În principiu, acest lucru nu afectează în niciun fel performanța e-mailului. Singurul lucru este că nu veți putea crea un alias pe o cutie poștală creată în PostfixAdmin. În loc să creați un alias, va trebui să editați unul existent. Apropo de pseudonime, în versiune noua iRedMail trebuie să facă o modificare la una dintre hărțile Postfix care gestionează aliasuri. Și dacă nu faceți acest lucru, aliasurile create nu vor funcționa. Pentru a face acest lucru, trebuie să corectați următoarele în fișierul /etc/postfix/mysql/virtual_alias_maps.cf:
Noi facem:
# nano /etc/postfix/mysql/virtual_alias_maps.cf
Și o reparăm.
Configurarea alias-urilor
Reporniți Postfix:
# repornire postfix serviciu
După aceasta, totul ar trebui să funcționeze.
Și așa, să începem să verificăm poșta. Ne vom conecta în căsuța poștală user1 prin Roundcube și în căsuța poștală user2 prin SOGo și vom trimite o scrisoare din căsuța poștală user1 către user2 și înapoi.
Trimiterea unui e-mail cu Roundcube
Primirea unei scrisori în SOGo
Trimiterea unui e-mail către SOGo
Primirea unei scrisori în Roundcube
Totul funcționează fără probleme. Livrarea scrisorii durează între două și cinci secunde. În același mod, scrisorile sunt livrate perfect către serverele Yandex și mail.ru (testate).
Acum să verificăm pseudonimele. Să creăm o cutie poștală user3 și să creăm un alias din căsuța poștală user1 la cutia poștală user2. Și vom trimite o scrisoare de la cutia poștală user3 către cutia poștală user1. În acest caz, scrisoarea ar trebui să ajungă la căsuța poștală a utilizatorului2.
Crearea unui alias
Trimiterea unei scrisori de la cutia poștală utilizator3 la căsuța poștală utilizator1
Primirea unei scrisori în căsuța poștală a utilizatorului2
Lucrarea aliasurilor este de asemenea bună.
Să testăm funcționarea serverului de e-mail prin local client de mail. De exemplu, luați în considerare Mozilla Thunderbird. Să mai creăm doi utilizatori: client1 și client2. Vom conecta o cutie poștală prin IMAP, cealaltă prin POP3 și vom trimite o scrisoare de la o cutie poștală la alta.
Conexiune IMAP
Conexiune prin POP3
Trimitem o scrisoare de la Clientul 1 către Clientul 2.
Trimiterea de la clientul 1
Chitanță pe clientul 2
Și în ordine inversă.
Se trimite de la clientul 2
Chitanță pe clientul 1
Totul merge.
Dacă mergeți la adresa: https://domain/netdata, puteți vedea grafice ale stării sistemului.
Aceasta finalizează instalarea, configurarea și testarea sistemului de e-mail iRedMail. Drept urmare, am primit un server de e-mail complet gratuit, cu un certificat SSL valid, doi clienți de e-mail web diferiți, două panouri de control, precum și antispam și antivirus încorporat în e-mail. Dacă doriți, în loc de clienți de e-mail web, puteți utiliza clienți de e-mail locali, cum ar fi Microsoft Outlook sau Mozilla Thunderbird. Dacă nu intenționați să utilizați clienți de e-mail web, nu îi puteți instala deloc, pentru a nu supraîncărca serverul sau pentru a instala ceva care vă place cel mai mult. Personal îmi place mai mult SOGo, deoarece interfața sa este optimizată pentru dispozitive mobile, ceea ce face foarte convenabil să vizualizați e-mailurile de pe smartphone. Același lucru este valabil și pentru NetData și iRedAdmin, dacă nu intenționați să îl utilizați, este mai bine să nu îl instalați. Acest sistem de e-mail nu este foarte solicitant cu resurse. Toate acestea funcționează pentru Server VPS cu 1024 MB de RAM și un procesor virtual. Dacă aveți întrebări despre acest sistem de e-mail, scrieți în comentarii.
P.S. La testarea acestui produs pe diverse sisteme de operare cu 1 GB RAM (Ubuntu, Debian, CentOS), s-a dovedit că 1 GB nu este suficient pentru ca ClamAV să funcționeze. În aproape toate cazurile, când se folosește 1 GB de memorie, antivirusul a citat o eroare legată de baza de date. În același timp, pe sistemele de operare Debian și Ubuntu, antivirusul pur și simplu nu a scanat corespondența care trecea prin server, altfel totul a funcționat bine. Pe CentOS situația a fost ușor diferită. Serviciul clamd a prăbușit complet sistemul, făcând astfel imposibilă funcționarea normală a serverului. Când încerca să se autentifice în interfețele web, NGINX producea periodic erori 502 și 504. De asemenea, e-mailurile au fost trimise de fiecare dată. Mai mult, dacă adăugăm până la 2 GB de RAM, atunci în toate cazurile nu au existat probleme cu funcționarea antivirusului și a serverului în ansamblu. ClamAV a scanat corespondența care trecea prin serverul de e-mail, despre care a scris în jurnalele. Când încercați să trimiteți un virus ca atașament, livrarea a fost blocată. Consumul de memorie a fost de aproximativ 1,2 - 1,7 GB.
NGINX poate fi folosit nu numai ca server web sau http-proxy, ci și pentru proxy mail prin protocoale SMTP, IMAP, POP3. Acest lucru vă va permite să configurați:
- Un singur punct de intrare pentru un sistem de e-mail scalabil.
- Echilibrarea încărcăturii între toate serverele de e-mail.
În acest articol, instalarea se realizează în sala de operație. sistem Linux. La fel de serviciu poștal, la care se trimit cereri, puteți folosi postfix, exim, porumbel, exchange, iredmail assembly și multe altele.
Principiul de funcționareNGINX acceptă cereri și se autentifică pe serverul web. În funcție de rezultatul verificării autentificarii și parolei, proxy-ul va returna un răspuns cu mai multe anteturi.
În caz de succes:
Astfel, determinăm serverul și portul serverului de e-mail pe baza autentificării. Acest lucru oferă multe oportunități cu cunoștințe adecvate a limbajelor de programare.
În caz de defecțiune:
În funcție de rezultatul autentificării și de antet, clientul este redirecționat către serverul de mail de care avem nevoie.
Pregătirea serveruluiSă facem câteva modificări setărilor de securitate ale serverului.
SELinuxDezactivați SELinux dacă folosim CentOS sau dacă folosim acest sistem securitate pe Ubuntu:
vi /etc/selinux/config
SELINUX=dezactivat
FirewallDacă folosim firewalld (implicit pe CentOS):
firewall-cmd --permanent --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp
firewall-cmd --reîncărcare
Dacă folosim iptables (implicit în Ubuntu):
iptables -A INTRARE -p tcp --dport 25 -j ACCEPT
iptables -A INTRARE -p tcp --dport 110 -j ACCEPT
iptables -A INTRARE -p tcp --dport 143 -j ACCEPT
apt-get install iptables-persistent
iptables-save > /etc/iptables/rules.v4
* în acest exemplu am permis SMTP (25), POP3 (110), IMAP (143).
Instalarea NGINXDepinzând de sistem de operare Instalarea NGINX este puțin diferită.
sau Linux Centos:
yum instalează nginx
sau Linux Ubuntu:
apt install nginx
Permitem pornirea automată a serviciului și îl pornim:
systemctl activa nginx
systemctl porniți nginx
Dacă NGINX este deja instalat pe sistem, verificați cu ce module funcționează:
Vom primi o listă de opțiuni cu care este construit serverul web - printre ele ar trebui să vedem --with-mail . Dacă modulul necesar nu este acolo, trebuie să actualizați nginx
Configurarea NGINXDeschideți fișierul de configurare nginx și adăugați opțiunea de e-mail:
vi /etc/nginx/nginx.conf
Poștă (
auth_http localhost:80/auth.php;
Server (
asculta 25;
protocol smtp;
smtp_auth login simplu cram-md5;
}
Server (
asculta 110;
protocol pop3;
}
Server (
asculta 143;
protocol imap;
}
}
* Unde:
- server_name este numele serverului de e-mail care va fi afișat în mesajul de întâmpinare SMTP.
- auth_http - server web și URL pentru cererea de autentificare.
- proxy_pass_error_message - permite sau interzice afișarea unui mesaj atunci când autentificarea eșuează.
- listen - portul pe care sunt ascultate cererile.
- protocol - protocolul de aplicație pentru care ascultă portul corespunzător.
- smtp_auth - metode de autentificare disponibile pentru SMTP.
- pop3_auth - metode de autentificare disponibile pentru POP3.
În secțiunea http - server adăugați:
Server (
asculta 80 default_server;
asculta [::]:80 default_server;
...
Locație ~ \.php$ (
setați $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $cale_rădăcină$nume_script_fastcgi;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $cale_rădăcină;
}
...
Reporniți serverul nginx:
systemctl reporniți nginx
Instalarea și configurarea PHPPentru a efectua autentificarea cu folosind PHP, trebuie să instalați următoarele pachete pe sistemul dvs.
Dacă CentOS:
yum instalează php php-fpm
Dacă Ubuntu:
apt-get install php php-fpm
Lansați PHP-FPM:
systemctl activează php-fpm
systemctl porniți php-fpm
AutentificareVerificarea login-ului și a parolei se realizează printr-un script, a cărui cale este specificată de opțiunea auth_http. În exemplul nostru, acesta este un script PHP.
Un exemplu de șablon oficial pentru un script de verificare a autentificarii și a parolei:
vi /usr/share/nginx/html/auth.php
* acest script acceptă orice login și parolă și redirecționează cererile către serverele 192.168.1.22 și 192.168.1.33. Pentru a seta algoritmul de autentificare, editați liniile 61 - 64. Liniile 73 - 77 sunt responsabile pentru returnarea serverelor către care se face redirecționarea - în acest exemplu, dacă autentificarea începe cu caracterele „a”, „c”, „f ”, „g”, atunci redirecționarea va fi către serverul mailhost01, în caz contrar, către mailhost02. Maparea numelor de server la adrese IP poate fi setată pe liniile 31, 32, în caz contrar apelul se va face folosind numele domeniului.
Configurarea unui server de e-mailSchimbul de date între proxy-ul NGINX și serverul de e-mail are loc în text clar. Este necesar să adăugați posibilitatea de autentificare folosind mecanismul PLAIN la excepție. De exemplu, pentru a configura porumbelul, procedați în felul următor:
vi /etc/dovecot/conf.d/10-auth.conf
Adăugați liniile:
la distanță 192.168.1.11 (
disable_plaintext_auth = nr
}
* în acest exemplu, am permis cereri de autentificare PLAIN de la serverul 192.168.1.11.
Verificăm și:
* dacă ssl este setat la obligatoriu, verificarea nu va funcționa, deoarece se dovedește că, pe de o parte, serverul permite solicitări în text clar, dar necesită criptare ssl.
Reporniți serviciul Dovecot:
systemctl reporniți dovecot
Configurarea clientuluiPuteți continua cu verificarea setărilor noastre proxy. Pentru a face acest lucru, în setările clientului, specificați adresa sau numele serverului nginx ca IMAP/POP2/SMTP, de exemplu:
* în acest exemplu, clientul de e-mail este configurat să se conecteze la serverul 192.168.1.11 prin porturile deschise 143 (IMAP) și 25 (SMTP).
CriptareAcum, să configuram o conexiune SSL. Nginx trebuie să fie construit cu modulul mail_ssl_module - verificați cu comanda:
Dacă modulul necesar lipsește, reconstruim nginx.
Apoi edităm fișierul nostru de configurare:
vi /etc/nginx/nginx.conf
Poștă (
nume_server mail.domain.local;
auth_http localhost/auth.php;
Proxy_pass_error_message activat;
Ssl activat;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
Server (
asculta 110;
protocol pop3;
pop3_auth plain apop cram-md5;
}
Server (
asculta 143;
protocol imap;
}
Motiv: Sistemul de securitate SELinux este declanșat.
Soluție: dezactivați sau configurați SELinux.
