🥇Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind

Kyçim i këtij artikulli është si të konfiguroni një server modern të postës elektronike.
Postfix + Dovecot. SPF + DKIM + rDNS. Me IPv6.
Me enkriptim TSL. Me mbështetje për shumë domain-e — pjesa me një certificat SSL të vërtetë.
Me mbrojtje ndaj spamit dhe një shkallë të lartë mbrojtjeje nga spam te serverët e tjerë të postës.
Me mbështetje për shumë interfesa fizike.
Me OpenVPN, lidhja me të duke kaluar përmes IPv4, e cila ofron IPv6.

Nëse nuk dëshironi të studioni këto teknologji të gjitha, por dëshironi të konfiguroni një server të tillë — atëherë ky artikull është për ju.

Artikulli nuk përmban përpjekje për të shpjeguar çdo detaj. Shpjegimi shkon në atë që është konfiguruar në mënyrë jo standarde ose është e rëndësishme nga këndvështrimi i konsumatorit.

Motivimi për të konfiguruar një server të postës elektronike — ëndrra ime e gjatë. Ndoshta tingëllon e çuditshme, por IMHO, është shumë më mirë se sa të ëndërrosh për një makinë të re të markës së preferuar.

Motivimi për të konfiguruar IPv6 — janë dy. Një specialist IT duhet të studiojë teknologjitë e reja vazhdimisht për të mbijetuar. Dëshiron të japë kontributin e tij modest në luftën kundër cenzurës.

Motivimi për të konfiguruar OpenVPN — vetëm për të bërë që IPv6 të funksionojë në makinën lokale.
Motivimi për të konfiguruar disa interfesa fizike — kam një interfes në serverin tim ‘të ngadalshëm, por pa limit’, dhe një tjetër ‘të shpejtë, por me tarifë’.

Motivimi për të konfiguruar Bind — ofruesi im ofron një server DNS të paqëndrueshëm, dhe google ndonjëherë gjithashtu ka probleme. Dëshiroj një server DNS të qëndrueshëm për përdorim personal.

Motivimi për të shkruar artikullin — skica u shkrua 10 muaj më parë, dhe unë kam parë në të tashmë dy herë. Nëse edhe autori e kërkon këtë rregullisht — atëherë ka probabilitet të madh që edhe të tjerët do ta kenë nevojën.

Nuk ka një zgjidhje universale për serverin e postës elektronike. Por do të përpiqem të shkruaj diçka si ‘bëni kështu dhe pastaj, kur gjithçka të punojë siç duhet — hidhni gjërat e tepërta’.

Kam një server Colocation me kompaninë tech.ru. Ka mundësi të krahasosh me OVH, Hetzner, AWS. Për zgjidhjen e kësaj çështjeje, do të jetë shumë më efektive të bashkëpunosh me tech.ru.

Në server është instaluar Debian 9.

Në server ka 2 interfesa `eno1` dhe `eno2`. E para është pa limit, kurse e dyta është e shpejtë përkatësisht.

Ka 3 adresa IP statike, XX.XX.XX.X0 dhe XX.XX.XX.X1 dhe XX.XX.XX.X2 në interfesën `eno1` dhe XX.XX.XX.X5 në interfesën `eno2`.

Ka një pool IPv6 adresash XXXX:XXXX:XXXX:XXXX::/64, të cilat janë caktuar në interfesën `eno1`, dhe nga ajo XXXX:XXXX:XXXX:XXXX:1:2::/96 sipas kërkesës time u caktuan në `eno2`.

Ka janë 3 domain-e `domain1.com`, `domain2.com`, `domain3.com`. Për `domain1.com` dhe `domain3.com` ekziston një certifikatë SSL.

Kam një llogari google, të cilës dëshiroj të lidh një kuti postare `vasya.pupkin@domain1.com` (pranimi dhe dërgimi i postës direkt nga ndërfaqja e gmail).
Duhet të ketë një kuti postare `support@domain2.com`, një kopje e postës së së cilës dëshiroj ta shoh në gmailin tim. Dhe rrallë të kem mundësinë për të dërguar diçka në emër të `support@domain2.com` përmes ndërfaqes web.

Duhet të ketë një kuti postare `ivanov@domain3.com`, që do ta përdorë Ivanov nga iPhone-i i tij.

Mesazhet e dërguara duhet të përputhen me të gjitha kërkesat moderne për anti-spam.
Duhet të ketë nivelin më të lartë të enkriptimit të parashikuar në rrjetet publike.
Duhet të ketë mbështetje për IPv6 për dërgimin dhe marrjen e postave.
Duhet të ketë SpamAssassin, i cili nuk do të fshijë kurrë mesazhet. Ai do të ketë mundësi të bëjë bounce, të kalojë ose të dërgojë në dosjen IMAP "Spam".
Duhet të jetë e konfiguruar mësimi automatik për SpamAssassin: nëse lë një mesazh në dosjen "Spam" - ai do të mësojë nga kjo; nëse e lë një mesazh nga dosja "Spam" - ai do të mësojë nga kjo. Rezultatet e mësimit të SpamAssassin duhet të ndikojnë në rastet kur një mesazh futet në dosjen "Spam".
Skedaret php duhet të jenë në gjendje të dërgojnë postë në emrin e çdo domaini në këtë server.
Duhet të ketë një shërbim openvpn, me mundësinë për të përdorur IPv6 në klientët që nuk kanë IPv6.

Së pari, duhet të konfigurohen ndërfaqet dhe routing, duke përfshirë IPv6.
Pastaj, duhet të konfigurohet OpenVPN, i cili do të lidhet përmes IPv4 dhe do t'i ofrojë klientit një adresë reale statike IPv6. Ky klient do të ketë akses në të gjitha shërbimet IPv6 në server dhe në çdo burim IPv6 në internet.
Më pas, duhet të konfigurohet Postfix për dërgimin e mesazheve + SPF + DKIM + rDNS dhe gjëra të tjera të tilla.
Më pas, duhet të konfigurohet Dovecot dhe të rregullohet Multidomain.
Më pas, duhet të konfigurohet SpamAssassin dhe të rregullohet mësimi.
Në përfundim, të instalohet Bind.

============= Multi-interfaces =============

Për të konfiguruar ndërfaqet, duhet të shkruhet kjo në "\/etc\/network\/interfaces".

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eno1
iface eno1 inet static
        address XX.XX.XX.X0/24
        gateway XX.XX.XX.1
        dns-nameservers 127.0.0.1 213.248.1.6
        post-up ip route add XX.XX.XX.0/24 dev eno1 src XX.XX.XX.X0 table eno1t
        post-up ip route add default via XX.XX.XX.1 table eno1t
        post-up ip rule add table eno1t from XX.XX.XX.X0
        post-up ip rule add table eno1t to XX.XX.XX.X0

auto eno1:1
iface eno1:1 inet static
address XX.XX.XX.X1
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X1
        post-up ip rule add table eno1t to XX.XX.XX.X1
        post-up   ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t
        post-down ip route del 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t

auto eno1:2
iface eno1:2 inet static
address XX.XX.XX.X2
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X2
        post-up ip rule add table eno1t to XX.XX.XX.X2

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
        gateway XXXX:XXXX:XXXX:XXXX::1
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:2/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:1:1:2/64 dev $IFACE

# The secondary network interface
allow-hotplug eno2
iface eno2 inet static
        address XX.XX.XX.X5
        netmask 255.255.255.0
        post-up   ip route add XX.XX.XX.0/24 dev eno2 src XX.XX.XX.X5 table eno2t
        post-up   ip route add default via XX.XX.XX.1 table eno2t
        post-up   ip rule add table eno2t from XX.XX.XX.X5
        post-up   ip rule add table eno2t to XX.XX.XX.X5
        post-up   ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X5 table eno2t
        post-down ip route del 10.8.0.0/24 dev tun0 src XX.XX.XX.X5 table eno2t

iface eno2 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:2::/96
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:2:1:1/64 dev $IFACE
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:2:1:2/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:2:1:1/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:2:1:2/64 dev $IFACE

# OpenVPN network
iface tun0 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:3::/80

Këto rregulla mund të aplikohet në çdo server në tech.ru (me një miratim të vogël me suportin) dhe do të funksionojë menjëherë siç duhet.

Nëse keni përvojë në konfigurimin e gjërave të ngjashme për Hetzner, OVH - aty është ndryshe. Më e komplikuar.

eno1 është emri i kartës së rrjetit #1 (i ngadalshëm, por pa kufizime).
eno2 është emri i kartës së rrjetit #2 (i shpejtë, por me tarifë).
tun0 — është emri i kartës virtuale të rrjetit nga OpenVPN.
XX.XX.XX.X0 — IPv4 #1 në eno1.
XX.XX.XX.X1 — IPv4 #2 në eno1.
XX.XX.XX.X2 — IPv4 #3 në eno1.
XX.XX.XX.X5 — IPv4 #1 në eno2.
XX.XX.XX.1 — gateway IPv4.
XXXX:XXXX:XXXX:XXXX::/64 — IPv6 për të gjithë serverin.
XXXX:XXXX:XXXX:XXXX:1:2::/96 — IPv6 për eno2, gjithë të tjerat hyjnë nga eno1.
XXXX:XXXX:XXXX:XXXX::1 — gateway IPv6 (duhet theksuar se këtu mund / duhet të bëhet ndryshe. Duhet të specifikohet IPv6 i switch-it).
dns-nameservers — janë specifikuar 127.0.0.1 (sepse bind është instaluar lokalisht) dhe 213.248.1.6 (kjo është nga tech.ru).

«table eno1t» dhe «table eno2t» — kuptimi i këtyre rregullave të rrugës është që trafiku i hyrë përmes eno1 -> të largohet përmes të njëjtës, ndërsa trafiku i hyrë përmes eno2 -> të largohet përmes të saj. Po ashtu, lidhjet sipas iniciativës së serverit do të largohet përmes eno1.

ip route add default via XX.XX.XX.1 table eno1t

Me këtë urdhër përcaktojmë se çdo trafik i paqartë, i cili bie nën çdo rregull që ka shenjen «table eno1t» -> të drejtohet në ndërfaqen eno1.

ip route add XX.XX.XX.0/24 dev eno1 src XX.XX.XX.X0 table eno1t

Me këtë urdhër përcaktojmë se çdo trafik nga iniciativa e serverit të drejtohet në ndërfaqen eno1.

ip rule add table eno1t from XX.XX.XX.X0
ip rule add table eno1t to XX.XX.XX.X0

Me këtë urdhër përcaktojmë rregullat e vetëetiketimit të trafikut.

auto eno1:2
iface eno1:2 inet static
address XX.XX.XX.X2
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X2
        post-up ip rule add table eno1t to XX.XX.XX.X2

Ky bllok përcakton një IPv4 të dytë për ndërfaqen eno1.

ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t

Me këtë urdhër përcaktojmë rrugën nga klientët OpenVPN deri te IPv4 lokalë përveç XX.XX.XX.X0.
Pse ky urdhër mjafton për të gjithë IPv4 — akoma nuk e kuptoj.

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
        gateway XXXX:XXXX:XXXX:XXXX::1

Këtu përcaktojmë adresën për vetë ndërfaqen. Serveri do ta përdorë si adresën «dalëse». Nuk do të përdoret ndryshe.

Pse u caktua «:1:1::» kaq ndërlikuar? Që OpenVPN të punojë siç duhet dhe vetëm për këtë. Për këtë do të flasim më vonë.

Për sa i përket gateway — kështu punon dhe është mirë. Por nga ana e duhur — këtu duhet të specifikohet IPv6 i switch-it të cilit i është lidhur serveri.

Megjithatë, për ndonjë arsye IPv6 ndalon së funksionuari, nëse e bëj kështu. Ndoshta janë disa çështje nga tech.ru.

ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE

Ky është shtimi i një adrese IPv6 në ndërfaqe. Nëse ka nevojë për njëqind adresa — atëherë njëqind rreshta në këtë skedë.

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
...
iface eno2 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:2::/96
...
iface tun0 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:3::/80

Të gjitha adresat dhe subnetet e të gjitha ndërfaqeve janë shënuar për të qenë më të qarta.
eno1 — duhet patjetër të jetë "\/64" — sepse ky është gjithë pool-i ynë i adresave.
tun0 — nënrrjeti duhet të jetë patjetër më i madh se eno1. Përndryshe, nuk do të jetë e mundur të konfigurohet gateway IPv6 për klientët OpenVPN.
eno2 — nënrrjeti duhet të jetë patjetër më i madh se tun0. Përndryshe, klientët OpenVPN nuk do të mund të arrijnë adresat IPv6 lokale.
Për qartësi, kam zgjedhur hapësirën e nënrrjetit 16, por nëse dëshiron, mund të përdorësh edhe hapësirën "1".
Prandaj 64+16 = 80, dhe 80+16 = 96.
Për më shumë qartësi:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY — këto janë adresat që duhet të caktohen për site apo shërbime në ndërfaqen eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY — këto janë adresat që duhet të caktohen për site apo shërbime në ndërfaqen eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY — këto janë adresat që duhet të caktohen për klientët OpenVPN ose të përdoren si adresat shërbyese të OpenVPN.

Për konfigurimin e rrjetit — duhet të ketë mundësinë për të ribërë serverin.
Ndryshimet IPv4 kapen gjatë ekzekutimit (patjetër të vendoset në screen — ndryshe kjo komandë thjesht do të rrëzojë rrjetin në server):

/etc/init.d/networking restart

Në skedarin "\/etc\/iproute2\/rt_tables" shto në fund:

100 eno1t
101 eno2t

Pa këtë, nuk është e mundur të përdoren tabelat e personalizuara në skedarin "\/etc\/network\/interfaces".
Numrat duhet të jenë unikë dhe më të vogla se 65535.

Ndryshimet IPv6 ndryshojnë lehtë pa ribërje, por për këtë duhet të mësohesh të paktën me tri komanda:

ip -6 addr ...
ip -6 route ...
ip -6 neigh ...

Konfigurimi "\/etc\/sysctl.conf"

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward = 1

# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0

# For receiving ARP replies
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.default.arp_filter = 0

# For sending ARP
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.default.arp_announce = 0

# Enable IPv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

# IPv6 configuration
net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.all.accept_ra = 0

# For OpenVPN
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1

# For nginx on boot
net.ipv6.ip_nonlocal_bind = 1

Këto janë cilësimet "sysctl" të serverit tim. Do theksoj diçka të rëndësishme.

net.ipv4.ip_forward = 1

Pa këtë, OpenVPN nuk do të funksionojë aspak.

net.ipv6.ip_nonlocal_bind = 1

Kushdo që përpiqet të bëjë bind IPv6 (për shembull nginx) menjëherë pas ngarkimit të ndërfaqes — do të marrë një gabim. Se kjo adresë nuk është e disponueshme.

Për të shmangur një situatë të tillë, bëhet një konfigurim i tillë.

net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1

Pa këto cilësime, trafiku IPv6 nga klienti OpenVPN nuk del në botë.

Cilësimet e tjera ose nuk kanë lidhje tregu ose nuk e mbaj mend se për çfarë janë.
Por për çdo rast, e lë "ashtu siç është".

Për të siguruar që ndryshimet e këtij skedari të kapen pa ribërje të serverit — duhet të ekzekutosh komandën:

sysctl -p

Më shumë detaje rreth rregullave "table": habr.com\/post\/108690

============= OpenVPN =============

OpenVPN IPv4 nuk funksionon pa iptables.

Iptables e mia janë kështu për VPN:

iptables -A INPUT -p udp -s YY.YY.YY.YY --dport 1194 -j ACCEPT
iptables -A FORWARD -i tun0 -o eno1 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j SNAT --to-source XX.XX.XX.X0
##iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j DROP
iptables -A FORWARD -p udp --dport 1194 -j DROP

YY.YY.YY.YY — është adresa ime IPv4 statike të kompjuterit lokal.
10.8.0.0/24 — rrjeti IPv4 openvpn. Adresat IPv4 për klientët openvpn.
Rëndësia e rendit të rregullave është shumë e madhe.

iptables -A INPUT -p udp -s YY.YY.YY.YY --dport 1194 -j ACCEPT
iptables -A FORWARD -i tun0 -o eno1 -j ACCEPT
...
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j DROP
iptables -A FORWARD -p udp --dport 1194 -j DROP

Ky është një kufizim që vetëm unë nga IP ime statike mund të përdor OpenVPN.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j SNAT --to-source XX.XX.XX.X0
  -- ose --
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE

Për të lejuar paketat IPv4 të kalojnë mes klientëve OpenVPN dhe internetit — duhet të jepni një nga këto komanda.

Për raste të ndryshme, një nga opsionet nuk është e përshtatshme.
Për rastin tim, të dy komandat janë të përshtatshme.
Pas leximit të dokumentacionit, zgjodha opsionin e parë, sepse ai përdor më pak CPU.

Për të siguruar që të gjitha konfigurimet e iptables të aplikohen pas reboot-it — duhet t'i ruani diku.

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

Këto emra janë zgjedhur jo rastësisht. Ata përdoren nga paketi "iptables-persistent".

apt-get install iptables-persistent

Instalimi i paketës kryesore OpenVPN:

apt-get install openvpn easy-rsa

Do të konfiguroni një shablon për certifikatat (zëvendësoni vlerat tuaja):

make-cadir ~/openvpn-ca
cd ~/openvpn-ca
ln -s openssl-1.0.0.cnf openssl.cnf

Të redaktojmë cilësimet e shablonit të certifikatave:

mcedit vars

...
# Këto janë vlerat e paracaktuara për fushat
# që do të vendosen në certifikatë.
# Mos e lini asnjë nga këto fusha bosh.
export KEY_COUNTRY="RU"
export KEY_PROVINCE="Krasnodar"
export KEY_CITY="Dinskaya"
export KEY_ORG="Own"
export KEY_EMAIL="admin@domain1.com"
export KEY_OU="VPN"

# Fusha X509 Subject
export KEY_NAME="server"
...

Krijimi i certifikatës së serverit:

cd ~/openvpn-ca
source vars
./clean-all
./build-ca
./build-key-server server
./build-dh
openvpn --genkey --secret keys/ta.key

Përgatitja për të krijuar skedarët përfundimtarë "client-name.opvn":

mkdir -p ~/client-configs/files
chmod 700 ~/client-configs/files
cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client-configs/base.conf
mcedit ~/client-configs/base.conf

# Client mode
client

# Interface tunnel type
dev tun

# TCP protocol
proto tcp-client

# Address/Port of VPN server
remote XX.XX.XX.X0 1194

# Don't bind to local port/address
nobind

# Don't need to re-read keys and re-create tun at restart
persist-key
persist-tun

# Remote peer must have a signed certificate
remote-cert-tls server
ns-cert-type server

# Enable compression
comp-lzo

# Custom
ns-cert-type server
tls-auth ta.key 1
cipher DES-EDE3-CBC

Përgatitja e një skripti që do të bashkojë të gjithë skedarët në një skedar të vetëm opvn.

mcedit ~/client-configs/make_config.sh
chmod 700 ~/client-configs/make_config.sh

#!/bin/bash

# First argument: Client identifier

KEY_DIR=~/openvpn-ca/keys
OUTPUT_DIR=~/client-configs/files
BASE_CONFIG=~/client-configs/base.conf

cat ${BASE_CONFIG} 
    <(echo -e '<ca>') 
    ${KEY_DIR}/ca.crt 
    <(echo -e '</ca>n<cert>') 
    ${KEY_DIR}/${1}.crt 
    <(echo -e '</cert>n<key>') 
    ${KEY_DIR}/${1}.key 
    <(echo -e '</key>n<tls-auth>') 
    ${KEY_DIR}/ta.key 
    <(echo -e '</tls-auth>') 
    > ${OUTPUT_DIR}/${1}.ovpn

Krijimi i klientit të parë OpenVPN:

cd ~/openvpn-ca
source vars
./build-key client-name
cd ~/client-configs
./make_config.sh client-name

Skedari "~/client-configs/files/client-name.ovpn" dërgohet në pajisjen e klientit.

Për klientët e iOS do të duhet të bëni një lëvizje:
Përmbajtja e tag-ut «tls-auth» duhet të jetë pa komente.
Dhe gjithashtu të vendosni «key-direction 1» menjëherë përpara tag-ut «tls-auth».

Le të konfigurojmë serverin OpenVPN:

cd ~/openvpn-ca/keys
cp ca.crt ca.key server.crt server.key ta.key dh2048.pem /etc/openvpn
gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz | tee /etc/openvpn/server.conf
mcedit /etc/openvpn/server.conf

# Listen port
port 1194

# Protocol
proto tcp-server

# IP tunnel
dev tun0
tun-ipv6
push tun-ipv6

# Master certificate
ca ca.crt

# Server certificate
cert server.crt

# Server private key
key server.key

# Diffie-Hellman parameters
dh dh2048.pem

# Allow clients to communicate with each other
client-to-client

# Client config dir
client-config-dir /etc/openvpn/ccd

# Run client-specific script on connection and disconnection
script-security 2
client-connect "/usr/bin/sudo -u root /etc/openvpn/server-clientconnect.sh"
client-disconnect "/usr/bin/sudo -u root /etc/openvpn/server-clientdisconnect.sh"

# Server mode and client subnets
server 10.8.0.0 255.255.255.0
server-ipv6 XXXX:XXXX:XXXX:XXXX:1:3::/80
topology subnet

# IPv6 routes
push "route-ipv6 XXXX:XXXX:XXXX:XXXX::/64"
push "route-ipv6 2000::/3"

# DNS (for Windows)
# These are OpenDNS
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

# Configure all clients to redirect their default network gateway through the VPN
push "redirect-gateway def1 bypass-dhcp"
push "redirect-gateway ipv6" #For iOS

# Don't need to re-read keys and re-create tun at restart
persist-key
persist-tun

# Ping every 10s. Timeout of 120s.
keepalive 10 120

# Enable compression
comp-lzo

# User and group
user vpn
group vpn

# Log a short status
status openvpn-status.log

# Logging verbosity
##verb 4

# Custom config
tls-auth ta.key 0
cipher DES-EDE3-CBC

Kjo është për të caktuar një adresë statike për secilin klient (nuk është e domosdoshme, por unë e përdor):

# Client config dir
client-config-dir /etc/openvpn/ccd

Detaji më i komplikuar dhe kyç.

Fatkeqësisht, OpenVPN akoma nuk di të konfigurojë vetë IPv6 gateway për klientët.
Më duhet ta kaloj këtë manualisht për çdo klient.

# Run client-specific script on connection and disconnection
script-security 2
client-connect "/usr/bin/sudo -u root /etc/openvpn/server-clientconnect.sh"
client-disconnect "/usr/bin/sudo -u root /etc/openvpn/server-clientdisconnect.sh"

Skedari «/etc/openvpn/server-clientconnect.sh»:

#!/bin/sh

# Check client variables
if [ -z "$ifconfig_pool_remote_ip" ] || [ -z "$common_name" ]; then
        echo "Missing environment variable."
        exit 1
fi

# Load server variables
. /etc/openvpn/variables

ipv6=""

# Find out if there is a specific config with fixed IPv6 for this client
if [ -f "/etc/openvpn/ccd/$common_name" ]; then
        # Get fixed IPv6 from client config file
        ipv6=$(sed -nr 's/^.*ifconfig-ipv6-push[ t]+([0-9a-fA-F:]+).*$/1/p' "/etc/openvpn/ccd/$common_name")
        echo $ipv6
fi

# Get IPv6 from IPv4
if [ -z "$ipv6" ]; then
        ipp=$(echo "$ifconfig_pool_remote_ip" | cut -d. -f4)
        if ! [ "$ipp" -ge 2 -a "$ipp" -le 254 ] 2>/dev/null; then
                echo "Invalid IPv4 part."
                exit 1
        fi
        hexipp=$(printf '%x' $ipp)
        ipv6="$prefix$hexipp"
fi

# Create proxy rule
/sbin/ip -6 neigh add proxy $ipv6 dev eno1

Skedari «/etc/openvpn/server-clientdisconnect.sh»:

#!/bin/sh

# Check client variables
if [ -z "$ifconfig_pool_remote_ip" ] || [ -z "$common_name" ]; then
        echo "Missing environment variable."
        exit 1
fi

# Load server variables
. /etc/openvpn/variables

ipv6=""

# Find out if there is a specific config with fixed IPv6 for this client
if [ -f "/etc/openvpn/ccd/$common_name" ]; then
        # Get fixed IPv6 from client config file
        ipv6=$(sed -nr 's/^.*ifconfig-ipv6-push[ t]+([0-9a-fA-F:]+).*$/1/p' "/etc/openvpn/ccd/$common_name")
fi

# Get IPv6 from IPv4
if [ -z "$ipv6" ]; then
        ipp=$(echo "$ifconfig_pool_remote_ip" | cut -d. -f4)
        if ! [ "$ipp" -ge 2 -a "$ipp" -le 254 ] 2>/dev/null; then
                echo "Invalid IPv4 part."
                exit 1
        fi
        hexipp=$(printf '%x' $ipp)
        ipv6="$prefix$hexipp"
fi

# Delete proxy rule
/sbin/ip -6 neigh del proxy $ipv6 dev eno1

Të dy skenaret përdorin skedarin «/etc/openvpn/variables»:

# Subnet
prefix=XXXX:XXXX:XXXX:XXXX:2:
# netmask
prefixlen=112

Pse është shkruar kështu — kam vështirësi ta kujtoj.

Aktualisht duket e çuditshme netmask = 112 (në këtë rast duhet të jetë 96).
Dhe prefix është i çuditshëm, nuk përputhet me rrjetin tun0.
Por mirë, e lë «siç është».

cipher DES-EDE3-CBC

Kjo është për shije — kam zgjedhur një mënyrë të tillë për enkriptimin e lidhjes.

Më shumë detaje rreth konfigurimit të OpenVPN IPv4.

Më shumë detaje rreth konfigurimit të OpenVPN IPv6.

============= Postfix =============

Instalimi i paketës kryesore:

apt-get install postfix

Gjatë instalimit, zgjidhni «internet-site».

Mënyra ime «/etc/postfix/main.cf» duket kështu:

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# Shtimi .domain është detyra e MUA.
append_dot_mydomain = no

readme_directory = no

# Shihni http://www.postfix.org/COMPATIBILITY_README.html -- tema e parazgjedhur është 2 në
# instalime të reja.
compatibility_level = 2

# Parametrat e TLS
smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
smtpd_tls_key_file=/etc/ssl/domain1.com.2018.key
smtpd_use_tls=yes
smtpd_tls_auth_only = yes
smtp_bind_address = XX.XX.XX.X0
smtp_bind_address6 = XXXX:XXXX:XXXX:XXXX:1:1:1:1

smtp_tls_security_level = may
smtp_tls_ciphers = export
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_loglevel = 1

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = domain1.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = domain1.com
mydestination = localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

internal_mail_filter_classes = bounce

# Lloji i ruajtjes
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

# Cilësimet e SMTP-Auth
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions =
        permit_sasl_authenticated,
        permit_mynetworks,
        #reject_invalid_hostname,
        #reject_unknown_recipient_domain,
        reject_unauth_destination,
        reject_rbl_client sbl.spamhaus.org,
        check_policy_service unix:private/policyd-spf

smtpd_helo_restrictions =
        #reject_invalid_helo_hostname,
        #reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname

smtpd_client_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_non_fqdn_helo_hostname,
        permit

# SPF
policyd-spf_time_limit = 3600

# OpenDKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:var/run/opendkim/opendkim.sock

# Adresa IP për çdo domain
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Le të shqyrtojmë detajet e këtij konfigurimi.

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
smtpd_tls_key_file=/etc/ssl/domain1.com.2018.key

Sipas mendimit të përdoruesve të Habr, ky bllok përmban `dezinformatë dhe tezë të gabuara`.Vetëm pas 8 vjetësh që nga fillimi i karrierës sime kam filluar të kuptoj si funksionon SSL.
Prandaj do të marrë guximin të përshkruaj si të përdorim SSL (pa u përgjigjur në pyetjet "Si funksionon?" dhe "Pse funksionon?").
Baza e enkriptimit modern është krijimi i një çifti çelësash (dy vargje shumë të gjata simboresh).
Një "çelës" është privat, tjetri është "publik". Çelësi privat ruhet me kujdes dhe në fshehtësi. Çelësi publik shpërndahet të gjithëve që duan.
Me ndihmën e çelësit publik, mund të enkriptohet një varg teksti në mënyrë që vetëm poseduesi i çelësit privat mund ta dekriptojë atë.
Kjo është gjithë baza e teknologjisë.
Hapi №1 — faqet https.
Brouzeri, kur i qaset një faqes, zbulohet nga serveri web se faqja është https dhe prandaj kërkon çelësin publik.
Serveri web dorëzon çelësin publik. Shfletuesi, duke përdorur çelësin publik, kripton http-request-in dhe e dërgon atë.
Përmbajtja e http-request-it mund të lexohet vetëm nga ai që ka çelësin privat, pra vetëm nga serveri në të cilin bëhet kërkesa.
Http-request përmban të paktën URI. Prandaj, nëse në një vend përpiqen të kufizojnë qasjen jo në të gjithë faqen, por në një faqe specifike — përfaqësimi i https nuk lejon që kjo të bëhet.
Hapi №2 — përgjigja e enkriptuar.
Serveri web jep një përgjigje, që mund të lexohet lehtësisht gjatë rrugës.
Zgjidhja është jashtëzakonisht e thjeshtë — shfletuesi formon lokal një çift çelësi privat-publik për çdo faqe https.
Dhe së bashku me kërkesën për çelësin publik të faqes, dërgon çelësin e tij publik lokal.
Serveri web e mban mend atë dhe kur dërgon http-response-in, e kripton me këtë çelës publik të klientit specifik.
Tani http-response mund të dekriptohet vetëm nga mbajtësi i çelësit privat të shfletuesit të klientit (pra vetë klienti).
Hapi №3 — vendosja e një lidhjeje të sigurt nëpërmjet kanalit publik.
Në shembullin №2 ka një vulnerabilitet — nuk ka asgjë që pengon të tjerët të kapin http-request-in dhe të redaktojnë informacionin mbi çelësin publik.
Kështu, ndërmjetësi do të jetë në gjendje të shikojë të gjithë përmbajtjen e mesazheve të dërguara-marrë deri sa të ndryshohet kanali i komunikimit.
Për ta luftuar këtë është jashtëzakonisht e thjeshtë — mjafton të dërgohet çelësi publik të shfletuesit si një mesazh i enkriptuar me çelësin publik të serverit web.
Serveri web atëherë fillimisht dërgon një përgjigje të tipit "çelësi yt publik është ky" dhe e kripton këtë mesazh me të njëjtin çelës publik.
Shfletuesi kontrollon përgjigjen — nëse është dërguar mesazhi "çelësi yt publik është ky" — kjo është 100% garanci që ky kanal lidhjeje është i sigurt.
Sa i sigurt është?
Krijimi i një kanali të tillë të sigurt ndodh me shpejtësi ping*2. Për shembull, 20ms.
Një sulmues duhet ose ta ketë më parë çelësin privat të njërës palë. Ose të gjejë çelësin privat brenda disa milisekondash.
Thyerja e një çelësi privat modern do të marrë dekada në një superkompjuter.
Hapi №4 — databaza publike e çelësave publik.
Është e qartë se në të gjithë këtë histori ekziston mundësia për një sulmues që ndodhet në kanalin e komunikimit midis klientit dhe serverit.
Mundësia për klientin të paraqitet si server, dhe serverit të paraqitet si klient. Dhe të simulojë një çift çelësash në të dy drejtimet.
Atëherë, sulmuesi do të shohë të gjithë trafikun dhe do të ketë mundësinë të "përmirësojë" trafikun.
Për shembull, të ndryshojë adresën se ku të dërgohen paratë ose të kopjojë fjalëkalimin nga banka online ose të bllokojë përmbajtjen "e padëshiruar".
Për të luftuar këta sulmues, është shpikur një DB publike me çelësa publikë për çdo site https.
Çdo shfletues "e di" për ekzistencën e rreth 200 të tillave. Kjo është e paracaktuar në çdo shfletues.
„Dija“ mbështetet nga çelësi publik i çdo certifikate. Kështu, lidhja me çdo qendër të caktuar të certifikimit është e pamundur të falsifikohet.
Tani kemi një kuptim të thjeshtë se si të përdorim SSL për https.
Nëse përdor mendjen — do të kuptohet se si shërbimet speciale mund të thyejnë ndonjë gjë në këtë strukturë. Por do t'iu kushtohet një përpjekje monstruoze.
Dhe për organizatat më të vogla se NSA ose CIA — është praktikisht e pamundur të thyhet niveli ekzistues i mbrojtjes edhe për VIP-at.
Po ashtu, do të shtoj për lidhjet ssh. Aty s'ka çelësa publik; si të veprohet. Problemi zgjidhet në dy mënyra.
Opsioni ssh me fjalëkalim:
Me lidhjen e parë, klienti ssh duhet të paralajmërojë se kemi një çelës publik të ri nga serveri ssh.
Dhe me lidhjet e mëtejshme, nëse shfaqet paralajmërimi "çelësi i ri publik nga serveri ssh" — do të thotë se po ju përgjojnë.
Ose që me lidhjen e parë ju kanë përgjuar, dhe tani po komunikoni me serverin pa ndërmjetës.
Faktikisht, për shkak se fakti i përgjojjes zbulohet lehtësisht, shpejt dhe pa ndonjë përpjekje — kjo sulm përdoret vetëm në raste të veçanta për klientë të caktuar.
Opsioni ssh me çelës:
Merrni një flash drive, shkruani në të çelësin privat për serverin ssh (për këtë ka terma dhe një mori nuancash të rëndësishme, por po shkruaj për edukim, e jo për udhëzim përdorimi).
Çelësi publik e lëmë në makinën ku do të jetë klienti ssh dhe gjithashtu e mbajmë në sekret.
E sjellim flash drive-n te serveri, e fusim, kopjojmë çelësin privat, dhe flash drive-n e shkatërrojmë dhe shpërndajmë pluhurin në erë (ose të paktën e formatizojmë me mbushje me zero).
Ky është fundi — pas një operacioni të tillë, do të jetë e pamundur të hakohet një lidhje ssh e tillë. Natyrisht, pas rreth 10 vjetësh në një superkompjuter do të jetë e mundur të shikoni trafikun — por kjo është një histori tjetër.
Më falni për offtopin.

Pra, tani që dihet teoria. Do të flas për procesin e krijimit të certifikatës ssl.

Me ndihmën e «openssl genrsa» krijojmë një çelës privat dhe «shabllone» për çelësin publik.
«Shabllonet» i dërgojmë një kompanie të tretë, së cilës i paguajmë rreth $9 për certifikatën më të thjeshtë.

Pas disa orësh, marrim nga kjo kompani të tretë çelësin tonë «publik» dhe gjithashtu një set të disa çelësave publikë të tjerë.

Pse të paguaj një kompani të tretë për të formalizuar çelësin tim publik — është një pyetje e veçantë, nuk do ta shqyrtojmë këtu.

Tani është e qartë ku qëndron kuptimi i shkrimit:

smtpd_tls_key_file= /etc/ssl/domain1.com.2018.key

Në dosjen «/etc/ssl» janë të ruajtura të gjitha skedarët për çështjet ssl.
domain1.com — emri i domenit.
2018 — viti i krijimit të çelësave.
«key» — tregon se skedari është çelësi privat.

Dhe kuptimi i këtij skedari:

smtpd_tls_cert_file= /etc/ssl/domain1.com.2018.chained.crt
domain1.com — emri i domenit.
2018 — viti i krijimit të çelësave.
chained — tregon se këtu është një zinxhir çelësash publikë (i pari — çelësi ynë publik dhe të tjerët — ato që erdhën nga kompania që e formalizoi çelësin publik).
crt — tregon se këtu është një certifikatë e gatshme (çelësi publik me shpjegime teknike).

smtp_bind_address = XX.XX.XX.X0
smtp_bind_address6 = XXXX:XXXX:XXXX:XXXX:1:1:1:1

Ky cilësim në këtë rast nuk përdoret, por është shkruar për shembull.

Sepse një gabim në këtë parametër do të çojë në dërgimin e spam-it nga serveri juaj (pa vullnetin tuaj).

Pastaj, provoni t'i demonstroni të gjithëve se nuk jeni fajtor.

recipient_delimiter = +

Mundësisht shumë njerëz nuk e dinë, kështu që ky është simboli standard për klasifikimin e pasemave, dhe është mbështetur nga shumica e serverëve të postës moderne.

Për shembull, nëse keni një kuti postare «username@gmail.com» provoni të dërgoni në «username+spam@gmail.com» — shikoni se çfarë do të ndodhë.

inet_protocols = ipv4

Mund të jetë një konfuzion.

Por kjo nuk është thjesht ashtu. Çdo domen i ri — sipas parimit vetëm IPv4, pastaj aktivizoj IPv6 për secilin veçmas.

virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Këtu përcaktojmë se gjithë posta e ardhshme shkon në dovecot.
Dhe rregullat për domain, mailbox, alias — shikohet në DB.

/etc/postfix/mysql-virtual-mailbox-domains.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT 1 FROM virtual_domains WHERE name='%s'

/etc/postfix/mysql-virtual-mailbox-maps.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT 1 FROM virtual_users WHERE email='%s'

/etc/postfix/mysql-virtual-alias-maps.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT destination FROM virtual_aliases WHERE source='%s'

# SMTP-Auth settings
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

Tani, postfix e di njohur se mund të pranojë email për dërgim vetëm me autorizim nga dovecot.

Më vjen vërtetë çudi pse duhet ta dyfishojmë këtë. Ne tashmë e kemi specifikuar në "virtual_transport" gjithçka që na duhet.

Por sistemi postfix është shumë i vjetër — ndoshta këto janë pengesa nga kohërat e kaluara.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Kjo duhet të konfigurhet për çdo server email sipas mënyrës së tij.

Kam në dispozicion 3 serverë email dhe këto konfigurime janë shumë të ndryshme për shkak të kërkesave të ndryshme për përdorim.

Duhet të konfiguroni me kujdes — përndryshe spami do të rrjedhë te ju ose akoma më keq — spam do të dërgohet nga ju.

# SPF
policyd-spf_time_limit = 3600

Konfigurimi për një plugin që është i lidhur me verifikimin e SPF të email-eve që vijnë.

# OpenDKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:var/run/opendkim/opendkim.sock

Konfigurimi që të gjitha email-et që dërgojmë duhet të jenë me nënshkrim DKIM.

# IP address per domain
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Kjo është një detaj kyç në rrjedhën e email-eve kur dërgojmë email-e nga skenarë php.

Skeda "\/etc\/postfix\/sdd_transport.pcre":

/^www-domain1@domain1.com$/ domain1:
/^www-domain2@domain1.com$/ domain2:
/^www-domain3@domain1.com$/ domain3:
/@domain1.com$/             domain1:
/@domain2.com$/             domain2:
/@domain3.com$/             domain3:

Majtas — shprehje të rregullta. Djathtas — etiketa që i atribuohet email-it.
Postfix, sipas etiketes, do të marrë parasysh disa rreshta të tjera konfigurimi për një email specifik.
Si do të rikonfigurohet postfix për një email të veçantë do të specifikohet në "master.cf".
Rreshtat 4, 5, 6 — ata janë kryesorët. Nga emri i cili domeni dërgojmë email — një etiketa e tillë vendoset.
Por jo gjithmonë në skenarët php në kodin e vjetër shihet fusha "from". Atëherë ndihmon emri i përdoruesit.
Bashkimi është gjithashtu i gjerë — nuk do të doja të shqetësohesha për konfigurimin e nginx+fpm.
Për shkurt — për çdo faqe caktuojmë një pronar linux-user përkatës. Dhe përkatësisht një fpm-pool të tijin.
Fpm-pool përdor çdo version php (kjo është e shkëlqyer kur në një server pa probleme për faqet fqinjë mund të përdorim versionin e ndryshëm php dhe madje edhe php.ini të ndryshëm).
Pra, ky linux-user konkret "www-domain2" ka faqen domain2.com. Në këtë faqe ka kodin që dërgon email-e pa specifikuar fushën from.
Pra, edhe në këtë rast email-et do të dërgohen saktë dhe kurrë nuk do të shkojnë në spam.

Skeda ime "\/etc\/postfix\/master.cf" duket kështu:

...
smtp      inet  n       -       y       -       -       smtpd
  -o content_filter=spamassassin
...
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
...
policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

spamassassin unix -     n       n       -       -       pipe
    user=spamd argv=/usr/bin/spamc -f -e
    /usr/sbin/sendmail -oi -f ${sender} ${recipient}
...
domain1  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X1
   -o smtp_helo_name=domain1.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:1:1
   -o syslog_name=postfix-domain1

domain2  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X5
   -o smtp_helo_name=domain2.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:2:1:1
   -o syslog_name=postfix-domain2

domain3  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X2
   -o smtp_helo_name=domain3
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:5:1
   -o syslog_name=postfix-domain3

Skeda nuk është e plotë — tashmë është shumë e madhe.
Kam shënuar vetëm atë që është ndryshuar.

smtp      inet  n       -       y       -       -       smtpd
  -o content_filter=spamassassin
...
spamassassin unix -     n       n       -       -       pipe
    user=spamd argv=/usr/bin/spamc -f -e
    /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Këto janë cilësimet e lidhura me spamassassin, për të cilin do të flasim më vonë.

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Lejojmë lidhjen me serverin e postës përmes portit 587.
Për këtë është e domosdoshme të autentikoheni.

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

Aktivizojmë kontrollin SPF.

apt-get install postfix-policyd-spf-python

Do të installojmë paketën për kontrollin SPF më sipër.

domain1  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X1
   -o smtp_helo_name=domain1.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:1:1
   -o syslog_name=postfix-domain1

Dhe kjo është më interesante. Kjo është mundësia për të dërguar letra për një domen specifik me një adresë specifike IPv4/IPv6.
Kjo bëhet për shkak të rDNS. rDNS është marrja e një vargu të caktuar përmes një adrese IP.
Dhe për postën, kjo mundësi përdoret për të konfirmuar që helo përputhet me rDNS të adresës nga e cila u dërgua emaili.
Nëse helo nuk përputhet me domenin e postës nga e cila u dërgua letra — akumulohet pikë spami.
Helo nuk përputhet me rDNS — akumulohet shumë pikë spami.
Prandaj, për çdo domen duhet të ketë një adresë IP të vetën.
Për OVH — në konsolë ka mundësi për të specifikuar rDNS.
Për tech.ru — çështja zgjidhet përmes suportit.
Për AWS — çështja zgjidhet përmes suportit.
«inet_protocols» dhe «smtp_bind_address6» aktivizojnë mbështetje për IPv6.
Për IPv6, gjithashtu duhet të caktohet rDNS.
«syslog_name» — kjo është për lehtësinë e leximit të regjistrimeve.

Blerja e certifikatave e rekomandoj këtu.

Konfigurimi i lidhjes postfix+dovecot këtu.

Konfigurimi i SPF.

============= Dovecot =============

apt-get install dovecot-imapd dovecot-pop3d dovecot-lmtpd dovecot-mysql dovecot-antispam

Konfigurimi i mysql, instalojmë vetë paketat.

Skeda «/etc/dovecot/conf.d/10-auth.conf»

disable_plaintext_auth = yes
auth_mechanisms = plain login

Autorizimi vetëm në formë të enkriptuar.

Skeda «/etc/dovecot/conf.d/10-mail.conf»

mail_location = maildir:/var/mail/vhosts/%d/%n

Këtu do të caktomë vendin e ruajtjes së mesazheve.

Dua që ato të ruhen në skedarë dhe të grumbullohen sipas domain-eve.

Skeda «/etc/dovecot/conf.d/10-master.conf»

service imap-login {
  inet_listener imap {
    port = 0
  }
  inet_listener imaps {
    address = XX.XX.XX.X1, XX.XX.XX.X2, XX.XX.XX.X5, [XXXX:XXXX:XXXX:XXXX:1:1:1:1], [XXXX:XXXX:XXXX:XXXX:1:2:1:1], [XXXX:XXXX:XXXX:XXXX:1:1:5:1]
    port = 993
    ssl = yes
  }
}
service pop3-login {
  inet_listener pop3 {
    port = 0
  }
  inet_listener pop3s {
    address = XX.XX.XX.X1, XX.XX.XX.X2, XX.XX.XX.X5, [XXXX:XXXX:XXXX:XXXX:1:1:1:1], [XXXX:XXXX:XXXX:XXXX:1:2:1:1], [XXXX:XXXX:XXXX:XXXX:1:1:5:1]
    port = 995
    ssl = yes
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}
service imap {
}
service pop3 {
}
service auth {
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
  }

  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
  user = dovecot
}
service auth-worker {
  user = vmail
}
service dict {
  unix_listener dict {
  }
}

Ky është skeda kryesore e konfigurimit të dovecot.
Këtu ne çaktivizojmë lidhjet e pa mbrojtura.
Dhe aktivizojmë lidhjet e mbrojtura.

Skeda «/etc/dovecot/conf.d/10-ssl.conf»

ssl = required
ssl_cert = </etc/nginx/ssl/domain1.com.2018.chained.crt
ssl_key = </etc/nginx/ssl/domain1.com.2018.key
local XX.XX.XX.X5 {
  ssl_cert = </etc/nginx/ssl/domain2.com.2018.chained.crt
  ssl_key =  </etc/nginx/ssl/domain2.com.2018.key
}

Konfigurojmë ssl. Tregojmë se ssl është e detyrueshme.
Dhe vetë certifikati. Një detaj i rëndësishëm — direktyva «local». Tregon se cfarë certifikate ssl duhet të përdoret për lidhje me cilin IPv4 lokal.
Për më tepër, IPv6 këtu nuk është konfiguruar, do ta rregulloj këtë mungesë ndonjëherë.
XX.XX.XX.X5 (domain2) — nuk ka certifikatë. Për lidhjen e klientëve duhet të caktohet domain1.com.
XX.XX.XX.X2 (domain3) — ka certifikatë, për lidhjen e klientëve mund të caktohet domain1.com ose domain3.com.

Skeda «/etc/dovecot/conf.d/15-lda.conf»

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Kjo në vazhdim do të jetë e nevojshme për spamassassin.

Skeda «/etc/dovecot/conf.d/20-imap.conf»

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Ky është plugin antispam. Nevojitet për trajnimin e spamassassin gjatë transferimit në/nga dosjen «Spam».

Skeda «/etc/dovecot/conf.d/20-pop3.conf»

protocol pop3 {
}

Thjesht një skedë e tillë ekziston.

Skeda «/etc/dovecot/conf.d/20-lmtp.conf»

protokolli lmtp {
  mail_plugins = $mail_plugins sieve
  postmaster_address = admin@domain1.com
}

Konfigurimi i lmtp.

Skedari «/etc/dovecot/conf.d/90-antispam.conf»

plugin {
  antispam_backend = pipe
  antispam_trash = Trash;trash
  antispam_spam = Junk;Spam;SPAM
  antispam_pipe_program_spam_arg = --spam
  antispam_pipe_program_notspam_arg = --ham
  antispam_pipe_program = /usr/bin/sa-learn
  antispam_pipe_program_args = --username=%Lu
}

Cilësimet për trajnimin e spamassassin në momentin e transferimit në/nga dosjet «Spam».

Skedari «/etc/dovecot/conf.d/90-sieve.conf»

plugin {
  sieve = ~/dovecot.sieve
  sieve_dir = ~/sieve
  sieve_after = /var/lib/dovecot/sieve/default.sieve
}

Skedari në të cilin specifikohet se çfarë duhej bërë me mesazhet e ardhshme.

Skedari «/var/lib/dovecot/sieve/default.sieve»

require ["fileinto", "mailbox"];

if header :contains "X-Spam-Flag" "YES" {
        fileinto :create "Spam";
}

Duhet të kompilohet skedari: «sievec default.sieve».

Skedari «/etc/dovecot/conf.d/auth-sql.conf.ext»

passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
}

Specifikimi i skedarëve sql për autorizim.
Dhe skedari vetë — si një metodë autorizimi.

Skedari «/etc/dovecot/dovecot-sql.conf.ext»

driver = mysql
connect = host=127.0.0.1 dbname=servermail user=usermail password=password
default_pass_scheme = SHA512-CRYPT
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';

Kjo i përmbush cilësimet e ngjashme për postfix.

Skedari «/etc/dovecot/dovecot.conf»

protocols = imap lmtp pop3
listen = *, ::
dict {
}
!include conf.d/*.conf
!include_try local.conf

Skedari kryesor i konfigurimit.
E rëndësishme është se këtu specifikojmë / shtojmë protokollet.

============= SpamAssassin =============

apt-get install spamassassin spamc

Të instalojmë paketat.

adduser spamd --disabled-login

Shtojmë përdoruesin në emër të të cilit.

systemctl enable spamassassin.service

Aktivizojmë ngarkesën automatike të shërbimit spamassassin gjatë ngarkesës.

Skedari «/etc/default/spamassassin»:

CRON=1

Aktivizojmë azhurnimin e rregullave «në mënyrë të paracaktuar».

Skedari «/etc/spamassassin/local.cf»:

report_safe 0

use_bayes          1
bayes_auto_learn   1
bayes_auto_expire  1
bayes_store_module Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn      DBI:mysql:sa:localhost:3306
bayes_sql_username sa
bayes_sql_password password

Duhet të krijoni një DB mysql «sa» me përdoruesin «sa» dhe fjalëkalimin «password» (zëvendësoni me diçka më të arsyeshme).

report_safe — për këtë do të dërgohet një raport për mesazhin spam në vend të mesazhit.
use_bayes — këto janë cilësimet e mësimit të makinerisë për spamassassin.

Cilësimet e tjera të spamassassin u aplikuan më parë sipas artikullit.

Cilësimi i përgjithshëm «spamassassin».
Rreth zhvendosjes së mesazheve të reja spam në dosjen IMAP «Spam».
Rreth lidhjes së thjeshtë Dovecot + SpamAssassin.
Rekomandoj leximin e teorisë së trajnimit të spamassassin gjatë lëvizjes së mesazheve në dosjet imap (dhe nuk rekomandoj ta zbatoj këtë).

============= Apeli për komunitetin =============

Më shumë do të doja të dërgoja një ide në komunitet rreth mënyrave për të rritur nivelin e sigurisë së email-eve të dërguara. Duke qenë se kam thelluar shumë në temën e postës.

Që përdoruesi të ketë mundësinë të krijojë disa çelësa në klientin e tij (outlook, thunderbird, browser-plugin, ...) të tipit publik dhe privat. Çelësi publik - dërgohet në DNS. Çelësi privat - ruhet në klient. Serverët e postës do të dinë të aplikojnë çelësin publik për dërgimin në një adresë të caktuar.

Dhe për të mbrojtur nga spam në rastet e tilla (po, serveri i postës nuk do të mund të shikojë përmbajtjen) - do të duhet të vendosen 3 rregulla:

Nënshkrimi DKIM i vërtetë detyrues, SPF i detyrueshëm, rDNS i detyrueshëm.
Një rrjet nervor për trajnimin e anti-spamit + një bazë të dhënash në anën e klientit.
Algoritmi i enkriptimit duhet të jetë i tillë, që pala dërguese të shpenzojë 100 herë më shumë burime CPU për enkriptim sesa pala pranuese.

Përveç email-eve publike - zhvilloni një standard për email-in propozues për "të filluar një komunikim të sigurt". Një nga përdoruesit (kutia postare) i dërgon një email një kutie tjetër postare me një kënd. Në email ka një tekst propozues për të filluar një kanal të sigurt komunikimi dhe çelësin publik të pronarit të kutisë postare (me çelësin privat në anën e klientit).

Edhe mund të krijohen disa çelësa posaçërisht për çdo komunikim. Përdoruesi-pranues mund të pranojë këtë propozim dhe të dërgojë çelësin e tij publik (po ashtu i bërë posaçërisht për këtë komunikim). Pastaj përdoruesi i parë dërgon një email kontrolli shërbimi (i enkriptuar me çelësin publik të përdoruesit të dytë) - kur e merr, përdoruesi i dytë mund ta konsiderojë kanalin e formuar si të besueshëm. Më pas përdoruesi i dytë dërgon një email kontrolli - dhe atëherë përdoruesi i parë gjithashtu mund ta konsiderojë kanalin e formuar si të mbrojtur.

Për të luftuar përhapjen e çelësave gjatë rrugës - do të duhet të parashikojmë në protokoll mundësinë e transmetimit të të paktën një çelësi publik përmes një flash drive.

Dhe më e rëndësishmja - që të gjithë kjo të funksionojë (pyetja "kush do ta paguajë këtë?"):
Të jepni certifikata postare me çmime nga 10$ për 3 vjet. Që do t'i lejojnë dërguesit të tregojnë në DNS se "çelësat e mi publikë janë atje." Dhe do të ofrojnë mundësinë për të nisur një lidhje të sigurt. Ndërkohë, do të pranojnë këto lidhje falas.
gmail më në fund po i monetizon përdoruesit e tij. Për 10$ në 3 vjet – e drejta për të krijuar kanale të sigurta të komunikimit.

============= Përfundimi =============

Për të testuar të gjithë artikullin, doja të merrja me qira një server të dedikuar për një muaj dhe të blija një domen me certifikatën SSL.

Por rrethanat e jetës bëri që ky çështje të vonohej për 2 muaj.
Dhe kur më erdhi përsëri koha e lirë – vendosa të publikoj artikullin siç është, dhe jo të rrezikoj që publikimi të vonohet edhe për një vit.

Nëse do të ketë mjaft pyetje si "këtu nuk është përshkruar mjaftueshëm" – atëherë ndoshta do të gjej forcë për të marrë një server të dedikuar me një domen të ri dhe një certifikatë SSL të re dhe të përshkruaj më në detaje dhe më e rëndësishmja – të zbuloj të gjitha detajet e rëndësishme që janë humbur.

Gjithashtu do të doja të merrja mendime mbi idenë për certifikatat postare. Nëse ideja pëlqen – do të mundohem të gjej forcë për të shkruar një draft për RFC.

Kur kopjoni pjesë të mëdha të artikullit – tregoni lidhjen në këtë artikull.
Kur përktheni në çdo gjuhë tjetër – tregoni lidhjen në këtë artikull.
Unë vetë do të mundohem ta përkthej në anglishte dhe do të lë lidhje të ndërthurura.

Burimi: habr.com