Nginx brzo dobija na popularnosti, prelazeći od samo statičkog akceleratora posluživanja za Apache do potpuno opremljenog i naprednog web servera koji se sve više koristi u izolaciji. U ovom članku ćemo govoriti o zanimljivim i nestandardnim scenarijima za korištenje nginxa, koji će vam omogućiti da izvučete maksimum iz web servera.

Mail proxy

Počnimo s najočiglednijim - nginx-ovom sposobnošću da djeluje kao proxy za poštu. Ova funkcija je u početku u nginxu, ali se iz nekog razloga u proizvodnji koristi izuzetno rijetko, neki čak i ne znaju za njeno postojanje. Kako god bilo, nginx podržava proxying POP3, IMAP i SMTP protokole s različitim metodama autentifikacije, uključujući SSL i StartTLS, i to vrlo brzo.

Zašto je ovo potrebno? Postoje najmanje dvije namjene za ovu funkcionalnost. Prvo, koristite nginx kao štit od dosadnih pošiljatelja neželjene pošte koji pokušavaju poslati neželjenu poštu preko našeg SMTP servera. Obično spameri ne stvaraju mnogo problema, jer se brzo odbijaju u fazi autentifikacije, međutim, kada ih ima zaista puno, nginx će pomoći u uštedi resursa procesora. Drugo, koristite nginx za preusmjeravanje korisnika na višestruke POP3/IMAP servere pošte. Naravno, drugi mail proxy bi takođe mogao ovo da reši, ali zašto bi ograđivali baštu servera ako je nginx već instaliran na frontend-u da bi služio statički preko HTTP-a, na primer?

Mail proxy u nginx-u nije sasvim standardan. Koristi dodatni sloj za autentifikaciju implementiran putem HTTP-a, i samo ako korisnik prođe ovu barijeru, on je proslijeđen dalje. Ova funkcionalnost je obezbeđena kreiranjem stranice/skripte, kojoj nginx daje podatke korisnika, a on/on vraća odgovor u obliku standardnog OK ili razloga odbijanja (kao što je „Nevažeća prijava ili lozinka“). Skripta se pokreće sa sljedećim zaglavljima:

Unos skripte za autentifikaciju HTTP_AUTH_USER: korisnik HTTP_AUTH_PASS: lozinka HTTP_AUTH_PROTOCOL: protokol pošte (IMAP, POP3 ili SMTP)

I vraća se ovako:

Izlaz skripte za autentifikaciju HTTP_AUTH_STATUS: OK ili razlog neuspjeha HTTP_AUTH_SERVER: pravi mail server za preusmjeravanje HTTP_AUTH_PORT: port servera

Izvanredna karakteristika ovog pristupa je da se može koristiti ne za samu autentifikaciju, već za rasipanje korisnika po različitim internim serverima, u zavisnosti od korisničkog imena, podataka o trenutnom opterećenju na serverima pošte, ili čak organizovanjem najjednostavnijeg balansiranja opterećenja koristeći round-robin . Međutim, ako samo trebate prenijeti korisnike na interni mail server, možete koristiti stub koji implementira sam nginx umjesto prave skripte. Na primjer, najjednostavniji SMTP i IMAP proxy u nginx konfiguraciji će izgledati ovako:

# vi /etc/nginx/nginx.conf mail ( # Adresa autentifikacione skripte auth_http localhost:8080/auth; # Onemogućite komandu XCLIENT, neki serveri pošte je ne razumeju xclient off; # IMAP server server (slušajte 143; protokol imap; proxy uključen; ) # SMTP server server (slušaj 25; protokol smtp; proxy uključen; ) )

# vi /etc/nginx/nginx.conf http ( # Mapiranje na ispravan port mail servera u zavisnosti od porta poslanog u mapi zaglavlja HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport ( default 25; smtp 25; imap 143; ) # Implementacija autentifikacije " script" - uvijek vraća OK i preusmjerava korisnika na interni mail server, postavljajući ispravan port koristeći gore navedeni server za mapiranje ( slušajte 8080; lokacija / auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" " 192.168.0.1" ; add_header "Auth-Port" $mailport; vrati 200; ) ) )

To je sve. Ova konfiguracija vam omogućava da transparentno preusmjerite korisnike na interni mail server bez stvaranja dodatnih troškova u obliku skripte koja je u ovom slučaju nepotrebna. Koristeći skriptu, ova se konfiguracija može značajno proširiti: postaviti balansiranje opterećenja, provjeriti korisnike u odnosu na LDAP bazu podataka i izvršiti druge operacije. Pisanje skripte je izvan okvira ovog članka, ali je vrlo lako implementirati čak i uz samo rudimentarno poznavanje PHP-a i Pythona.

Video streaming

Postavljanje redovnog video hostinga zasnovanog na nginxu je jednostavno. Sve što trebate učiniti je otpremiti transkodirani video u direktorij dostupan serveru, dodati ga u konfiguraciju i konfigurirati flash ili HTML5 player tako da preuzima video iz ovog direktorija. Međutim, ako želite da podesite kontinuirano emitovanje video zapisa sa nekog eksternog izvora ili web kamere, ova šema neće raditi, pa ćete morati da gledate na posebne protokole za striming.

Postoji nekoliko protokola koji rješavaju ovaj problem, a najefikasniji i podržani od njih je RTMP. Jedini problem je što skoro sve implementacije RTMP servera pate od problema. Zvanični Adobe Flash Media Server se plaća. Red5 i Wowza su napisani u Javi i stoga ne pružaju željene performanse, druga implementacija, Erlyvideo, je napisana na Erlangu, što je dobro u slučaju postavljanja klastera, ali nije toliko efikasno za jedan server.

Predlažem drugi pristup - koristite RTMP modul za nginx. Ima odlične performanse i također vam omogućava da koristite jedan server za posluživanje i web sučelja stranice i video streama. Jedini problem je što je ovaj modul nezvaničan, pa ćete morati sami da napravite nginx sa njegovom podrškom. Na sreću, montaža se izvodi na standardni način:

$ sudo apt-get ukloniti 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

Sada je potrebno konfigurirati modul. Ovo se radi, kao i obično, preko nginx konfiguracije:

Rtmp ( # Aktivirajte server za emitovanje na portu 1935 na site/rtmp serveru (slušajte 1935; aplikacija rtmp (uživo; ) ))

RTMP modul ne može raditi u konfiguraciji s više niti, tako da će se broj nginx radnih procesa morati smanjiti na jedan (kasnije ću vam reći kako zaobići ovaj problem):

worker_processes 1;

Sada možemo da sačuvamo datoteku i da nginx ponovo pročita konfiguraciju. Podešavanje nginxa je završeno, ali još uvijek nemamo sam video stream, pa ga moramo negdje nabaviti. Na primjer, neka to bude video.avi fajl iz trenutnog direktorija. Da ga pretvorimo u stream i umotamo u naš RTMP emiter, koristimo stari dobri FFmpeg:

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

Ako video datoteka nije u H264 formatu, trebalo bi je prekodirati. Ovo se može učiniti u hodu koristeći isti FFmpeg:

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

Prijenos se također može snimiti direktno sa web kamere:

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

Da vidite stream na strani klijenta, možete koristiti bilo koji plejer sa RTMP-om, kao što je mplayer:

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

Ili ugradite plejer direktno u web stranicu koju servira isti nginx (primjer iz službene dokumentacije):

Najjednostavniji RTMP web player

Ovdje postoje samo dvije važne linije: “file: “stream””, koji označava RTMP stream, i “streamer: “rtmp://localhost/rtmp””, koji specificira adresu RTMP streamera. Za većinu zadataka ove postavke će biti dovoljne. Nekoliko različitih tokova može se pokrenuti na jednoj adresi, a nginx će ih efektivno multipleksirati između klijenata. Ali to nije sve što RTMP modul može. Uz njegovu pomoć, na primjer, možete organizirati ponovni prijenos video toka s drugog servera. FFmpeg server uopće nije potreban za ovo, samo dodajte sljedeće redove u konfiguraciju:

# vi /etc/nginx/nginx.conf aplikacija rtmp (uživo; povucite rtmp://rtmp.example.com; )

Ako trebate kreirati više tokova različitih kvaliteta, možete pozvati FFmpeg transkoder direktno iz nginxa:

# vi /etc/nginx/nginx.conf aplikacija rtmp (uživo; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) aplikacija rtmp-320x240 (uživo; )

Sa ovom konfiguracijom dobićemo dva emitera odjednom, od kojih će jedan biti dostupan na rtmp://site/rtmp, a drugi, koji emituje u kvalitetu 320 x 240, na rtmp://site/rtmp–320x240. Dalje na web mjestu možete objesiti flash player i dugmad za odabir kvalitete koji će igraču prevući jednu ili drugu adresu emitera.

I na kraju, primjer emitiranja muzike na mrežu:

dok je istinito; do ffmpeg -re -i "`pronađi /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; urađeno

git proxy

Git sistem kontrole verzija je u mogućnosti da omogući pristup spremištima ne samo preko Git i SSH protokola, već i preko HTTP-a. Nekada je implementacija HTTP pristupa bila primitivna i nije mogla da obezbedi punopravni rad sa spremištem. Od verzije 1.6.6 situacija se promijenila i danas se ovaj protokol može koristiti za, na primjer, zaobilaženje ograničenja firewall-a na obje strane veze ili za kreiranje vlastitog Git hostinga s web sučeljem.

Nažalost, zvanična dokumentacija govori samo o organizovanju pristupa Gitu pomoću Apache web servera, ali kako je sama implementacija eksterna aplikacija sa standardnim CGI interfejsom, može se priključiti na skoro svaki drugi server, uključujući lighttpd i, naravno, nginx. Za ovo nije potrebno ništa osim samog servera, instaliranog Gita i malog FastCGI servera fcgiwrap, koji je potreban jer nginx ne zna kako da radi direktno sa CGI-jem, ali može pozvati skripte koristeći FastCGI protokol.

Cijela šema rada će izgledati ovako. fcgiwrap server će visjeti u pozadini i čekati zahtjev za izvršavanje CGI aplikacije. Nginx će, zauzvrat, biti konfigurisan da zahteva izvršenje git-http-backend CGI binarnog sistema kroz FastCGI interfejs svaki put kada se pristupi adresi koju smo naveli. Nakon što primi zahtjev, fcgiwrap izvršava git-http-backend sa navedenim CGI argumentima koje je proslijedio GIT klijent i vraća rezultat.

Da bismo implementirali takvu šemu, prvo instaliramo fcgiwrap:

$ sudo apt-get install fcgiwrap

Ne morate ga konfigurirati, svi parametri se prosljeđuju putem FastCGI protokola. Također će se pokrenuti automatski. Stoga ostaje samo konfigurirati nginx. Da biste to učinili, kreirajte datoteku /etc/nginx/sites-enabled/git (ako ne postoji takav direktorij, možete pisati u glavnu konfiguraciju) i u nju upišite sljedeće:

# vi /etc/nginx/sites-enabled/git server ( # Zadržite port 8080 slušajte 8080; # Adresa našeg servera (ne zaboravite da dodate DNS unos) server_name git.example.ru; # Zapisuje pristupni_log /var /log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Primarna adresa za lokaciju anonimnog pristupa / ( # Kada pokušavate da otpremite, pošaljite korisnika na privatnu adresu if ($ arg_service ~* "git-receive-pack") ( rewrite ^ /private$uri last; ) uključuje /etc/nginx/fastcgi_params; # Adresa našeg git-http-backend fastcgi_param SCRIPT_FILENAME /usr /lib/git-core/git- http-backend; # Adresa Git spremišta fastcgi_param GIT_PROJECT_ROOT /srv/git; # Adresa fajla fastcgi_param PATH_INFO $uri; # Adresa servera fcgiwrap fastcgi_pass 127.0.0.1:9001; ) Adresa za pristup lokaciji # ) ~/private(/.* )$ ( # Korisničke dozvole auth_basic "git anonimni samo za čitanje, autentificirano pisanje"; # HTTP autentifikacija zasnovana na htpasswd auth_basic_user_file /etc/nginx/htpasswd; # FastCGI postavke 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; ) )

Ova konfiguracija pretpostavlja tri važne stvari:

1. Adresa spremišta će biti /srv/git, pa postavite odgovarajuće dozvole: $ sudo chown -R www-data:www-data /srv/git
2. Samo spremište mora biti čitljivo od strane Anonymous i omogućiti upload putem HTTP-a: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true
3. Autentifikacija se vrši pomoću htpasswd datoteke, potrebno je da je kreirate i dodate korisnike u nju: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2. .

To je sve, ponovo pokrenite nginx:

Microcaching

Zamislimo situaciju s dinamičnom, često ažuriranom web lokacijom koja odjednom počinje primati vrlo velika opterećenja (pa, dospjela je na stranicu jedne od najvećih vijesti) i prestaje se nositi s povratkom sadržaja. Kompetentna optimizacija i implementacija ispravne šeme keširanja će potrajati dugo, a probleme je potrebno riješiti sada. Šta možemo učiniti?

Postoji nekoliko načina da se izađe iz ove situacije uz minimalne gubitke, ali najzanimljivija ideja je došla od Fenn Bailey (fennb.com). Ideja je jednostavno staviti nginx ispred servera i prisiliti ga da kešira sav preneseni sadržaj, ali ne samo keš, već samo na jednu sekundu. Vrhunac ovdje je da će stotine i hiljade posjetitelja stranice u sekundi, u stvari, generirati samo jedan poziv backendu, većina njih će dobiti keširanu stranicu. U isto vrijeme, rijetko ko će primijetiti razliku, jer čak i na dinamičnom sajtu jedna sekunda obično ne znači ništa.

Konfiguracija s implementacijom ove ideje neće izgledati tako komplicirano:

# vi /etc/nginx/sites-enabled/cache-proxy # Konfigurišite keš proxy_cache_path /var/cache/nginx leveli=1:2 keys_zone=microcache:5m max_size=1000m; server ( slušajte 80; server_name example.com; # Lokacija keš adrese / ( # Keširanje omogućeno po defaultu set $no_cache ""; # Onemogući keš za sve metode osim GET i HEAD if ($request_method !~ ^(GET|HEAD) $ ) ( postavite $no_cache "1"; ) # Ako klijent otpremi sadržaj na stranicu (no_cache = 1), vodimo računa da podaci koji su mu dati ne budu keširani dvije sekunde i on može vidjeti rezultat preuzimanja ako ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Put=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1"; ) # Omogući/onemogući keš memoriju u zavisnosti od stanja varijable no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Proxy zahtjevi za pravi server proxy_pass http://appserver.example.ru; proxy_cache mikrokeš; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Zaštita od problema sa grmljavinom krda proxy_cache_use_stale ažuriranje; # Dodaj standardna zaglavlja proxy_set_h zaglavlje Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Nemojte keširati datoteke veće od 1 MB proxy_max_temp_file_size 1M; ) )

Posebno mjesto u ovoj konfiguraciji zauzima linija "proxy_cache_use_stale updating;", bez koje bismo imali periodične navale opterećenja na backend serveru zbog zahtjeva koji su dolazili tokom ažuriranja keša. Inače, sve je standardno i trebalo bi da bude jasno bez dodatnog objašnjenja.

Približavanje proxyja ciljnoj publici

Uprkos široko rasprostranjenom globalnom porastu brzine Interneta, fizička udaljenost servera od ciljne publike i dalje igra ulogu. To znači da ako ruska stranica radi na serveru koji se nalazi negdje u Americi, brzina pristupa do njega će biti a priori sporija nego s ruskog servera sa istim propusnim opsegom (naravno, ako zatvorite oči pred svim ostalim faktorima ). Druga stvar je da je često isplativije hostovati servere u inostranstvu, uključujući i u smislu održavanja. Stoga, da biste ostvarili profit, u vidu viših stopa povrata, morat ćete ići na trik.

Jedna od mogućih opcija: da se glavni produktivni server smjesti na Zapad, a front-end, koji nije previše zahtjevan za resursima, daje statiku, u Rusiji. To će vam omogućiti da osvojite brzinu bez ozbiljnih troškova. Nginx konfiguracija za frontend u ovom slučaju će biti jednostavna implementacija proxyja koja je svima nama poznata:

# vi /etc/nginx/sites-enabled/proxy # Čuvajte keš memoriju 30 dana u skladištu od 100 GB proxy_cache_path /var/cache/nginx leveli=1:2 keys_zone=static:32m inactive=30d max_size=100g; server ( slušajte 80; ime_servera example.com; # Zapravo, naša proxy lokacija ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Pozadinska adresa 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-Za $proxy_add_x_forwarded_for; proxy_add_x_forwarded_for; proxy_buffer6k proxy_buffer_s; proxy_cache_valid 30d; proxy_ignore_headers "Kontrola predmemorije" "Ističe"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock uključen; ) )

nalazi

Danas, uz pomoć nginxa, možete riješiti mnogo različitih zadataka, od kojih mnogi uopće nisu povezani s web serverom i HTTP protokolom. Proxy e-pošte, streaming server i Git interfejs su samo neki od zadataka.

Ovaj članak će objasniti kako da konfigurišete NGINX Plus ili NGINX Open Source kao proxy server za poštu ili eksternu uslugu pošte.

Uvod

NGINX može proxy IMAP, POP3 i SMTP protokole na jedan od upstream servera e-pošte koji ugošćuju račune pošte i stoga se može koristiti kao jedna krajnja tačka za klijente e-pošte. Ovo može donijeti brojne prednosti, kao što su:

• jednostavno skaliranje broja mail servera
• odabir mail servera na osnovu različitih pravila, na primjer, odabir najbližeg servera na osnovu IP adrese klijenta
• distribuciju opterećenja između mail servera

Preduvjeti

NGINX Plus (već uključuje Mail module neophodne za proxy e-mail promet) ili NGINX Open Source je kompajlirao Mail module koristeći --with-mail parametar za funkcionalnost proxyja e-pošte i --with-mail_ssl_module parametar za SSL/TLS podršku:

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

IMAP, POP3 i/ili SMTP serveri pošte ili eksterni servis pošte

Konfiguriranje SMTP/IMAP/POP3 mail proxy servera

U NGINX konfiguracijskoj datoteci:

pošta (#...)

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

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

Alternativno, specificirajte da li da informišete korisnika o greškama sa servera za autentifikaciju tako što ćete navesti proxy_pass_error_message direktivu. Ovo može biti zgodno kada poštanskom sandučetu ponestane memorije:

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

Konfigurišite svaki SMTP, IMAP ili POP3 server sa serverskim blokovima. Za svaki server navedite:

• the broj porta koji odgovaraju specificiranom protokolu sa direktivom slušanja
• the protokol sa direktivom protokola (ako nije navedeno, automatski će se otkriti sa porta navedenog u direktivi slušanja)
• dozvoljeno metode autentifikacije sa imap_auth, pop3_auth i smtp_auth direktivama:

server ( slušaj 25 ; protokol smtp ; smtp_auth prijava običan cram-md5 ; ) server ( slušaj 110 ; protokol pop3 ; pop3_auth običan apop cram-md5 ; ) server ( slušaj 143 ; protokol imap ; )

Postavljanje autentifikacije za mail proxy

Svaki POP3/IMAP/SMTP zahtjev od klijenta će se prvo autentifikovati na eksternom HTTP serveru za autentifikaciju ili pomoću skripte za autentifikaciju. Posjedovanje servera za autentifikaciju je obavezno za proxy NGINX mail servera. Server možete sami kreirati u skladu sa NGINX protokolom za autentifikaciju koji je baziran na HTTP protokolu.

Ako je autentikacija uspješna, server za provjeru autentičnosti će izabrati uzvodni server i preusmjeriti zahtjev. U ovom slučaju, odgovor servera će sadržavati sljedeće redove:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # ime servera ili IP adresa upstream servera koji će se koristiti za obradu pošte Auth port: # port upstream servera

Ako autentifikacija ne uspije, server za provjeru autentičnosti će vratiti poruku o grešci. U ovom slučaju, odgovor servera će sadržavati sljedeće redove:

HTTP/1.0 200 OK Auth-Status: # poruka o grešci koja se vraća klijentu, na primjer "Neispravna prijava ili lozinka" Auth-Wait: # broj preostalih pokušaja autentifikacije dok se veza ne zatvori

Imajte na umu da će u oba slučaja odgovor sadržavati HTTP/1.0 200 OKšto bi moglo biti zbunjujuće.

Za više primjera zahtjeva i odgovora sa servera za provjeru autentičnosti, pogledajte ngx_mail_auth_http_module u NGINX Referentnoj dokumentaciji.

Postavljanje SSL/TLS-a za Mail proxy

Koristeći POP3/SMTP/IMAP preko SSL/TLS-a osiguravate da su podaci koji se prenose između klijenta i servera pošte zaštićeni.

Da biste omogućili SSL/TLS za mail proxy:

Uvjerite se da je vaš NGINX konfiguriran s podrškom za SSL/TLS tako što ćete upisati naredbu nginx -V u komandnu liniju, a zatim tražiti liniju with --mail_ssl_module u izlazu:

$ nginx -V konfigurirajte argumente: ... sa--mail_ssl_module

Provjerite jeste li nabavili serverske certifikate i privatni ključ i stavite ih na server. Certifikat se može dobiti od pouzdanog tijela za izdavanje certifikata (CA) ili generirati korištenjem SSL biblioteke kao što je OpenSSL.

ssl on ;

zaprepasti na ;

Dodajte SSL certifikate: navedite putanju do certifikata (koji moraju biti u PEM formatu) ssl_certificate direktivom i navedite stazu do privatnog ključa u direktivi ssl_certificate_key:

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

Možete koristiti samo jake verzije i šifre SSL/TLS-a sa ssl_protocols i ssl_ciphers direktivama, ili možete postaviti svoje preferirane protokole i šifre:

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

Optimizacija SSL/TLS-a za Mail Proxy

Ovi savjeti će vam pomoći da vaš NGINX mail proxy učinite bržim i sigurnijim:

Postavite broj radnih procesa jednak broju procesora s direktivom worker_processes postavljenom na istu razinu kao i kontekst pošte:

worker_processes auto ; pošta (#...)

Omogućite dijeljenu keš memoriju sesije i onemogućite ugrađenu keš memoriju sesije sa automatskim ; mail ( server_name mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message uključen ; ssl uključen ; ssl_certificate /etc/ssl/certs/server_certi ; sslskesl/server_certi ; sslcsl/server_cert ; ključ ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache shared:SSL:10m ; ssl_session_timeout 10m ; server (slušaj 25 ; tp login server sm-0; ; protokol pop3 ; pop3_auth običan apop cram-md5 ; ) server (slušaj 143; protokol imap ; ))

U ovom primjeru postoje tri proxy servera e-pošte: SMTP, POP3 i IMAP. Svaki od servera je konfigurisan sa podrškom za SSL i STARTTLS. Parametri SSL sesije će biti keširani.

Proxy server koristi HTTP server za autentifikaciju – njegova konfiguracija je izvan okvira ovog članka. Sve poruke o grešci sa servera će biti vraćene klijentima.

Nginx- male veličine, vrlo brz, prilično funkcionalan web server i mail proxy server, programer Igor Sysoev (rambler.ru). Zbog vrlo niske potrošnje sistemskih resursa i brzine, kao i fleksibilnosti konfiguracije, web nginx serverčesto se koristi kao front end za teže servere kao što su Apache, u projektima visokog opterećenja. Klasična opcija je gomila, Nginx - Apache - FastCGI. Radeći u takvoj šemi, nginx server, prihvata sve zahtjeve koji dolaze putem HTTP-a, te, ovisno o konfiguraciji i samom zahtjevu, odlučuje da li će sam obraditi zahtjev i dati klijentu spreman odgovor ili poslati zahtjev za obradu nekom od backenda ( Apache ili FastCGI).

Kao što znate, Apache server obrađuje svaki zahtjev u posebnom procesu (thread), koji, mora se reći, troši prilično NE malu količinu sistemskih resursa, ako postoji 10-20 takvih procesa, to je besmislica, a ako postoji ako ih ima 100-500 ili više, sistem postaje ne zabavan.

Pokušajmo zamisliti takvu situaciju. Pretpostavimo na Apache 300 HTTP zahtjeva dolazi od klijenata, 150 klijenata sjedi na brzim iznajmljenim linijama, a ostalih 150 na relativno sporim internet kanalima, čak i ako nisu na modemima. Šta se dešava u ovoj situaciji? I dogodi se sljedeće, Apache web server, da bi obradio ovih 300 konekcija, kreira za svaki proces (thread), brzo će generirati sadržaj, a 150 brzih klijenata će odmah uzeti rezultat svojih zahtjeva, procese koji su ih opsluživali. će biti ubijeni i resursi će biti pušteni, a 150 je sporo, a rezultate njihovih upita će uzimati sporo, zbog uskog Internet kanala, zbog čega će 150 procesa visiti u sistemu Apache, čekajući da klijenti uzmu sadržaj koji generiše web server, proždirući mnogo sistemskih resursa. Naravno, situacija je hipotetička, ali mislim da je suština jasna. Popraviti gornju situaciju i paket pomaže. Nakon što pročita cijeli zahtjev od klijenta, on ga prosljeđuje na obradu Apache, koji zauzvrat generiše sadržaj i vraća spreman odgovor Nginx-u što je brže moguće, nakon čega može mirne savjesti ubiti proces i osloboditi sistemske resurse koje zauzima. Nginx web server, koji prima rezultat zahtjeva od Apache, upisuje ga u bafer ili čak u datoteku na disku i može ga dati sporim klijentima proizvoljno dugo vremena, dok njegovi radni procesi troše tako malo resursa da je .. "čak je smiješno pričati o tome" ©. :) Takva šema značajno štedi sistemske resurse, ponavljam, ali Nginx radni procesi troše oskudnu količinu resursa, to je još relevantnije za velike projekte.

I ovo je samo mali dio onoga što Nginx server može učiniti, ne zaboravite na mogućnost keširanja podataka i rada sa memcached. Evo liste glavnih karakteristika Nginx web servera.

Funkcionalnost Nginx servera kao HTTP servera

• Statičko rukovanje sadržajem, indeksne datoteke, listanje direktorija, otvorena predmemorija deskriptora datoteka;
• Ubrzano proxying sa keširanjem, balansiranjem opterećenja i prelaskom na grešku;
• Ubrzana podrška FastCGI serveri sa keširanjem, balansiranjem opterećenja i tolerancijom grešaka;
• Modularna struktura, podrška za različite filtere (SSI, XSLT, GZIP, životopis, chunked odgovori);
• Podrška za SSL i TLS SNI ekstenzije;
• baziran na ip ili na osnovu imena virtuelni serveri;
• Rad sa KeepAlive i cevovodnim vezama;
• Mogućnost konfigurisanja bilo kojeg vremenskog ograničenja, kao i broja i veličine bafera, na nivou Apache server;
• Izvođenje raznih radnji u zavisnosti od adrese klijenta;
• Promjena URI-ja pomoću regularnih izraza;
• Posebne stranice grešaka za 4xx i 5xx;
• Ograničenje pristupa na osnovu adrese klijenta ili lozinke;
• Postavljanje formata datoteka dnevnika, rotacija dnevnika;
• Ograničavanje brzine odgovora klijentu;
• Ograničavanje broja istovremenih veza i zahtjeva;
• Podrška za metode PUT, DELETE, MKCOL, COPY i MOVE;
• Promjena postavki i ažuriranje servera bez prekida rada;
• ugrađen Perl;

Funkcionalnost Nginx servera, kao mail proxy servera

• Prosljeđivanje na IMAP/POP3 backend korištenjem eksternog HTTP servera za autentifikaciju;
• Provjera korisnikovog SMTP-a na vanjskom HTTP serveru za autentifikaciju i prosljeđivanje na interni SMTP server;
• Podrška za sljedeće metode provjere autentičnosti:
  • POP3 - KORISNIK/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI / PLAIN / CRAM-MD5;
• SSL podrška;
• podrška za STARTTLS i STLS;

Operativni sistemi i platforme koje podržava Nginx web server

• FreeBSD, platforme 3 do 8, i386 i amd64;
• Linux, od 2.2 do 2.6 - i386 platforma; Linux 2.6 - amd64;
• Solaris 9 - i386 i sun4u platforme; Solaris 10 - i386, amd64 i sun4v platforme;
• MacOS X platforme ppc, i386;
• Windows XP, Windows Server 2003; (Trenutno u beta testiranju)

Arhitektura Nginx servera i skalabilnost

• Glavni (glavni) proces, nekoliko (konfigurabilnih u konfiguracionoj datoteci) radni procesi koji se pokreću pod neprivilegovanim korisnikom;
• Podrška za sljedeće metode rukovanja vezom:
  • izaberite je standardna metoda. Odgovarajući Nginx modul se automatski gradi ako se na datoj platformi ne pronađe efikasnija metoda. Možete prisilno uključiti ili isključiti izgradnju ovog modula koristeći --with-select_module ili --without-select_module opcije konfiguracije.
  • anketa je standardna metoda. Odgovarajući Nginx modul se automatski gradi ako se na datoj platformi ne pronađe efikasnija metoda. Možete prisilno uključiti ili isključiti izgradnju ovog modula koristeći --with-poll_module ili --without-poll_module opcije konfiguracije.
  • kqueue je efikasan metod koji se koristi na operativnim sistemima FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 i MacOS X. Kada se koristi na MacOS X mašinama sa dva procesora, može izazvati paniku kernela.
  • epoll je efikasna metoda koja se koristi u Linuxu 2.6+. Neke distribucije, kao što je SuSE 8.2, imaju zakrpe koje podržavaju epoll u kernelu 2.4.
  • rtsig - signali u realnom vremenu, efikasna metoda koja se koristi u Linuxu 2.2.19+. Podrazumevano, ne može biti više od 1024 signala u redu čekanja za cijeli sistem. Ovo nije dovoljno za servere sa velikim opterećenjem, veličina reda se mora povećati pomoću /proc/sys/kernel/rtsig-max parametra kernela. Međutim, od Linuxa 2.6.6-mm2, ova opcija je uklonjena, umjesto toga svaki proces ima zaseban red signala, čiju veličinu određuje RLIMIT_SIGPENDING.
  • Kada je red pun, nginx server resetuje ga i obrađuje veze sa metodom ankete dok se situacija ne vrati u normalu.
  • /dev/poll- efikasan metod, podržan na Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ i Tru64 UNIX 5.1A+ operativnim sistemima.
  • eventport - portovi događaja, efikasna metoda koja se koristi u Solarisu 10. Prije upotrebe, mora se instalirati zakrpa kako bi se izbjegla panika kernela.
• Koristeći karakteristike metode kqueue, kao što su EV_CLEAR, EV_DISABLE (da biste privremeno onemogućili događaj), NOTE_LOWAT, EV_EOF, broj dostupnih podataka, kodovi grešaka;
• Rad sa sendfileom (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) i sendfilev (Solaris 8 7/01+);
• Podrška za filtere prihvata (FreeBSD 4.1+) i TCP_DEFER_ACCEPT (Linux 2.4+);
• 10.000 neaktivnih HTTP veza koje se održavaju u životu troše približno 2,5M memorije;
• Minimalni broj operacija kopiranja podataka;

iRedMail je gradnja servera pošte otvorenog koda. Sklop je baziran na Postfix SMTP serveru (Mail Transfer Agent, skraćeno MTA). Sklop takođe uključuje: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData i NGINX.

Golubnjak- IMAP/POP3 server.

Spamassassin- alat za filtriranje neželjene pošte.

Greylist- anti-spam alat baziran na sivim listama.

ClamAV- antivirus.

Roundcube i SOGo- Web klijenti za rad sa e-poštom.

NetData- program za praćenje rada servera u realnom vremenu.

Nginx- web server.

Podržava operativne sisteme: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 i OpenBSD 6.4.

iRedMail ima plaćene i besplatne verzije, koje se međusobno razlikuju po funkcionalnosti iRedAdmin-ovog vlastitog web sučelja mail sklopa. U besplatnoj verziji možete kreirati samo domene, korisničke i administratorske poštanske sandučiće. Ako trebate kreirati alias, nećete to moći učiniti u besplatnoj verziji putem iRedAdmin-a. Srećom, postoji besplatno rješenje pod nazivom PostfixAdmin koje vam to omogućava. PostfixAdmin se lako integriše sa iRedMailom i odlično radi sa njim.

Instalacija

Za instalaciju nam je potreban jedan od gore navedenih operativnih sistema. Koristiću Ubuntu Server 18.04. Također morate imati kupljeno ime domene i konfiguriranu DNS zonu. Ako koristite DNS server vašeg registratora domena, potrebno je da napravite dva zapisa u odeljku za upravljanje domenskom zonom: A i MX. Takođe možete koristiti sopstveni DNS postavljanjem delegiranja na ličnom nalogu registratora imena domena.

Postavljanje domenske zone kada koristite DNS registrator

Bilješka! DNS postavke stupaju na snagu od nekoliko sati do jedne sedmice. Dok podešavanja ne stupe na snagu, server pošte neće raditi ispravno.

Za instalaciju, preuzmite trenutnu verziju sa iRedMail web stranice. Trenutno je 0.9.9.

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

Zatim raspakujte preuzetu arhivu.

# tar xjf iRedMail-0.9.9.tar.bz2

Raspakivanje arhive

I idite na kreirani folder.

# cd iRedMail-0.9.9

Fascikla sa iRedMail instalaterom

Provjera sadržaja foldera

Sadržaj foldera

I pokrenite iRedMail instalacijsku skriptu.

# bash iRedMail.sh

Instalacija mail sistema će započeti. Tokom procesa instalacije, morat ćete odgovoriti na brojna pitanja. Slažemo se da započnemo instalaciju.

Početak instalacije

Odabir instalacijskog direktorija

Sada morate odabrati web server. Izbor nije veliki, pa smo odabrali NGINX.

Odabir web servera

Sada treba da izaberete server baze podataka koji će biti instaliran i konfigurisan za rad sa sistemom pošte. Odaberite MariaDB.

Odabir servera baze podataka

Postavite root lozinku za bazu podataka.

Kreiranje root lozinke baze podataka

Sada specificiramo naš mail domen.

Kreiranje mail domena

Zatim kreirajte lozinku za administratorsko polje [email protected] domain.ru.

Kreirajte lozinku administratora e-pošte

Odabir Web komponenti

Potvrđujemo navedene postavke.

Potvrda podešavanja

Instalacija je počela.

Instalacija

Po završetku instalacije potvrdite kreiranje pravila iptables za SSH i ponovo pokrenite zaštitni zid. iRedMail radi sa iptables. U Ubuntu-u, najčešće korišćeni uslužni program za upravljanje zaštitnim zidom UVW. Ako iz jednog ili drugog razloga imate takvu potrebu, instalirajte UVW (apt install ufw) i dodajte pravila u UVW(primjer: ufw dozvoli "nginx pun" ili ufw dozvoli Postfix) nije blokirao mail server. Možete pogledati listu dostupnih pravila pokretanjem naredbe: ufw lista aplikacija. Onda upali UVW: ufw enable.

Kreirajte iptables pravilo

Ponovno pokretanje zaštitnog zida

Ovim je završena instalacija iRedMaila. Sistem nam je dao adrese web interfejsa i akreditive za prijavu. Da biste omogućili sve komponente sistema pošte, morate ponovo pokrenuti server.

Kraj instalacije

Ponovo pokrećemo.

# ponovno pokretanje

Podešavanje

Prvo morate biti sigurni da sve radi. Pokušavamo da uđemo u iReadAdmin kontrolni panel na https://domain/iredadmin. Ulogovati se [email protected] domain.ru, lozinka je kreirana tokom instalacije. Postoji interfejs na ruskom jeziku.

Kao što vidite sve funkcioniše. Prilikom prijavljivanja na iRedAdmin, najvjerovatnije ste dobili sigurnosnu grešku vezanu za certifikat. To je zato što iRedMail ima samopotpisani certifikat na koji se pretraživač zaklinje. Da biste riješili ovaj problem, morate instalirati važeći SSL certifikat. Ako ste ga kupili, možete ga instalirati. U primjeru, instalirat ću besplatni SSL iz Let's Encrypt.

Instaliranje Let's Encrypt SSL certifikata

Certifikat ćemo instalirati pomoću uslužnog programa certbot. Hajde da prvo dodamo spremište.

# add-apt-repository ppa:certbot/certbot

Zatim instaliramo sam certboot sa potrebnim komponentama.

# apt instaliraj python-certbot-nginx

Dobijamo sertifikat.

# certbot --nginx -d domain.ru

Nakon što pokrenete komandu, sistem će od vas tražiti da unesete email adresu, unesite. Nakon toga ćete najvjerovatnije dobiti grešku da nije moguće pronaći serverski blok za koji je generiran certifikat. U ovom slučaju, to je normalno, jer nemamo nikakav serverski blok. Za nas je najvažnije da dobijemo sertifikat.

Dobijanje sertifikata

Kao što vidite, sertifikat je uspešno primljen i sistem nam je pokazao putanju do samog sertifikata i do ključa. Oni su upravo ono što nam treba. Generalno, dobili smo 4 fajla koji će biti pohranjeni u folderu "/etc/letsencrypt/live/domain". Sada moramo web serveru reći o našem certifikatu, odnosno zamijeniti ugrađeni certifikat onim koji smo upravo primili. Da bismo to uradili, potrebno je da uredimo samo jedan fajl.

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

I promijenite zadnja dva reda u njemu.

Zamjena SSL certifikata

Mijenjamo putanje u datoteci na staze koje nam je sistem rekao kada smo primili certifikat.

Zamjena SSL certifikata

I ponovo pokrenite NGINX.

# servis nginx restart

Pokušajmo se ponovo prijaviti. iRedAdmin.

Verifikacija SSL sertifikata

Nema više greške u certifikatu. Certifikat je važeći. Možete kliknuti na bravu i vidjeti njena svojstva. Kada certifikat istekne, certboot bi ga trebao automatski obnoviti.

Sada razgovarajmo o Dovecot i Postfix certifikatu. Da bismo to učinili, uredit ćemo dvije konfiguracijske datoteke. Mi radimo:

# nano /etc/dovecot/dovecot.conf

Pronalaženje bloka:

#SSL: Globalne postavke.

I promijenimo certifikat koji je tamo registriran u naš.

Zamjena certifikata za Dovecot

Također obratite pažnju na red "ssl_protocols". Njegova vrijednost mora biti "!SSLv3" inače ćete dobiti grešku "Upozorenje: SSLv2 nije podržan od strane OpenSSL-a. Razmislite o tome da ga uklonite iz ssl_protocols" prilikom ponovnog pokretanja Dovecot-a.

# nano /etc/postfix/main.cf

Pronalaženje bloka:

# SSL ključ, certifikat, CA

I mijenjamo putanje u njemu u putanje do datoteka našeg certifikata.

Zamjena certifikata za Postfix

Ovim je završena instalacija certifikata. Potrebno je ponovo pokrenuti Dovecot i Postfix, ali je bolje ponovo pokrenuti server.

# restart usluge dovecot

# ponovno pokretanje

Instaliranje PHPMyAdmin

Ova stavka nije obavezna, ali preporučujem da je dovršite i instalirate PHPMyAdmin za vaše iskustvo u bazi podataka.

# apt install phpmyadmin

Instalater će od vas tražiti da radite sa kojim web serverom da konfigurišete PHPMyAdmin, pošto NGINX nije na ovoj listi, samo pritisnite TAB i nastavite dalje.

Instaliranje PHPMyAdmin

Nakon što je instalacija završena, da bi phpmyadmin radio, morate napraviti simboličku vezu do direktorija s kojim NGINX radi po defaultu.

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

I pokušajte da odete do https://domain/phpmyadmin/

PHPMyAdmin radi. Veza je zaštićena certifikatom, nema grešaka. Pomakni se. Kreirajmo MySQL administratora baze podataka (MariaDB).

# mysql

I ulazimo u MariaDB konzolu za upravljanje. Zatim izvršavamo naredbe jednu po jednu:

MariaDB > KREIRAJ KORISNIKA "admin"@"localhost" IDENTIFIKOVANO JE "password";
MariaDB > DODAJTE SVE PRIVILEGIJE NA *.* "admin"@"localhost" SA OPCIJOM GRANT;
MariaDB > FLUSH PRIVILEGES;

Kreiranje MySQL korisnika

Sve je u redu, prijavljeni ste. PHPMyAdmin je spreman za rad.

Instaliranje PostfixAdmin

U principu, PostfixAdmin, kao i PHPMyAdmin, ne može se instalirati. Mail server će raditi sasvim dobro bez ovih komponenti. Ali tada nećete moći kreirati pseudonime pošte. Ako vam ovo nije potrebno, slobodno preskočite ove dijelove. Ako su vam i dalje potrebni aliasi, onda imate dvije opcije: kupiti plaćenu verziju iReaAdmin-a ili instalirati PostfixAdmin. Naravno, to možete učiniti bez dodatnog softvera ručnim pisanjem aliasa u bazi podataka, ali to nije uvijek zgodno i nije prikladno za sve. Preporučujem korištenje PostfixAdmina, sada ćemo razmotriti njegovu instalaciju i integraciju sa iRedMailom. Počinjemo sa instalacijom:

# apt install postfixadmin

Slažemo se i kreiramo lozinku za sistemsku bazu podataka programa.

Instaliranje PostfixAdmin

Instaliranje PostfixAdmin

Simbolsku vezu pravimo po analogiji sa instalacijom PHPMyAdmin-a.

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

Vlasnikom direktorija činimo korisnika u čije ime se pokreće web server. U našem slučaju, NGINX se pokreće kao korisnik www-data.

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

Sada trebamo urediti konfiguracijsku datoteku PostfixAdmin i dodati informacije o bazi podataka koju iRedAdmin koristi. Podrazumevano, ova baza podataka se zove vmail. Ako odete na PHPMyAdmin, možete ga vidjeti tamo. I tako, da bi PostfixAdmin izvršio promjene u bazi podataka, to propisujemo u konfiguraciji PostfixAdmin.

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

Pronalaženje linija:

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

I zapamtite:

$CONF["database_type"] = "mysqli"; # Vrsta baze podataka
$CONF["database_host"] = "localhost"; # Host servera baze podataka
$CONF["database_user"] = "admin"; # Prijavite se sa pristupom za pisanje na vmail bazu podataka. Možete koristiti prethodno kreiranog administratora
$CONF["database_password"] = "lozinka"; # Lozinka gore navedenog korisnika
$CONF["database_name"] = "vmail"; # Ime baze podataka iRedMail

Unošenje informacija u bazu podataka

Ako planirate koristiti SOGo web mail klijent, onda morate napraviti još jedan dodatni korak, odnosno promijeniti PostfixAdmin enkripciju u paragrafu $CONF["šifriranje"] sa "md5crypt" na "dovecot:SHA512-CRYPT". Ako to ne učinite, onda kada pokušate autorizirati u SOGo od strane korisnika kreiranog u PostfixAdmin-u, dobit ćete grešku s pogrešnim login-om ili lozinkom.

Promjena vrste šifriranja

Sada, kako biste uspješno dovršili instalaciju i ne biste dobili greške, trebate postaviti upit u bazu podataka. Zgodno je to učiniti preko PHPMyAdmin-a. Odaberite vmail bazu podataka i idite na karticu SQL. U prozoru unesite:

DROP INDEX domena na poštanskom sandučetu;
DROP INDEX domena na aliasu;
ALTER TABLE alias ADD COLUMN `goto` text NOT NULL;

Upit baze podataka

I pritisnite "Naprijed". Sada smo spremni, možete otići na PostfixAdmin web sučelje i završiti instalaciju. Da biste to uradili, u pretraživaču morate upisati: https://domain/postfixadmin/setup.php.

Trebalo bi se pojaviti sljedeće:

Instaliranje PostfixAdmin

Ako se sve radi prema uputama, onda ne bi trebalo biti grešaka. Ako i dalje jesu, onda su izdani da budu eliminisani, inače vam sistem neće dozvoliti da nastavite. Postavite lozinku za instalaciju i kliknite " Generirajte hash lozinke". Sistem će generirati hash lozinke, koji se mora umetnuti u parametar $CONF["setup_password"].

Završetak instalacije PostfixAdmin-a

Promjena postavki konfiguracijske datoteke

Sada unosimo lozinku koju smo upravo kreirali i kreiramo PostfixAdmin administratora. Bolje je da ne kreirate administratora sa prijavom na postmaster, jer može doći do problema sa prijavljivanjem na iRedAdmin administrativni panel.

Kreiranje PostfixAdmin administratora

Sve, administrator je kreiran. Možete se prijaviti.

Imajte na umu da je sa sigurnosne tačke gledišta bolje preimenovati ili izbrisati datoteku setup.php u direktoriju postfixadmin.

Idemo: https://domain/postfixadmin/ i unesite novokreirane vjerodajnice. U PostfixAdmin-u, kao iu iRedAdmin-u, dostupan je ruski jezik. Može se odabrati tokom autorizacije.

Pokušavamo kreirati korisničko sanduče.

Omogućite/onemogućite iRedMail module

iRedMail modulima upravlja iRedAPD. Ima konfiguracijski fajl koji sadrži radne module. Ako vam ne treba određeni modul, možete ga ukloniti iz konfiguracijske datoteke i on će prestati raditi. Mi radimo:

# nano /opt/iredapd/settings.py

Nađi liniju dodaci" i uklonite komponente koje vam nisu potrebne iz njega. Ja ću ukloniti komponentu "siva lista". Naravno, prilično efikasno štiti od neželjene pošte, ali potrebna pisma često ne stignu.

Greylist (siva lista) je automatska tehnologija zaštite od neželjene pošte zasnovana na analizi ponašanja servera pošiljaoca. Kada je "siva lista" omogućena, server odbija da prihvati pismo sa nepoznate adrese po prvi put, prijavljujući privremenu grešku. U tom slučaju, poslužitelj pošiljatelj mora ponovo pokušati slanje kasnije. Spameri to obično ne rade. Ako se pismo ponovo pošalje, dodaje se na listu na 30 dana i pošta se već razmjenjuje od prvog puta. Koristite ovaj modul ili ne odlučite sami.

Omogućavanje/onemogućavanje mail modula

Morate ponovo pokrenuti nakon unošenja izmjena. iRedAPD.

# usluga iredapd restart

Testiranje mail servera

Ovim je završeno podešavanje iRedMail servera pošte. Možete nastaviti do završne faze - testiranja. Kreirajmo dva poštanska sandučića. Za provjeru jednog preko iRedAdmina, drugog preko PostfixAdmin-a i slanje pisma iz jednog sandučeta u drugo i obrnuto. Kreirajte poštanski sandučić u iRedAdmin [email protected] domain.ru. U PostfixAdmin-u - [email protected] domain.ru

Kreiranje korisnika u iRedAdmin-u

Kreiranje korisnika u PostfixAdmin

Provjerite da li su korisnici kreirani.

Ako obratite pažnju na kolonu "Za" na listi PostfixAdmin poštanskih sandučića, možete vidjeti razliku između poštanskih sandučića kreiranih u iRedAdmin i PostfixAdmin. Poštanski sandučići kreirani u iRedAdmin-u su označeni kao " samo naprijed", a one kreirane u PostfixAdmin-u kao - " Mailbox". Dugo nisam mogao da shvatim zašto se to dešava i koja je razlika između njih, a na kraju sam primetio jednu stvar. Poštanski sandučići u iRedAdmin-u se kreiraju bez alijasa, a sandučići u PostfixAdmin-u sa pseudonimom za sebe.

A ako se ovi aliasi izbrišu, poštanski sandučići će biti prikazani kao oni kreirani u iRedAdmin-u" samo naprijed".

Uklanjanje alijasa

Aliasi su uklonjeni. Provjerite PostfixAdmin.

Kao što vidite, sve kutije su postale "Samo naprijed". Na isti način, ako kreirate pseudonim za sebe u poštanskom sandučetu kreiranom u iRedAdmin-u, ono će postati "Poštansko sanduče". U principu, to ne utiče na performanse pošte. Jedina stvar je da nećete moći kreirati pseudonim za poštansko sanduče kreirano u PostfixAdmin-u. Umjesto da kreirate alias, morat ćete urediti postojeći. Kad smo kod pseudonima, u novoj verziji iRedMail-a, potrebno je da izvršite promjenu jedne od Postfix kartica koja je odgovorna za pseudonime. A ako to ne učinite, onda stvoreni aliasi neće raditi. Za to je potrebno u fajlu /etc/postfix/mysql/virtual_alias_maps.cf ispraviti:

Mi radimo:

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

I mi to popravljamo.

Postavljanje alijasa

Ponovo pokreni Postfix:

# servis postfix restart

Nakon toga bi sve trebalo da funkcioniše.

I tako, hajde da provjeravamo poštu. U kutiji korisnik1 proći ćemo kroz Roundcube i u kutiju korisnik2- preko SOGo i pošaljite pismo iz poštanskog sandučeta korisnik1 na korisnik2 i nazad.

Slanje e-pošte sa Roundcube

Primanje e-pošte u SOGo

Slanje e-pošte na SOGo

Primanje e-pošte u Roundcube

Sve radi bez ikakvih problema. Dostava pisma traje od dvije do pet sekundi. Na isti način, pisma se savršeno isporučuju na Yandex i mail.ru servere (provjereno).

Sada provjerimo pseudonime. Kreirajmo kutiju korisnik3 i napravite pseudonim iz poštanskog sandučeta korisnik1 na kutiji korisnik2. I pošalji pismo iz kutije korisnik3 na kutiji korisnik1. U tom slučaju, pismo će morati doći u kutiju korisnik2.

Kreirajte pseudonim

Slanje e-pošte iz poštanskog sandučeta korisnika3 u poštansko sanduče korisnika1

Primanje pisma na poštansko sanduče korisnika2

I sa radom alijasa je sve u redu.

Testirajmo rad mail servera preko lokalnog mail klijenta. Na primjer, uzmite u obzir Mozilla Thunderbird. Kreirajmo još dva korisnika: klijent1 i klijent2. Jedno poštansko sanduče ćemo povezati preko IMAP-a, drugo preko POP3 i poslati pismo iz jednog sandučeta u drugi.

Povezivanje putem IMAP-a

POP3 veza

Šaljemo pismo od Klijenta 1 Klijentu 2.

Otprema od kupca 1

Primite od klijenta 2

I obrnutim redoslijedom.

Slanje od klijenta 2

Primite od klijenta 1

Sve radi.

ako idete na: https://domain/netdata, tada možete posmatrati grafikone stanja sistema.

Zaključak

Ovim je završena instalacija, konfiguracija i testiranje iRedMail sistema pošte. Kao rezultat toga, dobili smo potpuno besplatan, punopravni mail server sa važećim SSL certifikatom, dva različita web-bazirana mail klijenta, dva kontrolna panela, kao i anti-spam i anti-virus ugrađen u poštu. Ako želite, umjesto web mail klijenata možete koristiti lokalne klijente pošte kao što su Microsoft Outlook ili Mozilla Thunderbird. Ako ne planirate koristiti klijente web pošte, ne možete ih uopće instalirati kako ne biste preopteretili server ili instalirali nešto što vam se više sviđa. Meni se lično više sviđa SOGo jer je njegov interfejs optimizovan za mobilne uređaje, što ga čini veoma pogodnim za gledanje e-pošte sa pametnog telefona. Isto važi i za NetData i iRedAdmin, ako ne planirate da ga koristite, bolje je da ga ne instalirate. Ovaj sistem pošte nije mnogo zahtjevan za resurse. Sve ovo radi na VPS serveru sa 1024 MB RAM-a i jednim virtuelnim procesorom. Ako imate bilo kakvih pitanja o ovom sistemu pošte, pišite u komentarima.

P.S. Prilikom testiranja ovog proizvoda na različitim operativnim sistemima sa 1 GB RAM-a (Ubuntu, Debian, CentOS) pokazalo se da 1 GB nije dovoljno za ClamAV za rad. U gotovo svim slučajevima, kada se koristi 1 GB memorije, antivirus se pozivao na grešku baze podataka. Istovremeno, na operativnim sistemima Debian i Ubuntu, antivirus jednostavno nije skenirao poštu koja je prolazila kroz server, inače je sve radilo u redu. Na CentOS-u je situacija bila nešto drugačija. Clamd usluga je u potpunosti prekinula sistem i tako onemogućila normalan rad servera. Prilikom pokušaja da se prijavi na web interfejse, NGINX je periodično davao greške 502 i 504. Pošta je također poslana kroz vrijeme. U isto vrijeme, ako dodate do 2 GB RAM-a, tada u svim slučajevima nije bilo problema s radom antivirusa i servera u cjelini. ClamAV je skenirao poštu koja prolazi kroz mail server i pisao o tome u logovima. Prilikom pokušaja slanja virusa u prilogu, slanje je blokirano. Potrošnja memorije je bila otprilike 1,2 - 1,7 GB.

NGINX se može koristiti ne samo kao web server ili http-proxy, već i za proxy mail putem SMTP, IMAP, POP3 protokola. Ovo će postaviti:

• Jedna ulazna tačka za skalabilni sistem pošte.
• Balansiranje opterećenja između svih servera pošte.

Ovaj članak se instalira na Linux operativni sistem. Kao mail servis na koji se šalju zahtjevi, možete koristiti postfix, exim, dovecot, exchange, iredmail Assembly i još mnogo toga.

Princip rada

NGINX prihvata zahtjeve i provjerava autentičnost na web serveru. Ovisno o rezultatu provjere prijave i lozinke, proxy će vratiti odgovor s nekoliko zaglavlja.

U slučaju uspjeha:

Tako određujemo server i port mail servera na osnovu autentifikacije. Ovo daje puno mogućnosti uz odgovarajuće poznavanje programskih jezika.

U slučaju kvara:

Ovisno o rezultatu autentifikacije i zaglavlju, klijent se preusmjerava na mail server koji nam je potreban.

Priprema servera

Učinimo neke promjene u sigurnosnim postavkama servera.

SELinux

Onemogućite SELinux ako koristite CentOS ili ako koristite ovaj sigurnosni sistem na Ubuntu:

vi /etc/selinux/config

SELINUX=onemogućeno

Firewall

Ako koristimo firewalld(podrazumevano na CentOS-u):

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

firewall-cmd --reload

Ako koristimo iptables(podrazumevano u Ubuntu):

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

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

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

apt-get install iptables-persistent

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

* u ovom primjeru smo dozvolili SMTP (25), POP3 (110), IMAP (143).

Instaliranje NGINX-a

U zavisnosti od operativnog sistema, instalacija NGINX-a se malo razlikuje.

ili Linux centos:

yum instaliraj nginx

ili Linux ubuntu:

apt install nginx

Dozvoljavamo automatsko pokretanje servisa i pokrećemo ga:

systemctl omogući nginx

systemctl start nginx

Ako je NGINX već instaliran na sistemu, provjerite s kojim modulima radi:

Dobićemo listu opcija sa kojima je web server izgrađen - među njima treba da vidimo --sa poštom. Ako potrebni modul ne postoji, morate ažurirati nginx

Postavljanje NGINX-a

Otvorite nginx konfiguracijsku datoteku i dodajte opciju mail:

vi /etc/nginx/nginx.conf

pošta (

auth_http localhost:80/auth.php;

Server(
slušaj 25;
protokol smtp;
smtp_auth prijava običan cram-md5;
}

Server(
slušaj 110;
protokol pop3;

}

Server(
slušaj 143;
protocolimap;
}
}

* gdje:

• server_name— naziv mail servera koji će biti prikazan tokom SMTP pozdrava.
• auth_http— web server i URL za zahtjev za autentifikaciju.
• proxy_pass_error_message— dozvoljava ili odbija prikaz poruke u slučaju neuspješne autentifikacije.
• slušaj— port na kojem se slušaju zahtjevi.
• protokol je protokol aplikacije za koji odgovarajući port sluša.
• smtp_auth— dostupne metode provjere autentičnosti za SMTP.
• pop3_auth— dostupne metode provjere autentičnosti za POP3.

U odeljku http - server dodajte:

Server(
slušaj 80 default_server;
slušaj [::]:80 default_server;
...

Lokacija ~ \.php$ (
set $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;
uključiti fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

Ponovo pokrenite nginx server:

systemctl ponovo pokrenite nginx

Instalacija i konfiguracija PHP-a

Da biste izvršili autentifikaciju pomoću PHP-a, na sistemu moraju biti instalirani sljedeći paketi.

Ako a CentOS:

yum instaliraj php php-fpm

Ako a ubuntu:

apt-get install php php-fpm

Pokrenite PHP-FPM:

systemctl omogući php-fpm

systemctl start php-fpm

Autentifikacija

Prijava i lozinka se provjeravaju skriptom, do koje je putanja postavljena opcijom auth_http. U našem primjeru, ovo je PHP skripta.

Primjer službenog predloška za skriptu za provjeru prijave i lozinke:

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

* ova skripta prihvata bilo koju prijavu i lozinku i preusmjerava zahtjeve na servere 192.168.1.22 i 192.168.1.33 . Da bismo postavili algoritam za autentifikaciju, uređujemo linije 61 - 64. Linije 73 - 77 su odgovorne za vraćanje servera na koje je preusmjeravanje u toku - u ovom primjeru, ako prijava počinje znakovima "a", "c", "f", "g", tada će preusmjeravanje biti na server mailhost01, inače, na mailhost02. Mapiranje imena servera u IP adrese može se podesiti u redovima 31, 32, inače će poziv ići po imenu domene.

Podešavanje mail servera

Razmjena podataka između NGINX proxyja i mail servera je čista. Izuzetku je potrebno dodati mogućnost autentifikacije putem PLAIN mehanizma. Na primjer, da konfigurirate golubarnik, učinite sljedeće:

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

Dodaj redove:

daljinski 192.168.1.11 (
disable_plaintext_auth = ne
}

* u ovom primjeru smo dozvolili PLAIN zahtjeve za autentifikaciju sa servera 192.168.1.11 .

Također provjeravamo:

* ako ssl bit će važno potrebno, provjera neće raditi, jer se ispostavilo da s jedne strane server dozvoljava zahtjeve u čistom obliku, ali zahtijeva ssl enkripciju.

Ponovo pokrenite Dovecot uslugu:

systemctl restart dovecot

Podešavanje klijenta

Možete nastaviti s provjerom naših proxy postavki. Da biste to učinili, u postavkama klijenta navedite adresu ili ime nginx servera kao IMAP/POP2/SMTP, na primjer:

* u ovom primjeru, mail klijent je konfiguriran da se poveže sa serverom 192.168.1.11 otvorenim portovima 143 (IMAP) i 25 (SMTP).

Enkripcija

Sada postavimo SSL vezu. Nginx mora biti izgrađen sa modulom mail_ssl_module- provjerite komandom:

U nedostatku potrebnog modula, ponovo gradimo nginx.

Nakon uređivanja naše konfiguracijske datoteke:

vi /etc/nginx/nginx.conf

pošta (
server_name mail.domain.local;
auth_http localhost/auth.php;

proxy_pass_error_message on;

SSL uključen;
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(
slušaj 110;
protokol pop3;
pop3_auth običan apop cram-md5;
}

Server(
slušaj 143;
protocolimap;
}

Razlog: SELinux sigurnosni sistem je aktiviran.

Rješenje: onemogućite ili konfigurirajte SELinux.