Debian + Postfix + Dovecot + Többdomain + SSL + IPv6 + OpenVPN + Több-interface + SpamAssassin-tanulás + Bind

Ez a cikk arról szól, hogyan állítsunk be egy modern levelezőszervert.
Postfix + Dovecot. SPF + DKIM + rDNS. IPv6-tal.
TLS titkosítással. Több domain támogatásával — igazi SSL tanúsítvánnyal.
Spamvédelemmel és magas spamminősítéssel más levelezőszervereknél.
Több fizikai interfész támogatásával.
OpenVPN-nel, amelyhez IPv4-en csatlakoznak, és amely IPv6-ot ad.

Ha nem szeretné e technológiákat tanulmányozni, de szeretne egy ilyen szervert beállítani — akkor ez a cikk Önnek szól.

A cikkben nincsenek kísérletek, hogy minden részletet megmagyarázzunk. A magyarázat arra vonatkozik, ami nem szabványos vagy fontos a felhasználó szempontjából.

A levelezőszerver beállításának motivációja — régóta dédelgetett álmom. Lehet, hogy ez ostobán hangzik, de véleményem szerint ez sokkal jobb, mint arról álmodozni, hogy egy új autót szeretnék.

Az IPv6 beállításának két motivációja van. Az IT szakembernek folyamatosan új technológiákat kell tanulmányoznia, hogy túléljen. Szeretném, ha szerény közreműködésemmel hozzájárulhatnék a cenzúra elleni küzdelemhez.

Az OpenVPN beállításának motivációja — csak azért, hogy az IPv6 működjön a helyi gépen.
A több fizikai interfész beállításának motivációja — a szerveremen egy interfész van "lassú, de korlátlan", míg a másik "gyors, de tarifás".

A Bind beállításának motivációja — a szolgáltatóm instabil DNS szervert biztosít, a Google is néha megszakad. Stabil DNS szervert szeretnék személyes használatra.

A cikk megírásának motivációja — a vázlatot 10 hónappal ezelőtt írtam, és már kétszer is belekukucskáltam. Ha még az írónak is gyakran szüksége van rá — akkor nagy a valószínűsége, hogy másoknak is szüksége lesz.

Nincs univerzális megoldás a levelezőszerverek számára. De megpróbálom úgy megírni, hogy "csináld így, és amikor minden úgy működik, ahogy kell — dobd ki a felesleget".

Colocation szerverem van a tech.ru cégnél. Van lehetőség összehasonlítani az OVH, Hetzner, AWS szolgáltatókkal. E feladat megoldásához sokkal hatékonyabb a tech.ru-val való együttműködés.

A szerveren Debian 9 van telepítve.

A szerveren 2 interfész van `eno1` és `eno2`. Az első korlátlan, míg a második gyors értelemszerűen.

3 statikus IP cím áll rendelkezésre, XX.XX.XX.X0, XX.XX.XX.X1 és XX.XX.XX.X2 az `eno1` interfészen és XX.XX.XX.X5 az `eno2` interfészen.

Van XXXX:XXXX:XXXX:XXXX::/64 IPv6 címekből álló tartomány, amelyet az `eno1` interfészhez rendeltek, és az XXXX:XXXX:XXXX:XXXX:1:2::/96-ot az én kérésomra rendeltek az `eno2` interfészhez.

Három domain áll rendelkezésre: `domain1.com`, `domain2.com`, `domain3.com`. A `domain1.com` és a `domain3.com` esetében van SSL tanúsítvány.

Van egy Google-fiók, amelyhez szeretném csatolni a `vasya.pupkin@domain1.com` postaládát (a levelek fogadása és küldése közvetlenül a Gmail felületéről).
Kell egy `support@domain2.com` postaláda, aminek a leveleit szeretném látni a Gmailben. Ezen kívül ritkán lehetőségem kell, hogy legyen valamit küldeni a `support@domain2.com` nevében a webes felületen.

Kell egy `ivanov@domain3.com` postaláda, amelyet Ivanov fog használni az iPhone-ján.

A kiküldött leveleknek meg kell felelniük a modern spamellenes követelményeknek.
A legmagasabb szintű titkosításnak kell rendelkezésre állnia a nyilvános hálózatokban.
IPv6 támogatásnak kell lennie a levelek küldésére és fogadására is.
Kell egy SpamAssassin, amely soha nem törli a leveleket. Vagy visszadobja őket, vagy átengedi őket, vagy a „Spam” IMAP mappába küldi őket.
Be kell állítani a SpamAssassin automatikus tanulását: ha áthelyezek egy levelet a „Spam” mappába, azt tanulja; ha áthelyezek egy levelet a „Spam” mappából, azt is tanulja. A SpamAssassin tanulási eredményei befolyásolják a levelek spam mappába kerülését.
A php szkripteknek képesnek kell lenniük levelet küldeni bármely domain nevében ezen a szerveren.
Kell egy OpenVPN szolgáltatás, amely lehetővé teszi az IPv6 használatát olyan kliens számára, amelynek nincs IPv6-ja.

Először be kell állítani a felületeket és az útválasztást, beleértve az IPv6-ot.
Ezután be kell állítani az OpenVPN-t, amely IPv4-en csatlakozik és statikus, valós IPv6 címet biztosít a kliensnek. Ennek a kliensnek hozzáférése lesz az összes IPv6 szolgáltatáshoz a szerveren, és bármilyen IPv6 erőforráshoz az interneten.
Ezután be kell állítani a Postfixet levelek küldésére + SPF + DKIM + rDNS és egyéb hasonló apróságok.
Ezután be kell állítani a Dovecot-ot és a több domain kezelését.
Végül be kell állítani a SpamAssassin-t és a tanulást.
A végén telepíteni kell a Bind-ot.

============= Többfelület =============

A felületek beállításához a következőket kell beírni a „/etc/network/interfaces”-be.

# 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

Ezeket a beállításokat bármelyik szerveren alkalmazni lehet a tech.ru-n (kismértékű egyeztetéssel a támogatással), és azonnal működni fog, ahogyan kell.

Ha hasonló dolgok beállításában van tapasztalata Hetzner-nél, OVH-nál — ott más a helyzet. Nehezebb.

eno1 — ez az első hálózati kártya neve (lassú, de korlátlan).
eno2 — ez a második hálózati kártya neve (gyors, de tarifás).
tun0 — az OpenVPN virtuális hálózati kártyájának neve.
XX.XX.XX.X0 — első IPv4 az eno1-en.
XX.XX.XX.X1 — második IPv4 az eno1-en.
XX.XX.XX.X2 — harmadik IPv4 az eno1-en.
XX.XX.XX.X5 — első IPv4 az eno2-n.
XX.XX.XX.1 — IPv4 gateway.
XXXX:XXXX:XXXX:XXXX::/64 — IPv6 az egész szerverre.
XXXX:XXXX:XXXX:XXXX:1:2::/96 — IPv6 az eno2-hez, minden más kívülről az eno1-en érkezik.
XXXX:XXXX:XXXX:XXXX::1 — IPv6 gateway (fontos megjegyezni, hogy itt másképpen kellene eljárni. Az IPv6 switch IP-jét kellene megadni).
dns-nameservers — a 127.0.0.1 (mivel helyben van telepítve a bind) és a 213.248.1.6 (ez a tech.ru).

«table eno1t» és «table eno2t» — a route-rule értelme az, hogy az eno1-en érkező forgalom -> menjen az eno1-en, míg az eno2-n érkező forgalom -> menjen az eno2-n. Továbbá a szerver kezdeményezéséből származó kapcsolatok az eno1-en távoznak.

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

Ezzel a parancsal azt állítjuk be, hogy bármilyen érthetetlen forgalmat, ami bármilyen rule alá esik, amelyik «table eno1t»-ként van megjelölve -> irányítsuk az eno1 interfészre.

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

Ezzel a parancsal azt állítjuk be, hogy a szerver kezdeményezésével érkező forgalmat irányítsuk az eno1 interfészre.

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

Ezzel a parancsal beállítjuk a forgalom címkézésének szabályait.

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

Ez a blokk beállítja a második IPv4-et az eno1 interfészhez.

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

Ezzel a parancsal a OpenVPN ügyfelektől a helyi IPv4-ek elérhetőségét állítjuk be, kivéve XX.XX.XX.X0.
Miért elegendő ez a parancs minden IPv4-hez — még mindig nem értem.

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

Ezzel a parancsal beállítjuk a címét a saját interfésznek. A szerver ezt az «kimenő» címként fogja használni. Más célra nem fogják használni.

Miért ilyen bonyolult a «:1:1::» megadás? Ahhoz, hogy az OpenVPN rendesen működjön, és csak ennek érdekében. Részletesebben később.

A gatewayről — így működik és ennyi. De helyesen — ide kellene megadni az IPv6 switch IP-jét, amelyhez a szerver csatlakozik.

Mindazonáltal valamiért az IPv6 megszűnik működni, ha így csinálom. Valószínűleg a tech.ru valamilyen furcsasága áll a háttérben.

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

Ez az IPV6 cím hozzáadása az interfészhez. Ha egy tucat cím kell — akkor egy tucat sorra van szükség e fájlban.

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

Megjelöltem az összes interfész címét és alhálózatát, hogy áttekinthető legyen.
eno1 — kötelezően «/64»-nek kell lennie — mert ez a teljes címpoolunk.
tun0 — a hálózati alhálózatoknak kötelezően nagyobbnak kell lenniük, mint az eno1. Különben nem lehet beállítani az IPv6 átjárót az OpenVPN ügyfelek számára.
eno2 — a hálózati alhálózatoknak kötelezően nagyobbnak kell lenniük, mint a tun0. Különben az OpenVPN ügyfelek nem tudnak eljutni a helyi IPv6 címekhez.
A szemléltetés érdekében 16-os alhálózati lépést választottam, de szükség esetén akár «1» lépést is lehet beállítani.
Tehát 64+16 = 80, és 80+16 = 96.

A még nagyobb szemléltetés érdekében:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY — ezek a címek, amelyeket a konkrét webhelyekhez vagy szolgáltatásokhoz kell hozzárendelni az eno1 interfészen.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY — ezek a címek, amelyeket a konkrét webhelyekhez vagy szolgáltatásokhoz kell hozzárendelni az eno2 interfészen.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY — ezek a címek, amelyeket az OpenVPN ügyfeleknek kell hozzárendelni, vagy OpenVPN célcímekként kell használni.

A hálózat beállításához szükség van a szerver újraindítására.
Az IPv4 módosítások az alábbi parancs végrehajtásakor érvényesülnek (kötelezően screen-be kell csomagolni — különben ez a parancs le fogja állítani a hálózatot a szerveren):

/etc/init.d/networking restart

A fájl végére hozzá kell adni a következőt: «/etc/iproute2/rt_tables»:

100 eno1t
101 eno2t

Enélkül nem lehet egyedi táblákat használni a «/etc/network/interfaces» fájlban.
A számoknak egyedieknek kell lenniük, és 65535-nél kisebbek.

Az IPv6 módosítások könnyen módosíthatók újraindítás nélkül, de ez legalább három parancsot meg kell tanulni:

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

A «/etc/sysctl.conf» beállítása

# 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

Ezek a szerverem «sysctl» beállításai. Fontosat emelnék ki.

net.ipv4.ip_forward = 1

Enélkül az OpenVPN egyáltalán nem működik.

net.ipv6.ip_nonlocal_bind = 1

Bárki, aki próbál IPv6 címekhez bindelni (például nginx), miután az interfész beállításra került — hibát fog kapni. A cím nem elérhető.

Egy ilyen helyzet elkerülése érdekében készül ez a beállítás.

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

Ezek a beállítások nélkül az OpenVPN ügyfél IPv6 forgalma nem jut el a világba.

Más beállítások vagy nem kapcsolódnak a témához, vagy nem emlékszem, hogy miért vannak.
De a biztosra menve, úgy hagyom, ahogy van.

Ahhoz, hogy a fájl módosításai anélkül érvényesüljenek, hogy a szervert újra kellene indítani — a következő parancsot kell végrehajtani:

sysctl -p

Részletesebben a «table» szabályokról: habr.com/post/108690

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

Az OpenVPN IPv4 nem működik iptables nélkül.

Az iptables beállításaim a VPN-hez a következők:

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 — ez az én statikus IPv4-címem a helyi gépen.
10.8.0.0/24 — az openvpn IPv4 hálózata. IPv4 címek az openvpn kliensek számára.
A szabályok sorrendje fontos.

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

Ez a korlátozás arra szolgál, hogy csak én, a statikus IP-m segítségével használhassam az OpenVPN-t.

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

IPv4 csomagok átkonfigurálásához az OpenVPN kliensek és az internet között egyet kell megadni ezekből a parancsokból.

Különböző esetekben az egyik opció nem megfelelő.
Az én esetemben mindkét parancs megfelelő.
A dokumentáció átolvasása után az első opciót választottam, mert kevesebb CPU-t használ.

Ahhoz, hogy minden iptables beállítás érvényesüljön újraindítás után, el kell menteni valahová.

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

Ezek a nevek nem véletlenül lettek kiválasztva. Az „iptables-persistent” csomag használja őket.

apt-get install iptables-persistent

Az OpenVPN alapcsomag telepítése:

apt-get install openvpn easy-rsa

Beállítjuk a sablont a tanúsítványokhoz (helyettesítse a saját értékeivel):

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

Szerkeszteni fogjuk a tanúsítványok sablonbeállításait:

mcedit vars

...
# Ezek a mezők alapértelmezett értékei
# amelyek a tanúsítványban kerülnek elhelyezésre.
# Ne hagyjon egyetlen mezőt sem üresen.
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"

# X509 Tárgy Mező
export KEY_NAME="server"
...

Létrehozzuk a szerver tanúsítványt:

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

Előkészítjük a lehetőséget, hogy létrehozhassuk a végső „client-name.opvn” fájlokat:

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

Előkészítjük a szkriptet, amely összeállítja az összes fájlt egyetlen opvn fájlba.

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

Létrehozzuk az első OpenVPN klienst:

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

A fájl „~/client-configs/files/client-name.ovpn” eljuttatása a kliens eszközére.

Az iOS felhasználók számára egy trükköt kell alkalmazni:
A «tls-auth» címke tartalmának megjegyzések nélkül kell lennie.
Valamint a «key-direction 1»-et közvetlenül a «tls-auth» címke elé kell helyezni.

Beállítjuk az OpenVPN szerver konfigurációját:

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

Ez szükséges ahhoz, hogy statikus címet rendeljünk minden ügyfélhez (nem kötelező, de én használom):

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

A legnehezebb és kulcsfontosságú elem.

Sajnos az OpenVPN még nem tud automatikusan IPv6 gateway-t beállítani az ügyfelek számára.
Kézzel kell átkonfigurálni ezt minden egyes ügyfél számára.

# 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"

A fájl «/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

A fájl «/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

Mindkét szkript a «/etc/openvpn/variables» fájlt használja:

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

Nem emlékszem, miért írtam ezt így.

Jelenleg furcsán néz ki a netmask = 112 (itt 96-nak kellene lennie).
És a prefix is furcsa, nem felel meg a tun0 hálózatnak.
De rendben, így hagyom.

cipher DES-EDE3-CBC

Ez ízlés kérdése - én ilyen titkosítást választottam a kapcsolat számára.

Részletesebben az OpenVPN IPv4 beállításáról.

Részletesebben az OpenVPN IPv6 beállításáról.

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

A fő csomag telepítése:

apt-get install postfix

A telepítés során válasszuk az «internet-site» lehetőséget.

Az én «/etc/postfix/main.cf» fájlom így néz ki:

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

# a .domain hozzáfűzése a MUA feladata.
append_dot_mydomain = no

readme_directory = no

# Lásd http://www.postfix.org/COMPATIBILITY_README.html -- az alapértelmezett friss telepítéseknél 2.
compatibility_level = 2

# TLS paraméterek
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

# Tárolási típus
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

# SMTP-Auth beállítások
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

# IP cím domainként
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Nézzük meg ennek a konfigurációnak a részleteit.

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

A hírportál olvasói szerint ez a blokk `félrevezető információkat és téves téziseket` tartalmaz.Csak 8 évvel a karrierem kezdete után kezdtem megérteni, hogyan működik az SSL.

Ezért merem leírni, hogyan lehet használni az SSL-t (anélkül, hogy válaszolnék arra a kérdésre, «Hogyan működik ez?» és «Miért működik ez?»).

A modern titkosítás alapja a kulcspárok létrehozása (két nagyon hosszú karakterlánc).

Egy «kulcs» privát, a másik kulcs «nyilvános». A privát kulcsot titokban kell tartanunk, a nyilvános kulcsot pedig mindenkinek odaadhatjuk.

A nyilvános kulcs segítségével egy szöveges sort lehet titkosítani, amelyet csak a privát kulcs tulajdonosa tud visszafejteni.
Nos, ez a technológia lényege.

1. lépés — https weboldalak.
A böngésző a webservertől értesül arról, hogy az oldal https és ezért kéri a nyilvános kulcsot.
A web server provides a public key. The browser uses the public key to encrypt the HTTP request and sends it.
Only the one who has the private key, that is, only the server to which the request is made, can read the HTTP request content.
The HTTP request contains at least a URI. Therefore, if a country tries to restrict access not to the entire website but to a specific page, it is impossible to do so for HTTPS websites.

Step №2 — encrypted response.
The web server gives a response that can easily be read on the way.
The solution is quite simple — the browser locally forms a matching pair of private and public keys for each HTTPS site.
And together with the request for the site's public key, it sends its local public key.
The web server remembers it and encrypts the HTTP response for that specific client using this public key.
Now the HTTP response can only be decrypted by the holder of the client's browser's private key (that is, the client themselves).

Step №3 — establishing a secure connection over a public channel.
In example №2, there is a vulnerability — nothing prevents malicious actors from intercepting the HTTP request and modifying the information about the public key.
Thus, the intermediary will clearly see all the content of the sent and received messages until the communication channel is changed.
Dealing with this is quite simple — just send the browser's public key as a message encrypted with the web server's public key.
The web server then first sends a response of the type 'your public key is like this' and encrypts this message with the same public key.
The browser checks the response — if the message 'your public key is like this' arrives, it is a 100% guarantee that this communication channel is secure.
How secure is it?
The creation of such a secure communication channel occurs at a speed of ping*2. For example, 20ms.
The attacker must either previously possess the private key of one of the parties or crack the private key in a couple of milliseconds.
Cracking one modern private key can take decades on a supercomputer.

Step №4 — public database of public keys.
It is clear that in this whole story there exists the possibility for an attacker sitting on the communication channel between the client and the server.
Az ügyfél lehetősége, hogy szerverként lépjen fel, míg a szerver ügyfélként. És szimulálni a kulcsokat mindkét irányban.
Így a támadó látni fogja az összes forgalmat, és lehetősége lesz a forgalom "szerkesztésére".
Például megváltoztathatja, hova küldjenek pénzt, másolhatja az online bank jelszavát, vagy blokkolhat "nem kívánt" tartalmakat.
A támadók ellen egy nyilvános adatbázist találtak ki, amely minden HTTPS weboldal számára nyilvános kulcsokat tartalmaz.
Minden böngésző "tud" arról, hogy körülbelül 200 ilyen adatbázis létezik. Ez előre be van állítva minden böngészőben.
"Tudása" minden tanúsítvány nyilvános kulcsával van alátámasztva. Vagyis nem lehet hamisítani a kapcsolatot egy adott hitelesítési központtal.

Most már egyszerűen érthető, hogyan használhatjuk az SSL-t a HTTPS esetében.
Ha kicsit használjuk az észünket, akkor világos lesz, hogyan tudják a titkosszolgálatok feltörni ezt a rendszert. De ennek rengeteg erőfeszítése kerülne.
A szervezeteknek, mint az NSA vagy a CIA, gyakorlatilag lehetetlen feltörni a meglévő védelmi szintet, még VIP esetén is.

Még hozzáfűznék az SSH kapcsolatokról. Ott nincsenek nyilvános kulcsok, mit tegyünk? A kérdés két módon megoldható.
SSH-jelszó opció:
Az első kapcsolat során az SSH-kliensek figyelmeztetniük kell, hogy új nyilvános kulcs érkezett az SSH-szervertől.
A további kapcsolatok során, ha megjelenik a "új nyilvános kulcs az SSH-szervertől" figyelmeztetés, az azt jelenti, hogy megpróbálnak lehallgatni.
Vagy pedig az első kapcsolat során lehallgattak, és most közvetlen kapcsolatban állsz a szerverrel.
Valójában azért, mert a lehallgatás tényét könnyen, gyorsan és erőfeszítés nélkül lehet felfedni, ezt a támadást csak különleges esetekben alkalmazzák egy adott ügyfél ellen.

SSH-kulcs opció:
Végy egy pendrive-ot, és írj rá egy privát kulcsot az SSH-szerverhez (ehhez vannak kifejezések és sok lényeges részlet, de én most csak a tájékoztatás célját szolgálom, nem pedig használati utasítást írok).
A nyilvános kulcsot a gépen hagyjuk, ahol az SSH-kliens lesz, és azt is titokban tartjuk.
Hozd a pendrive-ot a szerverhez, csatlakoztasd, másold át a privát kulcsot, majd égesd el a pendrive-ot, és szórd szét a hamvait a szélben (vagy legalább formázd zero-k feltöltésével).
Ez az egész — egy ilyen művelet után lehetetlenné válik egy ssh kapcsolat feltörése. Persze 10 év alatt egy szuperszámítógépen meg lehet nézni a forgalmat — de ez egy külön történet.

Elnézést a témától való eltérést.

Tehát most, hogy a elmélet világos. Mesélek a ssl tanúsítvány létrehozási folyamatáról.

Az „openssl genrsa” segítségével létrehozzuk a privát kulcsot és a „mintákat” a nyilvános kulcshoz.
A „mintákat” elküldjük egy harmadik félnek, akinek körülbelül $9-ot fizetünk a legegyszerűbb tanúsítványért.

Két órán belül megkapjuk ezt a harmadik féltől a „nyilvános” kulcsunkat, és még néhány nyilvános kulcsot.

Miért kell egy harmadik félnek fizetni a nyilvános kulcsom elintézéséért — ez egy külön kérdés, itt most nem tárgyaljuk.

Most már világos, hogy mi a jelentősége a feliratnak:

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

A „/etc/ssl” mappa tartalmazza az összes fájlt az ssl kérdésekkel kapcsolatban.
domain1.com — a domain neve.
2018 — a kulcsok létrehozásának éve.
„key” — a fájl jelölése, hogy privát kulcsról van szó.

És ennek a fájlnak a jelentése:

smtpd_tls_cert_file= /etc/ssl/domain1.com.2018.chained.crt
domain1.com — a domain neve.
2018 — a kulcsok létrehozásának éve.
chained — jelölés, hogy itt nyilvános kulcsok láncolata található (az első a mi nyilvános kulcsunk, a többi pedig, ami a nyilvános kulcsot kiállító cégtől érkezett).
crt — jelölés, hogy itt egy kész tanúsítvány van (nyilvános kulcs technikai magyarázatokkal).

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

Ez a beállítás itt nem használatos, de példának írtam.

Mert egy hiba ebben a paraméterben azt okozza, hogy a szervered spamet küld (akaratod ellenére).

Aztán próbálj meg mindenkinek bizonyítani, hogy nem vagy hibás.

recipient_delimiter = +

Lehetséges, hogy sokan nem tudják, ez egy szabványos karakter a levelek rangsorolásához, és a legtöbb modern levelezőszerver támogatja.

Például, ha van egy e-mail fiókod „username@gmail.com”, próbálj meg írni a következő címre: „username+spam@gmail.com” — nézd meg, mi történik.

inet_protocols = ipv4

Ez lehet, hogy zavaró lesz.

De nem ok nélkül. Minden új domain — alapértelmezés szerint csak IPv4, később külön-külön aktiválom az IPv6-ot.

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

Itt beállítjuk, hogy minden beérkező e-mail a dovecot-ba menjen.
És a domain, mailbox, alias szabályokat nézd meg az adatbázisban.

/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

Most már a postfix tudja, hogy a levelezés fogadásához a dovecot hitelesítése szükséges.

Nem igazán értem, miért kell ezt itt megismételni. Már korábban megadtuk a 'virtual_transport'-ban, amit kellett.

De a postfix egy nagyon régi rendszer — valószínűleg ezek a régi idők óta itt maradt 'manipulációk'.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Ezt minden egyes levelezőszerver esetében a saját igényei szerint kell beállítani.

Három levelezőszerverem van, és ezek a beállítások nagyon eltérőek a felhasználás különböző követelményei miatt.

Gondosan kell beállítani — különben a spam özönleni fog hozzád, vagy ami még rosszabb — spam fog áradni tőled.

# SPF
policyd-spf_time_limit = 3600

Beállítás egy pluginhoz, amely az érkező levelek SPF ellenőrzésével foglalkozik.

# 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

Beállítás, hogy minden kimenő levelet DKIM aláírással kell ellátnunk.

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

Ez alapvető részlet a levelek útvonalának beállításában, amikor php szkriptekből levél küldése történik.

A fájl „/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:

Bal oldalon — reguláris kifejezések. Jobb oldalon — a levélhez hozzárendelt címke.
A postfix a címke alapján figyelembe vesz még néhány konfigurációs sort az adott levélhez.

Hogyan konfigurálják át a postfixet a konkrét levélhez — ezt a „master.cf” fájlban adják meg.

A 4., 5., 6. sorok a legfontosabbak. A levél küldésének domainje határozza meg a címkét, amelyet használunk.
De nem mindig jelölik a 'from' mezőt a régi php kódokban. Ilyenkor a felhasználónév segít.

A téma már így is széleskörű — nem szeretnék eltérni az nginx+fpm beállításaitól.

Röviden — minden webhely számára saját linux-user tulajdonost határozunk meg. És ennek megfelelően a saját fpm-poolt.

A fpm-pool bármilyen php verziót használhat (ez nagyszerű, mert egy szerveren könnyedén használhatunk különböző php verziókat, és akár különböző php.ini fájlokat is).

Tehát ez a konkrét linux-user 'www-domain2' rendelkezik a domain2.com webhellyel. Ezen a webhelyen van kód levelek küldésére, anélkül hogy megadná a 'from' mezőt.

Még ebben az esetben is a levelek helyesen fognak távozni, és soha nem kerülnek a spam közé.

Az én ‘/etc/postfix/master.cf’ fájlom így néz ki:

...
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

A fájl nem teljesen lett bemutatva — már így is nagyon nagy.
Csak a módosított részeket jelöltem meg.

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}

Ezek a spamassassin-nel kapcsolatos beállítások, erről később.

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

Engedélyezzük a hozzácsatlakozást a levelezőszerverhez a 587-es porton.
Ehhez kötelező a bejelentkezés.

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

Bekapcsoljuk az SPF ellenőrzést.

apt-get install postfix-policyd-spf-python

Telepítjük a csomagot az SPF ellenőrzéséhez.

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

Ez a legérdekesebb része. Ez lehetőséget ad arra, hogy leveleket küldjünk egy adott domain számára, egy adott IPv4/IPv6 címről.

Ezt az rDNS miatt csináljuk. Az rDNS a IP címhez tartozó string beszerzését jelenti.
Egy levelezésnél ezt a lehetőséget arra használják, hogy megerősítsék, hogy a helo pontosan megfelel ahhoz az rDNS-hez, ahonnan az emailt küldték.

Ha a helo nem felel meg a levelezési domainnek, akinek nevében a levelet küldték — spam pontok gyűlnek.

Helo nem felel meg az rDNS-nek — sok spam pontot gyűjt.
Ezek szerint minden domainnek saját IP-címre van szüksége.
Az OVH esetén a kezelőfelületen lehetőség van az rDNS megadására.
A tech.ru esetében a kérdés támogatáson keresztül megoldható.
Az AWS esetében a kérdés támogatáson keresztül megoldható.
Az «inet_protocols» és «smtp_bind_address6» az IPv6 támogatás bekapcsolásához szükséges.
IPv6 esetén is szükséges a rDNS beállítása.
Az «syslog_name» a naplók olvashatósága érdekében van.

Tanúsítványok vásárlása itt ajánlom.

A postfix+dovecot konfigurálása itt található.

SPF beállítása.

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

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

MySQL beállítása, maguk a csomagok kerülnek telepítésre.

A fájl «/etc/dovecot/conf.d/10-auth.conf»

disable_plaintext_auth = yes
auth_mechanisms = plain login

Csak titkosított módú hitelesítés.

A fájl «/etc/dovecot/conf.d/10-mail.conf»

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

Itt megadjuk a levelek tárolási helyét.

Azt akarom, hogy a fájlokban tárolódjanak és domain szerint csoportosítva legyenek.

A fájl «/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 {
  }
}

Ez a dovecot fő konfigurációs fájlja.
Itt kikapcsoljuk a nem titkosított kapcsolatokat.
És bekapcsoljuk a titkosított kapcsolatokat.

A fájl «/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
}

SSL-t állítunk be. Megadjuk, hogy az SSL kötelező.
És magát a tanúsítványt. Fontos részlet, hogy a «local» direktíva megadja, hogy adott helyi IPv4-hez melyik SSL tanúsítványt használjuk.

Egyébként az IPv6 itt nincs beállítva, ezt valamikor majd kijavítom.
XX.XX.XX.X5 (domain2) — nincs tanúsítvány. Az ügyfelek csatlakozásakor a domain1.com-ot kell megadni.
XX.XX.XX.X2 (domain3) — van tanúsítvány, az ügyfelek csatlakozásakor a domain1.com vagy domain3.com megadható.

A fájl «/etc/dovecot/conf.d/15-lda.conf»

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Ez később szükséges lesz a spamassassinhoz.

A fájl «/etc/dovecot/conf.d/20-imap.conf»

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Ez az antispam plugin. A spamassassin képzésére van szükség, amikor a «Spam» mappába költözik.

A fájl «/etc/dovecot/conf.d/20-pop3.conf»

protocol pop3 {
}

Egyszerűen létezik egy ilyen fájl.

A fájl «/etc/dovecot/conf.d/20-lmtp.conf»

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

lmtp beállítása.

A fájl „/etc/dovecot/conf.d/90-antispam.conf”

plug-in {
  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
}

A spamassassin tanítása a "Spam" mappába való áthelyezéskor.

A fájl „/etc/dovecot/conf.d/90-sieve.conf”

plug-in {
  sieve = ~/ .dovecot.sieve
  sieve_dir = ~/sieve
  sieve_after = /var/lib/dovecot/sieve/default.sieve
}

A fájl, amely meghatározza, mit tegyünk a bejövő levelekkel.

A fájl „/var/lib/dovecot/sieve/default.sieve”

kérjük, fordítsa le a fájlt: „sievec default.sieve”.

A fájl „/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 }

SQL fájlok megadása a hitelesítéshez.

A fájl önálló hitelesítési módként.
A fájl „/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';

Ez megfelel a postfix hasonló beállításainak.

A fájl „/etc/dovecot/dovecot.conf”

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

A fő konfigurációs fájl.

Fontos, hogy itt adjuk meg a protokollokat.
============= SpamAssassin =============

apt-get install spamassassin spamc

Csomagok telepítése.

adduser spamd --disabled-login

Felhasználó létrehozása, akinek a nevében.

systemctl enable spamassassin.service

A spamassassin szolgáltatás automatikus indítása a rendszerbetöltéskor.

A fájl „/etc/default/spamassassin”:

CRON=1

Az alapértelmezett szabályok automatikus frissítése engedélyezve.

A fájl „/etc/spamassassin/local.cf”:

report_safe 0use_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

A mysql adatbázist „sa” kell létrehozni „sa” felhasználóval és „password” jelszóval (helyettesítse valami megfelelővel).

A report_safe — a levél helyett egy spam jelentést küld.

A use_bayes — a spamassassin gépi tanulási beállításai.
Más spamassassin beállításokat korábban alkalmaztak a cikkben.

Átfogó spamassassin beállítás.

Az új spamlevelek IMAP mappába történő áthelyezése a „Spam”..
Dovecot + SpamAssassin egyszerű kombinációja..
Ajánlom a spamassassin gépi tanulásának elméleti áttekintését az IMAP mappákba való levelek mozgásakor (és nem ajánlom a gyakorlati alkalmazást)..
============= Kapcsolódás a közösséghez =============.

kapcsolat a közösséggel

Egy ötletet szeretnék bedobni a közösségbe arról, hogyan lehetne növelni az elküldött e-mailek védelmét. Mivel ennyire mélyen elmerültem a levelezés világában.

A felhasználó számára lehetővé kell tenni, hogy a kliensén (Outlook, Thunderbird, böngészőbővítmény stb.) létrehozhasson egy pár kulcsot. Egy nyilvános és egy privát kulcsot. A nyilvános kulcsot a DNS-be kell küldeni. A privát kulcsot a kliens gépén kell tárolni. A levelező szervereknek képesnek kell lenniük arra, hogy a nyilvános kulcsot használják a konkrét címzettnek történő küldéshez.

És a spam elleni védelem érdekében az ilyen levelek esetében (igen, a levelező szerver nem tudja megnézni a tartalmat) három szabályt kell bevezetni:

1. Kötelező a valódi DKIM aláírás, kötelező az SPF, kötelező az rDNS.
2. Neurális hálózat az antis spam oktatására + adatbázis a kliens oldalán.
3. A titkosítási algoritmusnak úgy kell működnie, hogy a küldő félnek 100-szor több CPU teljesítményt kellene felhasználnia a titkosításhoz, mint a fogadó félnek.

A nyilvános leveleken kívül ki kell dolgozni egy ajánlólevél mintát az 'védett levelezés megkezdésére'. Az egyik felhasználó (levélfiók) elküld egy másik levélfióknak egy levelet csatolmányként. A levélben javaslat szövege áll, hogy kezdjék el a biztonságos kommunikációs csatornát és a levélfiók tulajdonosának nyilvános kulcsát (a privát kulcs a kliens oldalán marad).

Még pár kulcsot is létrehozhatnak kifejezetten minden egyes levelezéshez. A fogadó felhasználó elfogadhatja ezt az ajánlatot, és elküldheti a saját nyilvános kulcsát (szintén kifejezetten ehhez a levelezéshez létrehozva). Ezután az első felhasználó elküld egy ellenőrző levelet (a második felhasználó nyilvános kulcsával titkosítva) - aminek a megérkezésével a második felhasználó megbízhatónak tekintheti a létrejött kommunikációs csatornát. Ezután a második felhasználó egy kontroll levelet küld - és ekkor az első felhasználó is megbízhatónak tekintheti a létrejött csatornát.

A kulcsok út közbeni elfogása ellen harcolva a protokollban lehetővé kell tenni legalább egy nyilvános kulcs flash meghajtón történő átvitelét.

És ami a legfontosabb - hogy mindez működjön (a kérdés: 'ki fog ezért fizetni?'):
Beillesztjük a 10 dollártól kezdődő árú email tanúsítványokat 3 évre. Ezek lehetővé teszik a feladó számára, hogy a DNS-ben jelezze, hogy „a közzétett kulcsaim ott vannak”. Emellett biztosítják a biztonságos kapcsolatok indítását. Ugyanakkor – a kapcsolatokat ingyenesen fogadják.
A Gmail végre monetizálni kezdi a felhasználóit. 10 dollár 3 évre – jogot ad a biztonságos levelezési csatornák létrehozására.

============= Következtetés =============

Az egész cikk teszteléséhez egy hónapra bérelni akartam egy dedikált szervert és vásárolni egy domaint SSL tanúsítvánnyal.

De az élet különböző körülményei miatt ez a kérdés 2 hónapig elhúzódott.
És amikor újra volt szabad időm – úgy döntöttem, hogy közzéteszem a cikket úgy, ahogy van, nem kockáztatva, hogy a publikáció tovább tartson akár egy évig is.

Ha sok kérdés érkezik arról, hogy „itt nem elég részletesen van leírva” – valószínűleg sikerül majd energiát találni arra, hogy béreljek egy dedikált szervert új domainnel és új SSL tanúsítvánnyal, és még részletesebben leírni, és ami a legfontosabb – feltárni minden fontos részletet, amit eddig elhanyagoltam.

Szeretném megkapni a véleményeket az email tanúsítványok ötletéről is. Ha az ötlet tetszik, megpróbálok energiát találni egy vázlat megírására az RFC-hez.

Nagyméretű cikkek másolásakor – kérlek, hivatkozz ezen cikkre.
Bármely más nyelvre történő fordításkor – kérlek, hivatkozz ezen cikkre.
Angol nyelvre próbálom majd én magam lefordítani, és kereszthivatkozásokat hagyok.

Forrás: habr.com