Az Nginx egyre népszerűbb, és az Apache statikus kiszolgálási gyorsítójáról egy teljes értékű és fejlett webszerverré vált, amelyet egyre inkább elszigetelten használnak. Ebben a cikkben az nginx használatának érdekes és nem szabványos forgatókönyveiről fogunk beszélni, amelyek lehetővé teszik, hogy a legtöbbet hozza ki a webszerverből.
Mail proxy
Kezdjük a legnyilvánvalóbbal – az nginx azon képességével, hogy levelezőproxyként működjön. Ez a funkció kezdetben az nginxben van, de valamiért rendkívül ritkán használják a termelésben, egyesek nem is tudnak a létezéséről. Bárhogy is legyen, az nginx támogatja a POP3, IMAP és SMTP protokollok proxyzását különféle hitelesítési módszerekkel, beleértve az SSL-t és a StartTLS-t, és ezt nagyon gyorsan megteszi.
Miért van erre szükség? Ennek a funkciónak legalább két felhasználási módja van. Először is használja az nginxet pajzsként a bosszantó spammerek ellen, akik kéretlen leveleket próbálnak küldeni az SMTP-szerverünkön keresztül. A spammerek általában nem okoznak sok problémát, mivel a hitelesítési szakaszban gyorsan visszapattannak, de ha valóban sok van belőlük, az nginx segít megtakarítani a CPU erőforrásait. Másodszor, az nginx segítségével irányítsa át a felhasználókat több POP3/IMAP levelezőszerverre. Persze ezt egy másik levelező proxy is megoldhatná, de minek keríteni a szerverkertet, ha az nginx már telepítve van a frontendre, hogy például HTTP-n keresztül statikusan kiszolgálhassa?
Az nginx levelezőproxyja nem teljesen szabványos. Egy további, HTTP-n keresztül megvalósított hitelesítési réteget használ, és csak ha a felhasználó átlépi ezt az akadályt, akkor adják tovább. Ezt a funkciót egy oldal / szkript létrehozása biztosítja, amelyhez az nginx megadja a felhasználó adatait, és visszaküldi a választ normál OK vagy elutasítási ok formájában (például „Érvénytelen bejelentkezés vagy jelszó”). A szkript a következő fejlécekkel fut:
Hitelesítési szkript bemenet HTTP_AUTH_USER: felhasználó HTTP_AUTH_PASS: jelszó HTTP_AUTH_PROTOCOL: levelezési protokoll (IMAP, POP3 vagy SMTP)
És így tér vissza:
Hitelesítési szkript kimenet HTTP_AUTH_STATUS: OK vagy hiba oka HTTP_AUTH_SERVER: valódi levelezőszerver átirányítja HTTP_AUTH_PORT: szerver port
Figyelemre méltó tulajdonsága ennek a megközelítésnek, hogy egyáltalán nem önmagában hitelesítésre használható, hanem a felhasználók szétszórására a különböző belső szervereken, a felhasználónévtől, a levelezőszerverek aktuális terhelési adataitól függően, vagy akár a legegyszerűbb terheléselosztás megszervezésével. körmérkőzés . Ha azonban csak a felhasználókat kell átvinnie egy belső levelezőszerverre, akkor valódi szkript helyett használhat egy csonkot, amelyet maga az nginx implementált. Például az nginx konfiguráció legegyszerűbb SMTP és IMAP proxyja így fog kinézni:
# vi /etc/nginx/nginx.conf mail ( # A hitelesítési szkript címe auth_http localhost:8080/auth; # Tiltsa le az XCLIENT parancsot, egyes levelezőszerverek nem értik xclient off; # IMAP szerver szerver ( figyelj 143; protokoll imap; proxy be; ) # SMTP szerver szerver ( figyelj 25; smtp protokoll; proxy be; ) )
# vi /etc/nginx/nginx.conf http ( # Leképezés a megfelelő levelezőszerver-porthoz a HTTP_AUTH_PROTOCOL fejlécleképezésben küldött porttól függően $http_auth_protocol $mailport (alapértelmezett 25; smtp 25; imap 143; ) # A hitelesítés végrehajtása " script" - mindig az OK-t adja vissza, és átirányítja a felhasználót a belső levelezőszerverre, beállítva a megfelelő portot a fenti leképezési szerver segítségével ( figyelj 8080; hely / auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" " 192.168.0.1" ; add_header "Auth-Port" $mailport; return 200; ) ) )
Ez minden. Ez a konfiguráció lehetővé teszi a felhasználók átlátható átirányítását a belső levelezőszerverre anélkül, hogy többletköltséget hozna létre egy szkript formájában, amely ebben az esetben szükségtelen. Egy parancsfájl használatával ez a konfiguráció jelentősen bővíthető: terheléselosztás beállítása, a felhasználók LDAP-adatbázissal való összehasonlítása és egyéb műveletek végrehajtása. A szkript írása túlmutat e cikk keretein, de a PHP és a Python kezdetleges ismeretével is nagyon könnyen megvalósítható.
Videó közvetítés
A szokásos nginx-alapú videotárhely beállítása egyszerű. Nincs más dolgod, mint feltölteni az átkódolt videót a szerver számára elérhető könyvtárba, hozzáadni a konfigurációhoz, és beállítani a flash vagy HTML5 lejátszót úgy, hogy ebből a könyvtárból vegyen videót. Ha azonban valamilyen külső forrásból vagy webkameráról szeretne folyamatos videoadást beállítani, akkor ez a séma nem fog működni, és speciális streaming protokollok felé kell néznie.
Több protokoll is megoldja ezt a problémát, ezek közül a leghatékonyabb és legtámogatottabb az RTMP. Az egyetlen probléma az, hogy szinte minden RTMP-kiszolgáló megvalósítása problémákkal küzd. A hivatalos Adobe Flash Media Server fizetős. A Red5 és a Wowza Java nyelven íródott, ezért nem adják a kívánt teljesítményt, egy másik implementáció, az Erlyvideo Erlang nyelven íródott, ami fürtbeállítás esetén jó, de egyetlen szervernél nem olyan hatékony.
Egy másik megközelítést javaslok - használja az RTMP modult az nginx-hez. Kiváló teljesítménnyel rendelkezik, és azt is lehetővé teszi, hogy egy szervert használjon az oldal webes felületének és a videó stream kiszolgálására. Az egyetlen probléma az, hogy ez a modul nem hivatalos, így magának kell elkészítenie az nginx-et a támogatásával. Szerencsére az összeszerelés szabványos módon történik:
$ sudo apt-get nginx eltávolítása $ 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
Most be kell állítani a modult. Ez a szokásos módon az nginx konfiguráción keresztül történik:
Rtmp (# Aktiválja a szórási kiszolgálót az 1935-ös porton a site/rtmp szerveren (figyelj 1935; alkalmazás rtmp (élő tovább; ) ))
Az RTMP modul nem működik többszálú konfigurációban, ezért az nginx worker folyamatok számát egyre kell csökkenteni (később elmondom, hogyan lehet megkerülni ezt a problémát):
dolgozói_folyamatok 1;
Most elmenthetjük a fájlt, és az nginx újra elolvashatja a konfigurációt. Az nginx beállítása kész, de még nincs meg a videó stream, ezért be kell szereznünk valahonnan. Legyen például az aktuális könyvtár video.avi fájlja. Használjuk a jó öreg FFmpeg-et, hogy folyammá alakítsuk és becsomagoljuk az RTMP műsorszórónkba:
# ffmpeg -re -i ~/video.avi -c copy -f flv rtmp://localhost/rtmp/stream
Ha a videofájl nem H264 formátumú, akkor újra kell kódolni. Ezt menet közben is megteheti ugyanazzal az FFmpeg-gel:
# ffmpeg -re -i ~/video.avi -c:v libx264 -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream
A stream közvetlenül a webkameráról is rögzíthető:
# ffmpeg -f video4linux2 -i /dev/video0 -c:v libx264 -an -f flv rtmp://localhost/rtmp/stream
Az adatfolyam kliensoldali megtekintéséhez bármilyen RTMP-képes lejátszót használhat, például az mplayert:
$ mplayer rmtp://example.com/rtmp/stream
Vagy ágyazd be a lejátszót közvetlenül a weboldalba, amelyet ugyanaz az nginx szolgál ki (példa a hivatalos dokumentációból):
A legegyszerűbb RTMP weblejátszó
Itt csak két fontos sor van: „file: „stream” – amely az RTMP adatfolyamot jelzi, és „streamer: „rtmp://localhost/rtmp””, amely az RTMP streamer címét adja meg. A legtöbb feladathoz ezek a beállítások elegendőek. Egy címen több különböző adatfolyam is elindítható, és az nginx hatékonyan multiplexeli őket az ügyfelek között. De ez nem minden, amire az RTMP modul képes. Segítségével megszervezheti például egy másik szerverről érkező video stream újraküldését. Ehhez egyáltalán nincs szükség FFmpeg szerverre, csak add hozzá a következő sorokat a konfigurációhoz:
# vi /etc/nginx/nginx.conf alkalmazás rtmp ( élőben ; húzza rtmp://rtmp.example.com; )
Ha több, különböző minőségű adatfolyamot kell létrehoznia, közvetlenül az nginx-ből hívhatja meg az FFmpeg átkódolót:
# vi /etc/nginx/nginx.conf alkalmazás rtmp ( élőben; exec ffmpeg -i rtmp://localhost/rtmp/$name -c:v flv -c:a -s 320x240 -f flv rtmp://localhost /rtmp-320x240/$name; ) rtmp-320x240 alkalmazás ( élőben; )
Ezzel a konfigurációval egyszerre két műsorszolgáltatót kapunk, amelyek közül az egyik az rtmp://site/rtmp címen, a másik pedig 320 x 240-es minőségben sugároz, az rtmp://site/rtmp–320x240 címen. Az oldalon tovább akaszthat egy flash lejátszót és minőségválasztó gombokat, amelyek a műsorszolgáltató egyik vagy másik címét csúsztatják a lejátszón.
És végül egy példa a zene hálózaton történő sugárzására:
míg igaz; do ffmpeg -re -i "`find /var/music -type f -name "*.mp3"|sort -R|head -n 1`" -vn -c:a libfaac -ar 44100 -ac 2 -f flv rtmp://localhost/rtmp/stream; Kész
git proxy
A Git verziókezelő rendszer nem csak a Git és SSH protokollokon, hanem HTTP-n keresztül is képes hozzáférést biztosítani a tárolókhoz. Valamikor a HTTP-elérés megvalósítása primitív volt, és nem tudott teljes értékű munkát biztosítani a tárolóval. Az 1.6.6-os verzió óta változott a helyzet, ma már ezzel a protokollal lehet például a kapcsolat mindkét oldalán tűzfalkorlátozásokat megkerülni, vagy webes felülettel létrehozni saját Git tárhelyet.
A hivatalos dokumentáció sajnos csak arról szól, hogy az Apache webszerver segítségével szervezzük meg a Githez való hozzáférést, de mivel maga az implementáció egy külső alkalmazás, szabványos CGI felülettel, így szinte bármilyen más szerverhez csatlakoztatható, beleértve a lighttpd-t és természetesen nginx. Ehhez nem kell más, mint maga a szerver, a telepített Git és egy kis FastCGI szerver fcgiwrap, amire azért van szükség, mert az nginx nem tud közvetlenül CGI-vel dolgozni, viszont a FastCGI protokoll segítségével képes szkripteket hívni.
Az egész munkaséma így fog kinézni. Az fcgiwrap szerver lefagy a háttérben, és vár egy CGI-alkalmazás végrehajtására vonatkozó kérésre. Az Nginx pedig úgy lesz beállítva, hogy a FastCGI felületen keresztül kérje a git-http-backend CGI bináris végrehajtását minden alkalommal, amikor az általunk megadott címhez hozzáférünk. A kérés fogadásakor az fcgiwrap végrehajtja a git-http-backend parancsot a GIT-ügyfél által továbbított megadott CGI-argumentumokkal, és visszaadja az eredményt.
Egy ilyen séma megvalósításához először telepítjük az fcgiwrap-ot:
$ sudo apt-get install fcgiwrap
Nem kell konfigurálnia, minden paraméter a FastCGI protokollon keresztül történik. Ez is automatikusan elindul. Ezért csak az nginx konfigurálása marad. Ehhez hozd létre az /etc/nginx/sites-enabled/git fájlt (ha nincs ilyen könyvtár, írhatsz a fő konfigba), és írd bele a következőket:
# vi /etc/nginx/sites-enabled/git szerver ( # Hang on port 8080 listen 8080; # Szerverünk címe (ne felejtse el hozzáadni a DNS-bejegyzést) server_name git.example.ru; # Logs access_log /var /log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Az anonim hozzáférési hely elsődleges címe / ( # Feltöltéskor küldje el a felhasználót egy privát címre if ($ arg_service ~* "git-receive-pack") ( ^ /private$uri last átírása; ) include /etc/nginx/fastcgi_params; # A git-http-backend fastcgi_param SCRIPT_FILENAME /usr címe /lib/git-core/git- http-backend; # Git lerakatcím fastcgi_param GIT_PROJECT_ROOT /srv/git; # Fájlcím fastcgi_param PATH_INFO $uri; # Szerver címe fcgiwrap fastcgi_pass 127.0.0.1:9001; Írási hely ~/private(/.* )$ ( # Felhasználói engedélyek auth_basic "git névtelen, csak olvasható, hitelesített írás"; # HTTP hitelesítés a htpasswd alapján auth_basic_user_file /etc/nginx/htpasswd; # FastCGI beállítások 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; ) )
Ez a konfiguráció három fontos dolgot feltételez:
- A lerakat címe /srv/git lesz, ezért állítsa be a megfelelő engedélyeket: $ sudo chown -R www-data:www-data /srv/git
- Magának a tárolónak olvashatónak kell lennie az Anonymous által, és engedélyeznie kell a HTTP-n keresztüli feltöltést: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true
- A hitelesítés a htpasswd fájl segítségével történik, ezt létre kell hozni és felhasználókat kell hozzáadni hozzá: $ sudo apt-get install apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2. .
Ennyi, indítsa újra az nginxet:
Mikrocaching
Képzeljünk el egy helyzetet egy dinamikus, gyakran frissülő oldallal, amely hirtelen nagyon nagy terhelést kezd kapni (na jó, az egyik legnagyobb híroldal oldalára került), és nem bírja a tartalom visszatérését. A megfelelő gyorsítótárazási séma hozzáértő optimalizálása és megvalósítása sokáig tart, és a problémákat most kell kezelni. Amit tehetünk?
Ebből a helyzetből többféleképpen is ki lehet kerülni minimális veszteségekkel, de a legérdekesebb ötlet Fenn Baileytől (fennb.com) származott. Az ötlet az, hogy egyszerűen tegyük az nginx-et a szerver elé, és kényszerítsük arra, hogy az összes továbbított tartalmat gyorsítótárba helyezze, de nem csak a gyorsítótárat, hanem csak egy másodpercre. A kiemelés itt az, hogy a webhely látogatóinak százai és ezrei másodpercenként valójában csak egy hívást generálnak a háttérrendszer felé, és legtöbbjük gyorsítótárazott oldalt kap. Ugyanakkor aligha veszi észre valaki a különbséget, hiszen még egy dinamikus oldalon sem általában semmit sem jelent egy másodperc.
Az ötlet megvalósításával kapcsolatos konfiguráció nem tűnik olyan bonyolultnak:
# vi /etc/nginx/sites-enabled/cache-proxy # A gyorsítótár proxy_cache_path konfigurálása /var/cache/nginx level=1:2 keys_zone=microcache:5m max_size=1000m; szerver ( figyelj 80; szerver_neve example.com; # Gyorsítótár cím helye / ( # A gyorsítótár alapértelmezés szerint engedélyezve van $no_cache "" ) ( $no_cache "1" beállítása; ) # Ha a kliens tartalmat tölt fel az oldalra (no_cache = 1), akkor ügyelünk arra, hogy a neki megadott adatok két másodpercig ne legyenek gyorsítótárazva, és akkor láthassa a letöltés eredményét, ha ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Max-Age=2; Path=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1 "; ) # A gyorsítótár engedélyezése/letiltása a no_cache proxy_no_cache változó állapotától függően $no_cache; proxy_cache_bypass $no_cache; # Proxy kérések a valódi szerverhez proxy_pass http://appserver.example.ru; proxy_cache microcache; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Mennydörgő csordaprobléma elleni védelem proxy_cache_use_stale frissítés fejléc Host $host; proxy_set_header X-Real-IP $ távoli_cím; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Ne tároljon gyorsítótárban 1 MB-nál nagyobb proxy_max_temp_file_size 1M fájlokat; ) )
Ebben a konfigurációban különleges helyet foglal el a "proxy_cache_use_stale updating;" sor, amely nélkül a gyorsítótár-frissítés során érkező kérések miatt időszakos terhelési rohamokat kaptunk volna a háttérkiszolgálón. Ellenkező esetben minden szabványos, és további magyarázat nélkül világosnak kell lennie.
A proxy közelítése a célközönséghez
Az internet sebességének globális növekedése ellenére továbbra is szerepet játszik a szerver fizikai távolsága a célközönségtől. Ez azt jelenti, hogy ha egy orosz oldal fut valahol Amerikában található szerveren, akkor a hozzáférés sebessége eleve lassabb lesz, mint egy azonos sávszélességű orosz szerverről (persze, ha becsukja a szemét minden más tényező előtt ). A másik dolog az, hogy gyakran jövedelmezőbb a szervereket külföldön tárolni, beleértve a karbantartást is. Ezért ahhoz, hogy magasabb megtérülési ráta formájában profitot szerezzen, egy trükköt kell végrehajtania.
Az egyik lehetséges lehetőség: a fő produktív szervert Nyugatra helyezzük, a nem túl erőforrásigényes, statikát adó front-endet pedig Oroszországba telepítjük. Ez lehetővé teszi, hogy gyorsasággal nyerjen komoly költségek nélkül. A frontend nginx konfigurációja ebben az esetben egy egyszerű proxy megvalósítás lesz, amely mindannyiunk számára ismerős:
# vi /etc/nginx/sites-enabled/proxy # Gyorsítótár tárolása 30 napig 100 GB tárhelyen. proxy_cache_path /var/cache/nginx level=1:2 keys_zone=static:32m inactive=30d max_size=100g; szerver ( figyelj 80; szerver_neve example.com; # Valójában a proxy helye ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Háttércím proxy_pass back.example.com:80; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $távoli_cím; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_6s; 3 proxy_1bufferk;2 proxy_6s proxy_cache_valid 30d; proxy_ignore_headers "Cache-Control" "Expires"; proxy_cache_key "$uri$is_args$args"; proxy_cache_lock on; ) )
megállapításait
Ma már az nginx segítségével sokféle feladatot meg lehet oldani, amelyek közül sok egyáltalán nem kapcsolódik a webszerverhez és a HTTP protokollhoz. A levelezési proxy, a streaming szerver és a Git felület csak néhány a feladatok közül.
Ez a cikk elmagyarázza, hogyan konfigurálható az NGINX Plus vagy az NGINX nyílt forráskód proxyként egy levelezőszerverhez vagy egy külső levelezőszolgáltatáshoz.
Bevezetés
Az NGINX képes IMAP-, POP3- és SMTP-protokollokat proxyszerezni a levelezőfiókokat tároló upstream levelezőszerverek egyikéhez, és így egyetlen végpontként használható az e-mail kliensek számára. Ez számos előnnyel járhat, mint például:
- a levelezőszerverek számának egyszerű skálázása
- levelezőszerver kiválasztása különböző szabályok alapján, például a legközelebbi szerver kiválasztása az ügyfél IP-címe alapján
- a terhelés elosztása a levelezőszerverek között
Előfeltételek
Az NGINX Plus (már tartalmazza az e-mail-forgalom proxyjához szükséges Mail modulokat) vagy az NGINX Open Source a --with-mail paraméterrel az e-mail proxy funkcióhoz és a --with-mail_ssl_module paraméterrel az SSL/TLS támogatásához fordította le a Mail modulokat:
$ ./configure --with-mail --with-mail_ssl_module --with-openssl=[ DIR] /openssl-1.1.1
IMAP, POP3 és/vagy SMTP levelezőszerverek vagy külső levelezőszolgáltatás
SMTP/IMAP/POP3 levelezőproxy szerverek konfigurálása
Az NGINX konfigurációs fájlban:
- a portszám amelyek megfelelnek a figyelési direktívával megadott protokollnak
- a jegyzőkönyv a protokoll direktívával (ha nincs megadva, a rendszer automatikusan észleli a figyelési direktívában megadott portról)
- megengedett hitelesítési módszerek imap_auth , pop3_auth és smtp_auth direktívákkal:
posta(#...)
mail ( szerver_neve mail.example.com ; #... )
mail ( szerver_neve mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; #... )
Alternatív megoldásként adja meg, hogy a proxy_pass_error_message direktíva megadásával értesítse-e a felhasználót a hitelesítési kiszolgáló hibáiról. Ez hasznos lehet, ha egy postafiók memóriája elfogy:
mail ( szerver_neve mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; #... )
Konfigurálja az egyes SMTP-, IMAP- vagy POP3-kiszolgálókat a kiszolgálóblokkokkal. Minden szerverhez adja meg:
szerver ( figyelj 25 ; protokoll smtp ; smtp_auth login sima cram-md5 ; ) szerver ( figyel 110 ; protokoll pop3 ; pop3_auth sima apop cram-md5 ; ) szerver ( figyel 143 ; protokoll imap ; )
Hitelesítés beállítása levelezőproxyhoz
Az ügyféltől érkező minden POP3/IMAP/SMTP-kérést először egy külső HTTP-hitelesítési kiszolgálón vagy egy hitelesítési parancsfájllal hitelesítenek. Az NGINX levelezőszerver-proxyhoz hitelesítési kiszolgáló megléte kötelező. A szervert saját maga is létrehozhatja az NGINX hitelesítési protokollnak megfelelően, amely a HTTP protokollon alapul.
Ha a hitelesítés sikeres, a hitelesítési kiszolgáló kiválaszt egy upstream kiszolgálót, és átirányítja a kérést. Ebben az esetben a szerver válasza a következő sorokat tartalmazza:
HTTP/1.0 200 OK Auth-Status: OK Auth-Server:
Ha a hitelesítés sikertelen, a hitelesítési szerver hibaüzenetet ad vissza. Ebben az esetben a szerver válasza a következő sorokat tartalmazza:
HTTP/1.0 200 OK Auth-Status:
Vegye figyelembe, hogy a válasz mindkét esetben tartalmazni fogja HTTP/1.0 200 OK ami zavaró lehet.
A hitelesítési kiszolgálóhoz intézett kérések és válaszok további példáiért tekintse meg az ngx_mail_auth_http_module részt az NGINX referenciadokumentációjában.
SSL/TLS beállítása levelezőproxyhoz
Az SSL/TLS-en keresztüli POP3/SMTP/IMAP használatával gondoskodik arról, hogy a kliens és a levelezőszerver között továbbított adatok biztonságosak legyenek.
Az SSL/TLS engedélyezése a levelezési proxy számára:
Győződjön meg arról, hogy az NGINX SSL/TLS támogatással van konfigurálva, ehhez írja be az nginx -V parancsot a parancssorba, majd keresse meg a with --mail_ssl_module sort a kimenetben:
$ nginx -V konfigurálja az argumentumokat: ... with---mail_ssl_module
Győződjön meg arról, hogy megszerezte a szervertanúsítványokat és a privát kulcsot, és helyezze el azokat a szerveren. A tanúsítvány beszerezhető egy megbízható tanúsító hatóságtól (CA), vagy egy SSL-könyvtár, például az OpenSSL segítségével hozható létre.
ssl be ;
megdöbben ;
SSL-tanúsítványok hozzáadása: adja meg a tanúsítványok elérési útját (amelynek PEM formátumúnak kell lennie) az ssl_certificate direktívával, és adja meg a privát kulcs elérési útját az ssl_certificate_key direktívában:
mail ( #... ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server.key ; )
Az ssl_protocols és ssl_ciphers direktívákkal csak az SSL/TLS erős verzióit és titkosításait használhatja, vagy beállíthatja saját preferált protokolljait és titkosításait:
mail ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; )
SSL/TLS optimalizálása levelezőproxyhoz
Ezek a tippek segítenek gyorsabbá és biztonságosabbá tenni NGINX levelezőproxyját:
Állítsa be a dolgozói folyamatok számát a processzorok számával megegyezően, ha a worker_processes direktíva ugyanazon a szinten van beállítva, mint a levelezési környezet:
worker_processes auto ; posta(#...)
Engedélyezze a megosztott munkamenet-gyorsítótárat, és tiltsa le a beépített munkamenet-gyorsítótárat az auto ; mail ( szerver_neve mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message on ; ssl on ; ssl_tanúsítvány /etc/ssl/certs/server_slkeyer/server_slkeyer kulcs ; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers HIGH:!aNULL:!MD5 ; ssl_session_cache share:SSL:10m ; ssl_session_timeout 10m ; ssl_session_timeout 10m ; kiszolgáló (figyelés 1 loginmm ; pop3 protokoll ; pop3_auth sima apop cram-md5 ; ) szerver ( figyelj 143 ; protokoll imap ; ) )
Ebben a példában három e-mail proxyszerver van: SMTP, POP3 és IMAP. Mindegyik kiszolgáló SSL és STARTTLS támogatással van konfigurálva. Az SSL-munkamenet paraméterei a gyorsítótárban lesznek.
A proxyszerver a HTTP-hitelesítési kiszolgálót használja – konfigurációja túlmutat e cikk hatókörén. A szerverről érkező összes hibaüzenet visszaküldésre kerül az ügyfeleknek.
Nginx- kis méretű, nagyon gyors, teljesen működőképes webszerver és levél proxyszerver, fejlesztő Igor Sysoev (rambler.ru). A nagyon alacsony rendszererőforrás- és sebességfogyasztás, valamint a konfigurációs rugalmasság miatt web nginx szerver gyakran használják kezelőfelületként nehezebb szerverekhez, mint pl Apache, nagy terhelésű projektekben. A klasszikus lehetőség egy csomó, Nginx - Apache - FastCGI. Egy ilyen rendszerben dolgozni, nginx szerver, elfogad minden HTTP-n keresztül érkező kérelmet, és a konfigurációtól és magától a kéréstől függően eldönti, hogy magát a kérést dolgozza fel, és kész választ ad a kliensnek, vagy küld egy feldolgozási kérelmet valamelyik háttérrendszerre ( Apache vagy FastCGI).
Tudniillik az Apache szerver minden kérést külön processzben (thread) dolgoz fel, ami mondjuk elég NEM csekély rendszererőforrást emészt fel, ha 10-20 ilyen processz van, az hülyeség, és ha igen. 100-500 vagy több van belőlük, a rendszer nem lesz szórakoztató.
Próbáljunk meg elképzelni egy ilyen helyzetet. Tegyük fel Apache 300 HTTP kérés érkezik kliensektől, 150 kliens gyors bérelt vonalon ül, a többi 150 pedig viszonylag lassú internetes csatornákon, még ha nem is modemen. Mi történik ebben a helyzetben? És a következő történik, hogy az Apache webszerver ennek a 300 kapcsolatnak a feldolgozásához minden egyes folyamathoz (szálhoz) létrehoz, gyorsan generál tartalmat, és 150 gyors kliens azonnal veszi a kéréseik eredményét, az őket kiszolgáló folyamatokat. megölnek és erőforrások szabadulnak fel, 150 pedig lassú, és lassan veszi le a lekérdezéseik eredményét a szűk internetes csatorna miatt, aminek következtében 150 folyamat fog lefagyni a rendszerben Apache, várja, hogy a kliensek elvigyék a webszerver által generált tartalmat, rengeteg rendszererőforrást felemésztve. Természetesen a helyzet hipotetikus, de szerintem a lényeg világos. A fenti helyzet megoldása és a csomag segít. Miután a teljes kérést elolvasta az ügyféltől, továbbítja azt feldolgozásra Apache, amely viszont tartalmat generál, és a lehető leggyorsabban visszaküldi a kész választ az Nginxnek, ami után az nyugodt lelkiismerettel meg tudja ölni a folyamatot, és felszabadítja az általa elfoglalt rendszererőforrásokat. Nginx webszerver, amely megkapja a kérés eredményét a következőtől Apache, pufferbe vagy akár lemezen lévő fájlba írja és tetszőlegesen hosszú ideig tudja adni a lassú klienseknek, miközben a dolgozói folyamatai olyan kevés erőforrást fogyasztanak, hogy .. "erről még beszélni is nevetséges" ©. :) Egy ilyen séma jelentősen megtakarítja a rendszer erőforrásait, ismétlem, de az Nginx dolgozói folyamatok csekély mennyiségű erőforrást fogyasztanak, ez még inkább releváns a nagy projekteknél.
És ez csak egy kis része annak, amit az Nginx szerver képes megtenni, ne feledkezzünk meg az adatok gyorsítótárazásának és a gyorsítótárban. Itt található az Nginx webszerver főbb funkcióinak listája.
Az Nginx szerver funkcionalitása HTTP szerverként
- Statikus tartalomkezelés, indexfájlok, könyvtárlista, megnyitott fájlleíró gyorsítótár;
- Gyorsított proxykezelés gyorsítótárazással, terheléselosztással és feladatátvétellel;
- Gyorsított támogatás FastCGI gyorsítótárazással, terheléselosztással és hibatűréssel rendelkező szerverek;
- Moduláris felépítés, különféle szűrők támogatása (SSI, XSLT, GZIP, önéletrajz, csonka válaszok);
- SSL és TLS SNI bővítmények támogatása;
- ip alapú vagy név alapú virtuális szerverek;
- Munkavégzés KeepAlive-val és csővezetékes kapcsolatokkal;
- Lehetőség az időkorlátok, valamint a pufferek számának és méretének szintjén történő konfigurálására Apache szerver;
- Különféle műveletek végrehajtása az ügyfél címétől függően;
- Az URI módosítása reguláris kifejezésekkel;
- Speciális hibaoldalak a 4xx és 5xx számára;
- Hozzáférés korlátozása ügyfélcím vagy jelszó alapján;
- Naplófájl formátumok beállítása, naplóforgatás;
- A válaszadás sebességének korlátozása az ügyfél számára;
- Az egyidejű kapcsolatok és kérések számának korlátozása;
- A PUT, DELETE, MKCOL, COPY és MOVE metódusok támogatása;
- Beállítások módosítása és a szerver frissítése a munka leállítása nélkül;
- beépített Perl;
Az Nginx szerver funkcionalitása levelezési proxyszerverként
- Továbbítás IMAP/POP3 háttérrendszerre külső HTTP hitelesítési kiszolgáló használatával;
- A felhasználó SMTP-jének ellenőrzése külső HTTP-hitelesítési kiszolgálón és továbbítása belső SMTP-kiszolgálóra;
- A következő hitelesítési módszerek támogatása:
- POP3 - FELHASZNÁLÓ/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
- IMAP - LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
- SMTP - AUTH LOGI / PLAIN / CRAM-MD5;
- SSL támogatás;
- STARTTLS és STLS támogatása;
Az Nginx webszerver által támogatott operációs rendszerek és platformok
- FreeBSD, 3-8 platform, i386 és amd64;
- Linux, 2.2-től 2.6-ig - i386 platform; Linux 2.6 - amd64;
- Solaris 9 – i386 és sun4u platformok; Solaris 10 – i386, amd64 és sun4v platformok;
- MacOS X platformok ppc, i386;
- Windows XP, Windows Server 2003; (Jelenleg béta tesztelés alatt)
Nginx szerver architektúra és méretezhetőség
- A fő (fő) folyamat, több (a konfigurációs fájlban konfigurálható) munkafolyamat, amely egy privilegizált felhasználó alatt fut;
- A következő kapcsolatkezelési módszerek támogatása:
- válassza ki a standard módszer. A megfelelő Nginx modul automatikusan létrejön, ha az adott platformon nem található hatékonyabb módszer. A modul buildjét a --with-select_module vagy a --without-select_module konfigurációs beállításokkal kényszerítheti be vagy ki.
- közvélemény kutatás a standard módszer. A megfelelő Nginx modul automatikusan létrejön, ha az adott platformon nem található hatékonyabb módszer. A modul buildjét a --with-poll_module vagy a --without-poll_module konfigurációs beállításokkal kényszerítheti be vagy ki.
- kqueue egy hatékony módszer, amelyet FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 és MacOS X operációs rendszereken használnak, kétprocesszoros MacOS X gépeken használva kernelpánikot okozhat.
- epoll egy hatékony módszer, amelyet Linux 2.6+-ban használnak. Egyes disztribúciók, például a SuSE 8.2, rendelkeznek javításokkal az epoll támogatására a 2.4-es kernelben.
- rtsig – valós idejű jelek, egy hatékony módszer, amelyet a Linux 2.2.19+ verziójában használnak. Alapértelmezés szerint a teljes rendszerben legfeljebb 1024 jel lehet a sorban. A nagy terhelésű szervereknél ez nem elég, a sor méretét a /proc/sys/kernel/rtsig-max kernel paraméterrel kell növelni. A Linux 2.6.6-mm2 verziótól azonban ez az opció megszűnt, ehelyett minden folyamatnak külön jelsora van, amelynek méretét az RLIMIT_SIGPENDING határozza meg.
- Amikor megtelik a sor, nginx szerver alaphelyzetbe állítja, és lekérdezési módszerrel kezeli a kapcsolatokat, amíg a helyzet vissza nem tér a normális kerékvágásba.
- /dev/poll- hatékony módszer, Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ és Tru64 UNIX 5.1A+ operációs rendszereken támogatott.
- eventport – eseményportok, a Solaris 10-ben használt hatékony módszer. Használat előtt egy javítást kell telepíteni a kernelpánik elkerülése érdekében.
- A kqueue metódus szolgáltatásainak felhasználásával, mint például EV_CLEAR, EV_DISABLE (az esemény ideiglenes letiltásához), NOTE_LOWAT, EV_EOF, az elérhető adatok száma, hibakódok;
- A sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) és sendfilev (Solaris 8 7/01+) használata;
- Az elfogadó szűrők (FreeBSD 4.1+) és a TCP_DEFER_ACCEPT (Linux 2.4+) támogatása;
- 10 000 tétlen HTTP-kapcsolat körülbelül 2,5 millió memóriát fogyaszt;
- Az adatmásolási műveletek minimális száma;
Az iRedMail egy nyílt forráskódú levelezőszerver. Az összeállítás a Postfix SMTP-kiszolgálón (röviden MTA) alapul. Az összeállítás a következőket is tartalmazza: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData és NGINX.
Galambdúc- IMAP/POP3 szerver.
Spamassassin- Spam szűrő eszköz.
Szürkelista- Szürke listákon alapuló levélszemét-szűrő eszköz.
ClamAV- vírusirtó.
Roundcubeés Így megy- Webes kliensek az e-mail kezeléshez.
NetData- egy program a szerver működésének valós idejű megfigyelésére.
Nginx- web szerver.
Támogatja az operációs rendszereket: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12és OpenBSD 6.4.
Az iRedMailnek van fizetős és ingyenes verziója, amelyek az iRedAdmin saját webes felületének funkcionalitásában különböznek egymástól. Az ingyenes verzióban csak tartományok, felhasználói és rendszergazdai postafiókok hozhatók létre. Ha álnevet kell létrehoznia, az ingyenes verzióban az iRedAdminon keresztül nem fogja tudni megtenni. Szerencsére van egy ingyenes megoldás, a PostfixAdmin, amely lehetővé teszi ezt. A PostfixAdmin könnyen integrálható az iRedMail-lel, és remekül működik vele.
Telepítés
A telepítéshez a fent felsorolt operációs rendszerek egyikére van szükségünk. Ubuntu Server 18.04-et fogok használni. Ezenkívül rendelkeznie kell egy megvásárolt tartománynévvel és egy konfigurált DNS-zónával. Ha a domainregisztrátor DNS-kiszolgálóját használja, akkor két rekordot kell készítenie a tartományzónakezelés szakaszban: A és MX. Saját DNS-ét is használhatja, ha beállítja a delegálást a domain név regisztrátora személyes fiókjában.
Domainzóna beállítása DNS-regisztrátor használatakor
Jegyzet! A DNS-beállítások néhány órától egy hétig érvényesek. Amíg a beállítások nem lépnek életbe, a levelezőszerver nem fog megfelelően működni.
A telepítéshez töltse le az aktuális verziót az iRedMail webhelyéről. Jelenleg 0,9,9.
# wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.9.tar.bz2
Ezután csomagolja ki a letöltött archívumot.
# tar xjf iRedMail-0.9.9.tar.bz2
Az archívum kicsomagolása
És lépjen a létrehozott mappába.
# cd iRedMail-0.9.9
Mappa iRedMail telepítővel
Egy mappa tartalmának ellenőrzése
Mappa tartalma
És futtassa az iRedMail telepítőszkriptet.
# bash iRedMail.sh
Elindul a levelezőrendszer telepítése. A telepítési folyamat során számos kérdésre kell válaszolnia. Megállapodunk a telepítés megkezdésében.
Telepítés kezdete
Telepítési könyvtár kiválasztása
Most ki kell választania egy webszervert. Nem nagy a választék, ezért az NGINX-et választjuk.
Webszerver kiválasztása
Most ki kell választania azt az adatbázis-kiszolgálót, amelyet a levelezőrendszerrel való együttműködésre telepít és konfigurál. Válassza a MariaDB-t.
Adatbázis-kiszolgáló kiválasztása
Állítsa be az adatbázis root jelszavát.
Adatbázis root jelszó létrehozása
Most megadjuk a levelezési tartományunkat.
Levelezési domain létrehozása
Ezután hozzon létre egy jelszót az adminisztrációs mezőhöz [e-mail védett] domain.ru.
Hozzon létre egy levelezőrendszergazdai jelszót
Webkomponensek kiválasztása
Megerősítjük a megadott beállításokat.
A beállítások megerősítése
A telepítés megkezdődött.
Telepítés
A telepítés befejezése után erősítse meg a szabály létrehozását iptables számára SSHés indítsa újra a tűzfalat. iRedMail működik iptables. Az Ubuntuban a leggyakrabban használt tűzfalkezelő segédprogram UVW. Ha ilyen vagy olyan okból szüksége van rá, telepítse UVW (apt install ufw), és adjon hozzá szabályokat UVW(példa: ufw engedélyezi az "nginx full" beállítást vagy ufw engedélyezi a Postfixet) nem blokkolta a levelezőszervert. Az elérhető szabályok listáját a parancs futtatásával tekintheti meg: ufw alkalmazások listája. Ezután kapcsolja be UVW: ufw engedélyezése.
Hozzon létre egy iptables szabályt
A tűzfal újraindítása
Ezzel befejeződik az iRedMail telepítése. A rendszer webes felület címeket és bejelentkezési adatokat adott nekünk. A levelezőrendszer összes összetevőjének engedélyezéséhez újra kell indítani a kiszolgálót.
A telepítés vége
Újraindítjuk.
# újraindítás
Beállítás
Először meg kell győződnie arról, hogy minden működik. Megpróbálunk belépni az iReadAdmin vezérlőpultjába a címen https://domain/iredadmin. Belépés [e-mail védett] domain.ru, a jelszó a telepítés során jött létre. Van egy orosz nyelvű felület.
Amint látod minden működik. Az iRedAdminba való bejelentkezéskor valószínűleg biztonsági hibaüzenetet kapott a tanúsítvánnyal kapcsolatban. Ennek az az oka, hogy az iRedMail rendelkezik egy önaláírt tanúsítvánnyal, amelyre a böngésző esküszik. A probléma megoldásához telepítenie kell egy érvényes SSL-tanúsítványt. Ha vásárolt egyet, telepítheti. A példában ingyenes SSL-t fogok telepíteni a Let's Encrypt alkalmazásból.
Let's Encrypt SSL-tanúsítvány telepítése
A tanúsítványt a certbot segédprogrammal telepítjük. Először adjunk hozzá egy adattárat.
# add-apt-repository ppa:certbot/certbot
Ezután telepítjük magát a certbootot a szükséges összetevőkkel.
# apt install python-certbot-nginx
oklevelet kapunk.
# certbot --nginx -d domain.ru
A parancs futtatása után a rendszer kérni fogja egy e-mail cím megadását, írja be. Ezt követően nagy valószínűséggel olyan hibaüzenetet kap, hogy nem lehet megtalálni azt a szerverblokkot, amelyhez a tanúsítvány készült. Ebben az esetben ez normális, mivel nincs szerverblokkunk. Nekünk az a lényeg, hogy bizonyítványt szerezzünk.
Tanúsítvány megszerzése
Mint látható, a tanúsítvány sikeresen érkezett, és a rendszer megmutatta nekünk a tanúsítványhoz és a kulcshoz vezető útvonalakat. Pont ezekre van szükségünk. Általában 4 fájlt kaptunk, amelyek a „/etc/letsencrypt/live/domain” mappában lesznek tárolva. Most közölnünk kell a webszerverrel a tanúsítványunkat, vagyis ki kell cserélni a beágyazott tanúsítványt az imént kapottra. Ehhez csak egy fájlt kell szerkesztenünk.
# nano /etc/nginx/templates/ssl.tmpl
És változtassa meg benne az utolsó két sort.
Az SSL tanúsítvány cseréje
A fájlban lévő elérési utakat megváltoztatjuk azokra az elérési utakra, amelyeket a rendszer a tanúsítvány átvételekor közölt velünk.
SSL-tanúsítvány cseréje
És indítsa újra az NGINX-et.
# szolgáltatás nginx újraindítása
Most próbáljunk meg újra bejelentkezni. iRedAdmin.
SSL tanúsítvány ellenőrzése
Nincs több tanúsítványhiba. A tanúsítvány érvényes. A zárra kattintva megtekintheti annak tulajdonságait. Amikor a tanúsítvány lejár, a certbootnak automatikusan meg kell újítania.
Most beszéljünk a Dovecot és Postfix tanúsítványról. Ehhez két konfigurációs fájlt szerkesztünk. Mi csináljuk:
# nano /etc/dovecot/dovecot.conf
Blokk keresése:
#SSL: Globális beállítások.
Az ott bejegyzett tanúsítványt pedig a miénkre cseréljük.
Tanúsítványcsere a Dovecot számára
Ügyeljen az "ssl_protocols" sorra is. Értékének "!SSLv3"-nak kell lennie, különben a "Figyelmeztetés: Az SSLv2-t nem támogatja az OpenSSL. Kérjük, fontolja meg az ssl_protocolsból" hibaüzenetet a Dovecot újraindításakor.
# nano /etc/postfix/main.cf
Blokk keresése:
# SSL kulcs, tanúsítvány, CA
És megváltoztatjuk a benne lévő elérési utakat a tanúsítványunk fájljainak elérési útjaira.
A Postfix tanúsítvány cseréje
Ezzel befejeződik a tanúsítvány telepítése. A Dovecot és a Postfix újraindítása szükséges, de jobb a szerver újraindítása.
# szerviz galambtartó újraindítás
# újraindítás
A PHPMyAdmin telepítése
Ez az elem nem kötelező, de azt javaslom, hogy töltse ki, és telepítse a PHPMyAdmin alkalmazást az adatbázis-élmény érdekében.
# apt install phpmyadmin
A telepítő megkérdezi, hogy melyik webszerverrel kell beállítani a PHPMyAdmin-t, mivel az NGINX nincs ebben a listában, csak nyomja meg a TAB billentyűt, és lépjen tovább.
A PHPMyAdmin telepítése
A telepítés befejezése után a phpmyadmin működéséhez szimbolikus hivatkozást kell létrehoznia arra a könyvtárra, amellyel az NGINX alapértelmezés szerint működik.
# ln -s /usr/share/phpmyadmin /var/www/html
És próbálj odamenni https://domain/phpmyadmin/
A PHPMyAdmin működik. A kapcsolatot tanúsítvány védi, nincs hiba. Lépj tovább. Hozzon létre egy MySQL adatbázis-adminisztrátort (MariaDB).
# mysql
És belépünk a MariaDB felügyeleti konzoljába. Ezután egyenként hajtjuk végre a parancsokat:
MariaDB > FELHASZNÁLÓ LÉTREHOZÁSA "admin"@"localhost" A "jelszó" AZONOSÍTÁSA;
MariaDB > AZ ÖSSZES KIVÁLTATÁS MEGADÁSA A *.* SZÁMÁRA "admin"@"localhost" AZ EGÉSZÍTŐ OPCIÓVAL;
MariaDB > FLUSH PRIVILEGES;
MySQL felhasználó létrehozása
Minden rendben, be vagy jelentkezve. A PHPMyAdmin használatra kész.
A PostfixAdmin telepítése
Elvileg a PostfixAdmin, akárcsak a PHPMyAdmin, nem telepíthető. A levelezőszerver tökéletesen működik ezen összetevők nélkül. De akkor nem tud majd levelezőneveket létrehozni. Ha erre nincs szüksége, akkor nyugodtan hagyja ki ezeket a részeket. Ha továbbra is szüksége van álnevekre, akkor két lehetősége van: megvásárolja az iReaAdmin fizetős verzióját vagy telepíti a PostfixAdmin programot. Természetesen ezt további szoftverek nélkül is megteheti, ha manuálisan beírja az álneveket az adatbázisba, de ez nem mindig kényelmes és nem mindenki számára megfelelő. A PostfixAdmin használatát javaslom, most megfontoljuk a telepítését és az iRedMail-lel való integrációját. Elkezdjük a telepítést:
# apt install postfixadmin
Megállapodunk és létrehozunk egy jelszót a program rendszeradatbázisához.
A PostfixAdmin telepítése
A PostfixAdmin telepítése
A PHPMyAdmin telepítésével analóg módon szimbolikus hivatkozást készítünk.
# ln -s /usr/share/postfixadmin /var/www/html
Azt a felhasználót tesszük a címtár tulajdonosává, akinek nevében a webszerver elindul. Esetünkben az NGINX www-adatfelhasználóként fut.
# chown -R www-data /usr/share/postfixadmin
Most szerkesztenünk kell a PostfixAdmin konfigurációs fájlját, és hozzá kell adnunk az iRedAdmin által használt adatbázisra vonatkozó információkat. Alapértelmezés szerint ennek az adatbázisnak a neve vmail. Ha a PHPMyAdmin oldalra lépsz, ott láthatod. Ezért, hogy a PostfixAdmin módosítsa az adatbázist, ezt a PostfixAdmin konfigurációjában írjuk elő.
# nano /etc/postfixadmin/config.inc.php
A vonalak megtalálása:
$CONF["adatbázis_típusa"] = $dbtípus;
$CONF["adatbázis_gazda"] = $dbszerver;
$CONF["adatbázis_felhasználó"] = $dbuser;
$CONF["adatbázis_jelszó"] = $dbpass;
$CONF["adatbázis_neve"] = $dbnév;
És jusson eszedbe:
$CONF["database_type"] = "mysqli"; # Adatbázis típusa
$CONF["database_host"] = "localhost"; # Adatbázis szerver gazdagép
$CONF["adatbázis_felhasználó"] = "admin"; # Jelentkezzen be írási hozzáféréssel a vmail adatbázisba. Használhatja a korábban létrehozott adminisztrátort
$CONF["database_password"] = "jelszó"; # A fent megadott felhasználó jelszava
$CONF["adatbázis_neve"] = "vmail"; # iRedMail adatbázis neve
Adatbázis adatok megadása
Ha a SOGo webes levelezőklienst tervezi használni, akkor még egy további lépést kell tennie, nevezetesen meg kell változtatnia a PostfixAdmin titkosítást a bekezdésben $CONF["titkosítás"] val vel "md5crypt" a "galambóc:SHA512-CRYPT". Ha ezt nem teszi meg, akkor amikor a PostfixAdminban létrehozott felhasználó SOGo-ban próbál meg hitelesíteni, hibaüzenetet kap, hibás bejelentkezési névvel vagy jelszóval.
A titkosítás típusának módosítása
Most, hogy sikeresen befejezze a telepítést, és ne kapjon hibákat, le kell kérdeznie az adatbázist. Ezt kényelmesen megteheti a PHPMyAdmin segítségével. Válassza ki a vmail adatbázist, és lépjen az SQL fülre. Az ablakba írja be:
DROP INDEX domain a postafiókba;
DROP INDEX domain aliasra;
ALTER TABLE alias ADD COLUMN `goto` text NOT NULL;
Adatbázis lekérdezés
És nyomja meg a "Tovább" gombot. Most már minden készen áll, lépjen a PostfixAdmin webes felületére, és fejezze be a telepítést. Ehhez a böngészőbe be kell írnia: https://domain/postfixadmin/setup.php.
A következőnek kell megjelennie:
A PostfixAdmin telepítése
Ha minden az utasításoknak megfelelően történik, akkor nem lehetnek hibák. Ha még mindig vannak, akkor elárulják, hogy megszüntessék, különben a rendszer nem engedi tovább. Állítsa be a telepítési jelszót, és kattintson a " Jelszókivonat generálása". A rendszer létrehoz egy kivonatot a jelszóból, amelyet be kell illeszteni a paraméterbe $CONF["setup_password"].
A PostfixAdmin telepítésének befejezése
A konfigurációs fájl beállításainak módosítása
Most beírjuk az imént létrehozott jelszót, és létrehozzuk a PostfixAdmin rendszergazdát. Jobb, ha nem postmaster bejelentkezéssel hoz létre adminisztrátort, mivel problémák adódhatnak az iRedAdmin adminisztrációs paneljébe való bejelentkezéssel.
PostfixAdmin rendszergazda létrehozása
Minden, a rendszergazda létrejön. Be lehet jelentkezni.
Kérjük, vegye figyelembe, hogy biztonsági szempontból jobb átnevezni vagy törölni a postfixadmin könyvtárban található setup.php fájlt.
Gyerünk: https://domain/postfixadmin/és adja meg az újonnan létrehozott hitelesítő adatokat. A PostfixAdminban és az iRedAdminban is elérhető az orosz nyelv. Az engedélyezés során választható ki.
Felhasználói postafiókot próbálunk létrehozni.
iRedMail modulok engedélyezése/letiltása
Az iRedMail modulokat az iRedAPD kezeli. Van egy konfigurációs fájlja, amely működő modulokat tartalmaz. Ha nincs szüksége egy adott modulra, eltávolíthatja a konfigurációs fájlból, és leáll. Mi csináljuk:
# nano /opt/iredapd/settings.py
Keresse meg a vonalat bővítmények", és távolítsa el belőle azokat az alkatrészeket, amelyekre nincs szüksége. Eltávolítom az összetevőt "szürkelista". Természetesen elég hatékonyan véd a spam ellen, de a szükséges levelek sokszor nem érnek el.
A Greylist (szürke lista) egy automatikus spamvédelmi technológia, amely a küldő szerverének viselkedésének elemzésén alapul. Ha a "greylisting" engedélyezve van, a szerver először nem hajlandó elfogadni egy ismeretlen címről érkező levelet, ideiglenes hibát jelezve. Ebben az esetben a küldő szervernek később újra meg kell próbálnia a küldést. A spammerek általában nem teszik ezt. Ha a levelet újra elküldik, akkor 30 napra felkerül a listára, és már az első alkalommal cserélik a levelet. Használja ezt a modult, vagy ne döntse el maga.
Levelezési modulok engedélyezése/letiltása
A változtatások elvégzése után újra kell indítania. iRedAPD.
# szolgáltatás iredapd újraindítás
Levelezőszerver tesztelése
Ezzel befejeződik az iRedMail levelezőszerver beállítása. Továbbléphet az utolsó szakaszhoz - a teszteléshez. Hozzunk létre két postafiókot. Az egyiket az iRedAdmin, a másodikat a PostfixAdmin segítségével ellenőrizheti, és levelet küldhet egyik postafiókból a másikba, és fordítva. Hozzon létre egy postafiókot az iRedAdminban [e-mail védett] domain.ru. A PostfixAdminban - [e-mail védett] domain.ru
Felhasználó létrehozása az iRedAdminban
Felhasználó létrehozása a PostfixAdminban
Ellenőrizze, hogy létrejött-e a felhasználók.
Ha figyel a PostfixAdmin postafiókok listájában a "Címzett" oszlopra, láthatja a különbséget az iRedAdmin és a PostfixAdmin programban létrehozott postafiókok között. Az iRedAdminban létrehozott postafiókok megjelölése " csak előre", és a PostfixAdminban mint - " Postafiók". Először sokáig nem értettem, hogy ez miért történik, és mi a különbség köztük, végül egy dologra lettem figyelmes. Az iRedAdminban a postafiókok álnevek nélkül jönnek létre, a PostfixAdminban pedig a saját álnévvel ellátott postafiókok.
És ha ezeket az álneveket törlik, akkor a postafiókok az iRedAdminban létrehozottakként jelennek meg. csak előre".
Álnevek eltávolítása
Az álnevek eltávolítva. Ellenőrizze a PostfixAdmin-t.
Amint látja, az összes doboz „Csak előre” lett. Ugyanígy, ha létrehoz egy álnevet magának az iRedAdminban létrehozott postafiókban, akkor az "Mailbox" lesz. Ez elvileg nem befolyásolja a levelezés teljesítményét. Az egyetlen dolog, hogy a PostfixAdminban létrehozott postafiókban nem tud álnevet létrehozni. Ahelyett, hogy aliast hozna létre, szerkesztenie kell egy meglévőt. Ha már az álneveknél tartunk, az iRedMail új verziójában módosítani kell az álnevekért felelős Postfix kártyák egyikén. És ha ezt nem teszi meg, akkor a létrehozott álnevek nem fognak működni. Ehhez szükséges a fájlban /etc/postfix/mysql/virtual_alias_maps.cf kijavítani:
Mi csináljuk:
# nano /etc/postfix/mysql/virtual_alias_maps.cf
És megjavítjuk.
Álnevek beállítása
Indítsa újra a Postfixet:
# service postfix újraindítás
Ezt követően mindennek működnie kell.
Tehát kezdjük el ellenőrizni a leveleket. Egy dobozban felhasználó1átmegyünk a Roundcube és be a dobozba felhasználó2- a SOGo-n keresztül, és küldjön egy levelet a postafiókból felhasználó1 a felhasználó2és vissza.
E-mail küldése a Roundcube segítségével
E-mail fogadása a SOGo-ban
E-mail küldése a SOGo-nak
E-mailek fogadása a Roundcube-ban
Minden probléma nélkül működik. A levél kézbesítése két-öt másodpercig tart. Ugyanígy a leveleket tökéletesen kézbesítik a Yandex és a mail.ru szerverekre (ellenőrizve).
Most nézzük meg az álneveket. Hozzunk létre egy dobozt felhasználó3és készítsen álnevet a postafiókból felhasználó1 a dobozon felhasználó2. És küldjön egy levelet a dobozból felhasználó3 a dobozon felhasználó1. Ebben az esetben a levélnek a dobozba kell érkeznie felhasználó2.
Hozzon létre egy aliast
E-mail küldése user3 postafiókjából user1 postafiókjába
Levél fogadása user2 postafiókjába
Az álnevek munkájával is minden rendben van.
Teszteljük a levelezőszerver működését a helyi levelezőkliensen keresztül. Vegyük például a Mozilla Thunderbird alkalmazást. Hozzunk létre még két felhasználót: ügyfél1és ügyfél2. Az egyik postafiókot IMAP-on, a másikat POP3-on keresztül csatlakoztatjuk, és levelet küldünk egyik postafiókból a másikba.
Csatlakozás IMAP-en keresztül
POP3 kapcsolat
Az 1. ügyféltől levelet küldünk a 2. ügyfélnek.
Kiszállítás az Ügyféltől 1
Fogadás a 2. ügyfélen
És fordított sorrendben.
Küldés a klienstől 2
Fogadás az 1. ügyfélen
Minden működik.
Ha erre jársz: https://domain/netdata, akkor megfigyelheti a rendszer állapotának grafikonjait.
Következtetés
Ezzel befejeződik az iRedMail levelezőrendszer telepítése, konfigurálása és tesztelése. Ennek eredményeként kaptunk egy teljesen ingyenes, teljes értékű levelezőszervert, érvényes SSL tanúsítvánnyal, két különböző webes levelezőklienst, két vezérlőpultot, valamint a levelekbe épített spam- és vírusirtót. Ha szeretné, a webes levelezőkliensek helyett helyi levelezőklienseket is használhat, például a Microsoft Outlookot vagy a Mozilla Thunderbirdot. Ha nem tervezi webes levelezőkliensek használatát, akkor egyáltalán nem telepítheti azokat, hogy ne terhelje túl a szervert, vagy telepítsen egy olyan dolgot, amely jobban tetszik. Én személy szerint jobban szeretem a SOGo-t, mert a felülete mobileszközökre van optimalizálva, ami nagyon kényelmessé teszi az e-mailek megtekintését okostelefonról. Ugyanez vonatkozik a NetDatára és az iRedAdminra is, ha nem tervezi használni, akkor jobb, ha nem telepíti. Ez a levelezőrendszer nem túl nagy erőforrásigényű. Mindez egy VPS szerveren fut 1024 MB RAM-mal és egy virtuális processzorral. Ha bármilyen kérdése van ezzel a levelezőrendszerrel kapcsolatban, írja meg a megjegyzésekben.
P.S. A termék tesztelése során különböző operációs rendszereken 1 GB RAM-mal (Ubuntu, Debian, CentOS) kiderült, hogy 1 GB nem elég a ClamAV működéséhez. Szinte minden esetben 1 GB memória használatakor a víruskereső adatbázis hibára hivatkozott. Ugyanakkor a Debian és Ubuntu operációs rendszereken a víruskereső egyszerűen nem vizsgálta át a szerveren áthaladó leveleket, különben minden rendben működött. A CentOS-en a helyzet némileg más volt. A clamd szolgáltatás teljesen leakasztotta a rendszert, így lehetetlenné tette a szerver normális működését. Amikor megpróbált bejelentkezni a webes felületekre, az NGINX időnként 502-es és 504-es hibát adott. A leveleket is időben küldték. Ugyanakkor, ha 2 GB RAM-ot ad hozzá, akkor minden esetben nem volt probléma a víruskereső és a szerver egészének működésével. A ClamAV megvizsgálta a levelezőszerveren áthaladó leveleket, és beírta a naplóba. Amikor egy mellékletben próbált vírust küldeni, a küldés blokkolva lett. A memóriafogyasztás körülbelül 1,2-1,7 GB volt.
Az NGINX nem csak webszerverként vagy http-proxyként használható, hanem SMTP, IMAP, POP3 protokollon keresztüli levél proxyként történő továbbítására is. Ez beállítja:
- Egyetlen belépési pont a méretezhető levelezőrendszerhez.
- Terheléselosztás az összes levelezőszerver között.
Ez a cikk Linux operációs rendszerre telepít. Levelezési szolgáltatásként, amelyre a kéréseket küldik, használhatja a postfix, exim, dovecot, Exchange, iredmail assembly és egyebeket.
Működés elve
Az NGINX fogadja a kéréseket és hitelesíti a webszervert. A bejelentkezés és a jelszó ellenőrzésének eredményétől függően a proxy több fejléccel ad választ.
Siker esetén:
Így hitelesítés alapján határozzuk meg a levelezőszerver szerverét és portját. Ez sok lehetőséget ad a megfelelő programozási nyelvek ismeretével.
Meghibásodás esetén:
A hitelesítés eredményétől és a fejléctől függően a kliens a szükséges levelezőszerverre kerül átirányításra.
Szerver előkészítés
Végezzünk néhány változtatást a szerver biztonsági beállításain.
SELinux
Tiltsa le a SELinuxot, ha CentOS-t használ, vagy ha ezt a biztonsági rendszert használja Ubuntun:
vi /etc/selinux/config
SELINUX=letiltva
Tűzfal
Ha tűzfalat használunk(alapértelmezett a CentOS-en):
firewall-cmd --permanent --add-port=25/tcp --add-port=110/tcp --add-port=143/tcp
firewall-cmd --reload
Ha iptables-t használunk(alapértelmezett Ubuntuban):
iptables -A BEMENET -p tcp --dport 25 -j ELFOGADÁS
iptables -A BEMENET -p tcp -dport 110 -j ELFOGADÁS
iptables -A BEMENET -p tcp -dport 143 -j ELFOGADÁS
apt-get install iptables-persistent
iptables-save > /etc/iptables/rules.v4
* Ebben a példában engedélyeztük az SMTP-t (25), a POP3-at (110), az IMAP-ot (143).
NGINX telepítése
Az operációs rendszertől függően az NGINX telepítése némileg eltérő.
vagy Linux centos:
yum telepítse az nginx-et
vagy Linux ubuntu:
apt install nginx
Engedélyezzük a szolgáltatás automatikus elindítását és elindítását:
systemctl engedélyezése nginx
systemctl start nginx
Ha az NGINX már telepítve van a rendszeren, ellenőrizze, hogy mely modulokkal működik:
Kapunk egy listát azokról a lehetőségekről, amelyekkel a webszerver épül – ezek között látni kell ---maillel. Ha a szükséges modul nem létezik, frissítenie kell az nginx-et
Az NGINX beállítása
Nyissa meg az nginx konfigurációs fájlt, és adja hozzá a lehetőséget posta:
vi /etc/nginx/nginx.conf
posta (
auth_http localhost:80/auth.php;
Szerver(
figyelj 25;
smtp protokoll;
smtp_auth bejelentkezés egyszerű cram-md5;
}
Szerver(
figyelj 110;
protokoll pop3;
}
Szerver(
figyelj 143;
protokollmap;
}
}
* ahol:
- szerver név— a levelezőszerver neve, amely az SMTP-köszöntés közben megjelenik.
- auth_http— webszerver és URL a hitelesítési kéréshez.
- proxy_pass_error_message— sikertelen hitelesítés esetén engedélyezi vagy letiltja az üzenet megjelenítését.
- hallgat— port, amelyen a kérések meghallgatásra kerülnek.
- jegyzőkönyv az az alkalmazási protokoll, amelyre a megfelelő port figyel.
- smtp_auth— elérhető hitelesítési módszerek az SMTP-hez.
- pop3_auth— elérhető hitelesítési módszerek a POP3 számára.
A http - szerver szakaszban adja hozzá:
Szerver(
Figyelj 80 default_server;
figyelj [::]:80 alapértelmezett_szerver;
...
Hely ~ \.php$ (
állítsa be a $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $gyökér_útvonal$fastcgi_script_name;
tartalmazza a fastcgi_params;
fastcgi_param DOCUMENT_ROOT $gyökér_útvonal;
}
...
Indítsa újra az nginx szervert:
systemctl indítsa újra az nginx-et
PHP telepítése és beállítása
A PHP segítségével történő hitelesítés végrehajtásához a következő csomagokat kell telepíteni a rendszerre.
Ha egy CentOS:
yum install php php-fpm
Ha egy ubuntu:
apt-get install php php-fpm
Indítsa el a PHP-FPM-et:
systemctl engedélyezi a php-fpm-et
systemctl start php-fpm
Hitelesítés
A bejelentkezést és a jelszót egy szkript ellenőrzi, amelynek elérési útját az auth_http opció állítja be. Példánkban ez egy PHP szkript.
Példa a bejelentkezési és jelszó-ellenőrző szkript hivatalos sablonjára:
vi /usr/share/nginx/html/auth.php
* Ez a szkript elfogad minden bejelentkezést és jelszót, és átirányítja a kéréseket a szerverekre 192.168.1.22 és 192.168.1.33 . A hitelesítési algoritmus beállításához a 61-64. sorokat szerkesztjük. A 73-77. sorok felelősek azoknak a szervereknek a visszaadásáért, amelyekre az átirányítás folyamatban van - ebben a példában, ha a bejelentkezés karakterekkel kezdődik "a", "c", "f", "g", akkor az átirányítás a szerverre lesz mailhost01, egyébként be mailhost02. A szervernevek IP-címekhez való hozzárendelése a 31-es, 32-es sorban állítható be, ellenkező esetben a hívás a domain néven fog menni.
Levelezőszerver beállítása
Az NGINX proxy és a levelezőszerver közötti adatcsere tiszta. A kivételhez hozzá kell adni a PLAIN mechanizmussal történő hitelesítés lehetőségét. Például a galambtartó konfigurálásához tegye a következőket:
vi /etc/dovecot/conf.d/10-auth.conf
Sorok hozzáadása:
távoli 192.168.1.11 (
disable_plaintext_auth = nem
}
* Ebben a példában engedélyeztük a kiszolgálóról érkező PLAIN hitelesítési kéréseket 192.168.1.11 .
Ellenőrizzük továbbá:
* ha ssl számítani fog kívánt, az ellenőrzés nem fog működni, mivel kiderült, hogy egyrészt a szerver engedélyezi a kéréseket tisztán, de ssl titkosítást igényel.
Indítsa újra a Dovecot szolgáltatást:
systemctl indítsa újra a dovecotot
Kliens beállítása
Folytathatja a proxybeállítások ellenőrzését. Ehhez a kliens beállításaiban adja meg az nginx szerver címét vagy nevét IMAP/POP2/SMTP formában, például:
* ebben a példában a levelezőkliens úgy van beállítva, hogy csatlakozzon a szerverhez 192.168.1.11 nyitott portokon keresztül 143 (IMAP) és 25 (SMTP).
Titkosítás
Most állítsunk be egy SSL kapcsolatot. Az Nginx-et egy modullal kell megépíteni mail_ssl_module- ellenőrizze a következő paranccsal:
A szükséges modul hiányában újraépítjük az nginx-et.
A konfigurációs fájlunk szerkesztése után:
vi /etc/nginx/nginx.conf
posta (
szerver_neve mail.domain.local;
auth_http localhost/auth.php;
proxy_pass_error_message on;
SSL bekapcsolva;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache megosztott:SSL:10m;
ssl_session_timeout 10m;
Szerver(
figyelj 110;
protokoll pop3;
pop3_auth sima apop cram-md5;
}
Szerver(
figyelj 143;
protokollmap;
}
Ok: A SELinux biztonsági rendszer működésbe lép.
Megoldás: tiltsa le vagy konfigurálja a SELinuxot.
