Server email Nginx. Menyiapkan NGINX untuk proksi email

Tanda-tanda kehamilan setelah implantasi embrio

Artikel ini akan menjelaskan cara mengonfigurasi NGINX Plus atau NGINX Open Source sebagai proxy untuk server email atau layanan email eksternal.

Perkenalan

NGINX dapat melakukan proxy protokol IMAP, POP3 dan SMTP ke salah satu server email upstream yang menghosting akun email dan dengan demikian dapat digunakan sebagai titik akhir tunggal untuk klien email. Hal ini dapat memberikan beberapa manfaat, seperti:

  • penskalaan jumlah server email yang mudah
  • memilih server email berdasarkan aturan yang berbeda, misalnya memilih server terdekat berdasarkan alamat IP klien
  • mendistribusikan beban di antara server email
Prasyarat

    NGINX Plus (sudah menyertakan modul Mail yang diperlukan untuk mem-proxy lalu lintas email) atau NGINX Open Source mengkompilasi modul Mail menggunakan parameter --with-mail untuk fungsionalitas proxy email dan parameter --with-mail_ssl_module untuk dukungan SSL/TLS:

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

    Server email IMAP, POP3 dan/atau SMTP atau layanan email eksternal

Mengonfigurasi Server Proksi Email SMTP/IMAP/POP3

Dalam file konfigurasi NGINX:

surat ( #... )

surat (nama_server mail.example.com; #...)

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

Alternatifnya, tentukan apakah akan memberi tahu pengguna tentang kesalahan dari server autentikasi dengan menentukan direktif proxy_pass_error_message. Ini mungkin berguna ketika kotak surat kehabisan memori:

surat (nama_server mail.example.com; auth_http localhost: 9000 /cgi-bin/nginxauth.cgi; proxy_pass_error_message aktif; #...)

Konfigurasikan setiap server SMTP, IMAP, atau POP3 dengan blok server. Untuk setiap server, tentukan:

  • itu nomor pelabuhan yang sesuai dengan protokol yang ditentukan dengan arahan mendengarkan
  • itu protokol dengan arahan protokol (jika tidak ditentukan, akan secara otomatis terdeteksi dari port yang ditentukan dalam arahan mendengarkan)
  • diizinkan metode otentikasi dengan arahan imap_auth , pop3_auth , dan smtp_auth :

server (dengarkan 25; protokol smtp; smtp_auth login plain cram-md5;) server (dengarkan 110; protokol pop3; pop3_auth polos apop cram-md5;) server (dengarkan 143; protokol imap;)

Menyiapkan Otentikasi untuk Proksi Email

Setiap permintaan POP3/IMAP/SMTP dari klien akan diautentikasi terlebih dahulu pada server autentikasi HTTP eksternal atau dengan skrip autentikasi. Memiliki server otentikasi adalah wajib untuk proxy server email NGINX. Server dapat dibuat sendiri sesuai dengan protokol otentikasi NGINX yang berbasis pada protokol HTTP.

Jika autentikasi berhasil, server autentikasi akan memilih server upstream dan mengalihkan permintaan. Dalam hal ini, respons dari server akan berisi baris berikut:

HTTP/1.0 200 OK Auth-Status: OK Auth-Server: # nama server atau alamat IP server upstream yang akan digunakan untuk pemrosesan email Auth-Port: # port server upstream

Jika otentikasi gagal, server otentikasi akan mengembalikan pesan kesalahan. Dalam hal ini, respons dari server akan berisi baris berikut:

HTTP/1.0 200 OK Auth-Status: # pesan kesalahan yang harus dikembalikan ke klien, misalnya “Login atau kata sandi tidak valid” Auth-Wait: # jumlah upaya otentikasi yang tersisa hingga koneksi ditutup

Perhatikan bahwa dalam kedua kasus, responsnya akan berisi HTTP/1.0 200 Oke yang mungkin membingungkan.

Untuk contoh lebih lanjut permintaan dan respons dari server autentikasi, lihat ngx_mail_auth_http_module dalam dokumentasi Referensi NGINX.

Menyiapkan SSL/TLS untuk Proksi Email

Dengan menggunakan POP3/SMTP/IMAP melalui SSL/TLS Anda memastikan bahwa data yang dikirimkan antara klien dan server email aman.

Untuk mengaktifkan SSL/TLS untuk proksi email:

Pastikan NGINX Anda dikonfigurasi dengan dukungan SSL/TLS dengan mengetikkan perintah nginx -V di baris perintah dan kemudian mencari baris with --mail_ssl_module di output:

$ nginx -V konfigurasikan argumen: ... dengan--mail_ssl_module

Pastikan Anda telah memperoleh sertifikat server dan kunci pribadi dan meletakkannya di server. Sertifikat dapat diperoleh dari otoritas sertifikat (CA) tepercaya atau dibuat menggunakan pustaka SSL seperti OpenSSL.

sl aktif;

mulai menyala;

Tambahkan sertifikat SSL: tentukan jalur ke sertifikat (yang harus dalam format PEM) dengan direktif ssl_certificate, dan tentukan jalur ke kunci pribadi di direktif ssl_certificate_key:

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

Anda hanya dapat menggunakan versi dan sandi SSL/TLS yang kuat dengan arahan ssl_protocols dan ssl_ciphers, atau Anda dapat mengatur protokol dan sandi pilihan Anda sendiri:

surat ( #... ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ; ssl_ciphers TINGGI:!aNULL:!MD5 ; )

Mengoptimalkan SSL/TLS untuk Proksi Email

Petunjuk berikut akan membantu Anda membuat proxy email NGINX Anda lebih cepat dan aman:

Tetapkan jumlah proses pekerja sama dengan jumlah prosesor dengan direktifworker_processes yang disetel pada tingkat yang sama dengan konteks email:

pekerja_proses otomatis; surat ( #... )

Aktifkan cache sesi bersama dan nonaktifkan cache sesi bawaan dengan auto ; mail ( nama_server mail.example.com ; auth_http localhost : 9000 /cgi-bin/nginxauth.cgi ; proxy_pass_error_message aktif ; ssl aktif ; ssl_certificate /etc/ssl/certs/server.crt ; ssl_certificate_key /etc/ssl/certs/server. kunci; ssl_protocols TLSv1 TLSv1.2; ssl_ciphers TINGGI:!aNULL:!MD5; 10 ; ; pop3_auth polos apop cram-md5) server (dengarkan 143; protokol imap;))

Dalam contoh ini, ada tiga server proxy email: SMTP, POP3 dan IMAP. Masing-masing server dikonfigurasi dengan dukungan SSL dan STARTTLS. Parameter sesi SSL akan di-cache.

Server proxy menggunakan server otentikasi HTTP – konfigurasinya berada di luar cakupan artikel ini. Semua pesan kesalahan dari server akan dikembalikan ke klien.

iRedMail adalah perakitan siap server email dengan terbuka Kode sumber. Perakitan didasarkan pada server SMTP Postfix (Mail Transfer Agent, disingkat MTA). Perakitannya juga mencakup: Dovecot, SpamAssassin, Greylist, ClamAV, SOGo Roundcube, NetData, dan NGINX.

Tempat perlindungan merpati - server IMAP/POP3.

Spamassassin adalah alat pemfilteran spam.

Greylist adalah alat anti-spam berbasis greylist.

ClamAV adalah sebuah antivirus.

Roundcube dan SOGo adalah klien web untuk bekerja dengan email.

NetData adalah program pemantauan server waktu nyata.

Nginx adalah server web.

Mendukung sistem operasi: CentOS 7, Debian 9, Ubuntu 16.04/18.04, FreeBSD 11/12 dan OpenBSD 6.4.

iRedMail memiliki versi berbayar dan gratis, yang berbeda satu sama lain dalam fungsi antarmuka webnya sendiri dari kumpulan email iRedAdmin. DI DALAM versi gratis Anda hanya dapat membuat kotak surat domain, pengguna dan administrator. Jika Anda perlu membuat alias, Anda tidak dapat lagi melakukannya dalam versi gratis melalui iRedAdmin. Untungnya, ada solusi gratis bernama PostfixAdmin yang memungkinkan Anda melakukan hal ini. PostfixAdmin mudah diintegrasikan ke dalam iRedMail dan berfungsi baik dengannya.

Instalasi

Untuk menginstal, kita memerlukan salah satu sistem operasi yang tercantum di atas. Saya akan menggunakan Ubuntu Server 18.04. Anda juga pasti sudah membeli Nama domain dan zona DNS yang dikonfigurasi. Jika Anda menggunakan server DNS pencatat domain Anda, maka Anda perlu membuat dua entri di bagian manajemen zona domain: A dan MX. Anda juga dapat menggunakan DNS Anda sendiri dengan mengatur delegasi akun pribadi pendaftar nama domain Anda.

Menyiapkan zona domain saat menggunakan registrar DNS

Catatan! Waktu masuk Pengaturan DNS berlangsung dari beberapa jam hingga satu minggu. Hingga pengaturan diterapkan, server email tidak akan berfungsi dengan benar.

Untuk menginstal, unduh dari situs web iRedMail versi sekarang. Saat ini 0.9.9.

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

Kemudian buka paket arsip yang diunduh.

# tar xjf iRedMail-0.9.9.tar.bz2

Membongkar arsip

Dan buka folder yang dibuat.

# cd iRedMail-0.9.9

folder pemasang iRedMail

Memeriksa isi folder

Isi Folder

Dan jalankan skrip instalasi iRedMail.

# pesta iRedMail.sh

Instalasi sistem email akan dimulai. Selama proses instalasi Anda perlu menjawab sejumlah pertanyaan. Kami setuju untuk memulai instalasi.

Mulai instalasi

Memilih direktori instalasi

Sekarang Anda perlu memilih server web. Tidak banyak pilihan, jadi kami memilih NGINX.

Memilih Server Web

Sekarang Anda perlu memilih server database yang akan diinstal dan dikonfigurasi untuk bekerja dengan sistem email. Pilih MariaDB.

Memilih Server Basis Data

Tetapkan kata sandi root untuk database.

Membuat kata sandi root basis data

Sekarang kami menunjukkan domain email kami.

Membuat domain email

Kemudian kami membuat kata sandi untuk kotak surat administrator [email protected].

Membuat kata sandi administrator email

Memilih Komponen Web

Konfirmasikan pengaturan yang ditentukan.

Mengonfirmasi pengaturan

Instalasi telah dimulai.

Instalasi

Setelah penginstalan selesai, konfirmasikan pembuatan aturan iptables untuk SSH dan mulai ulang firewall. iRedMail bekerja dengan iptables. Di Ubuntu, utilitas manajemen firewall yang paling umum digunakan adalah UFW. Jika karena satu dan lain hal Anda memerlukannya, maka instal UFW (apt install ufw) dan tambahkan aturan agar UFW (contoh: ufw izinkan "Nginx Full" atau ufw izinkan Postfix) tidak memblokir pekerjaan server email. Anda dapat melihat daftar aturan yang tersedia dengan menjalankan perintah: ufw app list . Kemudian aktifkan UFW: aktifkan ufw.

Membuat aturan iptables

Memulai ulang firewall

Ini menyelesaikan instalasi iRedMail. Sistem memberi kami alamat antarmuka web dan kredensial login. Untuk mengaktifkan semua komponen sistem email, Anda harus me-reboot server.

Menyelesaikan instalasi

Mari kita reboot.

# menyalakan ulang

Pengaturan

Pertama, Anda perlu memastikan semuanya berfungsi. Mari kita coba login ke control panel iReadAdmin di https://domain/iredadmin. Login [email protected], kata sandi dibuat saat instalasi. Ada antarmuka berbahasa Rusia.

Seperti yang Anda lihat, semuanya berfungsi. Saat masuk ke iRedAdmin, kemungkinan besar Anda menerima kesalahan keamanan terkait sertifikat. Hal ini terjadi karena iRedMail memiliki sertifikat yang ditandatangani sendiri, yang dikeluhkan oleh browser. Untuk mengatasi masalah ini, Anda harus memasang sertifikat SSL yang valid. Jika Anda sudah membeli, Anda dapat menginstalnya. Pada contoh saya akan menginstall SSL gratis dari Let's Encrypt.

Memasang sertifikat SSL Let's Encrypt

Kami akan menginstal sertifikat menggunakan utilitas certbot. Pertama, mari tambahkan repositori.

# tambahkan-apt-repositori ppa:certbot/certbot

Kemudian kita akan menginstal certboot sendiri dengan komponen yang diperlukan.

# tepat instal python-certbot-nginx

Kami menerima sertifikat.

# certbot --nginx -d domain.ru

Setelah menjalankan perintah, sistem akan meminta Anda memasukkan alamat email, enter. Setelah itu kemungkinan besar Anda akan menerima pesan kesalahan bahwa tidak mungkin menemukan blok server tempat sertifikat dibuat. Dalam hal ini, ini normal karena kami tidak memiliki blok server apa pun. Yang utama bagi kami adalah mendapatkan sertifikat.

Memperoleh sertifikat

Seperti yang bisa kita lihat, sertifikat berhasil diterima dan sistem menunjukkan kepada kita jalur menuju sertifikat itu sendiri dan ke kuncinya. Merekalah yang kita butuhkan. Secara umum, kami menerima 4 file yang akan disimpan di folder "/etc/letsencrypt/live/domain". Sekarang kita perlu memberi tahu server web tentang sertifikat kita, yaitu mengganti sertifikat yang disematkan dengan yang baru saja kita terima. Untuk melakukan ini, kita perlu mengedit satu file saja.

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

Dan kami mengubah dua baris terakhir di dalamnya.

Mengganti sertifikat SSL

Kami mengubah jalur dalam file ke jalur yang diberitahukan sistem kepada kami saat menerima sertifikat.

Mengganti sertifikat SSL

Dan mulai ulang NGINX.

# layanan nginx dimulai ulang

Sekarang mari kita coba masuk ke iRedAdmin lagi.

Memverifikasi sertifikat SSL

Tidak ada lagi kesalahan sertifikat. Sertifikat itu sah. Anda dapat mengklik kunci tersebut dan melihat propertinya. Ketika sertifikat habis masa berlakunya, certboot akan memperbaruinya secara otomatis.

Sekarang kami akan melaporkan tentang sertifikat Dovecot dan Postfix. Untuk melakukan ini, kita akan mengedit dua file konfigurasi. Kami melakukan:

# nano /etc/dovecot/dovecot.conf

Menemukan blok:

#SSL: Pengaturan global.

Dan kami mengubah sertifikat yang terdaftar di sana menjadi milik kami.

Sertifikat pengganti Dovecot

Perhatikan juga baris "ssl_protocols". Nilainya harus "!SSLv3", jika tidak, Anda akan menerima kesalahan "Peringatan: SSLv2 tidak didukung oleh OpenSSL. Harap pertimbangkan untuk menghapusnya dari ssl_protocols" saat memulai ulang Dovecot.

# nano /etc/postfix/main.cf

Menemukan blok:

# Kunci SSL, sertifikat, CA

Dan kami mengubah jalur di dalamnya dengan jalur ke file sertifikat kami.

Mengganti sertifikat untuk Postfix

Ini menyelesaikan instalasi sertifikat. Dovecot dan Postfix perlu di-restart, tetapi lebih baik me-reboot server.

# layanan tempat perlindungan merpati dimulai ulang

# menyalakan ulang

Menginstal PHPMyAdmin

Langkah ini opsional, tetapi saya sarankan melakukannya dan menginstal PHPMyAdmin untuk kemudahan bekerja dengan database.

# tepat instal phpmyadmin

Penginstal akan menanyakan server web mana yang akan digunakan untuk mengonfigurasi PHPMyAdmin, karena NGINX tidak ada dalam daftar ini, cukup tekan TAB dan lanjutkan.

Menginstal PHPMyAdmin

Setelah instalasi selesai, agar phpmyadmin berfungsi, Anda perlu membuat symlink ke direktori tempat NGINX bekerja secara default.

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

Dan kita coba masuk ke https://domain/phpmyadmin/

PHPMyAdmin sedang berjalan. Koneksi dilindungi sertifikat, tidak ada kesalahan. Teruskan. Mari kita buat administrator basis data MySQL (MariaDB).

#mysql

Dan kita masuk ke konsol manajemen MariaDB. Selanjutnya, kita jalankan perintah satu per satu:

MariaDB > BUAT PENGGUNA "admin"@"localhost" DIIDENTIFIKASI DENGAN "kata sandi";
MariaDB > BERIKAN SEMUA HAK ISTIMEWA DI *.* KEPADA "admin"@"localhost" DENGAN OPSI GRANT;
MariaDB > HAK ISTIMEWA;

Membuat Pengguna MySQL

Semuanya OK, login selesai. PHPMyAdmin siap digunakan.

Menginstal PostfixAdmin

Pada prinsipnya PostfixAdmin, seperti halnya PHPMyAdmin, tidak perlu diinstal. Server email akan berfungsi dengan baik tanpa komponen ini. Namun Anda tidak akan bisa membuat alias email. Jika Anda tidak membutuhkannya, Anda dapat melewati bagian ini dengan aman. Jika Anda masih memerlukan alias, Anda memiliki dua opsi: membeli iReaAdmin versi berbayar atau menginstal PostfixAdmin. Tentu saja, Anda dapat melakukan ini tanpa perangkat lunak tambahan, dengan mendaftarkan alias di database secara manual, namun hal ini tidak selalu nyaman dan tidak cocok untuk semua orang. Saya sarankan menggunakan PostfixAdmin, kita akan melihat instalasi dan integrasinya dengan iRedMail sekarang. Mari kita mulai instalasinya:

# tepat instal postfixadmin

Kami menyetujui dan membuat kata sandi untuk database sistem program.

Menginstal PostfixAdmin

Menginstal PostfixAdmin

Kita membuat symlink dengan cara yang sama seperti menginstal PHPMyAdmin.

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

Kami menjadikan pengguna yang atas nama server web diluncurkan sebagai pemilik direktori. Dalam kasus kami, NGINX diluncurkan sebagai pengguna data-www.

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

Sekarang kita perlu mengedit file konfigurasi PostfixAdmin dan menambahkan informasi tentang database yang digunakan iRedAdmin. Secara default database ini disebut vmail. Jika Anda pergi ke PHPMyAdmin Anda dapat melihatnya di sana. Jadi agar PostfixAdmin dapat melakukan perubahan pada database, kita mendaftarkannya pada konfigurasi PostfixAdmin.

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

Kami menemukan garis:

$CONF["database_type"] = $dbtipe;
$CONF["database_host"] = $dbserver;
$CONF["database_user"] = $dbuser;
$CONF["database_password"] = $dbpass;
$CONF["nama_database"] = $namadb;

Dan mari kita ingat:

$CONF["database_type"] = "mysqli"; # Tipe basis data
$CONF["database_host"] = "host lokal"; # Host server basis data
$CONF["database_user"] = "admin"; # Login dengan hak untuk menulis ke database vmail. Anda dapat menggunakan admin yang dibuat sebelumnya
$CONF["database_password"] = "kata sandi"; # Kata sandi untuk pengguna yang ditentukan di atas
$CONF["nama_database"] = "vmail"; # Nama basis data iRedMail

Memasukkan informasi tentang database

Jika Anda berencana menggunakan web mail client SOGo, maka Anda perlu melakukan satu langkah tambahan lagi yaitu mengubah enkripsi PostfixAdmin pada item $CONF["encrypt"] dari "md5crypt" menjadi "dovecot:SHA512-CRYPT" . Jika Anda tidak melakukan ini, maka ketika Anda mencoba masuk ke SOGo sebagai pengguna yang dibuat di PostfixAdmin, Anda akan menerima kesalahan: login atau kata sandi salah.

Mengubah jenis enkripsi

Sekarang, agar berhasil menyelesaikan instalasi dan tidak menerima kesalahan, Anda harus menjalankan query ke database. Lebih mudah untuk melakukan ini melalui PHPMyAdmin. Pilih database vmail dan buka tab SQL. Di jendela kita masuk:

DROP INDEX domain di kotak surat;
DROP INDEX domain dengan alias;
ALTER TABLE alias TAMBAHKAN KOLOM `goto` teks BUKAN NULL;

Kueri Basis Data

Dan klik "Teruskan". Sekarang kita semua sudah siap, kita bisa masuk ke antarmuka web PostfixAdmin dan menyelesaikan instalasi. Untuk melakukan ini, Anda perlu mengetik di browser Anda: https://domain/postfixadmin/setup.php.

Berikut ini akan muncul:

Menginstal PostfixAdmin

Jika semuanya dilakukan sesuai petunjuk, maka seharusnya tidak ada kesalahan. Jika ada, maka harus dihilangkan, jika tidak, sistem tidak akan mengizinkan Anda untuk melanjutkan. Tetapkan kata sandi instalasi dan klik "Buat hash kata sandi". Sistem akan menghasilkan hash kata sandi, yang harus dimasukkan ke dalam parameter $CONF["setup_password"] .

Menyelesaikan instalasi PostfixAdmin

Mengubah pengaturan file konfigurasi

Sekarang masukkan kata sandi yang baru dibuat dan buat administrator PostfixAdmin. Lebih baik tidak membuat administrator dengan login postmaster, karena mungkin ada masalah saat masuk ke panel administrasi iRedAdmin.

Membuat Administrator PostfixAdmin

Itu saja, administrator telah dibuat. Anda dapat masuk.

Harap dicatat bahwa dari sudut pandang keamanan, lebih baik mengganti nama atau menghapus file setup.php di direktori postfixadmin.

Buka: https://domain/postfixadmin/ dan masukkan kredensial yang baru dibuat. Di PostfixAdmin, serta di iRedAdmin, bahasa Rusia tersedia. Anda dapat memilihnya selama otorisasi.

Kami mencoba membuat kotak surat pengguna.

Mengaktifkan/Menonaktifkan modul iRedMail

iRedAPD bertanggung jawab untuk mengelola modul iRedMail. Ini memiliki file konfigurasi tempat modul kerja didaftarkan. Jika Anda tidak memerlukan modul tertentu, Anda dapat menghapusnya dari file konfigurasi dan modul tersebut akan berhenti berfungsi. Kami melakukan:

# nano /opt/iredapd/settings.py

Temukan baris "plugin" dan hapus komponen yang tidak Anda perlukan darinya. Saya akan menghapus komponen "daftar abu-abu". Tentu saja, ini melindungi terhadap spam dengan cukup efektif, tetapi surat-surat yang diperlukan sering kali tidak sampai.

Greylist adalah teknologi perlindungan spam otomatis berdasarkan analisis perilaku server pengirim email. Ketika "daftar abu-abu" diaktifkan, server menolak menerima surat dari alamat yang tidak diketahui untuk pertama kalinya, melaporkan kesalahan sementara. Dalam hal ini, server pengirim harus mengulangi pengirimannya nanti. Program spammer biasanya tidak melakukan hal ini. Jika surat itu dikirim kembali, maka surat itu ditambahkan ke dalam daftar selama 30 hari dan pertukaran surat terjadi untuk pertama kalinya. Putuskan sendiri apakah akan menggunakan modul ini atau tidak.

Mengaktifkan/Menonaktifkan modul email

Setelah melakukan perubahan, Anda harus me-restart iRedAPD.

# layanan iredapd restart

Menguji server email

Ini menyelesaikan konfigurasi server email iRedMail. Anda dapat melanjutkan ke tahap akhir - pengujian. Mari kita buat dua kotak surat. Untuk memeriksanya melalui iRedAdmin, yang kedua melalui PostfixAdmin dan mengirim surat dari satu kotak surat ke kotak surat lainnya dan sebaliknya. Di iRedAdmin kita akan membuat kotak surat [email protected]. Di PostfixAdmin - [email protected]

Membuat pengguna di iRedAdmin

Membuat pengguna di PostfixAdmin

Kami memeriksa apakah pengguna telah dibuat.

Jika Anda memperhatikan kolom “Kepada” dalam daftar kotak surat PostfixAdmin, Anda akan melihat perbedaan antara kotak surat yang dibuat di iRedAdmin dan PostfixAdmin. Kotak surat yang dibuat di iRedAdmin ditandai sebagai "Hanya penerusan", dan kotak surat yang dibuat di PostfixAdmin ditandai sebagai "Kotak Surat". Pada awalnya saya tidak dapat memahami untuk waktu yang lama mengapa hal ini terjadi dan apa perbedaan di antara keduanya, dan akhirnya saya menyadari satu hal. Kotak pesan di iRedAdmin dibuat tanpa alias, dan kotak pesan di PostfixAdmin dibuat dengan alias sendiri.

Dan jika alias ini dihapus, maka kotak surat akan ditampilkan seperti yang dibuat di iRedAdmin "Hanya penerusan".

Menghapus alias

Alias ​​telah dihapus. Memeriksa Admin Postfix.

Seperti yang Anda lihat, semua kotak telah menjadi “Forward only”. Dengan cara yang sama, jika Anda membuat alias untuk diri Anda sendiri di kotak surat yang dibuat di iRedAdmin, itu akan menjadi “Kotak Surat”. Pada prinsipnya, hal ini tidak mempengaruhi kinerja email dengan cara apapun. Satu-satunya hal adalah Anda tidak akan dapat membuat alias pada kotak surat yang dibuat di PostfixAdmin. Daripada membuat alias, Anda perlu mengedit alias yang sudah ada. Berbicara tentang alias, di versi baru iRedMail perlu melakukan perubahan pada salah satu peta Postfix yang menangani alias. Dan jika Anda tidak melakukan ini, alias yang dibuat tidak akan berfungsi. Untuk melakukannya, Anda perlu memperbaiki hal berikut di file /etc/postfix/mysql/virtual_alias_maps.cf:

Kami melakukan:

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

Dan kami memperbaikinya.

Menyiapkan alias

Mulai ulang Postfix:

# layanan postfix dimulai ulang

Setelah ini semuanya akan berfungsi.

Jadi, mari mulai memeriksa email. Kami akan masuk ke kotak surat pengguna1 melalui Roundcube, dan ke kotak surat pengguna2 melalui SOGo dan mengirim surat dari kotak surat pengguna1 ke pengguna2 dan sebaliknya.

Mengirim email dengan Roundcube

Menerima surat di SOGo

Mengirim email ke SOGo

Menerima surat di Roundcube

Semuanya berfungsi tanpa masalah. Pengiriman surat memakan waktu dua hingga lima detik. Dengan cara yang sama, surat terkirim dengan sempurna ke server Yandex dan mail.ru (diuji).

Sekarang mari kita periksa aliasnya. Mari kita buat kotak surat pengguna3 dan buat alias dari kotak surat pengguna1 ke kotak surat pengguna2. Dan kami akan mengirimkan surat dari kotak surat pengguna3 ke kotak surat pengguna1. Dalam hal ini, surat tersebut harus sampai di kotak surat pengguna2.

Membuat alias

Mengirim surat dari kotak surat pengguna3 ke kotak surat pengguna1

Menerima surat di kotak surat pengguna2

Pengerjaannya alias juga oke.

Mari kita uji pengoperasian server email melalui lokal klien email. Misalnya saja Mozilla Thunderbird. Mari buat dua pengguna lagi: klien1 dan klien2. Kami akan menghubungkan satu kotak surat melalui IMAP, yang lain melalui POP3 dan mengirim surat dari satu kotak surat ke kotak surat lainnya.

koneksi IMAP

Koneksi melalui POP3

Kami mengirimkan surat dari Klien 1 ke Klien 2.

Mengirim dari Klien 1

Penerimaan pada Klien 2

Dan dalam urutan terbalik.

Mengirim dari Klien 2

Penerimaan pada Klien 1

Semuanya berfungsi.

Jika Anda pergi ke alamat: https://domain/netdata, Anda dapat melihat grafik status sistem.

Kesimpulan

Ini menyelesaikan instalasi, konfigurasi dan pengujian sistem email iRedMail. Hasilnya, kami menerima server email lengkap yang sepenuhnya gratis dengan sertifikat SSL yang valid, dua klien email web berbeda, dua panel kontrol, serta antispam dan antivirus yang terpasang di dalam email. Jika diinginkan, alih-alih klien email web, Anda dapat menggunakan klien email lokal seperti Microsoft Outlook atau Mozilla Thunderbird. Jika Anda tidak berencana menggunakan klien email web, Anda tidak dapat menginstalnya sama sekali, agar tidak membebani server, atau menginstal satu hal yang paling Anda sukai. Saya pribadi lebih menyukai SOGo karena antarmukanya dioptimalkan perangkat seluler, membuatnya sangat nyaman untuk dilihat surel dari ponsel pintar. Begitu pula dengan NetData dan iRedAdmin, jika Anda tidak berencana menggunakannya, lebih baik tidak menginstalnya. Sistem email ini tidak terlalu menuntut sumber daya. Semua ini berfungsi pada server VPS dengan 1024 MB memori akses acak dan satu prosesor virtual. Jika Anda memiliki pertanyaan tentang sistem email ini, tulis di komentar.

P.S. Saat menguji produk ini di berbagai sistem operasi dengan RAM 1 GB (Ubuntu, Debian, CentOS), ternyata 1 GB saja tidak cukup untuk membuat ClamAV berfungsi. Di hampir semua kasus, saat menggunakan memori 1 GB, antivirus menyebutkan kesalahan terkait database. Pada saat yang sama, pada sistem operasi Debian dan Ubuntu, antivirus tidak memindai email yang melewati server, jika tidak semuanya berfungsi dengan baik. Di CentOS situasinya sedikit berbeda. Layanan clamd benar-benar membuat sistem crash, sehingga membuat pengoperasian server normal menjadi tidak mungkin. Saat mencoba masuk ke antarmuka web, NGINX secara berkala menghasilkan kesalahan 502 dan 504. Surat juga dikirim setiap waktu. Apalagi jika kita menambahkan RAM hingga 2 GB, maka dalam semua kasus tidak ada masalah dengan pengoperasian antivirus dan server secara keseluruhan. ClamAV memindai email yang melewati server email, yang ditulisnya di log. Saat mencoba mengirim virus sebagai lampiran, pengirimannya diblokir. Konsumsi memori sekitar 1,2 - 1,7 GB.

Nginx adalah server web dan server proxy email yang kecil, sangat cepat, dan cukup fungsional, yang dikembangkan oleh Igor Sysoev (rambler.ru). Karena konsumsi sumber daya sistem dan kecepatan operasi yang sangat rendah, serta fleksibilitas konfigurasi, web Server Nginx sering digunakan sebagai frontend ke server kelas berat, seperti apache, dalam proyek beban tinggi. Opsi klasiknya adalah kombinasi, Nginx - Apache - FastCGI. Bekerja dalam skema seperti itu, Server Nginx, menerima semua permintaan yang datang melalui HTTP, dan bergantung pada konfigurasi dan permintaan itu sendiri, memutuskan apakah akan memproses permintaan itu sendiri dan memberikan respons siap pakai kepada klien atau mengirim permintaan untuk diproses ke salah satu backend ( apache atau FastCGI).

Seperti yang Anda ketahui, server Apache memproses setiap permintaan dalam proses (utas) terpisah, yang harus dikatakan, menghabiskan sumber daya sistem dalam jumlah yang cukup kecil, jika ada 10-20 proses seperti itu, itu tidak masuk akal, dan jika ada 100-500 atau lebih, sistem menjadi tidak menyenangkan.

Mari kita coba bayangkan situasi serupa. Misalkan saja apache datang 300 Permintaan HTTP dari klien, 150 klien menggunakan jalur sewa cepat, dan 150 lainnya menggunakan saluran Internet yang relatif lambat, meskipun tidak menggunakan modem. Apa yang terjadi dalam situasi ini? Dan hal berikut terjadi: server web Apache, untuk memproses 300 koneksi ini, membuat proses (utas) untuk masing-masing koneksi, itu akan menghasilkan konten dengan cepat, dan 150 klien cepat akan segera mengambil hasil permintaan mereka, proses yang melayani mereka akan dimatikan dan sumber daya akan dilepaskan, dan 150 lambat, dan akan menerima hasil permintaan mereka dengan lambat, karena saluran Internet yang sempit, akibatnya 150 proses akan hang di sistem apache, menunggu klien mengambil konten yang dihasilkan oleh server web, menghabiskan banyak sumber daya sistem. Tentu saja, situasinya hanya hipotetis, tetapi menurut saya esensinya jelas. Bundel ini membantu memperbaiki situasi yang dijelaskan di atas. Setelah membaca seluruh permintaan dari klien, dia mengirimkannya untuk diproses apache, yang pada gilirannya menghasilkan konten dan mengembalikan respons siap pakai ke Nginx secepat mungkin, setelah itu dapat menghentikan proses dengan hati nurani yang bersih dan membebaskan sumber daya sistem yang digunakannya. Server web Nginx, menerima hasil permintaan dari apache, menulisnya ke buffer atau bahkan ke file di disk dan dapat memberikannya kepada klien yang lambat selama yang diinginkan, sementara proses kerjanya menghabiskan begitu sedikit sumber daya sehingga .. “bahkan lucu untuk membicarakannya” ©. :) Skema ini secara signifikan menghemat sumber daya sistem, saya ulangi, tetapi proses pekerja Nginx mengkonsumsi sejumlah kecil sumber daya, hal ini terutama berlaku untuk proyek-proyek besar.

Dan ini hanya sebagian kecil dari apa yang dapat dilakukan server Nginx; jangan lupakan kemampuan cache data dan cara kerjanya memcache. Saya akan memberikan daftar yang utama Kegunaan Server web Nginx.

Fungsionalitas server Nginx sebagai server HTTP
  • Perlakuan konten statis, file indeks, daftar direktori, cache deskriptor file terbuka;
  • Proksi yang dipercepat dengan caching, distribusi beban, dan toleransi kesalahan;
  • Dukungan yang dipercepat FastCGI server dengan caching, distribusi beban dan toleransi kesalahan;
  • Struktur modular, dukungan untuk berbagai filter (SSI, XSLT, GZIP, resume, respons terpotong);
  • Dukungan untuk ekstensi SSL dan TLS SNI;
  • berbasis IP atau Berdasarkan nama server virtual;
  • Bekerja dengan KeepAlive dan koneksi pipa;
  • Kemampuan untuk mengonfigurasi batas waktu apa pun serta jumlah dan ukuran buffer, pada levelnya server apache;
  • Melakukan berbagai tindakan tergantung pada alamat klien;
  • Mengubah URI menggunakan ekspresi reguler;
  • Halaman kesalahan khusus untuk 4xx dan 5xx;
  • Membatasi akses berdasarkan alamat klien atau kata sandi;
  • Menyiapkan format file log, memutar log;
  • Membatasi kecepatan respon terhadap klien;
  • Membatasi jumlah koneksi dan permintaan secara simultan;
  • Mendukung metode PUT, DELETE, MKCOL, COPY dan MOVE;
  • Mengubah pengaturan dan memperbarui server tanpa menghentikan pekerjaan;
  • Bawaan Perl;
Fungsionalitas server Nginx sebagai server proxy email
  • Meneruskan ke backend IMAP/POP3 menggunakan server otentikasi HTTP eksternal;
  • Memeriksa SMTP pengguna di eksternal server HTTP otentikasi dan penerusan ke server SMTP internal;
  • Mendukung metode otentikasi berikut:
    • POP3 - PENGGUNA/PASS, APOP, LOGIN AUTH/PLAIN/CRAM-MD5;
    • IMAP - LOGIN, LOGIN AUTH/POLOS/CRAM-MD5;
    • SMTP - LOGI AUTH/ POLOS/CRAM-MD5;
  • dukungan SSL;
  • dukungan STARTTLS dan STLS;
Sistem operasi dan platform yang didukung oleh server web Nginx
  • FreeBSD, dari 3 hingga 8 - platform, i386 dan amd64;
  • Linux, dari 2.2 hingga 2.6 - platform i386; Linux 2.6 - amd64;
  • Solaris 9 - platform i386 dan sun4u; Solaris 10 - platform i386, amd64 dan sun4v;
  • platform MacOS X ppc, i386;
  • Windows XP, Server Windows 2003; (saat ini dalam pengujian beta)
Arsitektur dan skalabilitas server Nginx
  • Proses utama (master), beberapa proses pekerja (dikonfigurasi dalam file konfigurasi) yang berjalan di bawah pengguna yang tidak memiliki hak istimewa;
  • Dukungan untuk metode pemrosesan koneksi berikut:
    • pilih adalah metode standar. Modul Nginx yang sesuai dibuat secara otomatis jika tidak ada metode yang lebih efisien ditemukan pada platform tertentu. Anda dapat memaksa pembangunan modul tertentu untuk diaktifkan atau dinonaktifkan menggunakan opsi konfigurasi --with-select_module atau --without-select_module.
    • jajak pendapat adalah metode standar. Modul Nginx yang sesuai dibuat secara otomatis jika tidak ada metode yang lebih efisien ditemukan pada platform tertentu. Anda dapat memaksa pembangunan modul tertentu untuk diaktifkan atau dinonaktifkan menggunakan opsi konfigurasi --with-poll_module atau --without-poll_module.
    • antrian - metode yang efektif, digunakan pada sistem operasi FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 dan MacOS X. Jika digunakan pada mesin prosesor ganda yang menjalankan MacOS X, hal ini dapat menyebabkan kepanikan kernel.
    • epoll adalah metode efisien yang digunakan di Linux 2.6+. Beberapa distribusi, seperti SuSE 8.2, memiliki patch untuk mendukung epoll di kernel 2.4.
    • rtsig - sinyal waktu nyata, metode efisien yang digunakan di Linux 2.2.19+. Secara default, tidak boleh ada lebih dari 1024 sinyal dalam antrian untuk keseluruhan sistem. Ini tidak cukup untuk server dengan beban tinggi; ukuran antrian perlu ditingkatkan menggunakan parameter kernel /proc/sys/kernel/rtsig-max. Namun, pada Linux 2.6.6-mm2, opsi ini tidak lagi tersedia, melainkan setiap proses memiliki antrian sinyal terpisah, yang ukurannya ditentukan menggunakan RLIMIT_SIGPENDING.
    • Ketika antrian sudah penuh, server nginx meresetnya dan memproses koneksi menggunakan metode polling hingga situasi kembali normal.
    • /dev/poll adalah metode yang efektif, didukung pada sistem operasi Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ dan Tru64 UNIX 5.1A+.
    • eventport - port event, metode efektif yang digunakan di Solaris 10. Sebelum menggunakan, Anda perlu menginstal patch untuk menghindari kepanikan kernel.
  • Menggunakan kemampuan metode kqueue seperti EV_CLEAR, EV_DISABLE (untuk menonaktifkan sementara suatu peristiwa), CATATAN_LOWAT, EV_EOF, jumlah data yang tersedia, kode kesalahan;
  • Bekerja dengan sendfile (FreeBSD 3.1+, Linux 2.2.+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+) dan sendfilev (Solaris 8 7/01+);
  • Dukungan untuk filter penerimaan (FreeBSD 4.1+) dan TCP_DEFER_ACCEPT (Linux 2.4+);
  • 10.000 koneksi HTTP keep-alive yang tidak aktif menghabiskan sekitar 2,5 juta memori;
  • Jumlah minimum operasi penyalinan data;

NGINX dapat digunakan tidak hanya sebagai server web atau http-proxy, tetapi juga untuk proxy email melalui protokol SMTP, IMAP, POP3. Ini memungkinkan Anda untuk mengonfigurasi:

  • Satu titik masuk untuk sistem email yang skalabel.
  • Penyeimbangan beban antara semua server email.

Pada artikel ini, instalasi dilakukan di ruang operasi. sistem Linux. Sebagai layanan email tempat permintaan dikirim, Anda dapat menggunakan postfix, exim, dovecot, exchange, iredmail assembly, dan banyak lagi.

Prinsip operasi

NGINX menerima permintaan dan mengautentikasi ke server web. Tergantung pada hasil login dan verifikasi kata sandi, proxy akan mengembalikan respons dengan beberapa header.

Jika berhasil:

Jadi, kami menentukan server dan port server email berdasarkan otentikasi. Ini memberikan banyak peluang dengan pengetahuan yang sesuai tentang bahasa pemrograman.

Jika terjadi kegagalan:

Tergantung pada hasil otentikasi dan header, klien diarahkan ke server email yang kita butuhkan.

Mempersiapkan server

Mari buat beberapa perubahan pada pengaturan keamanan server.

SELinux

Nonaktifkan SELinux jika kita menggunakan CentOS atau jika kita menggunakan sistem ini keamanan di Ubuntu:

vi /etc/selinux/config

SELINUX=dinonaktifkan

tembok api

Jika kita menggunakan firewalld (default pada CentOS):

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

firewall-cmd --muat ulang

Jika kita menggunakan iptables (default di Ubuntu):

iptables -A MASUKAN -p tcp --dport 25 -j TERIMA

iptables -A MASUKAN -p tcp --dport 110 -j TERIMA

iptables -A MASUKAN -p tcp --dport 143 -j TERIMA

apt-get install iptables-persisten

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

* V dalam contoh ini kami mengizinkan SMTP (25), POP3 (110), IMAP (143).

Menginstal NGINX

Tergantung pada sistem operasi Instalasi NGINX sedikit berbeda.

atau Linux Centos:

yum instal nginx

atau Linux Ubuntu:

tepat instal nginx

Kami mengizinkan layanan mulai otomatis dan meluncurkannya:

systemctl aktifkan nginx

systemctl mulai nginx

Jika NGINX sudah terinstal di sistem, periksa modul mana yang berfungsi:

Kami akan menerima daftar opsi yang digunakan untuk membangun server web - di antaranya kita akan melihat --with-mail . Jika modul yang diperlukan tidak ada, Anda perlu memperbarui nginx

Menyiapkan NGINX

Buka file konfigurasi nginx dan tambahkan opsi mail:

vi /etc/nginx/nginx.conf

surat (

auth_http localhost:80/auth.php;

pelayan (
dengarkan 25;
protokol smtp;
smtp_auth login biasa cram-md5;
}

pelayan (
dengarkan 110;
protokol pop3;

}

pelayan (
dengarkan 143;
peta protokol;
}
}

* Di mana:

  • server_name adalah nama server email yang akan ditampilkan di salam SMTP.
  • auth_http - server web dan URL untuk permintaan otentikasi.
  • proxy_pass_error_message - mengizinkan atau menolak menampilkan pesan jika otentikasi gagal.
  • mendengarkan - port tempat permintaan didengarkan.
  • protokol - protokol aplikasi yang mendengarkan port terkait.
  • smtp_auth - metode otentikasi yang tersedia untuk SMTP.
  • pop3_auth - metode otentikasi yang tersedia untuk POP3.

Di bagian http - server tambahkan:

pelayan (
dengarkan 80 default_server;
dengarkan [::]:80 default_server;
...

Lokasi ~ \.php$(
atur $root_path /usr/share/nginx/html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index indeks.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
sertakan fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
}
...

Mulai ulang server nginx:

systemctl restart nginx

Menginstal dan mengkonfigurasi PHP

Untuk melakukan otentikasi menggunakan PHP, Anda perlu menginstal paket berikut di sistem Anda.

Jika CentOS:

yum instal php php-fpm

Jika Ubuntu:

apt-get install php php-fpm

Luncurkan PHP-FPM:

systemctl aktifkan php-fpm

systemctl mulai php-fpm

Autentikasi

Verifikasi login dan kata sandi dilakukan oleh skrip, jalur yang ditentukan oleh opsi auth_http. Dalam contoh kita, ini adalah skrip PHP.

Contoh template resmi skrip verifikasi login dan kata sandi:

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

* skrip ini menerima login dan kata sandi apa pun dan mengalihkan permintaan ke server 192.168.1.22 dan 192.168.1.33. Untuk mengatur algoritma otentikasi, edit baris 61 - 64. Baris 73 - 77 bertanggung jawab untuk mengembalikan server tempat pengalihan dilakukan - dalam contoh ini, jika login dimulai dengan karakter "a", "c", "f ”, “g”, maka pengalihannya akan ke server mailhost01, jika tidak, ke mailhost02. Pemetaan nama server ke alamat IP dapat diatur pada baris 31, 32, jika tidak maka pemanggilan akan dilakukan menggunakan nama domain.

Menyiapkan server email

Pertukaran data antara proxy NGINX dan server email terjadi di bentuk terbuka. Penting untuk menambahkan kemungkinan otentikasi menggunakan mekanisme PLAIN ke pengecualian. Misalnya, untuk mengonfigurasi dovecot, lakukan hal berikut:

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

Tambahkan baris:

jarak jauh 192.168.1.11 (
nonaktifkan_plaintext_auth = tidak
}

* dalam contoh ini, kami mengizinkan permintaan otentikasi PLAIN dari server 192.168.1.11.

Kami juga memeriksa:

* jika ssl disetel ke wajib , pemeriksaan tidak akan berfungsi, karena ternyata di satu sisi server mengizinkan permintaan dalam teks yang jelas, tetapi memerlukan enkripsi ssl.

Mulai ulang layanan Dovecot:

systemctl restart tempat perlindungan merpati

Pengaturan klien

Anda dapat melanjutkan untuk memeriksa pengaturan proxy kami. Untuk melakukannya, di pengaturan klien, tentukan alamat atau nama server nginx sebagai IMAP/POP2/SMTP, misalnya:

* dalam contoh ini, klien email dikonfigurasi untuk terhubung ke server 192.168.1.11 melalui port terbuka 143 (IMAP) dan 25 (SMTP).

Enkripsi

Sekarang mari kita siapkan koneksi SSL. Nginx harus dibangun dengan modul mail_ssl_module - periksa dengan perintah:

Jika modul yang diperlukan tidak ada, kami membangun kembali nginx.

Kemudian kami mengedit file konfigurasi kami:

vi /etc/nginx/nginx.conf

surat (
nama_server mail.domain.lokal;
auth_http localhost/auth.php;

Proxy_pass_error_message aktif;

Lanjutkan;
ssl_certificate /etc/ssl/nginx/public.crt;
ssl_certificate_key /etc/ssl/nginx/private.key;
ssl_ciphers TINGGI:!aNULL:!MD5;
ssl_session_cache dibagikan:SSL:10m;
ssl_session_timeout 10m;

pelayan (
dengarkan 110;
protokol pop3;
pop3_auth polos apop cram-md5;
}

pelayan (
dengarkan 143;
peta protokol;
}

Alasan: Sistem keamanan SELinux terpicu.

Solusi: nonaktifkan atau konfigurasi SELinux.

Nginx dengan cepat mendapatkan popularitas, berubah dari sekadar akselerator pengiriman statis untuk Apache menjadi server web yang berfungsi penuh dan dikembangkan, yang semakin banyak digunakan secara terpisah. Pada artikel ini kita akan membahas skenario menarik dan non-standar untuk menggunakan nginx yang memungkinkan Anda memaksimalkan server web Anda.

Proksi surat

Mari kita mulai dengan yang paling jelas - dengan kemampuan nginx untuk bertindak sebagai proxy email. Fungsi ini awalnya ada di nginx, tetapi karena alasan tertentu fungsi ini sangat jarang digunakan dalam produksi; Meskipun demikian, nginx mendukung proksi protokol POP3, IMAP, dan SMTP dengan berbagai metode autentikasi, termasuk SSL dan StartTLS, dan melakukannya dengan sangat cepat.

Mengapa hal ini perlu? Setidaknya ada dua kegunaan fungsi ini. Pertama: gunakan nginx sebagai perisai terhadap spammer mengganggu yang mencoba mengirim email sampah melalui server SMTP kami. Biasanya, spammer tidak menimbulkan banyak masalah, karena mereka dengan cepat ditolak pada tahap otentikasi, namun, jika jumlahnya sangat banyak, nginx akan membantu menghemat sumber daya prosesor. Kedua: gunakan nginx untuk mengarahkan pengguna ke beberapa server email POP3/IMAP. Tentu saja, proxy email lain dapat menangani hal ini, tetapi mengapa harus menutup server jika nginx sudah diinstal di front-end untuk menyajikan konten statis melalui HTTP, misalnya?

Server proxy email di nginx tidak cukup standar. Ini menggunakan lapisan otentikasi tambahan yang diimplementasikan menggunakan HTTP, dan hanya jika pengguna melewati penghalang ini barulah dia diizinkan untuk melanjutkan lebih jauh. Fungsionalitas ini disediakan dengan membuat halaman/skrip ke mana nginx mengirimkan data pengguna, dan dia mengembalikan respons dalam bentuk OK standar atau alasan penolakan (seperti “Login atau kata sandi tidak valid”). Skrip berjalan dengan header berikut:

Data masukan skrip autentikasi HTTP_AUTH_USER: pengguna HTTP_AUTH_PASS: kata sandi HTTP_AUTH_PROTOCOL: protokol email (IMAP, POP3 atau SMTP)

Dan itu mengembalikan yang berikut:

Output skrip autentikasi HTTP_AUTH_STATUS: OK atau alasan kegagalan HTTP_AUTH_SERVER: server email asli untuk mengalihkan HTTP_AUTH_PORT: port server

Fitur luar biasa dari pendekatan ini adalah bahwa pendekatan ini tidak dapat digunakan sama sekali untuk otentikasi itu sendiri, tetapi untuk menyebarkan pengguna ke server internal yang berbeda, bergantung pada nama pengguna, data beban saat ini di server email, atau bahkan dengan mengatur penyeimbangan beban sederhana. menggunakan round-robin. Namun, jika Anda hanya perlu mentransfer pengguna ke server email internal, Anda dapat menggunakan stub yang diimplementasikan oleh nginx itu sendiri, bukan skrip sebenarnya. Misalnya, proksi SMTP dan IMAP paling sederhana di konfigurasi nginx akan terlihat seperti ini:

# vi /etc/nginx/nginx.conf mail ( # Alamat skrip otentikasi auth_http localhost:8080/auth; # Nonaktifkan perintah XCLIENT, beberapa server email tidak memahaminya xclient off; # Server server IMAP ( dengarkan 143; protokol imap; proksi aktif; ) # Server server SMTP (dengarkan 25; protokol smtp; proksi aktif; ) )

# vi /etc/nginx/nginx.conf http ( # Memetakan ke port server email yang diinginkan tergantung pada port yang dikirim dalam peta header HTTP_AUTH_PROTOCOL $http_auth_protocol $mailport ( default 25; smtp 25; imap 143; ) # Implementasi otentikasi "skrip" - selalu mengembalikan OK dan mentransfer pengguna ke server email internal, mengatur port yang diinginkan menggunakan server pemetaan di atas ( dengarkan 8080; lokasi /auth ( add_header "Auth-Status" "OK"; add_header "Auth-Server" "192.168.0.1" ; add_header "Port-Auth" $mailport kembali 200;

Ini semua. Konfigurasi ini memungkinkan Anda mengarahkan pengguna secara transparan ke server email internal, tanpa menimbulkan overhead dalam bentuk skrip yang tidak diperlukan dalam kasus ini. Dengan menggunakan skrip, konfigurasi ini dapat diperluas secara signifikan: mengonfigurasi penyeimbangan beban, memeriksa pengguna menggunakan database LDAP, dan melakukan operasi lainnya. Penulisan skrip berada di luar cakupan artikel ini, tetapi sangat mudah untuk diterapkan bahkan hanya dengan pengetahuan sekilas tentang PHP dan Python.

Streaming video

Sangat mudah untuk menyiapkan hosting video reguler berdasarkan nginx. Yang perlu Anda lakukan hanyalah mengunggah video yang ditranskode ke direktori yang dapat diakses oleh server, mendaftarkannya di konfigurasi dan mengkonfigurasi pemutar Flash atau HTML5 sehingga mengambil video dari direktori ini. Namun, jika Anda perlu mengatur siaran video berkelanjutan dari sumber eksternal atau webcam, skema ini tidak akan berfungsi, dan Anda harus menggunakan protokol streaming khusus.

Ada beberapa protokol yang dapat mengatasi masalah ini, yang paling efektif dan didukung adalah RTMP. Satu-satunya masalah adalah hampir semua implementasi server RTMP mengalami masalah. Resmi Adobe Flash Server Media berbayar. Red5 dan Wowza ditulis dalam Java, dan karenanya tidak menyediakan kinerja yang dibutuhkan, Implementasi lainnya, Erlyvideo, ditulis dalam Erlang, yang bagus untuk pengaturan cluster, tetapi tidak efektif untuk server tunggal.

Saya menyarankan pendekatan berbeda - gunakan modul RTMP untuk nginx. Ini memiliki kinerja luar biasa dan juga memungkinkan Anda menggunakan satu server untuk melayani antarmuka web situs dan streaming video. Satu-satunya masalah adalah modul ini tidak resmi, jadi Anda harus membuat sendiri nginx dengan dukungannya. Untungnya, perakitan telah dilakukan dengan cara standar:

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

Sekarang modul perlu dikonfigurasi. Ini dilakukan, seperti biasa, melalui konfigurasi nginx:

Rtmp ( # Aktifkan server siaran pada port 1935 di alamat situs/server rtmp (listen 1935; aplikasi rtmp (live on; ) ) )

Modul RTMP tidak dapat bekerja dalam konfigurasi multi-threaded, sehingga jumlah proses pekerja nginx harus dikurangi menjadi satu (nanti saya akan memberi tahu Anda cara mengatasi masalah ini):

Pekerja_proses 1;

Sekarang Anda dapat menyimpan file dan memaksa nginx membaca ulang konfigurasinya. Penyiapan nginx telah selesai, tetapi kami belum memiliki streaming videonya, jadi kami perlu membawanya ke suatu tempat. Misalnya, ini adalah file video.avi dari direktori saat ini. Untuk mengubahnya menjadi aliran dan membungkusnya di penyiar RTMP kami, kami akan menggunakan FFmpeg lama yang bagus:

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

Jika file video tidak dalam format H264, maka harus dikodekan ulang. Ini dapat dilakukan dengan cepat menggunakan FFmpeg yang sama:

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

Streaming juga dapat diambil langsung dari webcam:

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

Untuk melihat streaming di sisi klien, Anda dapat menggunakan pemutar apa pun yang mendukung RTMP, misalnya mplayer:

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

Atau sematkan pemutar langsung ke halaman web, yang dilayani oleh nginx yang sama (contoh dari dokumentasi resmi):

Pemutar web RTMP paling sederhana

jwplayer("container").setup(( mode: [( ketik: "flash", src: "/jwplayer/player.swf", config: ( bufferlength: 1, file: "stream", streamer: "rtmp:/ /localhost/rtmp", penyedia: "rtmp", ) )] ));

Hanya ada dua baris penting di sini: “file: “stream””, yang menunjukkan aliran RTMP, dan “streamer: “rtmp://localhost/rtmp””, yang menunjukkan alamat streamer RTMP. Untuk sebagian besar tugas, pengaturan ini sudah cukup. Anda dapat mengirim beberapa aliran berbeda ke satu alamat, dan nginx akan secara efektif melipatgandakannya antar klien. Namun bukan itu saja kemampuan modul RTMP. Dengan bantuannya, misalnya, Anda dapat mengatur relai aliran video dari server lain. Server FFmpeg tidak diperlukan sama sekali, cukup tambahkan baris berikut ke konfigurasi:

# vi /etc/nginx/nginx.conf aplikasi rtmp ( langsung; tarik rtmp://rtmp.example.com; )

Jika Anda perlu membuat beberapa aliran dengan kualitas berbeda, Anda dapat memanggil transcoder FFmpeg langsung dari nginx:

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

Dengan konfigurasi ini kita akan mendapatkan dua penyiar sekaligus, salah satunya akan tersedia di alamat rtmp://site/rtmp, dan yang kedua, siaran dalam kualitas 320 x 240, di alamat rtmp://site/rtmp –320x240. Selanjutnya, Anda dapat menambahkan pemutar flash dan tombol pemilihan kualitas ke situs, yang akan memberikan alamat penyiar tertentu kepada pemutar tersebut.

Dan terakhir, contoh penyiaran musik ke jaringan:

Meskipun benar; lakukan 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; Selesai

Proksi Git

Sistem kontrol versi Git mampu menyediakan akses ke repositori tidak hanya melalui protokol Git dan SSH, tetapi juga melalui HTTP. Dahulu kala, implementasi akses HTTP masih primitif dan tidak mampu menyediakan pekerjaan penuh dengan repositori. Dengan versi 1.6.6, situasinya telah berubah, dan saat ini protokol ini dapat digunakan, misalnya, untuk melewati batasan firewall di kedua sisi koneksi atau untuk membuat hosting Git Anda sendiri dengan antarmuka web.

Sayangnya, dokumentasi resmi hanya berbicara tentang mengatur akses ke Git menggunakan server web Apache, tetapi sejak implementasinya sendiri demikian aplikasi eksternal dengan antarmuka CGI standar, dapat dipasang ke hampir semua server lain, termasuk lighttpd dan, tentu saja, nginx. Ini tidak memerlukan apa pun kecuali server itu sendiri, menginstal Git dan server FastCGI kecil fcgiwrap, yang diperlukan karena nginx tidak tahu cara bekerja dengan CGI secara langsung, tetapi dapat memanggil skrip menggunakan protokol FastCGI.

Seluruh skema kerja akan terlihat seperti ini. Server fcgiwrap akan hang di latar belakang dan menunggu permintaan untuk menjalankan aplikasi CGI. Nginx, pada gilirannya, akan dikonfigurasi untuk meminta eksekusi biner CGI git-http-backend melalui antarmuka FastCGI setiap kali alamat yang kita tentukan diakses. Setelah menerima permintaan, fcgiwrap mengeksekusi git-http-backend dengan argumen CGI tertentu yang diteruskan oleh klien GIT dan mengembalikan hasilnya.

Untuk menerapkan skema seperti itu, instal fcgiwrap terlebih dahulu:

$ sudoapt-get install fcgiwrap

Tidak perlu mengkonfigurasinya; semua parameter dikirimkan melalui protokol FastCGI. Ini juga akan diluncurkan secara otomatis. Oleh karena itu, yang tersisa hanyalah mengkonfigurasi nginx. Untuk melakukan ini, buat file /etc/nginx/sites-enabled/git (jika tidak ada direktori seperti itu, Anda dapat menulis ke konfigurasi utama) dan menulis yang berikut ke dalamnya:

# vi /etc/nginx/sites-enabled/git server ( # Kami tergantung pada port 8080, dengarkan 8080; # Alamat server kami (jangan lupa menambahkan entri di DNS) server_name git.example.ru; # Log access_log /var/log/nginx /git-http-backend.access.log; error_log /var/log/nginx/git-http-backend.error.log; # Alamat utama untuk lokasi akses anonim / ( # Saat mencoba mengunduh, kirim pengguna ke alamat pribadi if ($ arg_service ~* "git-receive-pack") ( tulis ulang ^ /private$uri terakhir; ) sertakan /etc/nginx/fastcgi_params; # Alamat git-http-backend fastcgi_param SCRIPT_FILENAME kami; /usr/lib/git-core/git- http-backend; # Alamat repositori Git fastcgi_param GIT_PROJECT_ROOT /srv/git; # Alamat file fastcgi_param PATH_INFO $uri; # Alamat server fcgiwrap fastcgi_pass 127.0.0.1:9001; location ~/private(/.* )$ ( # Izin pengguna auth_basic "git anonim read-only, authenticated write"; # Otentikasi HTTP berdasarkan htpasswd auth_basic_user_file /etc/nginx/htpasswd; # Pengaturan FastCGI termasuk /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; ) )

Konfigurasi ini mengasumsikan tiga hal penting:

  • Alamat repositorinya adalah /srv/git, jadi kami menetapkan hak akses yang sesuai: $ sudo chown -R www-data:www-data /srv/git
  • Repositori itu sendiri harus terbuka untuk dibaca oleh pengguna anonim dan mengizinkan pengunggahan melalui HTTP: $ cd /srv/git $ git config core.sharedrepository true $ git config http.receivepack true
  • Otentikasi dilakukan menggunakan file htpasswd, Anda perlu membuatnya dan menambahkan pengguna ke dalamnya: $ sudo apt-get install Apache2-utils $ htpasswd -c /etc/nginx/htpasswd user1 $ htpasswd /etc/nginx/htpasswd user2 . ..

    • Itu saja, mulai ulang nginx:

    Microcache

    Mari kita bayangkan sebuah situasi dengan situs web yang dinamis dan sering diperbarui yang tiba-tiba mulai menerima beban yang sangat berat (ya, situs itu berakhir di halaman salah satu situs berita terbesar) dan tidak lagi dapat menangani pengembalian konten. Pengoptimalan yang tepat dan penerapan skema caching yang benar akan memakan waktu lama, dan masalah harus diselesaikan sekarang. Apa yang bisa kita lakukan?

    Ada beberapa cara untuk keluar dari situasi ini dengan kerugian paling sedikit, namun ide paling menarik dikemukakan oleh Fenn Bailey (fennb.com). Idenya adalah dengan meletakkan nginx di depan server dan memaksanya untuk menyimpan semua konten yang dikirimkan dalam cache, tetapi tidak hanya cache, tetapi hanya untuk satu detik. Yang menarik di sini adalah ratusan dan ribuan pengunjung situs per detik, pada kenyataannya, hanya akan menghasilkan satu permintaan ke backend, dan menerima sebagian besar halaman yang di-cache. Pada saat yang sama, hampir tidak ada orang yang akan melihat perbedaannya, karena bahkan di situs dinamis, satu detik biasanya tidak berarti apa-apa.

    Konfigurasi dengan implementasi ide ini tidak akan terlihat terlalu rumit:

    # vi /etc/nginx/sites-enabled/cache-proxy # Konfigurasi cache proxy_cache_path /var/cache/nginx level=1:2 key_zone=microcache:5m max_size=1000m; server ( dengarkan 80; nama_server example.com; # Lokasi alamat cache / ( # Cache diaktifkan secara default set $no_cache ""; # Nonaktifkan cache untuk semua metode kecuali GET dan HEAD if ($request_method !~ ^(GET|HEAD) $) ( set $no_cache "1"; ) # Jika klien mengunggah konten ke situs (no_cache = 1), kami memastikan bahwa data yang diberikan kepadanya tidak di-cache selama dua detik dan dia dapat melihat hasil unduhan if ($no_cache = "1") ( add_header Set-Cookie "_mcnc=1; Usia Maks=2; Jalur=/"; add_header X-Microcachable "0"; ) if ($http_cookie ~* "_mcnc") ( set $no_cache "1 "; ) # Mengaktifkan/menonaktifkan cache tergantung pada status variabel no_cache proxy_no_cache $no_cache; proxy_cache_bypass $no_cache; # Permintaan proxy ke server sebenarnya proxy_pass http://appserver.example.ru; ; proxy_cache_key $scheme$host$request_method$ request_uri; proxy_cache_valid 200 1s; # Perlindungan dari masalah pembaruan kawanan proxy_cache_use_stale; # Tambahkan header standar proxy_set_header Host $host; proxy_set_header X-IP Asli $remote_addr; proxy_set_header X-Diteruskan-Untuk $proxy_add_x_forwarded_for; # Kami tidak melakukan cache file yang lebih besar dari 1 MB proxy_max_temp_file_size 1M; ) )

    Tempat khusus dalam konfigurasi ini ditempati oleh baris "pembaruan proxy_cache_use_stale;", yang tanpanya kami akan menerima lonjakan beban berkala di server backend karena permintaan yang diterima selama pembaruan cache. Kalau tidak, semuanya standar dan harus jelas tanpa penjelasan yang tidak perlu.

    Membawa proxy lebih dekat ke audiens target

    Meskipun terjadi peningkatan kecepatan Internet secara global, jarak fisik server dari audiens target masih tetap berperan. Artinya, jika situs Rusia berjalan di server yang berlokasi di suatu tempat di Amerika, kecepatan aksesnya akan lebih lambat dibandingkan dari server Rusia dengan lebar saluran yang sama (tentu saja, jika Anda menutup mata terhadap semua faktor lainnya. ). Hal lainnya adalah menempatkan server di luar negeri seringkali lebih menguntungkan, termasuk dalam hal maintenance. Oleh karena itu, untuk mendapatkan keuntungan berupa tingkat pembayaran yang lebih tinggi, Anda harus menggunakan beberapa trik.

    Satu dari pilihan yang memungkinkan: menempatkan server produktif utama di Barat, dan menerapkan frontend yang tidak terlalu menuntut sumber daya dan menghasilkan listrik statis di Rusia. Ini akan memungkinkan Anda memperoleh kecepatan tanpa biaya besar. Konfigurasi nginx untuk frontend dalam hal ini akan menjadi implementasi proxy yang sederhana dan familier bagi kita semua:

    # vi /etc/nginx/sites-enabled/proxy # Simpan cache selama 30 hari dalam penyimpanan 100 GB proxy_cache_path /var/cache/nginx level=1:2 key_zone=static:32m inactive=30d max_size=100g; server ( dengarkan 80; server_name example.com; # Sebenarnya, lokasi proxy kami ~* .(jpg|jpeg|gif|png|ico|css|midi|wav|bmp|js|swf|flv|avi|djvu|mp3) $ ( # Alamat backend proxy_pass back.example.com:80; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffer_size 16k; proxy_buffers 32 16k; proxy_cache statis; proxy_cache_valid 30d; proxy_ignore_headers "Kontrol Cache" "Kedaluwarsa"; proxy_cache_key "$uri$is_args$args";

    kesimpulan

    Saat ini, dengan bantuan nginx, Anda dapat menyelesaikan banyak masalah berbeda, banyak di antaranya tidak terkait sama sekali dengan server web dan protokol HTTP. Proksi email, server streaming, dan antarmuka Git hanyalah beberapa dari tugas ini.

    Publikasi tentang topik tersebut