🥇Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Wiele interfejsów + SpamAssassin-learn + Bind

W tym artykule opisano, jak skonfigurować nowoczesny serwer pocztowy.
Postfix + Gołębnik. SPF + DKIM + rDNS. Z IPv6.
Z szyfrowaniem TSL. Z obsługą wielu domen - część z prawdziwym certyfikatem SSL.
Z ochroną antyspamową i wysoką oceną antyspamową z innych serwerów pocztowych.
Obsługuje wiele interfejsów fizycznych.
W przypadku OpenVPN połączenie odbywa się przez IPv4 i zapewnia IPv6.

Jeśli nie chcesz uczyć się tych wszystkich technologii, ale chcesz skonfigurować taki serwer, to ten artykuł jest dla Ciebie.

W artykule nie ma próby wyjaśnienia wszystkich szczegółów. Wyjaśnienie dotyczy tego, co nie jest skonfigurowane standardowo lub jest istotne z punktu widzenia konsumenta.

Motywacja do założenia serwera pocztowego była moim marzeniem od dawna. Może to zabrzmi głupio, ale IMHO jest to znacznie lepsze niż marzenie o nowym samochodzie ulubionej marki.

Istnieją dwie motywacje do skonfigurowania protokołu IPv6. Informatyk, aby przetrwać, musi stale uczyć się nowych technologii. Chciałbym wnieść swój skromny wkład w walkę z cenzurą.

Motywacją do skonfigurowania OpenVPN jest po prostu umożliwienie działania protokołu IPv6 na komputerze lokalnym.
Motywacją do skonfigurowania kilku interfejsów fizycznych jest to, że na moim serwerze mam jeden interfejs „wolny, ale nieograniczony” i drugi „szybki, ale z taryfą”.

Motywacją do skonfigurowania ustawień Bind jest to, że mój dostawca usług internetowych zapewnia niestabilny serwer DNS, a Google również czasami zawodzi. Chcę stabilny serwer DNS do użytku osobistego.

Motywacja do napisania artykułu – wersję roboczą napisałem 10 miesięcy temu i przeglądałem ją już dwa razy. Nawet jeśli autor regularnie tego potrzebuje, istnieje duże prawdopodobieństwo, że inni też będą go potrzebować.

Nie ma uniwersalnego rozwiązania dla serwera pocztowego. Ale spróbuję napisać coś w stylu „zrób to, a potem, gdy wszystko będzie działać tak, jak powinno, wyrzuć dodatkowe rzeczy”.

Firma tech.ru ma serwer kolokacyjny. Można porównać z OVH, Hetzner, AWS. Aby rozwiązać ten problem, współpraca z tech.ru będzie znacznie bardziej efektywna.

Na serwerze zainstalowany jest Debian 9.

Serwer posiada 2 interfejsy `eno1` i `eno2`. Pierwszy jest odpowiednio nieograniczony, a drugi szybki.

Istnieją 3 statyczne adresy IP, XX.XX.XX.X0 i XX.XX.XX.X1 i XX.XX.XX.X2 w interfejsie „eno1” oraz XX.XX.XX.X5 w interfejsie „eno2” .

Dostępne XXXX:XXXX:XXXX:XXXX::/64 pula adresów IPv6 przypisanych do interfejsu `eno1` i z niej XXXX:XXXX:XXXX:XXXX:1:2::/96 została na moją prośbę przydzielona do `eno2`.

Istnieją 3 domeny „domena1.com”, „domena2.com”, „domena3.com”. Istnieje certyfikat SSL dla domen `domain1.com` i `domain3.com`.

Mam konto Google, z którym chcę połączyć swoją skrzynkę pocztową[email chroniony]` (odbieranie i wysyłanie poczty bezpośrednio z interfejsu Gmaila).
Musi być skrzynka pocztowa[email chroniony]`, kopię wiadomości e-mail, którą chcę zobaczyć w moim Gmailu. Rzadko zdarza się, aby móc wysłać coś w imieniu `[email chroniony]` poprzez interfejs sieciowy.

Musi być skrzynka pocztowa[email chroniony]`, z którego Iwanow będzie korzystał ze swojego iPhone'a.

Wysyłane e-maile muszą spełniać wszystkie współczesne wymagania antyspamowe.
W sieciach publicznych musi być zapewniony najwyższy poziom szyfrowania.
Powinna istnieć obsługa protokołu IPv6 zarówno w przypadku wysyłania, jak i odbierania listów.
Powinien istnieć SpamAssassin, który nigdy nie usunie e-maili. Zostanie on odrzucony, pominięty lub wysłany do folderu „Spam” IMAP.
Należy skonfigurować automatyczne uczenie się SpamAssassin: jeśli przeniosę list do folderu Spam, nauczy się tego; jeśli przeniosę list z folderu Spam, dowie się o tym. Wyniki szkolenia SpamAssassin powinny mieć wpływ na to, czy list trafi do folderu Spam.
Skrypty PHP muszą mieć możliwość wysyłania poczty w imieniu dowolnej domeny na danym serwerze.
Powinna istnieć usługa openvpn z możliwością korzystania z protokołu IPv6 na kliencie, który nie ma protokołu IPv6.

Najpierw musisz skonfigurować interfejsy i routing, w tym IPv6.
Następnie będziesz musiał skonfigurować OpenVPN, który będzie łączyć się przez IPv4 i zapewniać klientowi statyczny, rzeczywisty adres IPv6. Klient ten będzie miał dostęp do wszystkich usług IPv6 na serwerze oraz dostęp do wszelkich zasobów IPv6 w Internecie.
Następnie będziesz musiał skonfigurować Postfix do wysyłania listów + SPF + DKIM + rDNS i innych podobnych drobiazgów.
Następnie będziesz musiał skonfigurować Dovecot i skonfigurować Multidomain.
Następnie będziesz musiał skonfigurować SpamAssassin i skonfigurować szkolenie.
Na koniec zainstaluj Bind.

============= Wiele interfejsów =============

Aby skonfigurować interfejsy, musisz zapisać to w „/etc/network/interfaces”.

# The loopback network interface
auto lo
iface lo inet loopback

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

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

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

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

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

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

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

Te ustawienia można zastosować na dowolnym serwerze w tech.ru (przy niewielkiej koordynacji ze wsparciem) i natychmiast będą działać tak, jak powinny.

Jeśli masz doświadczenie w konfigurowaniu podobnych rzeczy dla Hetzner, OVH, tam jest inaczej. Trudniejsze.

eno1 to nazwa karty sieciowej nr 1 (powolna, ale nieograniczona).
eno2 to nazwa karty sieciowej nr 2 (szybka, ale z taryfą).
tun0 to nazwa wirtualnej karty sieciowej z OpenVPN.
XX.XX.XX.X0 - IPv4 nr 1 na eno1.
XX.XX.XX.X1 - IPv4 nr 2 na eno1.
XX.XX.XX.X2 - IPv4 nr 3 na eno1.
XX.XX.XX.X5 - IPv4 nr 1 na eno2.
XX.XX.XX.1 - Brama IPv4.
XXXX:XXXXXX:XXXX:XXXX::/64 - IPv6 dla całego serwera.
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 dla eno2, wszystko inne z zewnątrz trafia do eno1.
XXXX:XXXX:XXXX:XXXX::1 — bramka IPv6 (warto zaznaczyć, że można/należy to zrobić inaczej. Określ przełącznik IPv6).
dns-nameservers - wskazany jest 127.0.0.1 (ponieważ bind jest zainstalowany lokalnie) i 213.248.1.6 (pochodzi z tech.ru).

„table eno1t” i „table eno2t” - znaczenie tych reguł trasy jest takie, że ruch wchodzący przez eno1 -> będzie przez nią wychodził, a ruch wchodzący przez eno2 -> będzie przez nią wychodził. A także połączenia inicjowane przez serwer będą przechodzić przez eno1.

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

Za pomocą tego polecenia określamy, że niezrozumiały ruch podlegający dowolnej regule oznaczonej jako „table eno1t” -> będzie wysyłany do interfejsu eno1.

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

Za pomocą tego polecenia określamy, że wszelki ruch inicjowany przez serwer powinien być kierowany do interfejsu eno1.

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

Za pomocą tego polecenia ustalamy zasady oznaczania ruchu.

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

Ten blok określa drugi adres IPv4 dla interfejsu eno1.

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

Za pomocą tego polecenia ustawiamy trasę od klientów OpenVPN do lokalnego IPv4 z wyjątkiem XX.XX.XX.X0.
Nadal nie rozumiem, dlaczego to polecenie wystarczy dla wszystkich IPv4.

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

Tutaj ustawiamy adres samego interfejsu. Serwer użyje go jako adresu „wychodzącego”. Nie będzie ponownie w żaden sposób używany.

Dlaczego „:1:1::” jest takie skomplikowane? Aby OpenVPN działał poprawnie i tylko w tym celu. Więcej na ten temat później.

Wracając do tematu gatewaya - tak to działa i jest w porządku. Ale poprawnym sposobem jest wskazanie tutaj IPv6 przełącznika, do którego podłączony jest serwer.

Jednak z jakiegoś powodu IPv6 przestaje działać, jeśli to zrobię. Prawdopodobnie jest to jakiś problem tech.ru.

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

Jest to dodanie adresu IPv6 do interfejsu. Jeśli potrzebujesz stu adresów, oznacza to sto linii w tym pliku.

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

Aby było jasne, zanotowałem adresy i podsieci wszystkich interfejsów.
eno1 - musi być "/64" - bo to jest cała nasza pula adresów.
tun0 - podsieć musi być większa niż eno1. W przeciwnym razie nie będzie możliwe skonfigurowanie bramy IPv6 dla klientów OpenVPN.
eno2 - podsieć musi być większa niż tun0. W przeciwnym razie klienci OpenVPN nie będą mogli uzyskać dostępu do lokalnych adresów IPv6.
Dla przejrzystości wybrałem krok podsieci wynoszący 16, ale jeśli chcesz, możesz nawet wykonać krok „1”.
Odpowiednio 64+16 = 80, a 80+16 = 96.

Dla jeszcze większej przejrzystości:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY to adresy, które należy przypisać do konkretnych witryn lub usług w interfejsie eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY to adresy, które należy przypisać do konkretnych witryn lub usług w interfejsie eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY to adresy, które należy przypisać klientom OpenVPN lub wykorzystać jako adresy usług OpenVPN.

Aby skonfigurować sieć, powinno być możliwe ponowne uruchomienie serwera.
Zmiany IPv4 są pobierane po wykonaniu (pamiętaj, aby owinąć je na ekranie — w przeciwnym razie to polecenie po prostu spowoduje awarię sieci na serwerze):

/etc/init.d/networking restart

Dodaj na końcu pliku „/etc/iproute2/rt_tables”:

100 eno1t
101 eno2t

Bez tego nie można używać tabel niestandardowych w pliku „/etc/network/interfaces”.
Liczby muszą być unikalne i mniejsze niż 65535.

Zmiany IPv6 można łatwo zmienić bez ponownego uruchamiania, ale aby to zrobić, musisz nauczyć się co najmniej trzech poleceń:

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

Ustawianie „/etc/sysctl.conf”

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

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

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

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

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

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

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

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

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

To są ustawienia „sysctl” mojego serwera. Zwrócę uwagę na coś istotnego.

net.ipv4.ip_forward = 1

Bez tego OpenVPN w ogóle nie będzie działać.

net.ipv6.ip_nonlocal_bind = 1

Każdy, kto spróbuje powiązać IPv6 (na przykład nginx) natychmiast po uruchomieniu interfejsu, otrzyma błąd. Że ten adres jest niedostępny.

Aby uniknąć takiej sytuacji, dokonuje się takiego ustawienia.

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

Bez tych ustawień IPv6 ruch z klienta OpenVPN nie wychodzi w świat.

Inne ustawienia albo są nieistotne, albo nie pamiętam, do czego służą.
Ale na wszelki wypadek zostawiam to „tak jak jest”.

Aby zmiany w tym pliku zostały odebrane bez ponownego uruchamiania serwera, należy uruchomić polecenie:

sysctl -p

Więcej szczegółów na temat zasad „stołu”: habr.com/post/108690

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

OpenVPN IPv4 nie działa bez iptables.

Moje iptables są takie dla VPN:

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

YY.YY.YY.YY to mój statyczny adres IPv4 komputera lokalnego.
10.8.0.0/24 - Sieć openvpn IPv4. Adresy IPv4 dla klientów openvpn.
Ważna jest spójność zasad.

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

Jest to ograniczenie polegające na tym, że tylko ja mogę korzystać z OpenVPN z mojego statycznego adresu IP.

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

Aby przekazywać pakiety IPv4 pomiędzy klientami OpenVPN a Internetem, musisz zarejestrować jedno z tych poleceń.

W różnych przypadkach jedna z opcji nie jest odpowiednia.
Obydwa polecenia są odpowiednie w moim przypadku.
Po przeczytaniu dokumentacji wybrałem pierwszą opcję, ponieważ zużywa mniej procesora.

Aby wszystkie ustawienia iptables zostały pobrane po ponownym uruchomieniu, musisz je gdzieś zapisać.

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

Takie nazwy nie zostały wybrane przypadkowo. Używane są przez pakiet „iptables-persistent”.

apt-get install iptables-persistent

Instalowanie głównego pakietu OpenVPN:

apt-get install openvpn easy-rsa

Skonfigurujmy szablon certyfikatów (zastąp wartości):

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

Edytujmy ustawienia szablonu certyfikatu:

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

Utwórz certyfikat serwera:

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

Przygotujmy możliwość utworzenia finalnych plików „nazwa-klienta.opvn”:

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

# Client mode
client

# Interface tunnel type
dev tun

# TCP protocol
proto tcp-client

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

# Don't bind to local port/address
nobind

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

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

# Enable compression
comp-lzo

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

Przygotujmy skrypt, który połączy wszystkie pliki w jeden plik opvn.

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

#!/bin/bash

# First argument: Client identifier

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

cat ${BASE_CONFIG} 
    <(echo -e '<ca>') 
    ${KEY_DIR}/ca.crt 
    <(echo -e '</ca>n<cert>') 
    ${KEY_DIR}/.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

Tworzenie pierwszego klienta OpenVPN:

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

Na urządzenie Klienta wysyłany jest plik „~/client-configs/files/client-name.ovpn”.

W przypadku klientów iOS musisz wykonać następującą sztuczkę:
Treść znacznika „tls-auth” musi być bez komentarzy.
A także umieść „key-direction 1” bezpośrednio przed tagiem „tls-auth”.

Skonfigurujmy konfigurację serwera OpenVPN:

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

# Listen port
port 1194

# Protocol
proto tcp-server

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

# Master certificate
ca ca.crt

# Server certificate
cert server.crt

# Server private key
key server.key

# Diffie-Hellman parameters
dh dh2048.pem

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

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

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

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

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

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

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

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

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

# Enable compression
comp-lzo

# User and group
user vpn
group vpn

# Log a short status
status openvpn-status.log

# Logging verbosity
##verb 4

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

Jest to potrzebne, aby ustawić adres statyczny dla każdego klienta (nie jest to konieczne, ale go używam):

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

Najtrudniejszy i kluczowy szczegół.

Niestety OpenVPN nie wie jeszcze, jak samodzielnie skonfigurować bramę IPv6 dla klientów.
Musisz „ręcznie” przekazać to każdemu klientowi.

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

Plik „/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

Plik „/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

Obydwa skrypty używają pliku „/etc/openvpn/variables”:

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

Trudno mi sobie przypomnieć, dlaczego jest to napisane w ten sposób.

Teraz maska sieci = 112 wygląda dziwnie (w tym miejscu powinno być 96).
A prefiks jest dziwny, nie pasuje do sieci tun0.
Ale OK, zostawię to tak jak jest.

cipher DES-EDE3-CBC

Nie jest to rozwiązanie dla każdego – ja wybrałem tę metodę szyfrowania połączenia.

Dowiedz się więcej o konfigurowaniu OpenVPN IPv4.

Dowiedz się więcej o konfigurowaniu OpenVPN IPv6.

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

Instalowanie pakietu głównego:

apt-get install postfix

Podczas instalacji wybierz „strona internetowa”.

Mój plik „/etc/postfix/main.cf” wygląda następująco:

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

Przyjrzyjmy się szczegółom tej konfiguracji.

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

Zdaniem mieszkańców Chabrowska blok ten zawiera „dezinformację i błędne tezy”.Dopiero 8 lat po rozpoczęciu mojej kariery zacząłem rozumieć, jak działa SSL.

Dlatego pozwolę sobie opisać, jak korzystać z protokołu SSL (bez odpowiadania na pytania „Jak to działa?” i „Dlaczego to działa?”).

Podstawą współczesnego szyfrowania jest utworzenie pary kluczy (dwóch bardzo długich ciągów znaków).

Jeden „klucz” jest prywatny, drugi klucz jest „publiczny”. Bardzo starannie przechowujemy klucz prywatny w tajemnicy. Udostępniamy klucz publiczny każdemu.

Za pomocą klucza publicznego możesz zaszyfrować ciąg tekstowy, aby tylko właściciel klucza prywatnego mógł go odszyfrować.
Cóż, to cała podstawa technologii.

Krok #1 – Strony https.
Podczas uzyskiwania dostępu do witryny przeglądarka dowiaduje się od serwera internetowego, że witryna ma protokół https i dlatego żąda klucza publicznego.
Serwer WWW udostępnia klucz publiczny. Przeglądarka używa klucza publicznego do szyfrowania żądania http i wysyłania go.
Treść żądania http może odczytać tylko osoba posiadająca klucz prywatny, czyli tylko serwer, do którego kierowane jest żądanie.
Żądanie HTTP zawiera co najmniej identyfikator URI. Dlatego jeśli kraj próbuje ograniczyć dostęp nie do całej witryny, ale do konkretnej strony, nie jest to możliwe w przypadku witryn https.

Krok #2 – zaszyfrowana odpowiedź.
Serwer WWW zapewnia odpowiedź, którą można łatwo odczytać w drodze.
Rozwiązanie jest niezwykle proste – przeglądarka lokalnie generuje dla każdej witryny https tę samą parę kluczy prywatny-publiczny.
Wraz z żądaniem klucza publicznego witryny wysyła swój lokalny klucz publiczny.
Serwer WWW zapamiętuje to i wysyłając odpowiedź http, szyfruje ją kluczem publicznym konkretnego klienta.
Teraz odpowiedź http może odszyfrować tylko właściciel klucza prywatnego przeglądarki klienta (czyli sam klient).

Krok nr 3 – nawiązanie bezpiecznego połączenia kanałem publicznym.
W przykładzie nr 2 występuje luka - nic nie stoi na przeszkodzie, aby życzliwi ludzie przechwycili żądanie http i edytowali informacje o kluczu publicznym.
Dzięki temu pośrednik będzie wyraźnie widział całą treść wysyłanych i odbieranych wiadomości, dopóki nie zmieni się kanał komunikacji.
Poradzenie sobie z tym jest niezwykle proste — wystarczy wysłać klucz publiczny przeglądarki jako wiadomość zaszyfrowaną kluczem publicznym serwera WWW.
Następnie serwer WWW najpierw wysyła odpowiedź w stylu „Twój klucz publiczny jest taki” i szyfruje tę wiadomość tym samym kluczem publicznym.
Przeglądarka patrzy na odpowiedź – jeśli otrzyma komunikat „Twój klucz publiczny jest taki” – to jest to 100% gwarancja, że ten kanał komunikacji jest bezpieczny.
Jak bezpieczne jest to rozwiązanie?
Samo utworzenie takiego bezpiecznego kanału komunikacji odbywa się z prędkością ping*2. Na przykład 20 ms.
Osoba atakująca musi wcześniej posiadać klucz prywatny jednej ze stron. Lub znajdź klucz prywatny w ciągu kilku milisekund.
Zhakowanie jednego nowoczesnego klucza prywatnego na superkomputerze zajmie dziesięciolecia.

Krok #4 - publiczna baza kluczy publicznych.
Oczywiście w tej całej historii istnieje szansa, że atakujący zasiądzie w kanale komunikacyjnym pomiędzy klientem a serwerem.
Klient może udawać serwer, a serwer może udawać klienta. I emuluj parę kluczy w obu kierunkach.
Wtedy osoba atakująca zobaczy cały ruch i będzie mogła go „edytować”.
Na przykład zmień adres, na który chcesz wysłać pieniądze lub skopiuj hasło z bankowości internetowej lub zablokuj „niestosowne” treści.
Aby walczyć z takimi atakującymi, opracowano publiczną bazę danych zawierającą klucze publiczne dla każdej witryny https.
Każda przeglądarka „wie” o istnieniu około 200 takich baz. Jest to preinstalowane w każdej przeglądarce.
„Wiedza” jest zabezpieczona kluczem publicznym z każdego certyfikatu. Oznacza to, że nie można sfałszować połączenia z każdym konkretnym urzędem certyfikacji.

Teraz jest już proste zrozumienie, jak używać SSL dla https.
Jeśli użyjesz mózgu, stanie się jasne, jak służby specjalne mogą zhakować coś w tej strukturze. Ale będzie ich to kosztować potworne wysiłki.
A organizacje mniejsze niż NSA czy CIA – złamanie istniejącego poziomu ochrony jest prawie niemożliwe, nawet dla VIP-ów.

Dodam jeszcze o połączeniach ssh. Nie ma tam kluczy publicznych, więc co możesz zrobić? Problem rozwiązuje się na dwa sposoby.
Opcja ssh-by-password:
Podczas pierwszego połączenia klient ssh powinien ostrzec, że mamy nowy klucz publiczny z serwera ssh.
A jeśli podczas dalszych połączeń pojawi się ostrzeżenie „nowy klucz publiczny z serwera ssh”, będzie to oznaczać, że próbują Cię podsłuchiwać.
Albo zostałeś podsłuchany przy pierwszym połączeniu, ale teraz komunikujesz się z serwerem bez pośredników.
Właściwie, ze względu na to, że fakt podsłuchu można łatwo, szybko i bez wysiłku ujawnić, atak ten stosowany jest jedynie w szczególnych przypadkach, dla konkretnego klienta.

Opcja ssh-by-key:
Bierzemy dysk flash, zapisujemy na nim klucz prywatny serwera ssh (są na to terminy i wiele ważnych niuansów, ale piszę program edukacyjny, a nie instrukcje użytkowania).
Klucz publiczny zostawiamy na maszynie, na której będzie klient ssh i również zachowujemy go w tajemnicy.
Przynosimy pendrive na serwer, wkładamy go, kopiujemy klucz prywatny, palimy pendrive i rozrzucamy popiół na wiatr (lub przynajmniej formatujemy go zerami).
To wszystko - po takiej operacji zhakowanie takiego połączenia ssh nie będzie możliwe. Oczywiście za 10 lat będzie można oglądać ruch na superkomputerze – ale to inna historia.

Przepraszam za offtop.

Skoro teoria jest już znana. Opowiem Ci o procesie tworzenia certyfikatu SSL.

Używając „openssl genrsa” tworzymy klucz prywatny i „puste” miejsca na klucz publiczny.
„Blanki” wysyłamy do zewnętrznej firmy, której za najprostszy certyfikat płacimy około 9 dolarów.

Po kilku godzinach otrzymujemy nasz klucz „publiczny” i zestaw kilku kluczy publicznych od tej zewnętrznej firmy.

Dlaczego zewnętrzna firma ma płacić za rejestrację mojego klucza publicznego, to osobne pytanie, nie będziemy go tutaj rozważać.

Teraz jest jasne, jakie jest znaczenie napisu:

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

Folder „/etc/ssl” zawiera wszystkie pliki związane z problemami z ssl.
domena1.com — nazwa domeny.
Rok 2018 to rok tworzenia kluczy.
„klucz” – oznaczenie, że plik jest kluczem prywatnym.

I znaczenie tego pliku:

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domena1.com — nazwa domeny.
Rok 2018 to rok tworzenia kluczy.
chained - oznaczenie, że istnieje łańcuch kluczy publicznych (pierwszy to nasz klucz publiczny, a pozostałe pochodzą od firmy, która wydała klucz publiczny).
crt - oznaczenie, że istnieje gotowy certyfikat (klucz publiczny z objaśnieniami technicznymi).

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

To ustawienie nie jest używane w tym przypadku, ale zostało zapisane jako przykład.

Ponieważ błąd w tym parametrze spowoduje wysłanie spamu z Twojego serwera (bez Twojej woli).

Następnie udowodnij wszystkim, że nie jesteś winny.

recipient_delimiter = +

Wiele osób może nie wiedzieć, ale jest to standardowy znak w rankingach e-maili i jest obsługiwany przez większość nowoczesnych serwerów pocztowych.

Na przykład, jeśli masz skrzynkę pocztową „[email chroniony]„spróbuj wysłać do”[email chroniony]„- zobacz, co z tego wyniknie.

inet_protocols = ipv4

To może być mylące.

Ale to nie tylko tak. Każda nowa domena domyślnie ma tylko IPv4, następnie włączam IPv6 dla każdej z osobna.

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

Tutaj określamy, że cała przychodząca poczta trafia do dovecot.
A zasady dotyczące domeny, skrzynki pocztowej, aliasu - poszukaj w bazie.

/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

Teraz postfix wie, że możliwe jest przyjęcie poczty do dalszego wysłania dopiero po autoryzacji za pomocą dovecot.

Naprawdę nie rozumiem, po co to tutaj powielać. Wszystko, co jest potrzebne w „wirtualnym_transporcie” już określiliśmy.

Ale system postfix jest bardzo stary - prawdopodobnie jest to powrót do dawnych czasów.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Można to skonfigurować inaczej dla każdego serwera pocztowego.

Mam do dyspozycji 3 serwery pocztowe i te ustawienia są bardzo różne ze względu na różne wymagania użytkowania.

Musisz to skonfigurować ostrożnie - w przeciwnym razie spam będzie do Ciebie napływał, lub co gorsza - spam będzie się z Ciebie wylewał.

# SPF
policyd-spf_time_limit = 3600

Konfiguracja wtyczki związanej ze sprawdzaniem SPF przychodzących listów.

# 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

Ustawienie jest takie, że musimy dostarczyć podpis DKIM do wszystkich wychodzących wiadomości e-mail.

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

Jest to kluczowy szczegół w kierowaniu listów podczas wysyłania listów ze skryptów PHP.

Plik „/etc/postfix/sdd_transport.pcre”:

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

Po lewej stronie znajdują się wyrażenia regularne. Po prawej stronie znajduje się etykieta oznaczająca literę.
Postfix zgodny z etykietą - uwzględni kilka dodatkowych linii konfiguracyjnych dla konkretnej litery.

To, jak dokładnie postfix zostanie przekonfigurowany dla konkretnej litery, zostanie wskazane w „master.cf”.

Linie 4, 5, 6 to linie główne. W imieniu jakiej domeny wysyłamy list, umieszczamy tę etykietę.
Jednak pole „od” nie zawsze jest wskazane w skryptach PHP w starym kodzie. Wtedy na ratunek przychodzi nazwa użytkownika.

Artykuł jest już obszerny - nie chciałbym się rozpraszać konfiguracją nginx+fpm.

W skrócie, dla każdej witryny ustalamy własnego właściciela użytkownika systemu Linux. I odpowiednio twoja pula fpm.

Fpm-pool używa dowolnej wersji php (świetnie jest, gdy na tym samym serwerze możesz bez problemu używać różnych wersji php, a nawet różnych php.ini dla sąsiadujących stron).

Zatem konkretny użytkownik Linuksa „www-domain2” ma witrynę internetową domain2.com. Ta witryna zawiera kod umożliwiający wysyłanie wiadomości e-mail bez określania pola nadawcy.

Zatem nawet w tym przypadku listy zostaną wysłane poprawnie i nigdy nie trafią do spamu.

Mój plik „/etc/postfix/master.cf” wygląda następująco:

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

Plik nie jest udostępniany w całości - jest już bardzo duży.
Zauważyłem tylko to, co zostało zmienione.

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}

Są to ustawienia związane ze spamassasinem, więcej o tym później.

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

Umożliwiamy połączenie się z serwerem pocztowym poprzez port 587.
Aby to zrobić musisz się zalogować.

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

Włącz sprawdzanie SPF.

apt-get install postfix-policyd-spf-python

Zainstalujmy powyższy pakiet do sprawdzania SPF.

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

I to jest najciekawsze. Jest to możliwość wysyłania listów dla konkretnej domeny z określonego adresu IPv4/IPv6.

Odbywa się to ze względu na rDNS. rDNS to proces otrzymywania ciągu znaków według adresu IP.
W przypadku poczty ta funkcja służy do potwierdzenia, że helo dokładnie pasuje do rDNS adresu, z którego wysłano wiadomość e-mail.

Jeśli helo nie pasuje do domeny e-mail, w imieniu której wysłano list, przyznawane są punkty za spam.

Helo nie pasuje do rDNS - przyznawanych jest dużo punktów za spam.
W związku z tym każda domena musi mieć własny adres IP.
W przypadku OVH - w konsoli można określić rDNS.
W przypadku tech.ru - problem został rozwiązany poprzez wsparcie.
W przypadku AWS problem został rozwiązany poprzez wsparcie.
„inet_protocols” i „smtp_bind_address6” - włączamy obsługę protokołu IPv6.
W przypadku protokołu IPv6 należy również zarejestrować rDNS.
„nazwa_sysloga” - ma to na celu ułatwienie czytania logów.

Kup certyfikaty Polecam tutaj.

Konfigurowanie łącza postfix+dovecot tutaj.

Ustawianie SPF.

============= Gołębnik =============

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

Konfigurowanie mysql, instalowanie samych pakietów.

Plik „/etc/dovecot/conf.d/10-auth.conf”

disable_plaintext_auth = yes
auth_mechanisms = plain login

Autoryzacja jest jedynie szyfrowana.

Plik „/etc/dovecot/conf.d/10-mail.conf”

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

Tutaj wskazujemy miejsce przechowywania liter.

Chcę, żeby były przechowywane w plikach i pogrupowane według domen.

Plik „/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 {
  }
}

To jest główny plik konfiguracyjny dovecot.
Tutaj wyłączamy niezabezpieczone połączenia.
I włącz bezpieczne połączenia.

Plik „/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
}

Konfigurowanie ssl. Wskazujemy, że wymagany jest protokół SSL.
I sam certyfikat. Ważnym szczegółem jest dyrektywa „lokalna”. Wskazuje, którego certyfikatu SSL należy użyć podczas łączenia się z którym lokalnym protokołem IPv4.

Nawiasem mówiąc, IPv6 nie jest tutaj skonfigurowany, później poprawię to pominięcie.
XX.XX.XX.X5 (domena2) - brak certyfikatu. Aby połączyć klientów, musisz podać domenę1.com.
XX.XX.XX.X2 (domena3) - istnieje certyfikat, możesz określić domenę1.com lub domenę3.com do łączenia klientów.

Plik „/etc/dovecot/conf.d/15-lda.conf”

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Będzie to potrzebne w przyszłości spamassassinowi.

Plik „/etc/dovecot/conf.d/20-imap.conf”

protocol imap {
  mail_plugins = $mail_plugins antispam
}

To jest wtyczka antyspamowa. Potrzebne do szkolenia spamassasina w momencie przenoszenia do/z folderu „Spam”.

Plik „/etc/dovecot/conf.d/20-pop3.conf”

protocol pop3 {
}

Jest właśnie taki plik.

Plik „/etc/dovecot/conf.d/20-lmtp.conf”

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

Konfigurowanie lmtp.

Plik „/etc/dovecot/conf.d/90-antispam.conf”

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

Ustawienia treningu Spamassasin w momencie przesyłania do/z folderu Spam.

Plik „/etc/dovecot/conf.d/90-sieve.conf”

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

Plik określający, co zrobić z przychodzącymi listami.

Plik „/var/lib/dovecot/sieve/default.sieve”

require ["fileinto", "mailbox"];

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

Należy skompilować plik: „sievec default.sieve”.

Plik „/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
}

Określanie plików sql do autoryzacji.
Sam plik służy jako metoda autoryzacji.

Plik „/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';

Odpowiada to podobnym ustawieniom dla postfixa.

Plik „/etc/dovecot/dovecot.conf”

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

Główny plik konfiguracyjny.
Ważne jest to, że tutaj wskazujemy - dodaj protokoły.

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

apt-get install spamassassin spamc

Zainstalujmy pakiety.

adduser spamd --disabled-login

Dodajmy użytkownika, w czyim imieniu.

systemctl enable spamassassin.service

Włączamy automatyczne ładowanie usługi spamassassin po załadowaniu.

Plik "/etc/default/spamassassin":

CRON=1

Włączając automatyczną aktualizację reguł „domyślnie”.

Plik „/etc/spamassassin/local.cf”:

report_safe 0

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

Musisz utworzyć bazę danych „sa” w mysql z użytkownikiem „sa” i hasłem „password” (zamień na coś odpowiedniego).

report_safe — spowoduje wysłanie raportu o spamie zamiast listu.
use_bayes to ustawienia uczenia maszynowego zabójcy spamu.

Pozostałe ustawienia zabójcy spamu zostały użyte wcześniej w artykule.

Ogólne ustawienie „spamasassin”.
Informacje o przenoszeniu nowych wiadomości e-mail będących spamem do folderu IMAP „Spam”..
O prostym połączeniu Dovecot + SpamAssassin.
Polecam zapoznać się z teorią uczenia się spamassasasin podczas przenoszenia liter w folderach imap (i nie polecam jej używać).

============= Apel do społeczności =============

Chciałbym także rzucić społeczeństwu pomysł jak zwiększyć poziom bezpieczeństwa przesyłanych listów. Ponieważ jestem tak głęboko zanurzony w temacie poczty.

Aby użytkownik mógł utworzyć parę kluczy na swoim kliencie (Outlook, Thunderbird, wtyczka do przeglądarki, ...). Publiczny i prywatny. Publiczne — wyślij do DNS. Prywatne - oszczędzaj na kliencie. Serwery pocztowe będą mogły używać klucza publicznego do wysyłania wiadomości do określonego odbiorcy.

Aby zabezpieczyć się przed spamem takimi listami (tak, serwer pocztowy nie będzie mógł zobaczyć treści) - będziesz musiał wprowadzić 3 zasady:

Obowiązkowy prawdziwy podpis DKIM, obowiązkowy SPF, obowiązkowy rDNS.
Sieć neuronowa na temat szkolenia antyspamowego + baza danych do tego po stronie klienta.
Algorytm szyfrowania musi być taki, aby strona wysyłająca musiała zużywać 100 razy więcej mocy procesora na szyfrowanie niż strona odbierająca.

Oprócz listów publicznych opracuj standardowy list z propozycją „w celu rozpoczęcia bezpiecznej korespondencji”. Jeden z użytkowników (skrzynka pocztowa) wysyła list z załącznikiem do innej skrzynki pocztowej. Pismo zawiera propozycję tekstową uruchomienia bezpiecznego kanału komunikacji dla korespondencji oraz klucz publiczny właściciela skrzynki pocztowej (z kluczem prywatnym po stronie klienta).

Możesz nawet zrobić kilka kluczy specjalnie dla każdej korespondencji. Użytkownik-odbiorca może zaakceptować tę ofertę i przesłać swój klucz publiczny (również wykonany specjalnie na potrzeby tej korespondencji). Następnie pierwszy użytkownik wysyła list kontrolny usługi (zaszyfrowany kluczem publicznym drugiego użytkownika) - po jego otrzymaniu drugi użytkownik może uznać utworzony kanał komunikacji za wiarygodny. Następnie drugi użytkownik wysyła list kontrolny – i wówczas pierwszy użytkownik również może uznać utworzony kanał za bezpieczny.

Aby przeciwdziałać przechwytywaniu kluczy na drodze, protokół musi przewidywać możliwość przesłania co najmniej jednego klucza publicznego za pomocą pendrive'a.

I najważniejsze, że to wszystko działa (pytanie „kto za to zapłaci?”):
Wprowadź certyfikaty pocztowe już od 10 USD na 3 lata. Co pozwoli nadawcy wskazać w DNS, że „moje klucze publiczne są tam”. Dają ci możliwość nawiązania bezpiecznego połączenia. Jednocześnie przyjmowanie takich połączeń jest bezpłatne.
Gmail wreszcie zarabia na swoich użytkownikach. Za 10 dolarów na 3 lata - prawo do tworzenia bezpiecznych kanałów korespondencji.

============= Wniosek =============

Aby przetestować cały artykuł, miałem zamiar wynająć serwer dedykowany na miesiąc i kupić domenę z certyfikatem SSL.

Ale okoliczności życiowe się potoczyły i sprawa ciągnęła się 2 miesiące.
I tak, gdy znów miałem wolny czas, zdecydowałem się opublikować artykuł w obecnej formie, zamiast ryzykować, że publikacja będzie się przeciągać o kolejny rok.

Jeśli pytań w stylu „ale nie jest to opisane wystarczająco szczegółowo” jest dość dużo, to prawdopodobnie wystarczy wziąć serwer dedykowany z nową domeną i nowym certyfikatem SSL i opisać go jeszcze bardziej szczegółowo, a w większości przypadków co ważne, zidentyfikuj wszystkie brakujące ważne szczegóły.

Chciałbym również uzyskać opinie na temat pomysłów dotyczących świadectw pocztowych. Jeśli pomysł Ci się spodoba, postaram się znaleźć siłę i napisać wersję roboczą dla RFC.

Kopiując duże części artykułu, podaj link do tego artykułu.
Tłumacząc na inny język, podaj link do tego artykułu.
Spróbuję sam przetłumaczyć to na angielski i zostawię odsyłacze.

Źródło: www.habr.com

Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Wiele interfejsów + SpamAssassin-learn + Bind