🥇Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Több interfészek + SpamAssassin-learn + Bind

Ez a cikk egy modern levelezőszerver beállításáról szól.
Postfix + Dovecot. SPF + DKIM + rDNS. IPv6-tal.
TSL titkosítással. Több tartomány támogatásával – vegyen részt valódi SSL-tanúsítvánnyal.
Antispam védelemmel és magas levélszemét-ellenőrzéssel más levelezőszerverektől.
Több fizikai interfészt támogat.
OpenVPN-nel, amelyhez IPv4-en keresztül csatlakozik, és amely biztosítja az IPv6-ot.

Ha nem szeretné megtanulni ezeket a technológiákat, de szeretne beállítani egy ilyen szervert, akkor ez a cikk neked szól.

A cikk nem tesz kísérletet minden részlet kifejtésére. A magyarázat arra vonatkozik, hogy mi nem szabványos vagy fontos a fogyasztó szempontjából.

A levelezőszerver létrehozásának motivációja régóta álmom volt. Lehet, hogy ez hülyén hangzik, de IMHO, sokkal jobb, mint álmodozni egy új autóról a kedvenc márkádtól.

Az IPv6 beállításának két oka van. Egy informatikusnak folyamatosan új technológiákat kell tanulnia a túléléshez. Szeretnék szerényen hozzájárulni a cenzúra elleni küzdelemhez.

Az OpenVPN beállításának motivációja csupán az, hogy az IPv6 működjön a helyi gépen.
Több fizikai interfész létrehozásának motivációja az, hogy a szerveremen van egy „lassú, de korlátlan” felület, a másik pedig „gyors, de tarifával”.

A kötési beállítások beállításának oka az, hogy az internetszolgáltatóm instabil DNS-kiszolgálót biztosít, és a google is néha meghibásodik. Szeretnék egy stabil DNS szervert személyes használatra.

Motiváció cikkíráshoz – 10 hónappal ezelőtt írtam egy piszkozatot, és már kétszer megnéztem. Még ha a szerzőnek rendszeresen szüksége is van rá, nagy a valószínűsége annak, hogy másoknak is szüksége lesz rá.

Nincs univerzális megoldás levelezőszerverre. De megpróbálok valami olyasmit írni, hogy „csináld ezt, majd ha minden úgy működik, ahogy kell, dobd ki a felesleges dolgokat”.

A tech.ru cég Colocation szerverrel rendelkezik. Összehasonlítható OVH, Hetzner, AWS. A probléma megoldása érdekében a tech.ru-val való együttműködés sokkal hatékonyabb lesz.

A Debian 9 telepítve van a szerveren.

A szervernek 2 interfésze van: `eno1` és `eno2`. Az első korlátlan, a második pedig gyors.

3 statikus IP-cím található: XX.XX.XX.X0 és XX.XX.XX.X1 és XX.XX.XX.X2 az "eno1" interfészen és XX.XX.XX.X5 az "eno2" interfészen .

Elérhető XXXX:XXXX:XXXX:XXXX::/64 egy IPv6-címkészlet, amely az "eno1" interfészhez van hozzárendelve, és ebből az XXXX:XXXX:XXXX:XXXX:1:2::/96 kérésemre az "eno2"-hez lett rendelve.

3 domain létezik: `domain1.com`, `domain2.com`, `domain3.com`. Létezik SSL-tanúsítvány a "domain1.com" és a "domain3.com" számára.

Van egy Google fiókom, amelyhez szeretném kapcsolni a postafiókomat[e-mail védett]` (levél fogadása és küldése közvetlenül a gmail felületéről).
Kell lennie egy postafióknak[e-mail védett]`, annak az e-mailnek a másolata, amelyből a Gmailben szeretném látni. És ritka az, hogy ` nevében el tudjunk küldeni valamit[e-mail védett]` a webes felületen keresztül.

Kell lennie egy postafióknak[e-mail védett]', amelyet Ivanov az iPhone-járól fog használni.

Az elküldött e-maileknek meg kell felelniük az összes modern antispam követelménynek.
A nyilvános hálózatokon a legmagasabb szintű titkosítást kell biztosítani.
Levelek küldésére és fogadására egyaránt rendelkeznie kell IPv6 támogatással.
Kell lennie egy SpamAssassinnak, amely soha nem törli az e-maileket. És vagy visszapattan, vagy kihagy, vagy az IMAP „Spam” mappájába küldi.
A SpamAssassin automatikus tanulást be kell állítani: ha áthelyezek egy levelet a Spam mappába, akkor ebből tanul; ha áthelyezek egy levelet a Spam mappából, akkor ebből tanul. A SpamAssassin képzés eredményei befolyásolhatják, hogy a levél a Spam mappába kerül-e.
A PHP szkripteknek képesnek kell lenniük levelet küldeni egy adott szerveren lévő bármely domain nevében.
Kell lennie egy openvpn szolgáltatásnak, amely képes IPv6 használatára olyan klienseken, amelyek nem rendelkeznek IPv6-tal.

Először be kell állítania az interfészek és az útválasztást, beleértve az IPv6-ot is.
Ezután be kell állítania az OpenVPN-t, amely IPv4-en keresztül csatlakozik, és statikus-valódi IPv6-címet biztosít az ügyfélnek. Ez a kliens hozzáférhet a kiszolgálón található összes IPv6-szolgáltatáshoz, és hozzáférhet az Internet bármely IPv6-erőforrásához.
Ezután be kell állítania a Postfixet, hogy leveleket + SPF + DKIM + rDNS és más hasonló apróságokat küldjön.
Ezután konfigurálnia kell a Dovecotot és a Multidomaint.
Ezután konfigurálnia kell a SpamAssassin-t és be kell állítania a képzést.
Végül telepítse a Bind-et.

============= Több interfész =============

Az interfészek konfigurálásához ezt be kell írnia az „/etc/network/interfaces” mappába.

# 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

Ezek a beállítások a tech.ru bármely szerverén alkalmazhatók (kis egyeztetéssel a támogatással), és azonnal működni fog, ahogy kell.

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

eno1 az 1. hálózati kártya neve (lassú, de korlátlan).
eno2 a #2 hálózati kártya neve (gyors, de tarifával).
A tun0 az OpenVPN virtuális hálózati kártyájának neve.
XX.XX.XX.X0 – IPv4 #1 az eno1-en.
XX.XX.XX.X1 – IPv4 #2 az eno1-en.
XX.XX.XX.X2 – IPv4 #3 az eno1-en.
XX.XX.XX.X5 – IPv4 #1 az eno2-en.
XX.XX.XX.1 – IPv4-átjáró.
XXXX:XXXX:XXXX:XXXX::/64 - IPv6 a teljes szerverhez.
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 az eno2-hez, minden más kívülről az eno1-be kerül.
XXXX:XXXX:XXXX:XXXX::1 — IPv6 átjáró (érdemes megjegyezni, hogy ezt másként is lehet/kell csinálni. Adja meg az IPv6 kapcsolót).
dns-nameservers - 127.0.0.1 van feltüntetve (mert a bind helyben van telepítve) és 213.248.1.6 (ez a tech.ru webhelyről származik).

„eno1t tábla” és „eno2t tábla” – ezeknek az útvonalszabályoknak az a jelentése, hogy az eno1-en keresztül bemenő forgalom -> azon keresztül indulna, és az eno2 -> átmenő forgalom azon keresztül távozna. És a szerver által kezdeményezett kapcsolatok is az eno1-en mennek keresztül.

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

Ezzel a paranccsal megadjuk, hogy az „eno1t tábla” -> jelzésű szabály alá eső érthetetlen forgalom az eno1 felületre kerüljön.

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

Ezzel a paranccsal megadjuk, hogy a szerver által kezdeményezett forgalom az eno1 felületre kerüljön.

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

Ezzel a paranccsal beállítjuk a forgalom megjelölé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 egy második IPv4-et határoz meg az eno1 interfész számára.

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

Ezzel a paranccsal beállítjuk az útvonalat az OpenVPN kliensektől a helyi IPv4 felé, kivéve a XX.XX.XX.X0.
Még mindig nem értem, hogy ez a parancs miért elég az összes IPv4-hez.

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

Itt állítjuk be magának az interfésznek a címét. A szerver „kimenő” címként fogja használni. Semmilyen módon nem lesz felhasználva.

Miért olyan bonyolult a ":1:1::"? Annak érdekében, hogy az OpenVPN megfelelően és csak erre a célra működjön. Erről később.

Az átjáró témában - ez így működik, és ez rendben van. De a helyes módja annak a kapcsolónak az IPv6-jának feltüntetése, amelyhez a szerver csatlakozik.

Az IPv6 azonban valamiért leáll, ha ezt teszem. Ez valószínűleg valami tech.ru probléma.

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

Ez egy IPv6-cím hozzáadása az interfészhez. Ha száz címre van szüksége, az száz sort jelent ebben a 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

Feljegyeztem az összes interfész címét és alhálózatát, hogy egyértelmű legyen.
eno1 - kell lennie "/64" - mert ez a teljes címkészletünk.
tun0 - az alhálózatnak nagyobbnak kell lennie, mint az eno1. Ellenkező esetben nem lehet IPv6-átjárót konfigurálni az OpenVPN-kliensek számára.
eno2 - az alhálózatnak nagyobbnak kell lennie, mint a tun0. Ellenkező esetben az OpenVPN-kliensek nem férhetnek hozzá a helyi IPv6-címekhez.
Az egyértelműség kedvéért 16-os alhálózati lépést választottam, de ha szeretné, akár „1” lépést is megtehet.
Ennek megfelelően 64+16 = 80, és 80+16 = 96.

A még nagyobb érthetőség érdekében:
Az XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY olyan címek, amelyeket az eno1 interfészen meghatározott webhelyekhez vagy szolgáltatásokhoz kell hozzárendelni.
Az XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY olyan címek, amelyeket az eno2 interfészen meghatározott webhelyekhez vagy szolgáltatásokhoz kell hozzárendelni.
Az XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY olyan címek, amelyeket OpenVPN-kliensekhez kell rendelni, vagy OpenVPN-szolgáltatási címként kell használni.

A hálózat konfigurálásához lehetővé kell tenni a szerver újraindítását.
Az IPv4-módosításokat a rendszer a végrehajtáskor veszi fel (feltétlenül csomagolja be a képernyőbe - különben ez a parancs egyszerűen összeomlik a szerveren):

/etc/init.d/networking restart

Adja hozzá az „/etc/iproute2/rt_tables” fájl végéhez:

100 eno1t
101 eno2t

E nélkül nem használhat egyéni táblázatokat az „/etc/network/interfaces” fájlban.
A számoknak egyedinek kell lenniük, és kisebbnek kell lenniük 65535-nél.

Az IPv6 módosításai egyszerűen módosíthatók újraindítás nélkül, de ehhez legalább három parancsot meg kell tanulni:

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

Az "/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. Hadd emeljek ki valami fontosat.

net.ipv4.ip_forward = 1

E nélkül az OpenVPN egyáltalán nem fog működni.

net.ipv6.ip_nonlocal_bind = 1

Bárki, aki megpróbálja kötni az IPv6-ot (például az nginxet) közvetlenül azután, hogy az interfész létrejött, hibaüzenetet kap. Hogy ez a cím nem elérhető.

Az ilyen helyzet elkerülése érdekében ilyen beállítást kell végezni.

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

Ezen IPv6-beállítások nélkül az OpenVPN-kliensről érkező forgalom nem jut el a világba.

Más beállítások vagy nem relevánsak, vagy nem emlékszem, mire valók.
De minden esetre "úgy, ahogy van" hagyom.

Annak érdekében, hogy a fájl módosításait a kiszolgáló újraindítása nélkül fogadja el, futtassa a következő parancsot:

sysctl -p

További részletek az „táblázat” szabályairól: habr.com/post/108690

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

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

Az én iptableim a következők VPN-hez:

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 az én statikus IPv4-címem a helyi gépen.
10.8.0.0/24 – IPv4 openvpn hálózat. IPv4-címek az openvpn ügyfelek számára.
Fontos a szabályok következetessége.

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 egy korlátozás, így csak én használhatom az OpenVPN-t a statikus IP-címemről.

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

Az IPv4-csomagok OpenVPN-kliensek és az internet közötti továbbításához regisztrálnia kell ezen parancsok egyikét.

Különböző esetekben az egyik lehetőség nem megfelelő.
Mindkét parancs alkalmas az én esetemre.
A dokumentáció elolvasása után az első opciót választottam, mert kevesebb CPU-t használ.

Ahhoz, hogy az iptables összes beállítása újraindítás után felvehető legyen, el kell menteni őket valahova.

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

Az ilyen neveket nem véletlenül választották. Ezeket az "iptables-persistent" csomag használja.

apt-get install iptables-persistent

A fő OpenVPN-csomag telepítése:

apt-get install openvpn easy-rsa

Állítsunk be egy sablont a tanúsítványokhoz (cserélje ki az értékeket):

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

Szerkesszük a tanúsítványsablon beállításait:

mcedit vars

...
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="RU"
export KEY_PROVINCE="Krasnodar"
export KEY_CITY="Dinskaya"
export KEY_ORG="Own"
export KEY_EMAIL="[email protected]"
export KEY_OU="VPN"

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

Szerver tanúsítvány létrehozása:

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

Készítsük elő a végső „kliensnév.opvn” fájlok létrehozásának lehetőségét:

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

Készítsünk elő egy szkriptet, amely az összes fájlt egyetlen opvn fájlba egyesíti.

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}/.crt 
    <(echo -e '</cert>n<key>') 
    ${KEY_DIR}/.key 
    <(echo -e '</key>n<tls-auth>') 
    ${KEY_DIR}/ta.key 
    <(echo -e '</tls-auth>') 
    > ${OUTPUT_DIR}/.ovpn

Az első OpenVPN kliens létrehozása:

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

A „~/client-configs/files/client-name.ovpn” fájl elküldésre kerül az ügyfél eszközére.

iOS kliensek esetén a következő trükköt kell végrehajtania:
A "tls-auth" címke tartalmának megjegyzés nélkül kell lennie.
És tegye a „key-direction 1”-et közvetlenül a „tls-auth” címke elé.

Állítsuk be 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

Erre azért van szükség, hogy minden klienshez statikus címet állítsunk be (nem szükséges, de használom):

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

A legnehezebb és legfontosabb részlet.

Sajnos az OpenVPN még nem tudja, hogyan kell önállóan konfigurálni az IPv6-átjárót az ügyfelek számára.
Ezt „manuálisan” kell továbbítania minden ü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"

„/etc/openvpn/server-clientconnect.sh” fájl:

#!/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

„/etc/openvpn/server-clientdisconnect.sh” fájl:

#!/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 az „/etc/openvpn/variables” fájlt használja:

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

Nehezen tudom megjegyezni, miért van így megírva.

Most a netmask = 112 furcsán néz ki (pontosan 96-nak kell lennie).
És az előtag furcsa, nem egyezik a tun0 hálózattal.
De oké, hagyom úgy ahogy van.

cipher DES-EDE3-CBC

Ez nem mindenkinek való – ezt a módszert választottam a kapcsolat titkosítására.

További információ az OpenVPN IPv4 beállításáról.

További információ az OpenVPN IPv6 beállításáról.

============= Utójavítás ==============

A fő csomag telepítése:

apt-get install postfix

Telepítéskor válassza az „internetes oldal” lehetőséget.

Az "/etc/postfix/main.cf" így néz ki:

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

# appending .domain is the MUA's job.
append_dot_mydomain = no

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2

# TLS parameters
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

# Storage type
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 settings
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 address per domain
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 habrovszkiak szerint ez a blokk „félreinformációkat és téves téziseket tartalmaz”.Csak 8 évvel pályafutásom kezdete után kezdtem megérteni az SSL működését.

Ezért vállalom a bátorságot, hogy leírjam, hogyan kell használni az SSL-t (anélkül, hogy válaszolnék a „Hogyan működik?” és a „Miért működik?” kérdésekre).

A modern titkosítás alapja egy kulcspár (két nagyon hosszú karaktersorozat) létrehozása.

Az egyik „kulcs” privát, a másik kulcs „nyilvános”. A privát kulcsot nagyon gondosan titokban tartjuk. A nyilvános kulcsot mindenkinek kiosztjuk.

Nyilvános kulcs használatával titkosíthat egy szöveget, így csak a titkos kulcs tulajdonosa tudja visszafejteni.
Nos, ez az egész technológia alapja.

1. lépés – https-webhelyek.
Egy webhely elérésekor a böngésző megtanulja a webszervertől, hogy az oldal https, és ezért nyilvános kulcsot kér.
A webszerver megadja a nyilvános kulcsot. A böngésző a nyilvános kulcsot használja a http-kérés titkosításához és elküldéséhez.
A http-kérés tartalmát csak azok olvashatják, akik rendelkeznek a privát kulccsal, vagyis csak az a szerver, amelyre a kérést küldik.
A HTTP-kérés legalább egy URI-t tartalmaz. Ezért, ha egy ország nem a teljes webhelyre, hanem egy adott oldalra próbálja korlátozni a hozzáférést, akkor ez a https webhelyek esetében lehetetlen.

2. lépés – titkosított válasz.
A webszerver útközben is könnyen olvasható választ ad.
A megoldás rendkívül egyszerű – a böngésző helyileg ugyanazt a privát-nyilvános kulcspárt állítja elő minden https oldalhoz.
És a webhely nyilvános kulcsának kérésével együtt elküldi a helyi nyilvános kulcsát.
A webszerver megjegyzi, és a http-válasz küldésekor titkosítja azt egy adott kliens nyilvános kulcsával.
A http-választ most csak a kliens böngésző privát kulcsának tulajdonosa tudja visszafejteni (vagyis maga az ügyfél).

3. lépés - biztonságos kapcsolat létrehozása nyilvános csatornán keresztül.
A 2. példában van egy sebezhetőség – semmi sem akadályozza meg a jó szándékú embereket abban, hogy elkapjanak egy http-kérést, és módosítsák a nyilvános kulcsra vonatkozó információkat.
Így a közvetítő egyértelműen látni fogja az elküldött és fogadott üzenetek teljes tartalmát, amíg a kommunikációs csatorna meg nem változik.
Ennek kezelése rendkívül egyszerű – csak küldje el a böngésző nyilvános kulcsát üzenetként a webszerver nyilvános kulcsával titkosítva.
A webszerver ezután először olyan választ küld, mint „a nyilvános kulcsa ilyen”, és ezt az üzenetet ugyanazzal a nyilvános kulccsal titkosítja.
A böngésző megnézi a választ – ha a „nyilvános kulcsod ilyen” üzenet érkezik – ez 100%-os garancia arra, hogy ez a kommunikációs csatorna biztonságos.
Mennyire biztonságos?
Egy ilyen biztonságos kommunikációs csatorna létrehozása ping*2 sebességgel történik. Például 20 ms.
A támadónak előzetesen rendelkeznie kell az egyik fél privát kulcsával. Vagy talál egy privát kulcsot néhány ezredmásodperc alatt.
Egy modern privát kulcs feltörése évtizedekig tart egy szuperszámítógépen.

4. lépés – nyilvános kulcsok nyilvános adatbázisa.
Nyilvánvalóan ebben az egész történetben lehetőség van arra, hogy a támadó ráüljön a kliens és a szerver közötti kommunikációs csatornára.
A kliens kiadhatja magát a szervernek, a szerver pedig úgy, mintha az ügyfél lenne. És emuláljon egy kulcspárt mindkét irányban.
Ekkor a támadó látni fogja az összes forgalmat, és képes lesz „szerkeszteni” a forgalmat.
Például módosítsa a pénzküldési címet, másolja ki a jelszót az online bankból, vagy blokkolja a „kifogásolható” tartalmat.
Az ilyen támadók leküzdésére egy nyilvános adatbázist készítettek nyilvános kulcsokkal minden https webhelyhez.
Minden böngésző körülbelül 200 ilyen adatbázis létezéséről „tud”. Ez minden böngészőben előre telepítve van.
A „tudást” minden tanúsítvány nyilvános kulcsa támogatja. Ez azt jelenti, hogy az egyes hitelesítési hatóságokkal való kapcsolat nem hamisítható.

Most már egyszerűen megértjük, hogyan kell használni az SSL-t https-hez.
Ha használja az agyát, akkor kiderül, hogy a speciális szolgálatok hogyan tudnak valamit feltörni ebben a struktúrában. De ez óriási erőfeszítésekbe fog kerülni.
És az NSA-nál vagy a CIA-nál kisebb szervezetek - szinte lehetetlen feltörni a meglévő védelmi szintet, még a VIP-ek számára is.

Hozzáteszem az ssh kapcsolatokat is. Nincsenek nyilvános kulcsok, szóval mit tehet? A problémát kétféleképpen oldják meg.
ssh-by-password opció:
Az első csatlakozás során az ssh-kliensnek figyelmeztetnie kell, hogy új nyilvános kulcsunk van az ssh-kiszolgálótól.
És a további kapcsolatok során, ha megjelenik az „új nyilvános kulcs az ssh szerverről” figyelmeztetés, az azt jelenti, hogy megpróbálják lehallgatni Önt.
Vagy lehallgatták az első kapcsolatnál, de most már közvetítők nélkül kommunikálsz a szerverrel.
Valójában, mivel a lehallgatás ténye könnyen, gyorsan és erőfeszítés nélkül kiderül, ezt a támadást csak speciális esetekben alkalmazzák egy adott ügyfél számára.

ssh-by-key opció:
Fogunk egy pendrive-ot, ráírjuk az ssh szerver privát kulcsát (erre van kifejezés és sok fontos árnyalat, de én egy oktató programot írok, nem használati utasítást).
A nyilvános kulcsot azon a gépen hagyjuk, ahol az ssh kliens lesz, és azt is titokban tartjuk.
A flash meghajtót bevisszük a szerverre, behelyezzük, kimásoljuk a privát kulcsot, a pendrive-ot pedig elégetjük és a hamvakat szélnek szórjuk (vagy legalább nullákkal formázzuk).
Ez minden - egy ilyen művelet után lehetetlen lesz feltörni egy ilyen ssh-kapcsolatot. Természetesen 10 év múlva szuperszámítógépen is lehet majd nézni a forgalmat – de ez egy másik történet.

Elnézést az offtopicért.

Tehát most, hogy az elmélet ismert. Elmondom az SSL-tanúsítvány létrehozásának folyamatát.

Az „openssl genrsa” használatával létrehozunk egy privát kulcsot és „üres mezőket” a nyilvános kulcshoz.
Az „üres papírokat” elküldjük egy külső cégnek, akinek körülbelül 9 dollárt fizetünk a legegyszerűbb tanúsítványért.

Néhány óra elteltével megkapjuk a „nyilvános” kulcsunkat és számos nyilvános kulcsot ettől a harmadik féltől.

Hogy miért fizessen egy külső cég a nyilvános kulcsom regisztrációjáért, az külön kérdés, itt nem foglalkozunk vele.

Most már világos, hogy mi a felirat jelentése:

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

Az „/etc/ssl” mappa az ssl-problémák összes fájlját tartalmazza.
domain1.com – domain név.
2018 a kulcsalkotás éve.
„kulcs” – annak megjelölése, hogy a fájl privát kulcs.

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

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domain1.com – domain név.
2018 a kulcsalkotás éve.
láncolt - annak megjelölése, hogy létezik nyilvános kulcsok lánca (az első a nyilvános kulcsunk, a többi pedig a nyilvános kulcsot kibocsátó cégtől származik).
crt - annak megjelölése, hogy van kész tanúsítvány (nyilvános kulcs műszaki magyarázatokkal).

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

Ezt a beállítást ebben az esetben nem használjuk, hanem példaként írjuk le.

Mivel a paraméter hibája azt eredményezi, hogy a kiszolgáló spameket küld (akarata nélkül).

Aztán bizonyítsd be mindenkinek, hogy nem vagy bűnös.

recipient_delimiter = +

Sokan nem tudják, de ez egy szabványos karakter az e-mailek rangsorolásához, és a legtöbb modern levelezőszerver támogatja.

Például ha van egy postafiókja "[e-mail védett]"próbáld meg elküldeni"[e-mail védett]"- nézd, mi sül ki belőle.

inet_protocols = ipv4

Ez zavaró lehet.

De ez nem csak így van. Minden új domain alapból csak IPv4, akkor mindegyiknél külön bekapcsolom 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 megadjuk, hogy minden bejövő levél a dovecot-ba kerüljön.
És a domain, postafiók, alias szabályok - 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

A postfix most már tudja, hogy a leveleket csak a dovecot-tal történő engedélyezés után fogadják el további küldésre.

Nem igazán értem, hogy ezt miért duplikálják itt. A „virtual_transport”-ban már mindent megadtunk, ami szükséges.

De a postfix rendszer nagyon régi - valószínűleg ez a régi idők visszalépése.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Ez minden levelezőszervernél eltérően konfigurálható.

3 levelezőszerver áll rendelkezésemre, és ezek a beállítások nagyon eltérőek az eltérő használati követelmények miatt.

Gondosan be kell állítania - különben a spam ömlik rád, vagy ami még rosszabb - a levélszemet ömlik ki belőled.

# SPF
policyd-spf_time_limit = 3600

A bejövő levelek SPF-jének ellenőrzéséhez kapcsolódó beépülő modul beállítása.

# 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

A beállítás az, hogy minden kimenő e-mailhez DKIM-aláírást kell adnunk.

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

Ez egy kulcsfontosságú részlet a levéltovábbítás során, amikor leveleket küldünk PHP-szkriptekből.

„/etc/postfix/sdd_transport.pcre” fájl:

/^[email protected]$/ domain1:
/^[email protected]$/ domain2:
/^[email protected]$/ domain3:
/@domain1.com$/             domain1:
/@domain2.com$/             domain2:
/@domain3.com$/             domain3:

A bal oldalon reguláris kifejezések találhatók. A jobb oldalon egy címke található, amely a betűt jelöli.
Postfix a címkének megfelelően - figyelembe vesz néhány további konfigurációs sort egy adott betűhöz.

Hogy pontosan hogyan lesz újrakonfigurálva a postfix egy adott betűhöz, azt a „master.cf” tartalmazza.

A 4., 5., 6. sor a fő. Hogy melyik domain nevében küldjük a levelet, ezt a címkét helyezzük el.
De a „feladó” mező nem mindig szerepel a PHP szkriptekben a régi kódban. Ezután a felhasználónév segít.

A cikk már így is kiterjedt – nem szeretném, ha az nginx+fpm beállításával elterelnék a figyelmemet.

Röviden, minden oldalhoz beállítjuk a saját Linux-felhasználó tulajdonosát. És ennek megfelelően az fpm-poolod.

Az Fpm-pool a php bármely verzióját használja (nagyszerű, ha ugyanazon a kiszolgálón probléma nélkül használhatja a php különböző verzióit, sőt, a szomszédos oldalakon különböző php.ini-t is).

Tehát egy adott „www-domain2” linux-felhasználónak van egy domain2.com webhelye. Ez a webhely kóddal rendelkezik az e-mailek küldéséhez a feladó mező megadása nélkül.

Tehát a levelek ebben az esetben is helyesen kerülnek elküldésre, és soha nem kerülnek spambe.

Az "/etc/postfix/master.cf" í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 nincs teljes egészében megadva - már nagyon nagy.
Csak azt vettem észre, hogy mi változott.

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 spamassasinhoz kapcsolódó 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

Lehetővé tesszük, hogy az 587-es porton keresztül csatlakozzon a levelezőszerverhez.
Ehhez be kell jelentkezni.

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

SPF ellenőrzés engedélyezése.

apt-get install postfix-policyd-spf-python

Telepítsük a fenti SPF-ellenőrzési csomagot.

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

És ez a legérdekesebb. Ez egy adott tartományhoz tartozó levelek küldésének képessége egy adott IPv4/IPv6 címről.

Ez az rDNS érdekében történik. Az rDNS egy karakterlánc IP-cím alapján történő fogadásának folyamata.
Leveleknél pedig ez a funkció annak ellenőrzésére szolgál, hogy a helo pontosan megegyezik-e annak a címnek az rDNS-ével, amelyről az e-mailt küldték.

Ha a helo nem egyezik azzal az e-mail domainnel, akinek a nevében a levelet küldték, akkor spampontokat adunk.

A Helo nem egyezik az rDNS-szel – sok spampont jár.
Ennek megfelelően minden tartománynak saját IP-címmel kell rendelkeznie.
OVH esetén - a konzolban lehetőség van rDNS megadására.
A tech.ru esetében - a probléma a támogatás révén megoldódik.
Az AWS esetében a probléma a támogatással megoldódik.
„inet_protocols” és „smtp_bind_address6” – engedélyezzük az IPv6 támogatását.
Az IPv6-hoz az rDNS-t is regisztrálnia kell.
„syslog_name” – és ez a naplók olvasásának megkönnyítésére szolgál.

Vásároljon tanúsítványokat itt ajánlom.

Postfix+dovecot link beállítása itt.

SPF beállítása.

============= Galamblakó ==============

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

A mysql beállítása, maguknak a csomagoknak a telepítése.

"/etc/dovecot/conf.d/10-auth.conf" fájl

disable_plaintext_auth = yes
auth_mechanisms = plain login

Az engedélyezés csak titkosított.

„/etc/dovecot/conf.d/10-mail.conf” fájl

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

Itt jelezzük a levelek tárolási helyét.

Azt akarom, hogy fájlokban legyenek tárolva és domain szerint csoportosítva.

"/etc/dovecot/conf.d/10-master.conf" fájl

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 letiltjuk a nem biztonságos kapcsolatokat.
És engedélyezze a biztonságos kapcsolatokat.

"/etc/dovecot/conf.d/10-ssl.conf" fájl

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 beállítása. Jelezzük, hogy az ssl szükséges.
És maga a tanúsítvány. És egy fontos részlet a „helyi” irányelv. Azt jelzi, hogy melyik helyi IPv4-hez való csatlakozáskor melyik SSL-tanúsítványt kell használni.

Itt egyébként az IPv6 nincs beállítva, ezt a hiányt később javítom.
XX.XX.XX.X5 (domain2) - nincs tanúsítvány. Az ügyfelek csatlakoztatásához meg kell adnia a domain1.com nevet.
XX.XX.XX.X2 (domain3) - van tanúsítvány, megadhatja a domain1.com vagy domain3.com domaint az ügyfelek csatlakoztatásához.

"/etc/dovecot/conf.d/15-lda.conf" fájl

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Erre a jövőben szükség lesz a spamassassin számára.

"/etc/dovecot/conf.d/20-imap.conf" fájl

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Ez egy levélszemét-elhárító bővítmény. A spamassasin képzéséhez szükséges a „Spam” mappába vagy onnan történő átvitelkor.

"/etc/dovecot/conf.d/20-pop3.conf" fájl

protocol pop3 {
}

Csak van egy ilyen fájl.

Fájl „/etc/dovecot/conf.d/20-lmtp.conf”

protocol lmtp {
  mail_plugins = $mail_plugins sieve
  postmaster_address = [email protected]
}

Lmtp beállítása.

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

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
}

A Spamassasin edzési beállításai a Spam mappába vagy onnan történő átvitelkor.

"/etc/dovecot/conf.d/90-sieve.conf" fájl

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

Egy fájl, amely meghatározza, hogy mit kell tenni a bejövő levelekkel.

"/var/lib/dovecot/sieve/default.sieve" fájl

require ["fileinto", "mailbox"];

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

Le kell fordítania a „sievec default.sieve” fájlt.

"/etc/dovecot/conf.d/auth-sql.conf.ext" fájl

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 az engedélyezéshez.
És magát a fájlt használják felhatalmazási módszerként.

"/etc/dovecot/dovecot-sql.conf.ext" fájl

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 a postfix hasonló beállításainak felel meg.

"/etc/dovecot/dovecot.conf" fájl

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

Fő konfigurációs fájl.
Az a fontos, hogy itt jelezzük - adjunk hozzá protokollokat.

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

apt-get install spamassassin spamc

Telepítsük a csomagokat.

adduser spamd --disabled-login

Adjunk hozzá egy felhasználót, akinek a nevében.

systemctl enable spamassassin.service

Betöltéskor engedélyezzük az automatikus betöltés spamassassin szolgáltatást.

"/etc/default/spamassassin" fájl:

CRON=1

A szabályok automatikus frissítésének engedélyezésével „alapértelmezés szerint”.

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

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

Létre kell hoznia egy „sa” adatbázist mysql-ben az „sa” felhasználóval a „password” jelszóval (cserélje ki valami megfelelőre).

report_safe – ez levél helyett spam e-mail jelentést küld.
A use_bayes a spamassassin gépi tanulási beállításai.

A fennmaradó spamassassin beállításokat a cikkben korábban használták.

Általános beállítás "spamassassin".
Az új spam e-mailek áthelyezése az IMAP „Spam” mappába.
A Dovecot + SpamAssassin egyszerű kombinációjáról.
Javaslom, hogy olvassa el a spamassasin tanulási elméletet, amikor betűket mozgat az imap mappákban (és nem javaslom a használatát).

============= Felhívás a közösséghez =============

Szeretnék egy ötletet is bedobni a közösségbe, hogyan lehetne növelni a továbbított levelek biztonsági szintjét. Mivel olyan mélyen elmerültem a levelezés témájában.

Hogy a felhasználó létrehozhasson egy kulcspárt a kliensén (outlook, thunderbird, böngésző-plugin, ...). Nyilvános és privát. Nyilvános – küldje el a DNS-nek. Privát – spóroljon az ügyfélen. A levelezőszerverek nyilvános kulcsot használhatnak egy adott címzettnek való küldéshez.

És az ilyen levelekkel való spam elleni védelem érdekében (igen, a levelezőszerver nem tudja megtekinteni a tartalmat) - 3 szabályt kell bevezetnie:

Kötelező valódi DKIM aláírás, kötelező SPF, kötelező rDNS.
Egy neurális hálózat a levélszemét elleni képzés témájában + egy adatbázis hozzá a kliens oldalon.
A titkosítási algoritmusnak olyannak kell lennie, hogy a küldő oldalnak 100-szor több CPU-teljesítményt kell fordítania a titkosításra, mint a fogadó oldalnak.

A nyilvános levelek mellett dolgozzon ki egy szabványos ajánlati levelet „a biztonságos levelezés megkezdéséhez”. Az egyik felhasználó (postafiók) csatolmányos levelet küld egy másik postafiókba. A levél szöveges javaslatot tartalmaz egy biztonságos kommunikációs csatorna indítására a levelezéshez és a postafiók tulajdonosának nyilvános kulcsát (ügyféloldali privát kulccsal).

Akár egy-két kulcsot is készíthet külön minden levelezéshez. A címzett felhasználó elfogadhatja ezt az ajánlatot, és elküldheti nyilvános kulcsát (szintén kifejezetten ehhez a levelezéshez készült). Ezt követően az első felhasználó szolgáltatásvezérlő levelet küld (a második felhasználó nyilvános kulcsával titkosítva), amelynek kézhezvétele után a második felhasználó megbízhatónak tekintheti a kialakított kommunikációs csatornát. Ezután a második felhasználó ellenőrző levelet küld - majd az első felhasználó biztonságosnak tekintheti a kialakított csatornát.

A kulcsok útközbeni elfogásának leküzdése érdekében a protokollnak lehetőséget kell biztosítania legalább egy nyilvános kulcs flash meghajtóval történő továbbítására.

És ami a legfontosabb, hogy mindez működjön (a kérdés az, hogy „ki fizeti meg?”):
Írja be a postai bizonylatokat 10 dollártól 3 évre. Ez lehetővé teszi a feladó számára, hogy jelezze a DNS-ben, hogy „a nyilvános kulcsaim ott vannak”. És lehetőséget adnak egy biztonságos kapcsolat létrehozására. Ugyanakkor az ilyen kapcsolatok elfogadása ingyenes.
A gmail végre pénzt szerez a felhasználóival. 10 évenként 3 dollárért - biztonságos levelezési csatornák létrehozásának joga.

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

A teljes cikk teszteléséhez béreltem egy dedikált szervert egy hónapra, és veszek egy SSL-tanúsítvánnyal rendelkező domaint.

De az életkörülmények úgy alakultak, hogy ez a probléma 2 hónapig elhúzódott.
Így aztán, amikor ismét szabadidőm volt, úgy döntöttem, hogy úgy teszem közzé a cikket, ahogy van, ahelyett, hogy megkockáztatom, hogy a megjelenés még egy évig elhúzódik.

Ha elég sok olyan kérdés van, mint „de ez nincs elég részletesen leírva”, akkor valószínűleg lesz erő venni egy dedikált szervert új domainnel és új SSL-tanúsítvánnyal, és még részletesebben leírni. ami fontos, azonosítsa az összes hiányzó fontos részletet.

Szeretnék visszajelzést kapni a postai igazolásokkal kapcsolatos ötletekről is. Ha tetszik az ötlet, megpróbálok erőt meríteni, hogy írjak egy piszkozatot az rfc-hez.

Ha egy cikk nagy részét másolja, adjon meg egy hivatkozást erre a cikkre.
Ha más nyelvre fordít, adjon meg egy linket ehhez a cikkhez.
Megpróbálom magam lefordítani angolra, és hagyok kereszthivatkozásokat.

Forrás: will.com

Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + több felület + SpamAssassin-learn + Bind