Nginx-postipalvelin. NGINX:n asettaminen sähköpostin välityspalvelinta varten

Tässä artikkelissa kerrotaan, kuinka NGINX Plus tai NGINX Open Source määritetään välityspalvelimeksi sähköpostipalvelimelle tai ulkoiselle sähköpostipalvelulle.

Johdanto

NGINX voi välittää IMAP-, POP3- ja SMTP-protokollia johonkin ylävirran sähköpostipalvelimista, jotka isännöivät sähköpostitilejä, ja näin ollen sitä voidaan käyttää yhtenä päätepisteenä sähköpostiohjelmille. Tämä voi tuoda useita etuja, kuten:

• sähköpostipalvelimien määrän helppo skaalaus
• sähköpostipalvelimen valinta eri sääntöjen perusteella, esimerkiksi lähimmän palvelimen valinta asiakkaan IP-osoitteen perusteella
• jakaa kuorman postipalvelimien kesken

Edellytykset

NGINX Plus (sisältää jo sähköpostiliikenteen välityspalvelimen edellyttämät Mail-moduulit) tai NGINX Open Source käänsi Mail-moduulit käyttämällä --with-mail-parametria sähköpostin välityspalvelintoiminnalle ja --with-mail_ssl_module-parametria SSL/TLS-tukeen:

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

IMAP-, POP3- ja/tai SMTP-sähköpostipalvelimet tai ulkoinen sähköpostipalvelu

SMTP/IMAP/POP3-sähköpostin välityspalvelinten määrittäminen

NGINX-määritystiedostossa:

posti ( #... )

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

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

Vaihtoehtoisesti voit määrittää, haluatko ilmoittaa käyttäjälle todennuspalvelimen virheistä määrittämällä proxy_pass_error_message-direktiivin. Tämä voi olla kätevää, kun postilaatikon muisti loppuu:

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

Määritä jokainen SMTP-, IMAP- tai POP3-palvelin palvelinlohkoilla. Määritä jokaiselle palvelimelle:

• the porttinumero jotka vastaavat kuunteluohjeen kanssa määritettyä protokollaa
• the protokollaa protokolladirektiivin kanssa (jos sitä ei ole määritetty, tunnistetaan automaattisesti kuunteluohjeessa määritetystä portista)
• sallittu todennusmenetelmiä imap_auth-, pop3_auth- ja smtp_auth-käskyillä:

palvelin (kuuntele 25 ; protokolla smtp ; smtp_auth login plain cram-md5 ; ) palvelin ( kuuntele 110 ; protokolla pop3 ; pop3_auth pelkkä apop cram-md5 ; ) palvelin ( kuuntele 143 ; protokolla imap ; )

Todennuksen määrittäminen sähköpostin välityspalvelimelle

Jokainen asiakkaan POP3/IMAP/SMTP-pyyntö todennetaan ensin ulkoisella HTTP-todennuspalvelimella tai todennuskomentosarjalla. Todennuspalvelimen käyttö on pakollista NGINX-postipalvelimen välityspalvelimelle. Palvelimen voi luoda itse NGINX-todennusprotokollan mukaisesti, joka perustuu HTTP-protokollaan.

Jos todennus onnistuu, todennuspalvelin valitsee ylävirran palvelimen ja ohjaa pyynnön uudelleen. Tässä tapauksessa palvelimen vastaus sisältää seuraavat rivit:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # sen ylävirran palvelimen palvelimen nimi tai IP-osoite, jota käytetään sähköpostin käsittelyyn Auth-Port: # ylävirran palvelimen portti

Jos todennus epäonnistuu, todennuspalvelin palauttaa virheilmoituksen. Tässä tapauksessa palvelimen vastaus sisältää seuraavat rivit:

HTTP/1.0 200 OK Auth-Status: # asiakkaalle palautettava virhesanoma, esimerkiksi "Virheellinen sisäänkirjautuminen tai salasana" Auth-Wait: # jäljellä olevien todennusyritysten määrä, kunnes yhteys suljetaan

Huomaa, että molemmissa tapauksissa vastaus sisältää HTTP/1.0 200 OK mikä saattaa olla hämmentävää.

Lisää esimerkkejä todennuspalvelimen pyynnöistä ja vastauksista on NGINX-viitedokumentaation ngx_mail_auth_http_moduulissa.

SSL/TLS:n määrittäminen sähköpostin välityspalvelimelle

Käyttämällä POP3/SMTP/IMAP yli SSL/TLS-protokollaa varmistat, että asiakkaan ja sähköpostipalvelimen välillä siirretyt tiedot ovat suojattuja.

Ota SSL/TLS käyttöön sähköpostin välityspalvelimelle seuraavasti:

Varmista, että NGINX:ssäsi on SSL/TLS-tuki kirjoittamalla komentoriville nginx -V-komento ja etsimällä sitten riviä with --mail_ssl_module tulosteesta:

$ nginx -V määrittää argumentit: ... with--mail_ssl_module

Varmista, että olet hankkinut palvelinvarmenteet ja yksityisen avaimen ja aseta ne palvelimelle. Varmenteen voi hankkia luotetulta sertifikaattiviranomaiselta (CA) tai luoda käyttämällä SSL-kirjastoa, kuten OpenSSL:ää.

ssl päällä;

starttls päällä ;

Lisää SSL-varmenteita: määritä sertifikaattien polku (jonka on oltava PEM-muodossa) ssl_certificate-käskyllä ​​ja yksityisen avaimen polku ssl_certificate_key-direktiivissä:

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

Voit käyttää vain vahvoja SSL/TLS-versioita ja salauksia ssl_protocols- ja ssl_ciphers-käskyjen kanssa tai voit määrittää omia protokollia ja salauksia:

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

SSL/TLS:n optimointi sähköpostin välityspalvelimelle

Nämä vinkit auttavat sinua tekemään NGINX-sähköpostivälityspalvelimestasi nopeamman ja turvallisemman:

Aseta työprosessien määrä yhtä suureksi kuin prosessorien määrä, kun worker_processes-direktiivi on asetettu samalle tasolle kuin sähköpostikonteksti:

työntekijä_prosessit auto ; posti ( #... )

Ota käyttöön jaettu istuntovälimuisti ja poista sisäänrakennettu istuntovälimuisti käytöstä automaattisella ; Mail (server_name mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message päällä; ssl päällä; ssl_certificate /etc/ssl/certs/server.crt; ssl_certificate_key/etsl/sserver.crt; avain; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; ssl_session_cache share:SSL:10m; ssl_session_timeout 10m; palvelin (kuuntelu -md5;) palvelin (kuuntele 1 10 ; protokolla pop3 ; pop3_auth pelkkä apop cram-md5 ; ) palvelin ( kuuntele 143 ; protokolla imap ; ) )

Tässä esimerkissä on kolme sähköpostin välityspalvelinta: SMTP, POP3 ja IMAP. Jokaisella palvelimilla on SSL- ja STARTTLS-tuki. SSL-istunnon parametrit tallennetaan välimuistiin.

Välityspalvelin käyttää HTTP-todennuspalvelinta – sen määritykset eivät kuulu tämän artikkelin piiriin. Kaikki palvelimen virheilmoitukset palautetaan asiakkaille.

iRedMail on valmis kokoonpano sähköpostipalvelin auki lähdekoodi. Kokoonpano perustuu Postfix SMTP -palvelimeen (Mail Transfer Agent, lyhenne MTA). Kokoonpano sisältää myös: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData ja NGINX.

Dovecot - IMAP/POP3-palvelin.

Spamassassin on roskapostin suodatustyökalu.

Greylist on greylist-pohjainen roskapostin estotyökalu.

ClamAV on virustorjunta.

Roundcube ja SOGo ovat web-asiakkaita sähköpostin kanssa työskentelemiseen.

NetData on reaaliaikainen palvelimen valvontaohjelma.

Nginx on verkkopalvelin.

Tukee käyttöjärjestelmiä: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 ja OpenBSD 6.4.

iRedMaililla on maksulliset ja ilmaiset versiot, jotka eroavat toisistaan ​​oman iRedAdmin-sähköpostikokoonpanon verkkoliittymänsä toimivuudessa. SISÄÄN ilmainen versio Voit luoda vain verkkotunnuksia, käyttäjä- ja järjestelmänvalvojan postilaatikoita. Jos sinun on luotava alias, et voi enää tehdä sitä ilmaisessa versiossa iRedAdminin kautta. Onneksi on olemassa ilmainen ratkaisu nimeltä PostfixAdmin, jonka avulla voit tehdä tämän. PostfixAdmin integroituu helposti iRedMailiin ja toimii hyvin sen kanssa.

Asennus

Asentaaksemme tarvitsemme jonkin yllä luetelluista käyttöjärjestelmistä. Käytän Ubuntu Server 18.04:ää. Sinun on myös täytynyt ostaa Verkkotunnus ja määritetty DNS-vyöhyke. Jos käytät DNS-palvelimet verkkotunnuksesi rekisteröijäsi, sinun on tehtävä kaksi merkintää verkkotunnuksen vyöhykkeen hallintaosioon: A ja MX. Voit myös käyttää omaa DNS:ääsi määrittämällä delegoinnin henkilökohtainen tili verkkotunnuksesi rekisteröijä.

Verkkoalueen vyöhykkeen määrittäminen DNS-rekisteröintipalvelua käytettäessä

Huomautus! Sisääntuloaika DNS-asetukset kestää useista tunteista yhteen viikkoon. Ennen kuin asetukset tulevat voimaan, sähköpostipalvelin ei toimi oikein.

Asenna lataamalla iRedMail-verkkosivustolta nykyinen versio. Tällä hetkellä se on 0.9.9.

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

Pura sitten ladattu arkisto.

# tar xjf iRedMail-0.9.9.tar.bz2

Arkiston purkaminen

Ja siirry luotuun kansioon.

# cd iRedMail-0.9.9

iRedMail-asennuskansio

Kansion sisällön tarkistaminen

Kansion sisältö

Ja suorita iRedMail-asennusskripti.

# bash iRedMail.sh

Postijärjestelmän asennus alkaa. Asennusprosessin aikana sinun on vastattava useisiin kysymyksiin. Sovimme asennuksen aloittamisesta.

Aloita asennus

Asennushakemiston valinta

Nyt sinun on valittava verkkopalvelin. Valinnanvaraa ei ole paljon, joten valitsemme NGINX:n.

Web-palvelimen valitseminen

Nyt sinun on valittava tietokantapalvelin, joka asennetaan ja konfiguroidaan toimimaan sähköpostijärjestelmän kanssa. Valitse MariaDB.

Tietokantapalvelimen valinta

Aseta tietokannan pääkäyttäjän salasana.

Luodaan tietokannan pääkäyttäjän salasana

Nyt ilmoitamme sähköpostiverkkotunnuksemme.

Sähköpostin verkkotunnuksen luominen

Sitten luomme salasanan järjestelmänvalvojan postilaatikkoon [email protected].

Sähköpostin ylläpitäjän salasanan luominen

Web-komponenttien valitseminen

Vahvista määritetyt asetukset.

Asetusten vahvistaminen

Asennus on alkanut.

Asennus

Kun asennus on valmis, vahvista SSH:n iptables-säännön luominen ja käynnistä palomuuri uudelleen. iRedMail toimii iptablesin kanssa. Ubuntussa yleisimmin käytetty palomuurin hallintaapuohjelma on UFW. Jos sinulla on syystä tai toisesta sellainen tarve, asenna UFW (apt install ufw) ja lisää säännöt, jotta UFW (esimerkki: ufw salli "Nginx Full" tai ufw salli Postfix) ei estä sähköpostipalvelimen toimintaa. Voit tarkastella saatavilla olevien sääntöjen luetteloa suorittamalla komennon: ufw app list . Ota sitten UFW käyttöön: ufw enable.

Iptables-säännön luominen

Palomuurin uudelleenkäynnistys

Tämä päättää iRedMailin asennuksen. Järjestelmä toimitti meille verkkokäyttöliittymän osoitteet ja kirjautumistiedot. Jos haluat ottaa kaikki sähköpostijärjestelmän osat käyttöön, sinun on käynnistettävä palvelin uudelleen.

Asennus valmistuu

Käynnistetään uudelleen.

#käynnistetään uudelleen

asetukset

Ensin sinun on varmistettava, että kaikki toimii. Yritetään kirjautua sisään iReadAdminin ohjauspaneeliin osoitteessa https://domain/iredadmin. Kirjaudu sisään [email protected], salasana luotiin asennuksen aikana. Siellä on venäjänkielinen käyttöliittymä.

Kuten näet, kaikki toimii. Kun kirjaudut iRedAdminiin, sait todennäköisesti varmenteeseen liittyvän suojausvirheen. Tämä johtuu siitä, että iRedMailissa on sisäänrakennettu itse allekirjoitettu varmenne, josta selain valittaa. Voit ratkaista tämän ongelman asentamalla kelvollisen SSL-varmenteen. Jos olet ostanut sellaisen, voit asentaa sen. Esimerkissä asenna ilmaisen SSL:n Let's Encryptistä.

Let's Encrypt SSL -varmenteen asentaminen

Asennamme varmenteen käyttämällä certbot-apuohjelmaa. Ensin lisätään arkisto.

# add-apt-arkisto ppa:certbot/certbot

Sitten asennamme itse certbootin tarvittavilla komponenteilla.

# apt install python-certbot-nginx

Saamme todistuksen.

# certbot --nginx -d domain.ru

Komennon suorittamisen jälkeen järjestelmä pyytää sinua antamaan sähköpostiosoitteesi, syötä. Tämän jälkeen saat todennäköisesti virheilmoituksen, että ei ole mahdollista löytää palvelinlohkoa, jolle varmenne on luotu. Tässä tapauksessa tämä on normaalia, koska meillä ei ole palvelinlohkoa. Meille tärkeintä on saada todistus.

Todistuksen saaminen

Kuten näemme, varmenne vastaanotettiin onnistuneesti ja järjestelmä näytti meille polut itse varmenteeseen ja avaimeen. Ne ovat juuri sitä mitä tarvitsemme. Yleensä saimme 4 tiedostoa, jotka tallennetaan kansioon "/etc/letsencrypt/live/domain". Nyt meidän on ilmoitettava verkkopalvelimelle varmenteestamme, eli korvattava upotettu varmenne juuri saamallamme varmenteella. Tätä varten meidän on muokattava vain yksi tiedosto.

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

Ja muutamme sen kaksi viimeistä riviä.

SSL-varmenteen vaihto

Muutamme tiedoston polut poluiksi, jotka järjestelmä kertoi meille varmennetta vastaanotettaessa.

SSL-varmenteen vaihtaminen

Ja käynnistä NGINX uudelleen.

# palvelu nginx käynnistyy uudelleen

Yritetään nyt kirjautua iRedAdminiin uudelleen.

SSL-varmennetta tarkistetaan

Varmennevirheitä ei enää ole. Todistus on voimassa. Voit napsauttaa lukkoa ja nähdä sen ominaisuudet. Kun varmenne vanhenee, certbootin pitäisi uusia se automaattisesti.

Nyt raportoimme Dovecot- ja Postfix-sertifikaatista. Tätä varten muokkaamme kahta asetustiedostoa. Me teemme:

# nano /etc/dovecot/dovecot.conf

Lohkon löytäminen:

#SSL: Yleiset asetukset.

Ja vaihdamme siellä rekisteröidyn varmenteen omaksemme.

Kyyhkysen vaihtotodistus

Kiinnitä huomiota myös riviin "ssl_protocols". Sen arvon on oltava "!SSLv3", muuten saat virheilmoituksen "Varoitus: OpenSSL ei tue SSLv2:ta. Harkitse sen poistamista ssl_protocolsista", kun käynnistät Dovecotin uudelleen.

# nano /etc/postfix/main.cf

Lohkon löytäminen:

# SSL-avain, varmenne, CA

Ja muutamme siinä olevat polut sertifikaattimme tiedostojen polulla.

Varmenteen vaihtaminen Postfixille

Tämä päättää varmenteen asennuksen. Dovecot ja Postfix on käynnistettävä uudelleen, mutta on parempi käynnistää palvelin uudelleen.

# huoltokyyhkysen uudelleenkäynnistys

#käynnistetään uudelleen

PHPMyAdminin asentaminen

Tämä vaihe on valinnainen, mutta suosittelen sen tekemistä ja PHPMyAdminin asentamista tietokantojen käytön helpottamiseksi.

# apt install phpmyadmin

Asennusohjelma kysyy, minkä web-palvelimen kanssa PHPMyAdmin tulee määrittää toimimaan, koska NGINX ei ole tässä luettelossa, paina SARKAINTA ja siirry eteenpäin.

PHPMyAdminin asentaminen

Kun asennus on valmis, jotta phpmyadmin toimisi, sinun on tehtävä symbolilinkki hakemistoon, jonka kanssa NGINX toimii oletuksena.

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

Ja yritämme mennä osoitteeseen https://domain/phpmyadmin/

PHPMyAdmin on käynnissä. Yhteys on suojattu varmenteella, virheitä ei ole. Mene eteenpäin. Luodaan MySQL-tietokannan ylläpitäjä (MariaDB).

# mysql

Ja pääsemme MariaDB-hallintakonsoliin. Seuraavaksi suoritamme komennot yksitellen:

MariaDB > LUO KÄYTTÄJÄ "admin"@"localhost" TUNNISTETTU "salasanalla";
MariaDB > MYÖNTÄ KAIKKI OIKEUDET *.*:lle "admin"@"localhost" MYÖNTÄVAIHTOEHDOLLA;
MariaDB > PUHDISTUS-ETUT;

MySQL-käyttäjän luominen

Kaikki on kunnossa, kirjautuminen on valmis. PHPMyAdmin on valmis käyttöön.

PostfixAdminin asennus

Periaatteessa PostfixAdminia, kuten PHPMyAdminia, ei tarvitse asentaa. Postipalvelin toimii hyvin ilman näitä komponentteja. Mutta silloin et voi luoda sähköpostialiaksia. Jos et tarvitse tätä, voit turvallisesti ohittaa nämä osiot. Jos tarvitset edelleen aliaksia, sinulla on kaksi vaihtoehtoa: ostaa iReaAdminin maksullinen versio tai asentaa PostfixAdmin. Tietenkin voit tehdä tämän ilman lisäohjelmistoja rekisteröimällä aliaksia tietokantaan manuaalisesti, mutta tämä ei ole aina kätevää eikä sovi kaikille. Suosittelen PostfixAdminin käyttöä; tarkastelemme nyt sen asennusta ja integrointia iRedMailin kanssa. Aloitetaan asennus:

# apt install postfixadmin

Sovimme ja luomme salasanan ohjelman järjestelmätietokantaan.

PostfixAdminin asennus

PostfixAdminin asennus

Luomme symlinkin samalla tavalla kuin asennamme PHPMyAdminin.

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

Teemme käyttäjän, jonka puolesta verkkopalvelin käynnistetään, hakemiston omistajaksi. Meidän tapauksessamme NGINX käynnistetään www-data-käyttäjänä.

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

Nyt meidän on muokattava PostfixAdmin-määritystiedostoa ja lisättävä tiedot iRedAdminin käyttämästä tietokannasta. Oletuksena tätä tietokantaa kutsutaan vmailiksi. Jos menet PHPMyAdminiin, näet sen siellä. Ja jotta PostfixAdmin voi tehdä muutoksia tietokantaan, rekisteröimme sen PostfixAdmin-kokoonpanoon.

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

Löydämme rivit:

$CONF["tietokannan_tyyppi"] = $db-tyyppi;
$CONF["tietokannan_isäntä"] = $db-palvelin;
$CONF["tietokannan_käyttäjä"] = $dbuser;
$CONF["tietokannan_salasana"] = $dbpass;
$CONF["tietokannan_nimi"] = $dbname;

Ja laitetaanpa mieleen:

$CONF["tietokannan_tyyppi"] = "mysqli"; # Tietokantatyyppi
$CONF["database_host"] = "paikallinen isäntä"; # Tietokantapalvelimen isäntä
$CONF["tietokannan_käyttäjä"] = "järjestelmänvalvoja"; # Kirjaudu sisään oikeuksilla kirjoittaaksesi vmail-tietokantaan. Voit käyttää aiemmin luotua järjestelmänvalvojaa
$CONF["database_password"] = "salasana"; # Salasana yllä määritetylle käyttäjälle
$CONF["tietokannan_nimi"] = "vmail"; # Tietokannan nimi iRedMail

Tietokannan tietojen syöttäminen

Jos aiot käyttää SOGo-verkkosähköpostiohjelmaa, sinun on tehtävä vielä yksi lisävaihe, nimittäin muutettava $CONF["encrypt"]-kohteen PostfixAdmin-salaus "md5crypt":stä "dovecot:SHA512-CRYPT":ksi. Jos et tee tätä, kun yrität kirjautua SOGoon PostfixAdminissa luodulla käyttäjällä, saat virheilmoituksen: väärä kirjautumistunnus tai salasana.

Salaustyypin vaihtaminen

Nyt sinun on suoritettava kysely tietokantaan, jotta asennus voidaan suorittaa onnistuneesti loppuun etkä saisi virheitä. Tämä on kätevää tehdä PHPMyAdminin kautta. Valitse vmail-tietokanta ja siirry SQL-välilehteen. Kirjoitamme ikkunaan:

PUDOTA INDEX-verkkotunnus postilaatikkoon;
DROP INDEX-verkkotunnus aliakseen;
ALTER TABLE alias ADD COLUMN "goto" teksti EI NULL;

Tietokantakysely

Ja napsauta "Eteenpäin". Nyt olemme kaikki valmiita, voimme siirtyä PostfixAdminin verkkokäyttöliittymään ja suorittaa asennuksen loppuun. Voit tehdä tämän kirjoittamalla selaimeesi: https://domain/postfixadmin/setup.php.

Seuraavan pitäisi näkyä:

PostfixAdminin asennus

Jos kaikki tehdään ohjeiden mukaan, virheitä ei pitäisi olla. Jos niitä on, ne on poistettava, muuten järjestelmä ei salli sinun jatkaa. Aseta asennuksen salasana ja napsauta "Luo salasanahajautus". Järjestelmä luo salasanahajasteen, joka on lisättävä parametriin $CONF["setup_password"].

PostfixAdminin asennuksen viimeistely

Konfiguraatiotiedoston asetusten muuttaminen

Kirjoita nyt uusi salasana ja luo PostfixAdmin-järjestelmänvalvoja. On parempi olla luomatta järjestelmänvalvojaa postmaster-kirjautumistunnuksella, koska iRedAdminin hallintapaneeliin kirjautumisessa voi olla ongelmia.

PostfixAdmin-järjestelmänvalvojan luominen

Siinä kaikki, ylläpitäjä on luotu. Voit kirjautua sisään.

Huomaa, että turvallisuussyistä on parempi nimetä setup.php tiedosto uudelleen tai poistaa se postfixadmin-hakemistossa.

Mene osoitteeseen: https://domain/postfixadmin/ ja anna äskettäin luodut tunnistetiedot. PostfixAdminissa ja iRedAdminissa on saatavilla venäjän kieli. Voit valita sen valtuutuksen aikana.

Yritämme luoda käyttäjäpostilaatikon.

iRedMail-moduulien käyttöönotto/poistaminen käytöstä

iRedAPD vastaa iRedMail-moduulien hallinnasta. Siinä on konfiguraatiotiedosto, johon työmoduulit on rekisteröity. Jos et tarvitse tiettyä moduulia, voit poistaa sen asetustiedostosta ja se lakkaa toimimasta. Me teemme:

# nano /opt/iredapd/settings.py

Etsi rivi "plugins" ja poista siitä komponentit, joita et tarvitse. Poistan "greylisting"-komponentin. Tietysti se suojaa roskapostilta varsin tehokkaasti, mutta tarvittavat kirjeet jäävät usein perille.

Greylist on automaattinen roskapostisuojaustekniikka, joka perustuu sähköpostin lähettäjän palvelimen toiminnan analysointiin. Kun "harmaalistaus" on käytössä, palvelin kieltäytyy hyväksymästä kirjettä tuntemattomasta osoitteesta ensimmäistä kertaa ja ilmoittaa väliaikaisesta virheestä. Tässä tapauksessa lähettävän palvelimen on toistettava lähetys myöhemmin. Roskapostiohjelmat eivät yleensä tee tätä. Jos kirje lähetetään uudelleen, se lisätään luetteloon 30 päiväksi ja postin vaihto tapahtuu ensimmäisen kerran. Päätä itse, käytätkö tätä moduulia vai et.

Sähköpostimoduulien käyttöönotto/poistaminen käytöstä

Kun olet tehnyt muutoksia, sinun on käynnistettävä iRedAPD uudelleen.

# palvelu iredapd uudelleenkäynnistys

Testataan postipalvelinta

Tämä päättää iRedMail-sähköpostipalvelimen määrityksen. Voit siirtyä viimeiseen vaiheeseen - testaukseen. Luodaan kaksi postilaatikoita. Voit tarkistaa yhden iRedAdminin kautta, toisen PostfixAdminin kautta ja lähettää kirjeen postilaatikosta toiseen ja päinvastoin. iRedAdminissa luomme postilaatikon [email protected]. PostfixAdminissa - [email protected]

Käyttäjän luominen iRedAdminissa

Käyttäjän luominen PostfixAdminissa

Tarkistamme, että käyttäjiä on luotu.

Jos kiinnität huomiota PostfixAdmin-postilaatikkoluettelon Vastaanottaja-sarakkeeseen, huomaat eron iRedAdminissa ja PostfixAdminissa luotujen postilaatikoiden välillä. iRedAdminissa luodut postilaatikot on merkitty "Vain edelleenlähetys" -merkinnällä ja PostfixAdminissa luodut postilaatikot. Aluksi en ymmärtänyt pitkään aikaan, miksi näin tapahtui ja mitä eroa niillä oli, ja lopulta huomasin yhden asian. iRedAdminin postilaatikot luodaan ilman aliaksia, ja PostfixAdminin postilaatikot luodaan aliaksella itselleen.

Ja jos nämä aliakset poistetaan, postilaatikot näytetään iRedAdminissa "Vain edelleenlähetys" luotuina.

Poistetaan aliaksia

Aliakset on poistettu. Tarkistetaan PostfixAdmin.

Kuten näet, kaikista laatikoista on tullut "Vain eteenpäin". Samalla tavalla, jos luot itsellesi aliaksen iRedAdminissa luotuun postilaatikkoon, siitä tulee "Mailbox". Periaatteessa tämä ei vaikuta postin toimivuuteen millään tavalla. Ainoa asia on, että et voi luoda aliasta PostfixAdminissa luotuun postilaatikkoon. Sen sijaan, että luot aliaksen, sinun on muokattava olemassa olevaa. Aliasista puheen ollen, in uusi versio iRedMailin on tehtävä muutos johonkin aliaksia käsittelevään Postfix-karttaan. Ja jos et tee tätä, luodut aliakset eivät toimi. Voit tehdä tämän korjaamalla seuraavat asiat /etc/postfix/mysql/virtual_alias_maps.cf-tiedostossa:

Me teemme:

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

Ja korjaamme sen.

Aliasten määrittäminen

Käynnistä Postfix uudelleen:

# palvelun postfix uudelleenkäynnistys

Tämän jälkeen kaiken pitäisi toimia.

Ja niin, aloitetaan postin tarkistaminen. Kirjaudumme käyttäjä1-postilaatikkoon Roundcuben kautta ja käyttäjä2-postilaatikkoon SOGon kautta ja lähetämme kirjeen käyttäjä1-postilaatikosta käyttäjälle2 ja takaisin.

Sähköpostin lähettäminen Roundcubella

Kirjeen vastaanottaminen SOGossa

Sähköpostin lähettäminen SOGolle

Kirjeen vastaanottaminen Roundcubessa

Kaikki toimii ilman ongelmia. Kirjeen toimitus kestää kahdesta viiteen sekuntiin. Samalla tavalla kirjeet toimitetaan täydellisesti Yandex- ja mail.ru-palvelimille (testattu).

Tarkastetaan nyt aliakset. Luodaan käyttäjä3-postilaatikko ja tehdään alias käyttäjä1-postilaatikosta käyttäjä2-postilaatikkoon. Ja lähetämme kirjeen käyttäjä3-postilaatikosta käyttäjä1-postilaatikkoon. Tässä tapauksessa kirjeen pitäisi saapua käyttäjä2:n postilaatikkoon.

Aliaksen luominen

Kirjeen lähettäminen käyttäjä3-postilaatikosta käyttäjä1-postilaatikkoon

Kirjeen vastaanottaminen käyttäjä2:n postilaatikkoon

Myös aliasten työ sujuu hyvin.

Testataan sähköpostipalvelimen toimintaa paikallisen kautta sähköpostiohjelma. Harkitse esimerkiksi Mozilla Thunderbirdia. Luodaan vielä kaksi käyttäjää: asiakas1 ja asiakas2. Yhdistämme yhden postilaatikon IMAP:n kautta, toisen POP3:n kautta ja lähetämme kirjeen postilaatikosta toiseen.

IMAP-yhteys

Yhteys POP3:n kautta

Lähetämme kirjeen asiakkaalta 1 asiakkaalle 2.

Lähetys asiakkaalta 1

Kuitti asiakkaalla 2

Ja käänteisessä järjestyksessä.

Lähetys asiakkaalta 2

Kuitti asiakkaalle 1

Kaikki toimii.

Jos menet osoitteeseen: https://domain/netdata, näet kaavioita järjestelmän tilasta.

Johtopäätös

Tämä päättää iRedMail-sähköpostijärjestelmän asennuksen, määrityksen ja testauksen. Tuloksena saimme täysin ilmaisen, täysimittaisen sähköpostipalvelimen, jossa on voimassa oleva SSL-sertifikaatti, kaksi erilaista verkkosähköpostiohjelmaa, kaksi ohjauspaneelia sekä sähköpostiin sisäänrakennetun roskapostin ja virustentorjunnan. Halutessasi voit käyttää web-sähköpostiohjelmien sijasta paikallisia sähköpostiohjelmia, kuten Microsoft Outlook tai Mozilla Thunderbird. Jos et aio käyttää web-sähköpostiohjelmia, et voi asentaa niitä ollenkaan, jotta et ylikuormittaisi palvelinta tai asenna jotain, josta pidät eniten. Itse pidän SOGosta paremmin, koska sen käyttöliittymä on optimoitu mobiililaitteet, joten se on erittäin kätevä katsella sähköpostiälypuhelimesta. Sama pätee NetDataan ja iRedAdminiin, jos et aio käyttää sitä, on parempi olla asentamatta sitä. Tämä sähköpostijärjestelmä ei ole kovin vaativa resursseja. Kaikki tämä toimii VPS-palvelimella, jossa on 1024 Mt RAM-muisti ja yksi virtuaalinen prosessori. Jos sinulla on kysyttävää tästä sähköpostijärjestelmästä, kirjoita kommentteihin.

P.S. Testattaessa tätä tuotetta eri käyttöjärjestelmissä, joissa on 1 Gt RAM-muistia (Ubuntu, Debian, CentOS), kävi ilmi, että 1 Gt ei riitä ClamAV:n toimimiseen. Lähes kaikissa tapauksissa, kun käytetään 1 Gt muistia, virustorjunta mainitsi tietokantaan liittyvän virheen. Samaan aikaan Debian- ja Ubuntu-käyttöjärjestelmissä virustorjunta ei yksinkertaisesti tarkistanut palvelimen kautta kulkevaa postia, muuten kaikki toimi hyvin. CentOS:ssä tilanne oli hieman erilainen. Clamd-palvelu kaatui järjestelmän täysin, mikä teki normaalin palvelimen toiminnan mahdottomaksi. Kun NGINX yriti kirjautua verkkokäyttöliittymiin, se tuotti ajoittain 502- ja 504-virheitä. Postia lähetettiin myös joka toinen kerta. Lisäksi, jos lisäämme jopa 2 Gt RAM-muistia, kaikissa tapauksissa ei ollut ongelmia virustorjunnan ja palvelimen toiminnassa. ClamAV tarkisti postipalvelimen kautta kulkevan postin, josta se kirjoitti lokeihin. Kun yritettiin lähettää virusta liitteenä, toimitus estettiin. Muistin kulutus oli noin 1,2 - 1,7 Gt.

Nginx on pieni, erittäin nopea, melko toimiva web-palvelin ja sähköpostin välityspalvelin, jonka on kehittänyt Igor Sysoev (rambler.ru). Järjestelmäresurssien ja toimintanopeuden erittäin alhaisen kulutuksen sekä konfiguroinnin joustavuuden vuoksi web Nginx-palvelin käytetään usein käyttöliittymänä raskaammille palvelimille, kuten Apache, suuren kuormituksen projekteissa. Klassinen vaihtoehto on yhdistelmä, Nginx - Apache - FastCGI. Työskentely tällaisessa järjestelmässä, Nginx-palvelin, hyväksyy kaikki HTTP:n kautta tulevat pyynnöt ja päättää asetuksista ja itse pyynnöstä riippuen, käsitteleekö pyynnön itse ja antaako asiakkaalle valmiin vastauksen vai lähettääkö käsittelypyynnön johonkin taustajärjestelmistä ( Apache tai FastCGI).

Kuten tiedät, Apache-palvelin käsittelee jokaisen pyynnön erillisessä prosessissa (säikeessä), mikä on sanottava, että kuluttaa melko vähän järjestelmäresursseja, jos tällaisia ​​prosesseja on 10-20, se on hölynpölyä, ja jos niitä on. 100-500 tai enemmän, järjestelmä ei ole hauska.

Yritetään kuvitella vastaava tilanne. Oletetaan päällä Apache tulee 300 HTTP-pyynnöt asiakkaista 150 asiakasta on nopeilla kiinteillä linjoilla ja loput 150 suhteellisen hitailla Internet-kanavilla, vaikka ei modeemeissa. Mitä tässä tilanteessa tapahtuu? Ja tapahtuu seuraavaa: Apache-verkkopalvelin näiden 300 yhteyden käsittelemiseksi luo kullekin prosessin (säikeen), se luo sisältöä nopeasti ja 150 nopeaa asiakasta ottavat välittömästi vastaan ​​pyyntöjensä tuloksen, niitä palvelevat prosessit. tapetaan ja resursseja vapautetaan ja 150 on hitaita ja saavat pyyntöjensä tulokset hitaasti kapeasta Internet-kanavasta johtuen, minkä seurauksena järjestelmään roikkuu 150 prosessia Apache, odottavat asiakkaiden poimivan verkkopalvelimen luoman sisällön, mikä kuluttaa paljon järjestelmäresursseja. Tilanne on luonnollisesti hypoteettinen, mutta mielestäni olemus on selvä. Kimppu auttaa korjaamaan edellä kuvatun tilanteen. Luettuaan asiakkaan koko pyynnön hän lähettää sen käsiteltäväksi Apache, joka puolestaan ​​tuottaa sisältöä ja palauttaa valmiin vastauksen Nginxille mahdollisimman nopeasti, minkä jälkeen se voi tappaa prosessin puhtaalla omallatunnolla ja vapauttaa käyttämänsä järjestelmäresurssit. Nginx-verkkopalvelin, joka vastaanottaa pyynnön tuloksen Apache, kirjoittaa sen puskuriin tai jopa levyllä olevaan tiedostoon ja voi antaa sen hitaille asiakkaille niin kauan kuin haluaa, samalla kun sen työprosessit kuluttavat niin vähän resursseja, että .. "on jopa hassua puhua siitä" ©. :) Tämä järjestelmä säästää merkittävästi järjestelmäresursseja, toistan, mutta Nginx-työprosessit kuluttavat pienen määrän resursseja, tämä pätee erityisesti suuriin projekteihin.

Ja tämä on vain pieni osa siitä, mitä Nginx-palvelin voi tehdä; älä unohda tiedon välimuistin ja työskentelyn ominaisuuksia muistissa. Annan luettelon tärkeimmistä toiminnallisuutta Nginx-verkkopalvelin.

Nginx-palvelintoiminto HTTP-palvelimena

• Hoito staattista sisältöä, hakemistotiedostot, hakemistolistaukset, avaa tiedostokuvaajan välimuisti;
• Nopeutettu välityspalvelin välimuistilla, kuormanjako ja vikasietoisuus;
• Nopeutettu tuki FastCGI palvelimet, joissa on välimuisti, kuormanjako ja vikasietoisuus;
• Modulaarinen rakenne, tuki eri suodattimille (SSI, XSLT, GZIP, jatkaminen, lohkotut vastaukset);
• Tuki SSL- ja TLS SNI -laajennuksille;
• IP-pohjainen tai Nimiperusteinen virtuaalipalvelimet;
• Työskentely KeepAlive- ja liukuhihnayhteyksien kanssa;
• Mahdollisuus määrittää aikakatkaisut sekä puskurien lukumäärä ja koko tasolla Apache-palvelin;
• Erilaisten toimintojen suorittaminen asiakkaan osoitteesta riippuen;
• URI:iden muuttaminen säännöllisten lausekkeiden avulla;
• Erikoisvirhesivut malleille 4xx ja 5xx;
• Pääsyn rajoittaminen asiakkaan osoitteen tai salasanan perusteella;
• Lokitiedostomuotojen määrittäminen, lokien kiertäminen;
• Vastausnopeuden rajoittaminen asiakkaalle;
• Samanaikaisten yhteyksien ja pyyntöjen määrän rajoittaminen;
• Tukee PUT-, DELETE-, MKCOL-, COPY- ja MOVE-menetelmiä;
• Asetusten muuttaminen ja palvelimen päivittäminen keskeyttämättä työtä;
• Sisäänrakennettu Perl;

Nginx-palvelintoiminto sähköpostin välityspalvelimena

• Edelleenlähetys IMAP/POP3-taustajärjestelmään ulkoisen HTTP-todennuspalvelimen avulla;
• Tarkistetaan ulkoisen käyttäjän SMTP:tä HTTP-palvelin todennus ja edelleenlähetys sisäiselle SMTP-palvelimelle;
• Tukee seuraavia todennusmenetelmiä:
  • POP3 - KÄYTTÄJÄ/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP - KIRJAUDU, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP - AUTH LOGI/ PLAIN/CRAM-MD5;
• SSL-tuki;
• STARTTLS- ja STLS-tuki;

Nginx-verkkopalvelimen tukemat käyttöjärjestelmät ja alustat

• FreeBSD, 3 - 8 - alustat, i386 ja amd64;
• Linux, 2.2 - 2.6 - i386-alusta; Linux 2.6 - amd64;
• Solaris 9 - i386- ja sun4u-alustat; Solaris 10 - i386-, amd64- ja sun4v-alustat;
• MacOS X -alustat ppc, i386;
• Windows XP, Windows Server 2003; (tällä hetkellä beta-testauksessa)

Nginx-palvelinarkkitehtuuri ja skaalautuvuus

• Pääprosessi (pääprosessi), useat (konfiguraatiotiedostossa konfiguroidut) työprosessit, jotka suoritetaan etuoikeutettoman käyttäjän alaisuudessa;
• Tuki seuraaville yhteydenkäsittelymenetelmille:
  • valinta on vakiomenetelmä. Vastaava Nginx-moduuli rakennetaan automaattisesti, jos tehokkaampaa menetelmää ei löydy tietyltä alustalta. Voit pakottaa tietyn moduulin koontiversion ottamaan käyttöön tai poistamaan sen käytöstä käyttämällä --with-select_module- tai --without-select_module -määritysasetuksia.
  • kysely on vakiomenetelmä. Vastaava Nginx-moduuli rakennetaan automaattisesti, jos tehokkaampaa menetelmää ei löydy tietyltä alustalta. Voit pakottaa tietyn moduulin koontiversion ottamaan käyttöön tai poistamaan sen käytöstä käyttämällä --with-poll_module- tai --without-poll_module -määritysasetuksia.
  • kqueue - tehokas menetelmä, jota käytetään käyttöjärjestelmissä FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 ja MacOS X. Käytettäessä MacOS X:ää käyttävissä kaksiprosessorisissa koneissa se voi aiheuttaa ytimen paniikin.
  • epoll on tehokas menetelmä, jota käytetään Linux 2.6+:ssa. Joissakin jakeluissa, kuten SuSE 8.2:ssa, on korjaustiedostoja epollin tukemiseksi 2.4-ytimessä.
  • rtsig - reaaliaikaiset signaalit, tehokas menetelmä, jota käytetään Linuxissa 2.2.19+. Oletuksena koko järjestelmän jonossa voi olla enintään 1024 signaalia. Tämä ei riitä palvelimille, joilla on suuri kuormitus, vaan jonon kokoa on suurennettava /proc/sys/kernel/rtsig-max ydinparametrilla. Linux 2.6.6-mm2:sta lähtien tämä vaihtoehto ei kuitenkaan ole enää käytettävissä, vaan jokaisella prosessilla on erillinen signaalijono, jonka koko määritetään RLIMIT_SIGPENDING:llä.
  • Kun jono on täynnä, nginx-palvelin nollaa sen ja käsittelee yhteyksiä poll-menetelmällä, kunnes tilanne palautuu normaaliksi.
  • /dev/poll on tehokas menetelmä, jota tuetaan käyttöjärjestelmissä Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ ja Tru64 UNIX 5.1A+.
  • eventport - tapahtumaportit, tehokas menetelmä, jota käytetään Solaris 10:ssä. Ennen käyttöä sinun on asennettava korjaustiedosto ytimen paniikin välttämiseksi.
• kqueue-menetelmän ominaisuuksien käyttäminen, kuten EV_CLEAR, EV_DISABLE (tapahtuman tilapäinen poistaminen käytöstä), NOTE_LOWAT, EV_EOF, käytettävissä olevien tietojen määrä, virhekoodit;
• Toimii sendfilen (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64:n (Linux 2.4.21+) ja sendfilevin (Solaris 8 7/01+) kanssa;
• Tuki hyväksymissuodattimille (FreeBSD 4.1+) ja TCP_DEFER_ACCEPT (Linux 2.4+);
• 10 000 ei-aktiivista HTTP-säilytysyhteyttä kuluttavat noin 2,5 miljoonaa muistia;
• Tietojen kopiointitoimintojen vähimmäismäärä;

NGINX:ää voidaan käyttää paitsi verkkopalvelimena tai http-välityspalvelimena, myös sähköpostin välityspalvelimena SMTP-, IMAP-, POP3-protokollien kautta. Tämän avulla voit määrittää:

• Yksi sisääntulopiste skaalautuvalle sähköpostijärjestelmälle.
• Kuormituksen tasapainotus kaikkien sähköpostipalvelimien välillä.

Tässä artikkelissa asennus suoritetaan leikkaussalissa. Linux järjestelmä. Postipalveluna, johon pyynnöt lähetetään, voit käyttää postfix-, exim-, dovecot-, Exchange-, iredmail-kokoonpano ja paljon muuta.

Toimintaperiaate

NGINX hyväksyy pyynnöt ja todentaa verkkopalvelimelle. Kirjautumisen ja salasanan tarkistuksen tuloksesta riippuen välityspalvelin palauttaa vastauksen, jossa on useita otsikoita.

Menestyksen sattuessa:

Näin ollen määritämme sähköpostipalvelimen palvelimen ja portin todennuksen perusteella. Tämä tarjoaa monia mahdollisuuksia asianmukaisella ohjelmointikielten tuntemuksella.

Vian sattuessa:

Todennustuloksesta ja otsikosta riippuen asiakas ohjataan tarvitsemamme sähköpostipalvelimelle.

Palvelimen valmistelu

Tehdään joitain muutoksia palvelimen suojausasetuksiin.

SELinux

Poista SELinux käytöstä, jos käytämme CentOS:ää tai jos käytämme tämä järjestelmä turvallisuus Ubuntussa:

vi /etc/selinux/config

SELINUX=pois käytöstä

Palomuuri

Jos käytämme palomuuria (oletus CentOS:ssä):

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

firewall-cmd --reload

Jos käytämme iptablesia (oletus Ubuntussa):

iptables -A INPUT -p tcp -dport 25 -j HYVÄKSY

iptables -A INPUT -p tcp -dport 110 -j HYVÄKSY

iptables -A INPUT -p tcp -dport 143 -j HYVÄKSY

apt-get install iptables-persistent

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

* Tässä esimerkissä sallimme SMTP (25), POP3 (110), IMAP (143).

Asenna NGINX

Riippuen käyttöjärjestelmä NGINX-asennus on hieman erilainen.

tai Linux Centos:

yum asenna nginx

tai Linux Ubuntu:

apt asentaa nginx

Sallimme palvelun automaattisen käynnistyksen ja käynnistämme sen:

systemctl salli nginx

systemctl käynnistä nginx

Jos NGINX on jo asennettu järjestelmään, tarkista, minkä moduulien kanssa se toimii:

Saamme luettelon vaihtoehdoista, joilla verkkopalvelin on rakennettu - niiden joukossa meidän pitäisi nähdä --with-mail . Jos vaadittua moduulia ei ole, sinun on päivitettävä nginx

Asetetaan NGINX

Avaa nginx-määritystiedosto ja lisää sähköpostivaihtoehto:

vi /etc/nginx/nginx.conf

posti (

auth_http localhost:80/auth.php;

Palvelin (
kuuntele 25;
protokolla smtp;
smtp_auth kirjautuminen pelkkä cram-md5;
}

Palvelin (
kuuntele 110;
protokolla pop3;

}

Palvelin (
kuuntele 143;
protokolla imap;
}
}

* Missä:

• palvelimen_nimi on sähköpostipalvelimen nimi, joka näytetään SMTP-tervehdyksessä.
• auth_http - verkkopalvelin ja URL-osoite todennuspyyntöä varten.
• proxy_pass_error_message - sallii tai estää viestin näyttämisen, jos todennus epäonnistuu.
• kuuntele - portti, jossa pyyntöjä kuunnellaan.
• protokolla - sovellusprotokolla, jota vastaava portti kuuntelee.
• smtp_auth – SMTP:lle käytettävissä olevat todennustavat.
• pop3_auth - käytettävissä olevat todennustavat POP3:lle.

Lisää http -palvelin-osioon:

Palvelin (
kuuntele 80 oletuspalvelin;
kuuntele [::]:80 oletuspalvelin;
...

Sijainti ~ \.php$ (
aseta $juuripolku /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $juuripolku$fastcgi_script_name;
sisältää fastcgi_params;
fastcgi_param DOCUMENT_ROOT $juuripolku;
}
...

Käynnistä nginx-palvelin uudelleen:

systemctl käynnistä nginx uudelleen

PHP:n asennus ja konfigurointi

Todennuksen suorittamiseksi PHP:llä sinun on asennettava seuraavat paketit järjestelmääsi.

Jos CentOS:

yum asenna php php-fpm

Jos Ubuntu:

apt-get asenna php php-fpm

Käynnistä PHP-FPM:

systemctl ota käyttöön php-fpm

systemctl käynnistä php-fpm

Todennus

Kirjautumisen ja salasanan vahvistus suoritetaan komentosarjalla, jonka polku on määritetty auth_http-vaihtoehdolla. Esimerkissämme tämä on PHP-skripti.

Esimerkki virallisesta mallista kirjautumistunnuksen ja salasanan vahvistusskriptille:

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

* Tämä skripti hyväksyy kaikki kirjautumistunnukset ja salasanat ja ohjaa pyynnöt palvelimille 192.168.1.22 ja 192.168.1.33. Määritä todennusalgoritmi muokkaamalla rivejä 61 - 64. Rivit 73 - 77 vastaavat niiden palvelinten palauttamisesta, joihin uudelleenohjaus on tehty - tässä esimerkissä, jos kirjautuminen alkaa merkeillä "a", "c", "f" ”, ”g”, uudelleenohjaus ohjataan mailhost01-palvelimeen, muussa tapauksessa mailhost02:een. Palvelinten nimien yhdistäminen IP-osoitteisiin voidaan asettaa riveillä 31, 32, muuten puhelu soitetaan verkkotunnuksella.

Postipalvelimen asettaminen

Tiedonvaihto NGINX-välityspalvelimen ja sähköpostipalvelimen välillä tapahtuu sisään avoin lomake. Poikkeukseen on lisättävä mahdollisuus todentaa käyttämällä PLAIN-mekanismia. Voit esimerkiksi määrittää kyyhkyskopan seuraavasti:

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

Lisää rivit:

kaukosäädin 192.168.1.11 (
disable_plaintext_auth = ei
}

* Tässä esimerkissä sallimme PLAIN-todennuspyynnöt palvelimelta 192.168.1.11.

Tarkistamme myös:

* jos ssl on asetettu pakolliseksi, tarkistus ei toimi, koska toisaalta palvelin sallii pyynnöt selkeänä tekstinä, mutta vaatii ssl-salauksen.

Käynnistä Dovecot-palvelu uudelleen:

systemctl käynnistä dovecot uudelleen

Asiakkaan asetukset

Voit jatkaa välityspalvelinasetustemme tarkistamista. Voit tehdä tämän määrittämällä asiakkaan asetuksissa nginx-palvelimen osoitteeksi tai nimeksi IMAP/POP2/SMTP, esimerkiksi:

* Tässä esimerkissä sähköpostiohjelma on määritetty muodostamaan yhteys palvelimeen 192.168.1.11 kautta avoimet portit 143 (IMAP) ja 25 (SMTP).

Salaus

Luodaan nyt SSL-yhteys. Nginx on rakennettava mail_ssl_module-moduulilla - tarkista komennolla:

Jos tarvittava moduuli puuttuu, rakennamme nginxin uudelleen.

Sitten muokkaamme asetustiedostoamme:

vi /etc/nginx/nginx.conf

posti (
palvelimen_nimi mail.domain.local;
auth_http localhost/auth.php;

Proxy_pass_error_message päällä;

Ssl päällä;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache jaettu:SSL:10m;
ssl_session_timeout 10m;

Palvelin (
kuuntele 110;
protokolla pop3;
pop3_auth pelkkä apop cram-md5;
}

Palvelin (
kuuntele 143;
protokolla imap;
}

Syy: SELinux-turvajärjestelmä on lauennut.

Ratkaisu: poista SELinux käytöstä tai määritä se.

Nginx on saamassa nopeasti suosiota muuttuen vain Apachen staattisesta toimituskiihdyttimestä täysin toimivaksi ja kehittyneeksi verkkopalvelimeksi, jota käytetään yhä enemmän erillään. Tässä artikkelissa puhumme mielenkiintoisista ja epätyypillisistä skenaarioista nginxin käyttämiseen, joiden avulla voit saada kaiken irti verkkopalvelimestasi.

Sähköpostin välityspalvelin

Aloitetaan ilmeisimmästä - nginxin kyvystä toimia sähköpostin välityspalvelimena. Tämä toiminto on alun perin nginxissä, mutta jostain syystä sitä käytetään tuotannossa erittäin harvoin; jotkut ihmiset eivät edes tiedä sen olemassaolosta. Oli miten oli, nginx tukee POP3-, IMAP- ja SMTP-protokollien välityspalvelinta erilaisilla todennusmenetelmillä, mukaan lukien SSL ja StartTLS, ja tekee sen erittäin nopeasti.

Miksi tämä on välttämätöntä? Tälle toiminnalle on ainakin kaksi käyttötarkoitusta. Ensinnäkin: käytä nginxiä suojana ärsyttäviä roskapostittajia vastaan, jotka yrittävät lähettää roskapostiviestejä SMTP-palvelimemme kautta. Yleensä roskapostittajat eivät aiheuta monia ongelmia, koska ne hylätään nopeasti todennusvaiheessa, mutta kun niitä on todella paljon, nginx auttaa säästämään prosessoriresursseja. Toiseksi: käytä nginxiä käyttäjien uudelleenohjaamiseen useille POP3/IMAP-sähköpostipalvelimille. Tietenkin toinen sähköpostin välityspalvelin voisi käsitellä tämän, mutta miksi eristää palvelimia, jos nginx on jo asennettu käyttöliittymään palvelemaan staattista sisältöä esimerkiksi HTTP:n kautta?

Nginxin sähköpostin välityspalvelin ei ole aivan vakio. Se käyttää ylimääräistä HTTP:n avulla toteutettua todennuskerrosta, ja vain jos käyttäjä ylittää tämän esteen, hän saa jatkaa eteenpäin. Tämä toiminto saadaan aikaan luomalla sivu/skripti, jolle nginx lähettää käyttäjätiedot ja hän palauttaa vastauksen tavallisen OK tai kieltäytymissyyn muodossa (kuten "Virheellinen sisäänkirjautuminen tai salasana"). Skripti suoritetaan seuraavilla otsikoilla:

Todennuskomentosarjan syöttötiedot HTTP_AUTH_USER: käyttäjä HTTP_AUTH_PASS: salasana HTTP_AUTH_PROTOCOL: sähköpostiprotokolla (IMAP, POP3 tai SMTP)

Ja se palauttaa seuraavan:

Todennusskriptin lähtö HTTP_AUTH_STATUS: OK tai virheen syy HTTP_AUTH_SERVER: oikea sähköpostipalvelin uudelleenohjaamaan HTTP_AUTH_PORT: palvelimen portti

Tämän lähestymistavan huomionarvoinen piirre on, että sitä ei voida käyttää lainkaan todentamiseen, vaan käyttäjien hajauttamiseen eri sisäisille palvelimille riippuen käyttäjänimestä, sähköpostipalvelimien nykyisestä kuormituksesta tai jopa järjestämällä yksinkertainen kuormituksen tasapainotus. käyttäen round robin . Jos sinun on kuitenkin vain siirrettävä käyttäjiä sisäiselle sähköpostipalvelimelle, voit käyttää nginxin itsensä toteuttamaa tyngiä oikean komentosarjan sijaan. Esimerkiksi nginx-kokoonpanon yksinkertaisin SMTP- ja IMAP-välityspalvelin näyttää tältä:

# vi /etc/nginx/nginx.conf mail ( # Todennuskomentosarjan osoite auth_http localhost:8080/auth; # Poista XCLIENT-komento käytöstä, jotkut sähköpostipalvelimet eivät ymmärrä sitä xclient off; # IMAP-palvelinpalvelin ( kuuntele 143; protokolla imap; välityspalvelin päällä; ) # SMTP-palvelinpalvelin (kuuntele 25; protokolla smtp; välityspalvelin päällä; ) )

# vi /etc/nginx/nginx.conf http ( # Yhdistäminen haluttuun sähköpostipalvelinporttiin HTTP_AUTH_PROTOCOL-otsikkokartassa lähetetystä portista riippuen $http_auth_protocol $mailport (oletus 25; smtp 25; imap 143; ) # Todennuksen toteutus "script" - palauttaa aina OK ja siirtää käyttäjän sisäiselle sähköpostipalvelimelle asettamalla halutun portin yllä olevan kartoituspalvelimen avulla ( kuuntele 8080; sijainti /auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" "192.168.0.1" ; add_header "Auth-Port" $postiportti; return 200; ) ) )

Tässä kaikki. Tämän kokoonpanon avulla voit läpinäkyvästi uudelleenohjata käyttäjät sisäiseen sähköpostipalvelimeen ilman, että muodostuu ylimääräistä komentosarjaa, joka on tässä tapauksessa tarpeeton. Komentosarjaa käyttämällä tätä kokoonpanoa voidaan laajentaa merkittävästi: määrittää kuormituksen tasapainotuksen, tarkistaa käyttäjät LDAP-tietokannan avulla ja suorittaa muita toimintoja. Skriptin kirjoittaminen ei kuulu tämän artikkelin piiriin, mutta se on erittäin helppo toteuttaa jopa vain ohimenevällä PHP:n ja Pythonin tuntemuksella.

Videon suoratoisto

On helppoa perustaa tavallinen videopalvelu nginx-pohjaisena. Sinun tarvitsee vain ladata transkoodattu video palvelimen käytettävissä olevaan hakemistoon, rekisteröidä se asetuksiin ja määrittää Flash- tai HTML5-soitin niin, että se ottaa videon tästä hakemistosta. Kuitenkin, jos sinun on määritettävä jatkuva videolähetys joiltakin ulkoinen lähde tai verkkokamera, tämä järjestelmä ei toimi, ja sinun on etsittävä erityisiä suoratoistoprotokollia.

On olemassa useita protokollia, jotka ratkaisevat tämän ongelman, tehokkain ja tuetuin niistä on RTMP. Ainoa ongelma on, että lähes kaikki RTMP-palvelintoteutukset kärsivät ongelmista. Virallinen Adobe Flash Media Server on maksullinen. Red5 ja Wowza on kirjoitettu Java-kielellä, joten ne eivät tarjoa vaadittu suorituskyky, Toinen toteutus, Erlyvideo, on kirjoitettu Erlangilla, joka on hyvä klusterin asennukselle, mutta ei yhtä tehokas yksittäiselle palvelimelle.

Ehdotan erilaista lähestymistapaa - käytä RTMP-moduulia nginxille. Sillä on erinomainen suorituskyky, ja sen avulla voit myös käyttää yhtä palvelinta palvelemaan sekä sivuston verkkokäyttöliittymää että videovirtaa. Ainoa ongelma on, että tämä moduuli on epävirallinen, joten sinun on rakennettava nginx sen tuella itse. Onneksi kokoonpano on suoritettu tavallisella tavalla:

$ sudo apt-get poista nginx $ cd /tmp $ wget http://bit.ly/VyK0lU -O nginx-rtmp.zip $ pura 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 tee asennus

Nyt moduuli on konfiguroitava. Tämä tehdään tavalliseen tapaan nginx-konfiguraation kautta:

Rtmp (# Aktivoi lähetyspalvelin portissa 1935 osoitteessa site/rtmp-palvelin (kuuntele 1935; sovellus rtmp ( live on; ) ) )

RTMP-moduuli ei voi toimia monisäikeisessä kokoonpanossa, joten nginx-työprosessien määrä on vähennettävä yhteen (myöhemmin kerron kuinka kiertää tämä ongelma):

Työntekijän_prosessit 1;

Nyt voit tallentaa tiedoston ja pakottaa nginxin lukemaan asetukset uudelleen. Nginx-asennus on valmis, mutta meillä ei ole vielä itse videovirtaa, joten meidän on hankittava se jostain. Olkoon tämä esimerkiksi video.avi-tiedosto nykyisestä hakemistosta. Käytämme vanhaa kunnon FFmpegiä muuntaaksemme sen streamiksi ja kääriäksemme sen RTMP-lähettimeen:

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

Jos videotiedosto ei ole H264-muodossa, se on koodattava uudelleen. Tämä voidaan tehdä lennossa samalla FFmpegillä:

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

Stream voidaan kaapata myös suoraan verkkokamerasta:

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

Voit tarkastella streamia asiakaspuolella käyttämällä mitä tahansa RTMP:tä tukevaa soitinta, esimerkiksi mplayeria:

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

Tai upota soitin suoraan web-sivulle, jota palvelee sama nginx (esimerkki virallisesta dokumentaatiosta):

Yksinkertaisin RTMP-verkkosoitin

jwplayer("container").setup(( mode: [( tyyppi: "flash", src: "/jwplayer/player.swf", config: ( puskurin pituus: 1, tiedosto: "stream", streamer: "rtmp:/") /localhost/rtmp", tarjoaja: "rtmp", ) )] ));

Tässä on vain kaksi tärkeää riviä: "file: "stream", joka osoittaa RTMP-virran, ja "streamer: "rtmp://localhost/rtmp"", joka osoittaa RTMP-suoratoistolaitteen osoitteen. Useimpiin tehtäviin tällaiset asetukset ovat aivan riittäviä. Voit lähettää useita eri virtoja yhteen osoitteeseen, ja nginx multipleksoi ne tehokkaasti asiakkaiden välillä. Mutta tämä ei ole kaikki, mihin RTMP-moduuli pystyy. Sen avulla voit esimerkiksi järjestää toiselta palvelimelta tulevan videovirran välityksen. FFmpeg-palvelinta ei tarvita tähän ollenkaan, lisää vain seuraavat rivit konfiguraatioon:

# vi /etc/nginx/nginx.conf sovellus rtmp ( livenä; vedä rtmp://rtmp.example.com; )

Jos sinun on luotava useita erilaatuisia streameja, voit soittaa FFmpeg-transkooderille suoraan nginxistä:

# vi /etc/nginx/nginx.conf sovellus rtmp ( käytössä; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) sovellus rtmp-320x240 ( livenä; )

Tällä kokoonpanolla saamme kaksi lähetysyhtiötä kerralla, joista toinen on saatavilla osoitteessa rtmp://site/rtmp ja toinen, joka lähettää 320 x 240-laadulla, osoitteessa rtmp://site/rtmp. -320x240. Seuraavaksi voit lisätä sivustolle flash-soittimen ja laadunvalintapainikkeet, jotka antavat soittimelle yhden tai toisen lähettäjän osoitteen.

Ja lopuksi esimerkki musiikin lähettämisestä verkkoon:

Vaikka totta; do ffmpeg -re -i "`etsi /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; tehty

Ota välityspalvelin

Git-versionhallintajärjestelmä pystyy tarjoamaan pääsyn arkistoihin paitsi Git- ja SSH-protokollien, myös HTTP:n kautta. Aikoinaan HTTP-käytön toteutus oli primitiivistä eikä pystynyt tarjoamaan täysimittaista työtä arkiston kanssa. Version 1.6.6 myötä tilanne on muuttunut, ja nykyään tällä protokollalla voidaan esimerkiksi ohittaa palomuurirajoitukset yhteyden molemmilla puolilla tai luoda oma Git-hosting verkkoliittymällä.

Valitettavasti virallisessa dokumentaatiossa puhutaan vain Gitiin pääsyn järjestämisestä Apache-verkkopalvelimen avulla, mutta koska itse toteutus on ulkoinen sovellus tavallisella CGI-liittymällä se voidaan liittää melkein mihin tahansa muuhun palvelimeen, mukaan lukien lighttpd ja tietysti nginx. Tämä ei vaadi muuta kuin itse palvelin, asennettu Git ja pieni FastCGI-palvelin fcgiwrap, jota tarvitaan, koska nginx ei osaa työskennellä suoraan CGI:n kanssa, mutta voi kutsua skriptejä FastCGI-protokollan avulla.

Koko työsuunnitelma näyttää tältä. Fcgiwrap-palvelin roikkuu taustalla ja odottaa pyyntöä suorittaa CGI-sovellus. Nginx puolestaan ​​​​määritetään pyytämään git-http-taustajärjestelmän CGI-binaarin suorittamista FastCGI-rajapinnan kautta aina, kun määrittämäämme osoitetta käytetään. Pyynnön saatuaan fcgiwrap suorittaa git-http-backendin GIT-asiakkaan välittämillä määritetyillä CGI-argumenteilla ja palauttaa tuloksen.

Jos haluat toteuttaa tällaisen järjestelmän, asenna ensin fcgiwrap:

$ sudo apt-get asenna fcgiwrap

Sitä ei tarvitse määrittää, vaan kaikki parametrit lähetetään FastCGI-protokollan kautta. Se myös käynnistyy automaattisesti. Siksi jäljellä on vain määrittää nginx. Tee tämä luomalla tiedosto /etc/nginx/sites-enabled/git (jos sellaista hakemistoa ei ole, voit kirjoittaa pääkonfiguraatioon) ja kirjoittaa siihen seuraava:

# vi /etc/nginx/sites-enabled/git server ( # Olemme riippuvaisia ​​portista 8080, kuuntele 8080; # Palvelimemme osoite (älä unohda lisätä merkintää DNS:ään) palvelimen_nimi git.example.ru; # Lokit access_log /var/log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Anonyymin käyttöpaikan ensisijainen osoite / ( # Kun yrität ladata, lähetä käyttäjä yksityiseen osoitteeseen if ($ arg_service ~* "git-receive-pack") (kirjoita uudelleen ^ /private$uri viimeksi; ) sisältää /etc/nginx/fastcgi_params; # Git-http-taustajärjestelmän fastcgi_param SCRIPT_FILENAME osoite /usr/lib/git-core/git- http-backend; # Git-tietovaraston osoite fastcgi_param GIT_PROJECT_ROOT /srv/git; # Tiedostoosoite fastcgi_param PATH_INFO $uri; # fcgiwrap-palvelimen osoite fastcgi_pass 127.0.0.1:9001; sijainti ~/private(/.* )$ ( # Käyttäjäoikeudet auth_basic "git anonyymi vain luku, todennettu kirjoitus"; # HTTP-todennus perustuu htpasswd auth_basic_user_file /etc/nginx/htpasswd; # FastCGI-asetukset sisältävät /etc/nginx/fastcgi ; 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; ) )

Tämä konfiguraatio olettaa kolme tärkeää asiaa:

Arkiston osoite on /srv/git, joten asetamme asianmukaiset käyttöoikeudet: $ sudo chown -R www-data:www-data /srv/git

Itse arkiston on oltava avoinna anonyymien käyttäjien luettavaksi ja sallittava lataus HTTP:n kautta: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true

Todennus suoritetaan htpasswd-tiedoston avulla, sinun on luotava se ja lisättävä siihen käyttäjät: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 . ..

Siinä kaikki, käynnistä nginx uudelleen:

Mikrokätköily

Kuvitellaanpa tilanne dynaamisella, usein päivitetyllä verkkosivustolla, joka yhtäkkiä alkaa saada erittäin raskaita kuormia (no, se päätyi yhden suurimman uutissivuston sivulle) ja lakkaa selviytymästä sisällön palautumisesta. Oikean välimuistijärjestelmän asianmukainen optimointi ja käyttöönotto vie kauan, ja ongelmat on ratkaistava nyt. Mitä voimme tehdä?

On olemassa useita tapoja selviytyä tästä tilanteesta pienimmällä tappiolla, mutta mielenkiintoisimman idean ehdotti Fenn Bailey (fennb.com). Ajatuksena on yksinkertaisesti laittaa nginx palvelimen eteen ja pakottaa se tallentamaan välimuistiin kaiken lähetetyn sisällön, mutta ei vain välimuistiin, vaan vain yhdeksi sekunniksi. Käänteenä tässä on se, että sadat ja tuhannet sivuston vierailijat sekunnissa luovat itse asiassa vain yhden pyynnön taustajärjestelmään, vastaanottaen enimmäkseen välimuistissa olevan sivun. Samaan aikaan tuskin kukaan huomaa eroa, sillä edes dynaamisella sivustolla sekunti ei yleensä merkitse mitään.

Tämän idean toteuttamisen konfiguraatio ei näytä niin monimutkaiselta:

# vi /etc/nginx/sites-enabled/cache-proxy # Välimuistin määritys proxy_cache_path /var/cache/nginx level=1:2 keys_zone=microcache:5m max_size=1000m; server ( kuuntele 80; palvelimen_nimi esimerkki.com; # Välimuistin osoite sijainti / ( # Välimuisti on oletusarvoisesti käytössä asetettu $no_cache ""; # Poista välimuisti käytöstä kaikissa menetelmissä paitsi GET ja HEAD if ($request_method !~ ^(GET|HEAD) $) ( aseta $no_cache "1"; ) # Jos asiakas lataa sisältöä sivustolle (no_cache = 1), varmistamme, että hänelle annettuja tietoja ei tallenneta välimuistiin kahteen sekuntiin ja hän näkee latauksen tuloksen if ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcacheable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1"; ) # Ota välimuisti käyttöön tai poista se käytöstä riippuen muuttujan no_cache proxy_no_cache $no_cache tilasta; proxy_cache_bypass $no_cache; # Välityspalvelimen pyynnöt oikealle palvelimelle proxy_pass http://appserver.example.ru; proxy_cache microcache proxy_cache_key $scheme$host$request_method$ request_uri proxy_cache_valid 200 1s # Suojaus Thundering laumaongelmalta proxy_cache_use_stale päivitys # Lisää vakiootsikot proxy_set_header Isäntä $host; proxy_set_header X-Real-IP $etäosoite; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Emme tallenna välimuistiin tiedostoja, jotka ovat suurempia kuin 1 Mt proxy_max_temp_file_size 1M; ) )

Erityinen paikka tässä kokoonpanossa on rivillä "proxy_cache_use_stale updating;", jota ilman olisimme saaneet ajoittain kuormituspurskeita taustapalvelimelle välimuistin päivityksen aikana vastaanotettujen pyyntöjen vuoksi. Muuten kaikki on normaalia ja sen pitäisi olla selvää ilman tarpeettomia selityksiä.

Välityspalvelinten tuominen lähemmäs kohdeyleisöä

Huolimatta laajasta maailmanlaajuisesta Internet-nopeuksien kasvusta, palvelimen fyysisellä etäisyydellä kohdeyleisöstä on edelleen merkitystä. Tämä tarkoittaa, että jos venäläinen sivusto toimii jossain Amerikassa sijaitsevalla palvelimella, pääsy siihen on a priori hitaampi kuin venäläiseltä palvelimelta, jolla on sama kanavanleveys (tietysti, jos suljet silmäsi kaikilta muilta tekijöiltä ). Toinen asia on, että palvelimien sijoittaminen ulkomaille on usein kannattavampaa, myös ylläpidon kannalta. Siksi sinun on käytettävä joitain temppuja saadaksesi voittoa korkeampien maksuprosenttien muodossa.

Yksi mahdollisista vaihtoehdoista: sijoita tärkein tuottava palvelin länteen ja ota käyttöön käyttöliittymä, joka ei ole liian resursseja vaativa ja tuottaa staattista dataa Venäjällä. Näin voit saada nopeutta ilman vakavia kustannuksia. Tässä tapauksessa käyttöliittymän nginx-asetus on yksinkertainen ja tuttu välityspalvelintoteutus meille kaikille:

# vi /etc/nginx/sites-enabled/proxy # Säilytä välimuistia 30 päivää 100 Gt:n tallennustilassa proxy_cache_path /var/cache/nginx level=1:2 keys_zone=static:32m inactive=30d max_size=100g; palvelin ( kuuntele 80; palvelimen_nimi esimerkki.fi; # Itse asiassa välityspalvelimemme sijainti ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Taustaosoite proxy_pass back.example.com:80; välityspalvelimen_uudelleenohjaus pois; proxy_set_header Isäntä $isäntä; proxy_set_header X-Real-IP $kaukosäädin; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffer_k_s; 3 proxy_buffer_6 staattinen; proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock on; ) )

johtopäätöksiä

Nykyään nginxin avulla voit ratkaista monia erilaisia ​​​​ongelmia, joista monet eivät liity Web-palvelimeen ja HTTP-protokollaan ollenkaan. Sähköpostin välityspalvelin, suoratoistopalvelin ja Git-käyttöliittymä ovat vain joitain näistä tehtävistä.