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

Denne artikkelen handler om hvordan du setter opp en moderne e-postserver.
Postfix + Dueslag. SPF + DKIM + rDNS. Med IPv6.
Med TSL-kryptering. Med støtte for flere domener - del med et ekte SSL-sertifikat.
Med antispam-beskyttelse og høy antispam-vurdering fra andre e-postservere.
Støtter flere fysiske grensesnitt.
Med OpenVPN, tilkoblingen som er via IPv4, og som gir IPv6.

Hvis du ikke vil lære alle disse teknologiene, men ønsker å sette opp en slik server, så er denne artikkelen for deg.

Artikkelen gjør ikke noe forsøk på å forklare alle detaljer. Forklaringen går til hva som ikke er konfigurert som standard eller er viktig fra forbrukerens synspunkt.

Motivasjonen for å sette opp en e-postserver har vært en drøm for meg lenge. Dette høres kanskje dumt ut, men IMHO, det er mye bedre enn å drømme om en ny bil fra favorittmerket ditt.

Det er to motivasjoner for å sette opp IPv6. En IT-spesialist må hele tiden lære nye teknologier for å overleve. Jeg vil gjerne gi mitt beskjedne bidrag til kampen mot sensur.

Motivasjonen for å sette opp OpenVPN er bare å få IPv6 til å fungere på den lokale maskinen.
Motivasjonen for å sette opp flere fysiske grensesnitt er at jeg på min server har ett grensesnitt "sakte men ubegrenset" og et annet "raskt men med en tariff".

Motivasjonen for å sette opp Bind-innstillinger er at min ISP gir en ustabil DNS-server, og google feiler også noen ganger. Jeg vil ha en stabil DNS-server for personlig bruk.

Motivasjon til å skrive en artikkel - Jeg skrev et utkast for 10 måneder siden, og jeg har allerede sett på det to ganger. Selv om forfatteren regelmessig trenger det, er det stor sannsynlighet for at andre også trenger det.

Det finnes ingen universell løsning for en e-postserver. Men jeg skal prøve å skrive noe sånt som "gjør dette og så, når alt fungerer som det skal, kast ut de ekstra tingene."

Selskapet tech.ru har en Colocation-server. Det er mulig å sammenligne med OVH, Hetzner, AWS. For å løse dette problemet vil samarbeidet med tech.ru være mye mer effektivt.

Debian 9 er installert på serveren.

Serveren har 2 grensesnitt `eno1` og `eno2`. Den første er ubegrenset, og den andre er henholdsvis rask.

Det er 3 statiske IP-adresser, XX.XX.XX.X0 og XX.XX.XX.X1 og XX.XX.XX.X2 på «eno1»-grensesnittet og XX.XX.XX.X5 på «eno2»-grensesnittet .

Tilgjengelig XXXX:XXXX:XXXX:XXXX::/64 en pool med IPv6-adresser som er tilordnet `eno1`-grensesnittet, og fra det ble XXXX:XXXX:XXXX:XXXX:1:2::/96 tildelt `eno2` etter min forespørsel.

Det er 3 domener `domain1.com`, `domain2.com`, `domain3.com`. Det er et SSL-sertifikat for `domain1.com` og `domain3.com`.

Jeg har en Google-konto som jeg vil koble postkassen min til[e-postbeskyttet]` (motta e-post og sende e-post direkte fra Gmail-grensesnittet).
Det må være en postkasse`[e-postbeskyttet]`, en kopi av e-posten som jeg vil se i gmailen min. Og det er sjelden man kan sende noe på vegne av `[e-postbeskyttet]` via nettgrensesnittet.

Det må være en postkasse`[e-postbeskyttet]`, som Ivanov vil bruke fra sin iPhone.

Sendte e-poster må overholde alle moderne krav til antispam.
Det må være det høyeste nivået av kryptering i offentlige nettverk.
Det bør være IPv6-støtte for både sending og mottak av brev.
Det burde være en SpamAssassin som aldri vil slette e-poster. Og den vil enten sprette eller hoppe over eller sende til IMAP "Spam"-mappen.
SpamAssassin auto-læring må konfigureres: hvis jeg flytter et brev til Spam-mappen, vil det lære av dette; hvis jeg flytter et brev fra Spam-mappen, vil det lære av dette. Resultatene av SpamAssassin-trening bør påvirke om brevet havner i Spam-mappen.
PHP-skript må kunne sende e-post på vegne av et hvilket som helst domene på en gitt server.
Det bør være en openvpn-tjeneste, med muligheten til å bruke IPv6 på en klient som ikke har IPv6.

Først må du konfigurere grensesnitt og ruting, inkludert IPv6.
Deretter må du konfigurere OpenVPN, som kobler til via IPv4 og gir klienten en statisk ekte IPv6-adresse. Denne klienten vil ha tilgang til alle IPv6-tjenester på serveren og tilgang til eventuelle IPv6-ressurser på Internett.
Da må du konfigurere Postfix til å sende brev + SPF + DKIM + rDNS og andre lignende småting.
Deretter må du konfigurere Dovecot og konfigurere Multidomain.
Deretter må du konfigurere SpamAssassin og konfigurere trening.
Til slutt, installer Bind.

============= Multi-grensesnitt ==============

For å konfigurere grensesnitt, må du skrive dette i "/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

Disse innstillingene kan brukes på hvilken som helst server i tech.ru (med litt koordinering med støtte) og det vil umiddelbart fungere som det skal.

Hvis du har erfaring med å sette opp lignende ting for Hetzner, OVH, er det annerledes der. Vanskeligere.

eno1 er navnet på nettverkskort #1 (sakte, men ubegrenset).
eno2 er navnet på nettverkskort #2 (rask, men med en tariff).
tun0 er navnet på det virtuelle nettverkskortet fra OpenVPN.
XX.XX.XX.X0 - IPv4 #1 på eno1.
XX.XX.XX.X1 - IPv4 #2 på eno1.
XX.XX.XX.X2 - IPv4 #3 på eno1.
XX.XX.XX.X5 - IPv4 #1 på eno2.
XX.XX.XX.1 – IPv4-gateway.
XXXX:XXXX:XXXX:XXXX::/64 - IPv6 for hele serveren.
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 for eno2, alt annet fra utsiden går inn i eno1.
XXXX:XXXX:XXXX:XXXX::1 — IPv6-gateway (det er verdt å merke seg at dette kan/bør gjøres annerledes. Spesifiser IPv6-svitsjen).
dns-navneservere - 127.0.0.1 er indikert (fordi bind er installert lokalt) og 213.248.1.6 (dette er fra tech.ru).

"tabell eno1t" og "tabell eno2t" - meningen med disse rutereglene er at trafikk som kommer inn gjennom eno1 -> ville gå gjennom den, og trafikk som kommer inn gjennom eno2 -> ville gå gjennom den. Og også tilkoblinger initiert av serveren ville gå gjennom eno1.

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

Med denne kommandoen spesifiserer vi at all uforståelig trafikk som faller inn under en regel merket "tabell eno1t" -> sendes til eno1-grensesnittet.

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

Med denne kommandoen spesifiserer vi at all trafikk initiert av serveren skal dirigeres til eno1-grensesnittet.

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

Med denne kommandoen setter vi reglene for merking av trafikk.

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

Denne blokken spesifiserer en andre IPv4 for eno1-grensesnittet.

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

Med denne kommandoen setter vi ruten fra OpenVPN-klienter til lokal IPv4 bortsett fra XX.XX.XX.X0.
Jeg forstår fortsatt ikke hvorfor denne kommandoen er nok for all IPv4.

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

Det er her vi setter adressen til selve grensesnittet. Serveren vil bruke den som en "utgående" adresse. Blir ikke brukt på noen måte igjen.

Hvorfor er ":1:1::" så komplisert? Slik at OpenVPN fungerer riktig og kun for dette. Mer om dette senere.

Når det gjelder gateway - det er slik det fungerer, og det er greit. Men den riktige måten er å angi her IPv6-en til svitsjen som serveren er koblet til.

Av en eller annen grunn slutter IPv6 å fungere hvis jeg gjør dette. Dette er sannsynligvis et slags tech.ru-problem.

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

Dette legger til en IPv6-adresse til grensesnittet. Hvis du trenger hundre adresser, betyr det hundre linjer i denne filen.

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

Jeg noterte adressene og subnettene til alle grensesnitt for å gjøre det klart.
eno1 - må være "/64" - fordi dette er hele vår adressesamling.
tun0 - undernettet må være større enn eno1. Ellers vil det ikke være mulig å konfigurere en IPv6-gateway for OpenVPN-klienter.
eno2 - undernettet må være større enn tun0. Ellers vil ikke OpenVPN-klienter kunne få tilgang til lokale IPv6-adresser.
For klarhetens skyld valgte jeg et subnetttrinn på 16, men hvis du ønsker det, kan du til og med gjøre "1" trinn.
Følgelig er 64+16 = 80 og 80+16 = 96.

For enda større klarhet:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY er adresser som bør tildeles spesifikke nettsteder eller tjenester på eno1-grensesnittet.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY er adresser som bør tildeles spesifikke nettsteder eller tjenester på eno2-grensesnittet.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY er adresser som bør tildeles OpenVPN-klienter eller brukes som OpenVPN-tjenesteadresser.

For å konfigurere nettverket bør det være mulig å starte serveren på nytt.
IPv4-endringer plukkes opp når de utføres (pass på å pakke den inn i skjermen - ellers vil denne kommandoen ganske enkelt krasje nettverket på serveren):

/etc/init.d/networking restart

Legg til på slutten av filen "/etc/iproute2/rt_tables":

100 eno1t
101 eno2t

Uten dette kan du ikke bruke egendefinerte tabeller i filen "/etc/network/interfaces".
Tallene må være unike og mindre enn 65535.

IPv6-endringer kan enkelt endres uten å starte på nytt, men for å gjøre dette må du lære minst tre kommandoer:

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

Innstilling av "/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

Dette er serverens "sysctl"-innstillinger. La meg påpeke noe viktig.

net.ipv4.ip_forward = 1

Uten dette vil ikke OpenVPN fungere i det hele tatt.

net.ipv6.ip_nonlocal_bind = 1

Alle som prøver å binde IPv6 (for eksempel nginx) umiddelbart etter at grensesnittet er oppe vil få en feilmelding. At denne adressen ikke er tilgjengelig.

For å unngå en slik situasjon gjøres en slik innstilling.

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

Uten disse IPv6-innstillingene går ikke trafikk fra OpenVPN-klienten ut i verden.

Andre innstillinger er enten ikke relevante eller jeg husker ikke hva de er for.
Men i tilfelle lar jeg det være "som det er".

For at endringer i denne filen skal hentes uten å starte serveren på nytt, må du kjøre kommandoen:

sysctl -p

Flere detaljer om "tabell"-regler: habr.com/post/108690

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

OpenVPN IPv4 fungerer ikke uten iptables.

Mine iptables er slik for 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 er min statiske IPv4-adresse til den lokale maskinen.
10.8.0.0/24 - IPv4 openvpn-nettverk. IPv4-adresser for openvpn-klienter.
Konsistensen i reglene er viktig.

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

Dette er en begrensning slik at bare jeg kan bruke OpenVPN fra min statiske 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

For å videresende IPv4-pakker mellom OpenVPN-klienter og Internett, må du registrere en av disse kommandoene.

For forskjellige tilfeller er et av alternativene ikke egnet.
Begge kommandoene passer for mitt tilfelle.
Etter å ha lest dokumentasjonen, valgte jeg det første alternativet fordi det bruker mindre CPU.

For at alle iptables-innstillingene skal hentes etter omstart, må du lagre dem et sted.

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

Slike navn ble ikke valgt ved en tilfeldighet. De brukes av "iptables-persistent"-pakken.

apt-get install iptables-persistent

Installere hovedpakken for OpenVPN:

apt-get install openvpn easy-rsa

La oss sette opp en mal for sertifikater (erstatt verdiene dine):

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

La oss redigere sertifikatmalinnstillingene:

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

Opprett et serversertifikat:

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

La oss forberede muligheten til å lage de endelige “client-name.opvn”-filene:

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

La oss forberede et skript som vil slå sammen alle filene til en enkelt opvn-fil.

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

Opprette den første OpenVPN-klienten:

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

Filen "~/client-configs/files/client-name.ovpn" sendes til klientens enhet.

For iOS-klienter må du gjøre følgende triks:
Innholdet i "tls-auth"-taggen må være uten kommentarer.
Og sett også "key-direction 1" rett før "tls-auth"-taggen.

La oss konfigurere OpenVPN-serverkonfigurasjonen:

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

Dette er nødvendig for å angi en statisk adresse for hver klient (ikke nødvendig, men jeg bruker den):

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

Den vanskeligste og mest sentrale detaljen.

Dessverre vet ikke OpenVPN ennå hvordan man uavhengig konfigurerer en IPv6-gateway for klienter.
Du må "manuelt" videresende dette for hver klient.

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

Filen "/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

Filen "/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

Begge skriptene bruker filen "/etc/openvpn/variables":

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

Jeg synes det er vanskelig å huske hvorfor det er skrevet slik.

Nå ser nettmaske = 112 rart ut (det burde være 96 der).
Og prefikset er rart, det samsvarer ikke med tun0-nettverket.
Men ok, jeg lar det være som det er.

cipher DES-EDE3-CBC

Dette er ikke for alle - jeg valgte denne metoden for å kryptere forbindelsen.

Lær mer om å sette opp OpenVPN IPv4.

Lær mer om å sette opp OpenVPN IPv6.

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

Installere hovedpakken:

apt-get install postfix

Når du installerer, velg "nettsted".

Min "/etc/postfix/main.cf" ser slik ut:

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

La oss se på detaljene i denne konfigurasjonen.

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

I følge innbyggere i Khabrovsk inneholder denne blokken «feilinformasjon og feilaktige teser».Bare 8 år etter starten av min karriere begynte jeg å forstå hvordan SSL fungerer.

Derfor vil jeg ta meg friheten til å beskrive hvordan man bruker SSL (uten å svare på spørsmålene "Hvordan fungerer det?" og "Hvorfor fungerer det?").

Grunnlaget for moderne kryptering er opprettelsen av et nøkkelpar (to veldig lange tegnstrenger).

En "nøkkel" er privat, den andre nøkkelen er "offentlig". Vi holder den private nøkkelen svært nøye hemmelig. Vi deler ut den offentlige nøkkelen til alle.

Ved å bruke en offentlig nøkkel kan du kryptere en tekststreng slik at bare eieren av den private nøkkelen kan dekryptere den.
Vel, det er hele grunnlaget for teknologien.

Trinn #1 - https-sider.
Når du får tilgang til et nettsted, lærer nettleseren fra nettserveren at nettstedet er https og ber derfor om en offentlig nøkkel.
Nettserveren gir den offentlige nøkkelen. Nettleseren bruker den offentlige nøkkelen til å kryptere http-forespørselen og sende den.
Innholdet i en http-forespørsel kan bare leses av de som har den private nøkkelen, det vil si kun serveren som forespørselen er sendt til.
Http-forespørsel inneholder minst en URI. Derfor, hvis et land prøver å begrense tilgangen ikke til hele nettstedet, men til en bestemt side, er dette umulig å gjøre for https-nettsteder.

Trinn #2 - kryptert svar.
Nettserveren gir et svar som lett kan leses på veien.
Løsningen er ekstremt enkel – nettleseren genererer lokalt det samme private-offentlige nøkkelparet for hver https-side.
Og sammen med forespørselen om nettstedets offentlige nøkkel, sender den sin lokale offentlige nøkkel.
Nettserveren husker den, og når den sender http-svar, krypterer den med den offentlige nøkkelen til en spesifikk klient.
Nå kan http-svar bare dekrypteres av eieren av klientens private nettlesernøkkel (det vil si klienten selv).

Trinn nr. 3 - etablere en sikker forbindelse via en offentlig kanal.
Det er en sårbarhet i eksempel nr. 2 - ingenting hindrer velvillige i å fange opp en http-forespørsel og redigere informasjon om den offentlige nøkkelen.
Dermed vil mellommannen tydelig se alt innholdet i sendte og mottatte meldinger inntil kommunikasjonskanalen endres.
Å håndtere dette er ekstremt enkelt - bare send nettleserens offentlige nøkkel som en melding kryptert med nettserverens offentlige nøkkel.
Nettserveren sender først et svar som "din offentlige nøkkel er slik" og krypterer denne meldingen med den samme offentlige nøkkelen.
Nettleseren ser på svaret - hvis meldingen "din offentlige nøkkel er slik" mottas - så er dette en 100 % garanti for at denne kommunikasjonskanalen er sikker.
Hvor trygt er det?
Selve opprettelsen av en slik sikker kommunikasjonskanal skjer med en hastighet på ping*2. For eksempel 20ms.
Angriperen må ha den private nøkkelen til en av partene på forhånd. Eller finn en privat nøkkel på et par millisekunder.
Å hacke en moderne privat nøkkel vil ta flere tiår på en superdatamaskin.

Trinn #4 - offentlig database med offentlige nøkler.
Åpenbart, i hele denne historien er det en mulighet for en angriper til å sitte på kommunikasjonskanalen mellom klienten og serveren.
Klienten kan utgi seg for å være serveren, og serveren kan utgi seg for å være klienten. Og emuler et par nøkler i begge retninger.
Da vil angriperen se all trafikken og kunne "redigere" trafikken.
Endre for eksempel adressen hvor du skal sende penger eller kopier passordet fra nettbanken eller blokker "støtende" innhold.
For å bekjempe slike angripere kom de opp med en offentlig database med offentlige nøkler for hvert https-nettsted.
Hver nettleser "vet" om eksistensen av rundt 200 slike databaser. Dette kommer forhåndsinstallert i alle nettlesere.
"Kunnskap" støttes av en offentlig nøkkel fra hvert sertifikat. Det vil si at forbindelsen til hver spesifikke sertifiseringsinstans ikke kan forfalskes.

Nå er det en enkel forståelse av hvordan du bruker SSL for https.
Hvis du bruker hjernen din, vil det vise seg hvordan spesialtjenestene kan hacke noe i denne strukturen. Men det vil koste dem monstrøse anstrengelser.
Og organisasjoner mindre enn NSA eller CIA - det er nesten umulig å hacke det eksisterende beskyttelsesnivået, selv for VIP-er.

Jeg vil også legge til om ssh-tilkoblinger. Det er ingen offentlige nøkler der, så hva kan du gjøre? Problemet løses på to måter.
Alternativ ssh-by-password:
Under den første tilkoblingen skal ssh-klienten varsle om at vi har en ny offentlig nøkkel fra ssh-serveren.
Og under ytterligere tilkoblinger, hvis advarselen "ny offentlig nøkkel fra ssh-serveren" vises, vil det bety at de prøver å avlytte deg.
Eller du ble avlyttet på din første tilkobling, men nå kommuniserer du med serveren uten mellomledd.
Faktisk, på grunn av det faktum at avlytting enkelt, raskt og uanstrengt avsløres, brukes dette angrepet kun i spesielle tilfeller for en spesifikk klient.

Alternativ ssh-for-key:
Vi tar en flash-stasjon, skriver den private nøkkelen for ssh-serveren på den (det er vilkår og mange viktige nyanser for dette, men jeg skriver et pedagogisk program, ikke bruksanvisning).
Vi lar den offentlige nøkkelen ligge på maskinen der ssh-klienten vil være, og vi holder den også hemmelig.
Vi tar med flash-stasjonen til serveren, setter den inn, kopierer den private nøkkelen og brenner flash-stasjonen og sprer asken for vinden (eller i det minste formater den med nuller).
Det er alt - etter en slik operasjon vil det være umulig å hacke en slik ssh-tilkobling. Selvfølgelig, om 10 år vil det være mulig å se trafikk på en superdatamaskin - men det er en annen historie.

Jeg beklager offtopic.

Så nå som teorien er kjent. Jeg vil fortelle deg om flyten ved å lage et SSL-sertifikat.

Ved å bruke "openssl genrsa" lager vi en privat nøkkel og "blanks" for den offentlige nøkkelen.
Vi sender "blanks" til et tredjepartsselskap, som vi betaler omtrent $9 for det enkleste sertifikatet.

Etter et par timer mottar vi vår "offentlige" nøkkel og et sett med flere offentlige nøkler fra dette tredjepartsselskapet.

Hvorfor skal et tredjepartsselskap betale for registreringen av min offentlige nøkkel er et eget spørsmål, vi vil ikke vurdere det her.

Nå er det klart hva meningen med inskripsjonen er:

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

"/etc/ssl"-mappen inneholder alle filene for ssl-problemer.
domain1.com - domenenavn.
2018 er året for nøkkelskaping.
"nøkkel" - betegnelse på at filen er en privat nøkkel.

Og betydningen av denne filen:

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domain1.com - domenenavn.
2018 er året for nøkkelskaping.
lenket - betegnelse på at det er en kjede av offentlige nøkler (den første er vår offentlige nøkkel og resten er det som kom fra selskapet som utstedte den offentlige nøkkelen).
crt - betegnelse på at det finnes et ferdig sertifikat (offentlig nøkkel med tekniske forklaringer).

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

Denne innstillingen brukes ikke i dette tilfellet, men er skrevet som et eksempel.

Fordi en feil i denne parameteren vil føre til at spam sendes fra serveren din (uten din vilje).

Så bevis for alle at du ikke er skyldig.

recipient_delimiter = +

Mange vet kanskje ikke, men dette er et standardtegn for rangering av e-poster, og det støttes av de fleste moderne e-postservere.

For eksempel, hvis du har en postkasse "[e-postbeskyttet]"prøv å sende til"[e-postbeskyttet]"- se hva som kommer ut av det.

inet_protocols = ipv4

Dette kan være forvirrende.

Men det er ikke bare sånn. Hvert nye domene er som standard kun IPv4, så slår jeg på IPv6 for hvert enkelt domene.

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

Her spesifiserer vi at all innkommende post går til dovecot.
Og reglene for domene, postkasse, alias - se i databasen.

/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

Nå vet postfix at post kun kan aksepteres for videre sending etter autorisasjon med dovecot.

Jeg forstår egentlig ikke hvorfor dette dupliseres her. Vi har allerede spesifisert alt som trengs i "virtuell_transport".

Men postfix-systemet er veldig gammelt - sannsynligvis er det et tilbakeslag fra gamle dager.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Dette kan konfigureres forskjellig for hver e-postserver.

Jeg har 3 e-postservere til rådighet og disse innstillingene er svært forskjellige på grunn av ulike brukskrav.

Du må konfigurere den nøye - ellers vil spam strømme inn til deg, eller enda verre - spam vil strømme ut fra deg.

# SPF
policyd-spf_time_limit = 3600

Oppsett for noen plugin relatert til å sjekke SPF for innkommende brev.

# 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

Innstillingen er at vi må gi en DKIM-signatur med alle utgående e-poster.

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

Dette er en nøkkeldetalj i brevruting når du sender brev fra PHP-skript.

Filen "/etc/postfix/sdd_transport.pcre":

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

Til venstre er regulære uttrykk. Til høyre er en etikett som markerer bokstaven.
Postfix i samsvar med etiketten - vil ta hensyn til noen flere konfigurasjonslinjer for en bestemt bokstav.

Hvor nøyaktig postfix vil bli rekonfigurert for en spesifikk bokstav vil bli indikert i "master.cf".

Linje 4, 5, 6 er de viktigste. På vegne av hvilket domene vi sender brevet, setter vi denne etiketten.
Men "fra"-feltet er ikke alltid angitt i PHP-skript i den gamle koden. Da kommer brukernavnet til unnsetning.

Artikkelen er allerede omfattende - jeg vil ikke bli distrahert av å sette opp nginx+fpm.

Kort sagt, for hvert nettsted angir vi sin egen linux-bruker-eier. Og følgelig fpm-poolen din.

Fpm-pool bruker hvilken som helst versjon av php (det er flott når du på samme server kan bruke forskjellige versjoner av php og til og med forskjellige php.ini for nabosider uten problemer).

Så en spesifikk linux-bruker "www-domain2" har et nettsted domain2.com. Denne siden har en kode for å sende e-post uten å spesifisere fra-feltet.

Så selv i dette tilfellet vil brevene bli sendt riktig og vil aldri havne i spam.

Min "/etc/postfix/master.cf" ser slik ut:

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

Filen er ikke oppgitt i sin helhet - den er allerede veldig stor.
Jeg noterte bare hva som ble endret.

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}

Dette er innstillinger relatert til spamassasin, mer om det senere.

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

Vi lar deg koble til e-postserveren via port 587.
For å gjøre dette må du logge inn.

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

Aktiver SPF-sjekk.

apt-get install postfix-policyd-spf-python

La oss installere pakken for SPF-sjekker ovenfor.

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

Og dette er det mest interessante. Dette er muligheten til å sende brev for et spesifikt domene fra en spesifikk IPv4/IPv6-adresse.

Dette gjøres av hensyn til rDNS. rDNS er prosessen med å motta en streng etter IP-adresse.
Og for e-post brukes denne funksjonen til å bekrefte at heloen samsvarer nøyaktig med rDNS-en til adressen som e-posten ble sendt fra.

Hvis heloen ikke samsvarer med e-postdomenet som brevet ble sendt på vegne av, tildeles spampoeng.

Helo samsvarer ikke med rDNS - det tildeles mange spampoeng.
Følgelig må hvert domene ha sin egen IP-adresse.
For OVH - i konsollen er det mulig å spesifisere rDNS.
For tech.ru - problemet er løst gjennom støtte.
For AWS er problemet løst gjennom støtte.
"inet_protocols" og "smtp_bind_address6" - vi aktiverer IPv6-støtte.
For IPv6 må du også registrere rDNS.
"syslog_name" - og dette er for enkel lesing av logger.

Kjøp sertifikater Jeg anbefaler her.

Setter opp postfix+dovecot link her.

Stille inn SPF.

============= Dueslag ==============

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

Setter opp mysql, installerer selve pakkene.

Filen "/etc/dovecot/conf.d/10-auth.conf"

disable_plaintext_auth = yes
auth_mechanisms = plain login

Autorisasjonen er kun kryptert.

Filen "/etc/dovecot/conf.d/10-mail.conf"

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

Her angir vi lagringsstedet for bokstavene.

Jeg vil at de skal lagres i filer og grupperes etter domene.

Filen "/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 {
  }
}

Dette er hovedkonfigurasjonsfilen for dueslag.
Her deaktiverer vi usikrede tilkoblinger.
Og muliggjør sikre tilkoblinger.

Filen "/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
}

Sette opp ssl. Vi indikerer at ssl er påkrevd.
Og selve sertifikatet. Og en viktig detalj er det "lokale" direktivet. Indikerer hvilket SSL-sertifikat som skal brukes ved tilkobling til hvilken lokal IPv4.

Forresten, IPv6 er ikke konfigurert her, jeg skal rette denne utelatelsen senere.
XX.XX.XX.X5 (domene2) – ingen sertifikat. For å koble til klienter må du spesifisere domain1.com.
XX.XX.XX.X2 (domene3) - det er et sertifikat, du kan spesifisere domain1.com eller domain3.com for å koble til klienter.

Filen "/etc/dovecot/conf.d/15-lda.conf"

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Dette vil være nødvendig for spamassassin i fremtiden.

Filen "/etc/dovecot/conf.d/20-imap.conf"

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Dette er en antispam-plugin. Nødvendig for trening spamassasin ved overføring til/fra "Spam"-mappen.

Filen "/etc/dovecot/conf.d/20-pop3.conf"

protocol pop3 {
}

Det er akkurat en slik fil.

Filen "/etc/dovecot/conf.d/20-lmtp.conf"

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

Sette opp lmtp.

Filen "/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
}

Spamassasin treningsinnstillinger på tidspunktet for overføring til/fra Spam-mappen.

Filen "/etc/dovecot/conf.d/90-sieve.conf"

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

En fil som spesifiserer hva som skal gjøres med innkommende brev.

Filen "/var/lib/dovecot/sieve/default.sieve"

require ["fileinto", "mailbox"];

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

Du må kompilere filen: "sievec default.sieve".

Filen "/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
}

Spesifisere sql-filer for autorisasjon.
Og selve filen brukes som en autorisasjonsmetode.

Filen "/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';

Dette tilsvarer lignende innstillinger for postfix.

Filen "/etc/dovecot/dovecot.conf"

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

Hovedkonfigurasjonsfil.
Det viktige er at vi indikerer her - legg til protokoller.

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

apt-get install spamassassin spamc

La oss installere pakkene.

adduser spamd --disabled-login

La oss legge til en bruker på hvis vegne.

systemctl enable spamassassin.service

Vi aktiverer automatisk innlasting av spamassassin-tjeneste ved lasting.

Fil "/etc/default/spamassassin":

CRON=1

Ved å aktivere automatisk oppdatering av regler "som standard".

Fil "/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

Du må opprette en database "sa" i mysql med brukeren "sa" med passordet "passord" (erstatt med noe tilstrekkelig).

report_safe - dette vil sende en rapport om søppelpost i stedet for et brev.
use_bayes er spamassassin maskinlæringsinnstillinger.

De resterende spamassassin-innstillingene ble brukt tidligere i artikkelen.

Generell innstilling "spamassassin".
Om å flytte nye spam-e-poster til IMAP "Spam"-mappen.
Om en enkel kombinasjon av Dovecot + SpamAssassin.
Jeg anbefaler å lese spamassasin-læringsteorien når du flytter bokstaver i imap-mapper (og jeg anbefaler ikke å bruke den).

============= Appell til fellesskapet ==============

Jeg vil også kaste en idé inn i fellesskapet om hvordan man kan øke sikkerhetsnivået for videresendte brev. Siden jeg er så dypt fordypet i emnet post.

Slik at brukeren kan lage et par nøkler på klienten sin (outlook, thunderbird, nettleser-plugin, ...). Offentlig og privat. Offentlig - send til DNS. Privat – spar på klienten. E-postservere vil kunne bruke en offentlig nøkkel for å sende til en bestemt mottaker.

Og for å beskytte mot spam med slike brev (ja, e-postserveren vil ikke kunne se innholdet) - må du innføre 3 regler:

Obligatorisk ekte DKIM-signatur, obligatorisk SPF, obligatorisk rDNS.
Et nevralt nettverk om antispamopplæring + en database for det på klientsiden.
Krypteringsalgoritmen må være slik at avsendersiden må bruke 100 ganger mer CPU-kraft på kryptering enn mottakersiden.

I tillegg til offentlige brev, utvikle et standard forslagsbrev "for å begynne sikker korrespondanse." En av brukerne (postkasse) sender et brev med vedlegg til en annen postkasse. Brevet inneholder et tekstforslag om å starte en sikker kommunikasjonskanal for korrespondanse og den offentlige nøkkelen til eieren av postkassen (med privat nøkkel på klientsiden).

Du kan til og med lage et par nøkler spesifikt for hver korrespondanse. Mottakerbrukeren kan godta dette tilbudet og sende sin offentlige nøkkel (også laget spesielt for denne korrespondansen). Deretter sender den første brukeren et tjenestekontrollbrev (kryptert med den offentlige nøkkelen til den andre brukeren) - ved mottak av dette kan den andre brukeren vurdere den dannede kommunikasjonskanalen som pålitelig. Deretter sender den andre brukeren et kontrollbrev - og da kan den første brukeren også vurdere den dannede kanalen som sikker.

For å bekjempe avskjæring av nøkler på veien, må protokollen gi mulighet for å overføre minst én offentlig nøkkel ved hjelp av en flash-stasjon.

Og det viktigste er at alt fungerer (spørsmålet er "hvem skal betale for det?"):
Skriv inn postbevis som starter på $10 for 3 år. Som vil tillate avsenderen å indikere i dns at "mine offentlige nøkler er der borte." Og de vil gi deg muligheten til å starte en sikker tilkobling. Samtidig er det gratis å akseptere slike forbindelser.
Gmail tjener endelig penger på brukerne. For $10 per 3 år - retten til å opprette sikre korrespondansekanaler.

============= Konklusjon ==============

For å teste hele artikkelen skulle jeg leie en dedikert server i en måned og kjøpe et domene med SSL-sertifikat.

Men livsomstendighetene utviklet seg, så dette problemet varte i 2 måneder.
Og så, da jeg hadde fri igjen, bestemte jeg meg for å publisere artikkelen som den er, i stedet for å risikere at publiseringen ville trekke ut i ett år til.

Hvis det er ganske mange spørsmål som "men dette er ikke beskrevet i tilstrekkelig detalj", så vil det sannsynligvis være styrke å ta en dedikert server med et nytt domene og et nytt SSL-sertifikat og beskrive det enda mer detaljert og, de fleste viktigst, identifiser alle de manglende viktige detaljene.

Jeg vil også gjerne få tilbakemelding på ideer om postbevis. Hvis du liker ideen, skal jeg prøve å finne styrken til å skrive et utkast til rfc.

Når du kopierer store deler av en artikkel, oppgi en lenke til denne artikkelen.
Når du oversetter til et annet språk, oppgi en lenke til denne artikkelen.
Jeg skal prøve å oversette den til engelsk selv og legge igjen kryssreferanser.

Kilde: www.habr.com

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