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

Այս հոդվածը այն մասին է, թե ինչպես ստեղծել ժամանակակից փոստային սերվեր:
Postfix + Dovecot. SPF + DKIM + rDNS: IPv6-ով:
TSL կոդավորումով: Բազմաթիվ տիրույթների աջակցությամբ - մաս իրական SSL վկայականով:
Հակասպամ պաշտպանությամբ և փոստի այլ սերվերների բարձր հակասպամ վարկանիշով:
Աջակցում է բազմաթիվ ֆիզիկական միջերեսներ:
OpenVPN-ով, որի կապը IPv4-ի միջոցով է, և որն ապահովում է IPv6:

Եթե ​​դուք չեք ցանկանում սովորել այս բոլոր տեխնոլոգիաները, բայց ցանկանում եք ստեղծել այդպիսի սերվեր, ապա այս հոդվածը ձեզ համար է:

Հոդվածում փորձ չի արվում բացատրել յուրաքանչյուր մանրուք: Բացատրությունը վերաբերում է այն բանին, ինչը կազմաձևված չէ որպես ստանդարտ կամ կարևոր է սպառողի տեսանկյունից:

Փոստի սերվեր ստեղծելու մոտիվացիան եղել է իմ վաղեմի երազանքը: Սա կարող է հիմարություն թվալ, բայց IMHO, դա շատ ավելի լավ է, քան երազել ձեր սիրելի ապրանքանիշի նոր մեքենայի մասին:

IPv6-ի ստեղծման երկու դրդապատճառ կա. ՏՏ մասնագետը պետք է անընդհատ նոր տեխնոլոգիաներ սովորի, որպեսզի գոյատևի: Ցանկանում եմ իմ համեստ ներդրումն ունենալ գրաքննության դեմ պայքարում։

OpenVPN-ի ստեղծման շարժառիթն այն է, որ IPv6-ն աշխատի տեղական մեքենայի վրա:
Մի քանի ֆիզիկական ինտերֆեյս տեղադրելու շարժառիթն այն է, որ իմ սերվերի վրա ես ունեմ մեկ ինտերֆեյս «դանդաղ, բայց անսահմանափակ», և մյուսը «արագ, բայց սակագնով»:

Bind-ի կարգավորումները կարգավորելու շարժառիթն այն է, որ իմ ISP-ն ապահովում է անկայուն DNS սերվեր, և google-ը նույնպես երբեմն ձախողվում է: Ես ուզում եմ կայուն DNS սերվեր անձնական օգտագործման համար:

Հոդված գրելու մոտիվացիա - Ես նախագիծ եմ գրել 10 ամիս առաջ, և արդեն երկու անգամ նայել եմ դրան: Եթե ​​նույնիսկ հեղինակին պարբերաբար դա պետք է, մեծ է հավանականությունը, որ ուրիշներին էլ դա պետք կգա։

Փոստի սերվերի համար ունիվերսալ լուծում չկա: Բայց ես կփորձեմ գրել այնպիսի մի բան, ինչպիսին է «արա սա և հետո, երբ ամեն ինչ աշխատի այնպես, ինչպես պետք է, դուրս գցիր ավելորդ բաները»:

Tech.ru ընկերությունն ունի Colocation սերվեր: Հնարավոր է համեմատել OVH-ի, Hetzner-ի, AWS-ի հետ։ Այս խնդիրը լուծելու համար tech.ru-ի հետ համագործակցությունը շատ ավելի արդյունավետ կլինի։

Debian 9-ը տեղադրված է սերվերի վրա:

Սերվերն ունի 2 ինտերֆեյս՝ «eno1» և «eno2»: Առաջինն անսահմանափակ է, իսկ երկրորդը՝ համապատասխանաբար արագ։

Կան 3 ստատիկ IP հասցեներ՝ XX.XX.XX.X0 և XX.XX.XX.X1 և XX.XX.XX.X2 «eno1» ինտերֆեյսի վրա և XX.XX.XX.X5 «eno2» ինտերֆեյսի վրա: .

Հասանելի է XXXX:XXXX:XXXX:XXXX::/64 IPv6 հասցեների մի խումբ, որոնք վերագրված են «eno1» ինտերֆեյսին և դրանից XXXX:XXXX:XXXX:XXXX:1:2::/96 նշանակվել է «eno2»-ին իմ խնդրանքով:

Կան 3 տիրույթ՝ «domain1.com», «domain2.com», «domain3.com»: «domain1.com» և «domain3.com» համար կա SSL վկայագիր:

Ես ունեմ Google հաշիվ, որին կցանկանայի կապել իմ փոստարկղը[էլեկտրոնային փոստով պաշտպանված]` (փոստի ստացում և փոստի ուղարկում անմիջապես gmail-ի միջերեսից):
Պետք է լինի փոստարկղ»:[էլեկտրոնային փոստով պաշտպանված]`, նամակի պատճենը, որից ես ուզում եմ տեսնել իմ gmail-ում: Եվ հազվադեպ է, որ կարողանալ ինչ-որ բան ուղարկել «-ի անունից[էլեկտրոնային փոստով պաշտպանված]` վեբ ինտերֆեյսի միջոցով:

Պետք է լինի փոստարկղ»:[էլեկտրոնային փոստով պաշտպանված]«, որը Իվանովը կօգտագործի իր iPhone-ից։

Ուղարկված նամակները պետք է համապատասխանեն հակասպամի բոլոր ժամանակակից պահանջներին:
Հանրային ցանցերում պետք է լինի գաղտնագրման ամենաբարձր մակարդակը:
Պետք է լինի IPv6 աջակցություն նամակներ ուղարկելու և ստանալու համար:
Պետք է լինի SpamAssassin, որը երբեք չի ջնջի էլ. Եվ այն կա՛մ կցատկի, կա՛մ բաց կթողնի կամ կուղարկի IMAP «Սպամ» պանակ:
SpamAssassin auto-learning-ը պետք է կազմաձևվի. եթե ես նամակ տեղափոխեմ Spam պանակ, այն կսովորի դրանից. եթե ես նամակ տեղափոխեմ Spam թղթապանակից, այն կսովորի դրանից: SpamAssassin-ի վերապատրաստման արդյունքները պետք է ազդեն, թե արդյոք նամակը հայտնվում է Spam թղթապանակում:
PHP սկրիպտները պետք է կարողանան փոստ ուղարկել տվյալ սերվերի ցանկացած տիրույթի անունից:
Պետք է լինի openvpn ծառայություն՝ IPv6-ը IPv6 չունեցող հաճախորդի վրա օգտագործելու հնարավորությամբ:

Նախ անհրաժեշտ է կարգավորել միջերեսները և երթուղին, ներառյալ IPv6-ը:
Այնուհետև ձեզ հարկավոր է կարգավորել OpenVPN-ը, որը կմիանա IPv4-ի միջոցով և հաճախորդին կտրամադրի ստատիկ-իրական IPv6 հասցե։ Այս հաճախորդը մուտք կունենա սերվերի բոլոր IPv6 ծառայությունները և մուտք կունենա ինտերնետի ցանկացած IPv6 ռեսուրս:
Այնուհետև ձեզ հարկավոր է կարգավորել Postfix-ը տառեր + SPF + DKIM + rDNS և նմանատիպ այլ մանրուքներ ուղարկելու համար:
Այնուհետև ձեզ հարկավոր է կարգավորել Dovecot-ը և կարգավորել Multidomain-ը:
Այնուհետև ձեզ հարկավոր է կարգավորել SpamAssassin-ը և կարգավորել ուսուցումը:
Վերջապես տեղադրեք Bind-ը:

============= Բազմ ինտերֆեյս =============

Միջերեսները կարգավորելու համար դուք պետք է սա գրեք «/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

Այս կարգավորումները կարող են կիրառվել tech.ru-ի ցանկացած սերվերի վրա (աջակցության հետ մի փոքր համակարգմամբ) և այն անմիջապես կաշխատի այնպես, ինչպես պետք է:

Եթե ​​դուք ունեք նմանատիպ բաներ ստեղծելու փորձ Hetzner, OVH-ի համար, այնտեղ այլ է: Ավելի դժվար.

eno1-ը թիվ 1 ցանցային քարտի անունն է (դանդաղ, բայց անսահմանափակ):
eno2-ը թիվ 2 ցանցային քարտի անվանումն է (արագ, բայց սակագնով):
tun0-ը OpenVPN-ից վիրտուալ ցանցային քարտի անունն է:
XX.XX.XX.X0 - IPv4 #1 eno1-ում:
XX.XX.XX.X1 - IPv4 #2 eno1-ում:
XX.XX.XX.X2 - IPv4 #3 eno1-ում:
XX.XX.XX.X5 - IPv4 #1 eno2-ում:
XX.XX.XX.1 - IPv4 դարպաս:
XXXX:XXXX:XXXX:XXXX::/64 - IPv6 ամբողջ սերվերի համար:
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 eno2-ի համար, մնացած ամեն ինչ դրսից գնում է eno1:
XXXX:XXXX:XXXX:XXXX::1 — IPv6 դարպաս (արժե նշել, որ դա կարող է/պետք է այլ կերպ արվի: Նշեք IPv6 անջատիչը):
dns-nameservers - նշված է 127.0.0.1 (քանի որ bind-ը տեղադրված է տեղում) և 213.248.1.6 (սա tech.ru-ից է):

«աղյուսակ eno1t» և «table eno2t» - այս երթուղի-կանոնների իմաստն այն է, որ eno1 ->-ով մուտք գործող երթևեկությունը դուրս է գալիս դրա միջով, իսկ eno2 ->-ով մուտք գործող երթևեկությունը դուրս է գալիս դրա միջով: Եվ նաև սերվերի կողմից նախաձեռնված կապերը կանցնեն eno1-ի միջոցով:

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

Այս հրամանով մենք նշում ենք, որ ցանկացած անհասկանալի տրաֆիկ, որը պատկանում է «աղյուսակ eno1t» -> նշվող ցանկացած կանոնին, ուղարկվի eno1 ինտերֆեյս:

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

Այս հրամանով մենք նշում ենք, որ սերվերի կողմից նախաձեռնված ցանկացած տրաֆիկ պետք է ուղղվի eno1 ինտերֆեյսին:

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

Այս հրամանով մենք սահմանում ենք երթեւեկության նշագրման կանոնները։

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

Այս բլոկը սահմանում է երկրորդ IPv4 eno1 ինտերֆեյսի համար:

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

Այս հրամանով մենք երթուղին սահմանեցինք OpenVPN հաճախորդներից դեպի տեղական IPv4, բացառությամբ XX.XX.XX.X0-ի:
Ես դեռ չեմ հասկանում, թե ինչու է այս հրամանը բավարար բոլոր IPv4-ի համար:

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

Այստեղ մենք սահմանում ենք ինտերֆեյսի հասցեն: Սերվերը կօգտագործի այն որպես «ելքային» հասցե: Այլևս ոչ մի կերպ չի օգտագործվի։

Ինչո՞ւ է «:1:1::»-ն այդքան բարդ: Որպեսզի OpenVPN-ն աշխատի ճիշտ և միայն դրա համար։ Այս մասին ավելի ուշ:

Դարպասի թեմայի վերաբերյալ, դա այդպես է աշխատում, և դա լավ է: Բայց ճիշտ ճանապարհը այստեղ նշելն է այն անջատիչի IPv6-ը, որին միացված է սերվերը։

Այնուամենայնիվ, ինչ-ինչ պատճառներով IPv6-ը դադարում է աշխատել, եթե ես դա անեմ: Սա հավանաբար ինչ-որ tech.ru-ի խնդիր է:

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

Սա IPv6 հասցե է ավելացնում ինտերֆեյսին: Եթե ​​Ձեզ անհրաժեշտ է հարյուր հասցե, դա նշանակում է հարյուր տող այս ֆայլում:

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

Ես նշել եմ բոլոր ինտերֆեյսերի հասցեները և ենթացանցերը, որպեսզի պարզ լինի:
eno1 - պետք է լինի/64- որովհետև սա մեր հասցեների ամբողջ լողավազանն է։
tun0 - ենթացանցը պետք է լինի eno1-ից մեծ: Հակառակ դեպքում, OpenVPN հաճախորդների համար հնարավոր չի լինի կարգավորել IPv6 դարպաս:
eno2 - ենթացանցը պետք է լինի tun0-ից մեծ: Հակառակ դեպքում, OpenVPN հաճախորդները չեն կարողանա մուտք գործել տեղական IPv6 հասցեներ:
Պարզության համար ես ընտրեցի ենթացանցային քայլը 16-ից, բայց եթե ցանկանում եք, կարող եք նույնիսկ «1» քայլ կատարել:
Համապատասխանաբար, 64+16 = 80, և 80+16 = 96:

Նույնիսկ ավելի մեծ պարզության համար.
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY հասցեներ են, որոնք պետք է վերագրվեն eno1 ինտերֆեյսի հատուկ կայքերին կամ ծառայություններին:
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY հասցեներ են, որոնք պետք է վերագրվեն eno2 ինտերֆեյսի հատուկ կայքերին կամ ծառայություններին:
XXXX:XXX:XXXX:XXXX:1:3:YYYY:YYYY հասցեներ են, որոնք պետք է վերագրվեն OpenVPN հաճախորդներին կամ օգտագործվեն որպես OpenVPN ծառայության հասցեներ:

Ցանցը կարգավորելու համար պետք է հնարավոր լինի վերագործարկել սերվերը:
IPv4-ի փոփոխություններն ընդունվում են կատարման ժամանակ (համոզվեք, որ այն փաթաթեք էկրանին, հակառակ դեպքում այս հրամանը պարզապես կխափանի ցանցը սերվերի վրա).

/etc/init.d/networking restart

Ավելացնել ֆայլի վերջում «/etc/iproute2/rt_tables»:

100 eno1t
101 eno2t

Առանց դրա, դուք չեք կարող օգտագործել հատուկ աղյուսակներ «/etc/network/interfaces» ֆայլում:
Թվերը պետք է լինեն եզակի և 65535-ից պակաս։

IPv6-ի փոփոխությունները կարելի է հեշտությամբ փոխել՝ առանց վերագործարկման, բայց դա անելու համար դուք պետք է սովորեք առնվազն երեք հրաման.

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

«/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

Սրանք իմ սերվերի «sysctl» կարգավորումներն են: Մի կարևոր բան նշեմ.

net.ipv4.ip_forward = 1

Առանց դրա, OpenVPN-ն ընդհանրապես չի աշխատի.

net.ipv6.ip_nonlocal_bind = 1

Յուրաքանչյուր ոք, ով կփորձի կապել IPv6-ը (օրինակ՝ nginx) ինտերֆեյսի գործարկումից անմիջապես հետո, սխալ կստանա: Որ այս հասցեն հասանելի չէ։

Նման իրավիճակից խուսափելու համար նման պարամետր է արվում.

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

Առանց այս IPv6 պարամետրերի, OpenVPN հաճախորդից երթևեկությունը դուրս չի գալիս աշխարհ:

Մյուս կարգավորումները կամ տեղին չեն, կամ ես չեմ հիշում, թե ինչի համար են դրանք:
Բայց ամեն դեպքում թողնում եմ «ինչպես կա»:

Որպեսզի այս ֆայլի փոփոխություններն ընդունվեն առանց սերվերի վերագործարկման, դուք պետք է գործարկեք հրամանը.

sysctl -p

Ավելի մանրամասն «սեղանի» կանոնների մասին. habr.com/post/108690

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

OpenVPN IPv4-ը չի աշխատում առանց iptable-ների.

Իմ iptable-ները 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-ն տեղական մեքենայի իմ ստատիկ IPv4 հասցեն է:
10.8.0.0/24 - IPv4 openvpn ցանց: IPv4 հասցեներ openvpn հաճախորդների համար.
Կարևոր է կանոնների հետևողականությունը.

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

Սա սահմանափակում է, որպեսզի միայն ես կարողանամ օգտագործել OpenVPN իմ ստատիկ 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

IPv4 փաթեթները OpenVPN հաճախորդների և ինտերնետի միջև փոխանցելու համար դուք պետք է գրանցեք այս հրամաններից մեկը:

Տարբեր դեպքերի համար տարբերակներից մեկը հարմար չէ։
Երկու հրամաններն էլ հարմար են իմ գործի համար։
Փաստաթղթերը կարդալուց հետո ես ընտրեցի առաջին տարբերակը, քանի որ այն ավելի քիչ պրոցեսոր է օգտագործում:

Որպեսզի iptables-ի բոլոր կարգավորումները վերագործարկվելուց հետո վերցվեն, դուք պետք է դրանք ինչ-որ տեղ պահեք:

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

Նման անուններ պատահական չեն ընտրվել. Դրանք օգտագործվում են «iptables-persistent» փաթեթով։

apt-get install iptables-persistent

Հիմնական OpenVPN փաթեթի տեղադրում.

apt-get install openvpn easy-rsa

Եկեք ստեղծենք վկայագրերի ձևանմուշ (փոխարինեք ձեր արժեքները).

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

Եկեք խմբագրենք վկայագրի ձևանմուշի կարգավորումները.

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

Ստեղծեք սերվերի վկայագիր.

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

Եկեք պատրաստենք վերջնական «client-name.opvn» ֆայլերը ստեղծելու հնարավորությունը.

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

# Client mode
client

# Interface tunnel type
dev tun

# TCP protocol
proto tcp-client

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

# Don't bind to local port/address
nobind

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

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

# Enable compression
comp-lzo

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

Եկեք պատրաստենք մի սցենար, որը կմիավորի բոլոր ֆայլերը մեկ 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

Առաջին OpenVPN հաճախորդի ստեղծումը.

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

«~/client-configs/files/client-name.ovpn» ֆայլն ուղարկվում է հաճախորդի սարքին:

iOS-ի հաճախորդների համար դուք պետք է կատարեք հետևյալ հնարքը.
«tls-auth» թեգի բովանդակությունը պետք է լինի առանց մեկնաբանությունների։
Եվ նաև դրեք «key-direction 1» անմիջապես «tls-auth» թեգից առաջ:

Եկեք կարգավորենք 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

Սա անհրաժեշտ է յուրաքանչյուր հաճախորդի համար ստատիկ հասցե սահմանելու համար (անհրաժեշտ չէ, բայց ես օգտագործում եմ այն).

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

Ամենադժվար և առանցքային դետալը.

Ցավոք, OpenVPN-ը դեռ չգիտի, թե ինչպես ինքնուրույն կարգավորել IPv6 դարպասը հաճախորդների համար:
Դուք պետք է «ձեռքով» փոխանցեք սա յուրաքանչյուր հաճախորդի համար:

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

Ֆայլ «/etc/openvpn/server-clientconnect.sh»:

#!/bin/sh

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

# Load server variables
. /etc/openvpn/variables

ipv6=""

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

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

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

Ֆայլ «/etc/openvpn/server-clientdisconnect.sh»:

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

Երկու սցենարներն էլ օգտագործում են «/etc/openvpn/variables» ֆայլը՝

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

Դժվարանում եմ հիշել, թե ինչու է այսպես գրված.

Այժմ netmask = 112 տարօրինակ տեսք ունի (այն պետք է լինի 96 հենց այնտեղ):
Իսկ նախածանցը տարօրինակ է, այն չի համապատասխանում tun0 ցանցին։
Բայց լավ, ես կթողնեմ այնպես, ինչպես կա:

cipher DES-EDE3-CBC

Սա բոլորի համար չէ. ես ընտրեցի կապի գաղտնագրման այս մեթոդը:

Իմացեք ավելին OpenVPN IPv4 կարգավորելու մասին:

Իմացեք ավելին OpenVPN IPv6 կարգավորելու մասին:

============= Փոստֆիքս ==============

Հիմնական փաթեթի տեղադրում.

apt-get install postfix

Տեղադրելիս ընտրեք «ինտերնետ կայք»:

Իմ «/etc/postfix/main.cf»-ն այսպիսի տեսք ունի.

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

Եկեք նայենք այս կազմաձևի մանրամասներին:

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

Խաբրովսկի բնակիչների խոսքով՝ այս բլոկը պարունակում է «ապատեղեկատվություն և սխալ թեզեր»։Իմ կարիերայի սկզբից ընդամենը 8 տարի անց ես սկսեցի հասկանալ, թե ինչպես է աշխատում SSL-ը:

Հետևաբար, ես կվերցնեմ ազատությունը նկարագրելու, թե ինչպես օգտագործել SSL-ը (առանց «Ինչպե՞ս է այն աշխատում» և «Ինչու՞ է այն աշխատում» հարցերին պատասխանելու):

Ժամանակակից գաղտնագրման հիմքը բանալիների զույգի ստեղծումն է (նիշերի երկու շատ երկար տողեր):

Մեկ «բանալին» մասնավոր է, մյուս բանալին՝ «հանրային»: Մենք անձնական բանալին շատ խնամքով գաղտնի ենք պահում: Մենք հանրային բանալին ենք բաժանում բոլորին:

Օգտագործելով հանրային բանալի, դուք կարող եք գաղտնագրել տեքստի տողը այնպես, որ միայն մասնավոր բանալու սեփականատերը կարողանա այն վերծանել:
Դե, դա տեխնոլոգիայի ամբողջ հիմքն է:

Քայլ #1 - https կայքեր:
Կայք մուտք գործելիս զննարկիչը վեբ սերվերից իմանում է, որ կայքը https է և, հետևաբար, պահանջում է հանրային բանալի:
Վեբ սերվերը տալիս է հանրային բանալին: Բրաուզերն օգտագործում է հանրային բանալին՝ http- հարցումը գաղտնագրելու և այն ուղարկելու համար:
http-հարցման բովանդակությունը կարող են կարդալ միայն նրանք, ովքեր ունեն անձնական բանալին, այսինքն՝ միայն այն սերվերը, որին ուղարկվում է հարցումը։
Http հարցումը պարունակում է առնվազն URI: Հետևաբար, եթե երկիրը փորձում է սահմանափակել մուտքը ոչ թե ամբողջ կայքի, այլ կոնկրետ էջի, ապա դա անհնար է անել https կայքերի համար։

Քայլ # 2 - կոդավորված պատասխան:
Վեբ սերվերը տալիս է պատասխան, որը կարելի է հեշտությամբ կարդալ ճանապարհին:
Լուծումը չափազանց պարզ է. զննարկիչը լոկալ կերպով ստեղծում է նույն մասնավոր-հանրային բանալիների զույգ յուրաքանչյուր https կայքի համար:
Եվ կայքի հանրային բանալու հարցմանը զուգահեռ, այն ուղարկում է իր տեղական հանրային բանալին:
Վեբ սերվերը հիշում է այն և http-պատասխանն ուղարկելիս այն գաղտնագրում է կոնկրետ հաճախորդի հանրային բանալիով։
Այժմ http-response-ը կարող է վերծանել միայն հաճախորդի բրաուզերի մասնավոր բանալու սեփականատերը (այսինքն՝ ինքը՝ հաճախորդը):

Քայլ թիվ 3 - անվտանգ կապի հաստատում հանրային ալիքի միջոցով:
Թիվ 2 օրինակում կա խոցելիություն. ոչինչ չի խանգարում բարի ցանկացողներին գաղտնալսել http- հարցումը և խմբագրել հանրային բանալու մասին տեղեկատվությունը:
Այսպիսով, միջնորդը հստակ կտեսնի ուղարկված և ստացված հաղորդագրությունների ողջ բովանդակությունը, մինչև կապի ալիքը փոխվի:
Դրանով զբաղվելը չափազանց պարզ է. պարզապես ուղարկեք զննարկչի հանրային բանալին որպես հաղորդագրություն՝ գաղտնագրված վեբ սերվերի հանրային բանալիով:
Այնուհետև վեբ սերվերը նախ պատասխան է ուղարկում, ինչպիսին է «ձեր հանրային բանալին այսպիսին է» և գաղտնագրում է այս հաղորդագրությունը նույն հանրային բանալիով:
Բրաուզերը նայում է պատասխանին. եթե ստացվել է «ձեր հանրային բանալին այսպիսին է» հաղորդագրությունը, ապա սա 100% երաշխիք է, որ այս հաղորդակցման ալիքն ապահով է:
Որքանո՞վ է դա անվտանգ:
Նման անվտանգ հաղորդակցման ալիքի ստեղծումը տեղի է ունենում ping*2 արագությամբ: Օրինակ 20 մս.
Հարձակվողը պետք է նախապես ունենա կողմերից մեկի անձնական բանալին: Կամ մի քանի միլիվայրկյանում գտնեք անձնական բանալի:
Մեկ ժամանակակից մասնավոր բանալի կոտրելը սուպերհամակարգչի վրա տասնամյակներ կպահանջի:

Քայլ #4 - հանրային բանալիների հանրային տվյալների բազա:
Ակնհայտ է, որ այս ամբողջ պատմության մեջ հարձակվողի համար հնարավորություն կա նստել հաճախորդի և սերվերի միջև կապի ալիքի վրա:
Հաճախորդը կարող է ձևանալ որպես սերվեր, իսկ սերվերը կարող է ձևանալ որպես հաճախորդ: Եվ ընդօրինակեք զույգ բանալիներ երկու ուղղություններով:
Այնուհետև հարձակվողը կտեսնի ամբողջ տրաֆիկը և կկարողանա «խմբագրել» երթևեկությունը:
Օրինակ՝ փոխեք հասցեն, որտեղ գումար ուղարկելու համար, կամ պատճենեք գաղտնաբառը առցանց բանկինգից կամ արգելափակեք «առարկելի» բովանդակությունը:
Նման հարձակվողների դեմ պայքարելու համար նրանք ստեղծեցին հանրային տվյալների բազա՝ յուրաքանչյուր https կայքի համար հանրային բանալիներով:
Յուրաքանչյուր բրաուզեր «գիտի» մոտ 200 նման տվյալների բազաների գոյության մասին։ Սա նախապես տեղադրված է յուրաքանչյուր բրաուզերում:
«Գիտելիքը» ապահովված է յուրաքանչյուր վկայագրի հրապարակային բանալիով: Այսինքն՝ կապը հավաստագրման յուրաքանչյուր կոնկրետ մարմնի հետ չի կարող կեղծվել:

Այժմ պարզ հասկացողություն կա, թե ինչպես օգտագործել SSL-ը https-ի համար:
Եթե ​​օգտագործեք ձեր ուղեղը, պարզ կդառնա, թե ինչպես կարող են հատուկ ծառայությունները կոտրել ինչ-որ բան այս կառույցում։ Բայց դա կարժենա նրանց հրեշավոր ջանքեր:
Իսկ NSA-ից կամ ԿՀՎ-ից ավելի փոքր կազմակերպություններ՝ գրեթե անհնար է կոտրել պաշտպանության առկա մակարդակը, նույնիսկ VIP-ների համար:

Ես նաև կավելացնեմ ssh կապերի մասին. Այնտեղ հանրային բանալիներ չկան, ուստի ի՞նչ կարող եք անել: Հարցը լուծվում է երկու ճանապարհով.
Տարբերակ ssh-by-password.
Առաջին կապի ժամանակ ssh հաճախորդը պետք է զգուշացնի, որ մենք ունենք նոր հանրային բանալի ssh սերվերից։
Իսկ հետագա միացումների ժամանակ, եթե հայտնվի «նոր հանրային բանալին ssh սերվերից» նախազգուշացումը, դա կնշանակի, որ նրանք փորձում են գաղտնալսել ձեզ։
Կամ քեզ գաղտնալսել են քո առաջին կապը, բայց հիմա դու առանց միջնորդների շփվում ես սերվերի հետ։
Իրականում, քանի որ գաղտնալսման փաստը հեշտությամբ, արագ և առանց ջանքերի բացահայտվում է, այս հարձակումը կիրառվում է միայն հատուկ դեպքերում կոնկրետ հաճախորդի համար։

Տարբերակ ssh-by-key:
Մենք ֆլեշ կրիչ ենք վերցնում, դրա վրա գրում ենք ssh սերվերի անձնական բանալին (դրա համար կան տերմիններ և շատ կարևոր նրբերանգներ, բայց ես գրում եմ կրթական ծրագիր, ոչ թե օգտագործման հրահանգներ):
Մենք թողնում ենք հանրային բանալին այն մեքենայի վրա, որտեղ կլինի ssh հաճախորդը, և մենք այն նաև գաղտնի ենք պահում:
Ֆլեշ սկավառակը բերում ենք սերվեր, տեղադրում ենք, պատճենում ենք անձնական բանալին և վառում ենք ֆլեշ կրիչը և մոխիրը ցրում քամուն (կամ գոնե ֆորմատավորում ենք զրոներով):
Այսքանը. նման գործողությունից հետո անհնար կլինի կոտրել նման ssh կապը։ Իհարկե, 10 տարի հետո հնարավոր կլինի դիտել տրաֆիկը սուպերհամակարգչով, բայց դա այլ պատմություն է:

Ներողություն եմ խնդրում օֆֆթոպի համար։

Այսպիսով, այժմ, երբ տեսությունը հայտնի է: Ես ձեզ կասեմ SSL վկայագրի ստեղծման հոսքի մասին:

Օգտվելով «openssl genrsa»-ից՝ մենք ստեղծում ենք անձնական բանալի և «դատարկ»՝ հանրային բանալու համար:
Մենք ուղարկում ենք «դատարկները» երրորդ կողմի ընկերությանը, որին մենք վճարում ենք մոտավորապես 9 դոլար ամենապարզ վկայագրի համար:

Մի քանի ժամ անց մենք ստանում ենք մեր «հանրային» բանալին և մի քանի հանրային բանալիների հավաքածու այս երրորդ կողմի ընկերությունից:

Ինչու պետք է երրորդ կողմ ընկերությունը վճարի իմ հանրային բանալու գրանցման համար, դա առանձին հարց է, մենք դա այստեղ չենք դիտարկի:

Այժմ պարզ է, թե որն է մակագրության իմաստը.

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

«/etc/ssl» թղթապանակը պարունակում է ssl խնդիրների բոլոր ֆայլերը:
domain1.com — տիրույթի անուն։
2018 թվականը բանալիների ստեղծման տարի է։
«բանալին» - նշանակում է, որ ֆայլը մասնավոր բանալի է:

Եվ այս ֆայլի իմաստը.

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domain1.com — տիրույթի անուն։
2018 թվականը բանալիների ստեղծման տարի է։
շղթայված - նշում, որ կա հանրային բանալիների շղթա (առաջինը մեր հանրային բանալին է, իսկ մնացածը այն է, ինչ ստացվել է հանրային բանալին թողարկած ընկերությունից):
crt - նշում, որ կա պատրաստի վկայական (հրապարակային բանալին տեխնիկական բացատրություններով):

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

Այս պարամետրը այս դեպքում չի օգտագործվում, այլ գրված է որպես օրինակ:

Քանի որ այս պարամետրի սխալը կհանգեցնի ձեր սերվերից սպամի ուղարկմանը (առանց ձեր կամքի):

Հետո բոլորին ապացուցիր, որ դու մեղավոր չես։

recipient_delimiter = +

Շատերը կարող են չգիտեն, բայց սա ստանդարտ նիշ է էլ. փոստի դասակարգման համար, և այն աջակցվում է ժամանակակից փոստային սերվերների կողմից:

Օրինակ, եթե դուք ունեք փոստարկղ «[էլեկտրոնային փոստով պաշտպանված]«Փորձեք ուղարկել»[էլեկտրոնային փոստով պաշտպանված]- Տեսեք, թե ինչ է ստացվում դրանից:

inet_protocols = ipv4

Սա կարող է շփոթեցնող լինել:

Բայց դա միայն այդպես չէ: Յուրաքանչյուր նոր տիրույթ լռելյայն միայն IPv4 է, այնուհետև ես IPv6-ը միացնում եմ յուրաքանչյուրի համար առանձին։

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

Այստեղ մենք նշում ենք, որ բոլոր մուտքային նամակները գնում են dovecot:
Իսկ տիրույթի, փոստարկղի, կեղծանունների կանոնները՝ նայեք տվյալների բազայում:

/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

Այժմ postfix-ը գիտի, որ փոստը կարող է ընդունվել հետագա ուղարկման համար միայն dovecot-ով թույլտվությունից հետո:

Ես իսկապես չեմ հասկանում, թե ինչու է սա կրկնօրինակված այստեղ: Մենք արդեն նշել ենք այն ամենը, ինչ անհրաժեշտ է «virtual_transport»-ում:

Բայց հետֆիքսային համակարգը շատ հին է, հավանաբար, դա հետադարձ է հին օրերից:

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Սա կարող է տարբեր կերպ կարգավորվել յուրաքանչյուր փոստի սերվերի համար:

Ես ունեմ 3 փոստի սերվեր իմ տրամադրության տակ, և այս կարգավորումները շատ տարբեր են օգտագործման տարբեր պահանջների պատճառով:

Դուք պետք է զգույշ կազմաձևեք այն, հակառակ դեպքում սպամը կհոսի ձեզ մոտ, կամ ավելի վատ՝ սպամը կհոսի ձեզանից:

# SPF
policyd-spf_time_limit = 3600

Որոշ հավելվածի կարգավորում՝ կապված մուտքային տառերի SPF-ի ստուգման հետ:

# 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

Կարգավորումն այն է, որ մենք պետք է տրամադրենք DKIM ստորագրություն բոլոր ելքային նամակների հետ:

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

Սա PHP սկրիպտներից տառեր ուղարկելիս նամակների երթուղման հիմնական դետալն է:

Ֆայլ «/etc/postfix/sdd_transport.pcre»:

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

Ձախ կողմում կանոնավոր արտահայտություններ են: Աջ կողմում կա պիտակ, որը նշում է տառը:
Postfix պիտակի համաձայն - հաշվի կառնվի ևս մի քանի կոնֆիգուրացիայի տող կոնկրետ տառի համար:

Թե կոնկրետ ինչպես կվերակազմավորվի postfix-ը կոնկրետ տառի համար, կնշվի «master.cf»-ում:

4, 5, 6 տողերը հիմնականն են։ Որ տիրույթի անունից ենք ուղարկում նամակը, դնում ենք այս պիտակը.
Սակայն «from» դաշտը միշտ չէ, որ նշված է հին կոդում PHP սկրիպտներում: Այնուհետև օգնության է գալիս օգտվողի անունը:

Հոդվածն արդեն ընդարձակ է. ես չէի ցանկանա, որ ինձ շեղեն՝ կարգավորելով nginx+fpm:

Մի խոսքով, յուրաքանչյուր կայքի համար մենք սահմանել ենք իր սեփական Linux-user սեփականատերը: Եվ համապատասխանաբար ձեր fpm-pool-ը:

Fpm-pool-ն օգտագործում է php-ի ցանկացած տարբերակ (հիանալի է, երբ նույն սերվերում կարող եք առանց խնդիրների օգտագործել php-ի տարբեր տարբերակներ և նույնիսկ տարբեր php.ini հարևան կայքերի համար):

Այսպիսով, կոնկրետ Linux-օգտագործող «www-domain2» ունի վեբ կայք domain2.com: Այս կայքը ունի կոդ՝ նամակներ ուղարկելու համար՝ առանց «ից» դաշտը նշելու:

Այսպիսով, նույնիսկ այս դեպքում նամակները կուղարկվեն ճիշտ և երբեք չեն հայտնվի սպամում:

Իմ «/etc/postfix/master.cf»-ն այսպիսի տեսք ունի.

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

Ֆայլն ամբողջությամբ ներկայացված չէ. այն արդեն շատ մեծ է:
Ես միայն նշել եմ, թե ինչ է փոխվել։

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}

Սրանք spamassasin-ի հետ կապված կարգավորումներ են, դրա մասին ավելի ուշ:

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

Մենք թույլ ենք տալիս միանալ փոստային սերվերին 587 պորտի միջոցով:
Դա անելու համար դուք պետք է մուտք գործեք:

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

Միացնել SPF ստուգումը:

apt-get install postfix-policyd-spf-python

Եկեք տեղադրենք փաթեթը վերը նշված 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

Եվ սա ամենահետաքրքիրն է։ Սա կոնկրետ IPv4/IPv6 հասցեից որոշակի տիրույթի համար տառեր ուղարկելու հնարավորություն է:

Սա արվում է հանուն rDNS: rDNS-ը IP հասցեով տող ստանալու գործընթաց է:
Իսկ փոստի համար այս հատկությունն օգտագործվում է հաստատելու համար, որ helo-ն ճիշտ համընկնում է այն հասցեի rDNS-ի հետ, որտեղից ուղարկվել է նամակը:

Եթե ​​բարևը չի համընկնում էլփոստի տիրույթի հետ, որի անունից ուղարկվել է նամակը, ապա սպամի միավորներ են շնորհվում:

Helo-ն չի համընկնում rDNS-ի հետ. շատ սպամի միավորներ են շնորհվում:
Համապատասխանաբար, յուրաքանչյուր տիրույթ պետք է ունենա իր IP հասցեն։
OVH-ի համար - վահանակում հնարավոր է նշել rDNS:
Tech.ru-ի համար - հարցը լուծվում է աջակցության միջոցով:
AWS-ի համար խնդիրը լուծվում է աջակցության միջոցով:
«inet_protocols» և «smtp_bind_address6» - մենք միացնում ենք IPv6 աջակցությունը:
IPv6-ի համար անհրաժեշտ է նաև գրանցել rDNS:
«syslog_name» - և սա տեղեկամատյանները հեշտացնելու համար է:

Գնեք վկայագրեր Ես խորհուրդ եմ տալիս այստեղ.

Այստեղ տեղադրվում է postfix+dovecot հղումը.

SPF-ի կարգավորում:

============= Աղավնանոց =============

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

Mysql-ի կարգավորում, փաթեթների տեղադրում իրենք:

Ֆայլ «/etc/dovecot/conf.d/10-auth.conf»

disable_plaintext_auth = yes
auth_mechanisms = plain login

Թույլտվությունը միայն կոդավորված է:

Ֆայլ «/etc/dovecot/conf.d/10-mail.conf»

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

Այստեղ մենք նշում ենք տառերի պահպանման վայրը:

Ես ուզում եմ, որ դրանք պահվեն ֆայլերում և խմբավորվեն ըստ տիրույթի:

Ֆայլ «/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 {
  }
}

Սա dovecot-ի հիմնական կազմաձևման ֆայլն է:
Այստեղ մենք անջատում ենք անապահով կապերը:
Եվ միացրեք անվտանգ կապերը:

Ֆայլ «/etc/dovecot/conf.d/10-ssl.conf»

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

ssl-ի կարգավորում: Մենք նշում ենք, որ ssl-ը պահանջվում է:
Եվ ինքնին վկայականը: Եվ կարևոր դետալ է «տեղական» հրահանգը։ Ցույց է տալիս, թե որ SSL վկայականը պետք է օգտագործել տեղական IPv4-ին միանալու ժամանակ:

Ի դեպ, IPv6-ն այստեղ կազմաձևված չէ, ես ավելի ուշ կուղղեմ այս բացթողումը:
XX.XX.XX.X5 (domain2) - վկայական չկա: Հաճախորդներին միացնելու համար դուք պետք է նշեք domain1.com:
XX.XX.XX.X2 (domain3) - կա վկայագիր, կարող եք նշել domain1.com կամ domain3.com հաճախորդներին միացնելու համար:

Ֆայլ «/etc/dovecot/conf.d/15-lda.conf»

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Սա ապագայում անհրաժեշտ կլինի spamassassin-ին:

Ֆայլ «/etc/dovecot/conf.d/20-imap.conf»

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Սա հակասպամ հավելված է: Անհրաժեշտ է spamassasin-ի վերապատրաստման համար «Սպամ» թղթապանակից/փոխանցման պահին:

Ֆայլ «/etc/dovecot/conf.d/20-pop3.conf»

protocol pop3 {
}

Հենց այդպիսի ֆայլ կա.

Ֆայլ «/etc/dovecot/conf.d/20-lmtp.conf»

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

lmtp-ի կարգավորում:

Ֆայլ «/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-ի ուսուցման կարգավորումները Spam թղթապանակից/փոխանցման պահին:

Ֆայլ «/etc/dovecot/conf.d/90-sieve.conf»

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

Ֆայլ, որը նշում է, թե ինչ անել մուտքային տառերի հետ:

Ֆայլ «/var/lib/dovecot/sieve/default.sieve»

require ["fileinto", "mailbox"];

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

Դուք պետք է կազմեք ֆայլը՝ «sievec default.sieve»:

Ֆայլ «/etc/dovecot/conf.d/auth-sql.conf.ext»

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

Թույլտվության համար sql ֆայլերի նշում:
Եվ ֆայլն ինքնին օգտագործվում է որպես թույլտվության մեթոդ:

Ֆայլ «/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';

Սա համապատասխանում է postfix-ի նմանատիպ կարգավորումներին:

Ֆայլ «/etc/dovecot/dovecot.conf»

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

Հիմնական կազմաձևման ֆայլ:
Կարևորն այն է, որ մենք նշում ենք այստեղ՝ ավելացնել արձանագրություններ:

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

apt-get install spamassassin spamc

Եկեք տեղադրենք փաթեթները:

adduser spamd --disabled-login

Ավելացնենք օգտատեր, ում անունից։

systemctl enable spamassassin.service

Մենք միացնում ենք ավտոմատ բեռնման spamassassin ծառայությունը բեռնումից հետո:

Ֆայլ «/etc/default/spamassassin»:

CRON=1

«Լռելյայն» կանոնների ավտոմատ թարմացումը միացնելով:

Ֆայլ «/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

Դուք պետք է ստեղծեք տվյալների բազա «sa» mysql-ում «sa» օգտագործողի հետ «password» գաղտնաբառով (փոխարինեք համարժեք որևէ բանով):

report_safe - սա նամակի փոխարեն կուղարկի սպամի էլփոստի հաշվետվություն:
use_bayes-ը spamassassin մեքենայական ուսուցման կարգավորումներ են:

Մնացած spamassassin կարգավորումները օգտագործվել են ավելի վաղ հոդվածում:

«Spamassassin» ընդհանուր կարգավորում.
Նոր Սպամ նամակները IMAP «Սպամ» պանակ տեղափոխելու մասին.
Dovecot + SpamAssassin-ի պարզ համադրության մասին.
Ես խորհուրդ եմ տալիս կարդալ spamassasin-ի ուսուցման տեսությունը, երբ տառերը տեղափոխում եք imap թղթապանակներում (և ես խորհուրդ չեմ տալիս օգտագործել այն).

============= Բողոք համայնքին =============

Կցանկանայի նաև գաղափար գցել համայնքի մեջ, թե ինչպես բարձրացնել ուղարկված նամակների անվտանգության մակարդակը: Քանի որ ես այնքան խորն եմ ընկղմված փոստի թեմայի մեջ:

Որպեսզի օգտատերը կարողանա իր հաճախորդի վրա ստեղծել զույգ ստեղներ (outlook, thunderbird, բրաուզեր-պլագին, ...): Հանրային և մասնավոր. Հանրային - ուղարկել DNS: Մասնավոր - խնայել հաճախորդի վրա: Փոստի սերվերները կկարողանան օգտագործել հանրային բանալին՝ կոնկրետ հասցեատիրոջ ուղարկելու համար:

Եվ նման տառերով սպամից պաշտպանվելու համար (այո, փոստի սերվերը չի կարողանա դիտել բովանդակությունը) - ձեզ հարկավոր է ներմուծել 3 կանոն.

  1. Պարտադիր իրական DKIM ստորագրություն, պարտադիր SPF, պարտադիր rDNS:
  2. Նյարդային ցանց հակասպամի ուսուցման թեմայով + դրա համար տվյալների բազա հաճախորդի կողմից:
  3. Գաղտնագրման ալգորիթմը պետք է լինի այնպիսին, որ ուղարկող կողմը պետք է 100 անգամ ավելի շատ պրոցեսորի հզորություն ծախսի գաղտնագրման վրա, քան ընդունող կողմը:

Բացի հրապարակային նամակներից, մշակեք ստանդարտ առաջարկային նամակ «անվտանգ նամակագրություն սկսելու համար»: Օգտատերերից մեկը (փոստարկղը) կից նամակ է ուղարկում մեկ այլ փոստարկղ: Նամակը պարունակում է տեքստային առաջարկ՝ նամակագրության համար անվտանգ կապի ալիք սկսելու և փոստարկղի սեփականատիրոջ հանրային բանալին (հաճախորդի կողմից մասնավոր բանալիով):

Դուք նույնիսկ կարող եք մի քանի բանալի պատրաստել հատուկ յուրաքանչյուր նամակագրության համար: Ստացող օգտատերը կարող է ընդունել այս առաջարկը և ուղարկել իր հանրային բանալին (նաև հատուկ պատրաստված այս նամակագրության համար): Հաջորդը, առաջին օգտվողը ուղարկում է ծառայության կառավարման նամակ (գաղտնագրված երկրորդ օգտագործողի հանրային բանալիով), որը ստանալուց հետո երկրորդ օգտվողը կարող է հուսալի համարել ձևավորված կապի ալիքը: Հաջորդը, երկրորդ օգտվողը ուղարկում է հսկիչ նամակ, և այնուհետև առաջին օգտվողը կարող է նաև ապահով համարել ձևավորված ալիքը:

Ճանապարհին բանալիների խափանումների դեմ պայքարելու համար արձանագրությունը պետք է նախատեսի ֆլեշ կրիչի միջոցով առնվազն մեկ հանրային բանալին փոխանցելու հնարավորություն:

Եվ ամենակարևորն այն է, որ ամեն ինչ աշխատում է (հարցն այն է, թե «ո՞վ է վճարելու դրա համար»).
Մուտքագրեք փոստային վկայականներ՝ սկսած $10-ից 3 տարվա համար: Ինչը թույլ կտա ուղարկողին dns-ում նշել, որ «իմ հանրային բանալիներն այնտեղ են»: Եվ նրանք ձեզ հնարավորություն կտան անվտանգ կապ սկսել։ Միևնույն ժամանակ, նման կապերի ընդունումն անվճար է։
gmail-ը վերջապես դրամայնացնում է իր օգտատերերին: 10 տարվա համար $3-ով` ապահով նամակագրության ալիքներ ստեղծելու իրավունք:

============= Եզրակացություն =============

Ամբողջ հոդվածը փորձարկելու համար ես պատրաստվում էի մեկ ամսով հատուկ սերվեր վարձել և SSL վկայականով տիրույթ գնել։

Բայց կյանքի հանգամանքները զարգացան, այնպես որ այս հարցը ձգձգվեց 2 ամիս։
Եվ այսպես, երբ նորից ազատ ժամանակ ունեցա, որոշեցի հոդվածը տպագրել այնպես, ինչպես կա, այլ ոչ թե ռիսկի դիմել, որ հրատարակությունը կձգձգվի ևս մեկ տարի։

Եթե ​​կան բավականին շատ հարցեր, ինչպիսիք են «բայց սա բավական մանրամասն նկարագրված չէ», ապա, հավանաբար, ուժ կլինի վերցնել հատուկ սերվեր նոր տիրույթով և նոր SSL վկայականով և նկարագրել այն նույնիսկ ավելի մանրամասն և, մեծ մասը: կարևոր է, բացահայտել բոլոր բացակայող կարևոր մանրամասները:

Ես կցանկանայի նաև կարծիքներ ստանալ փոստային վկայականների վերաբերյալ գաղափարների վերաբերյալ: Եթե ​​ձեզ դուր է գալիս գաղափարը, ես կփորձեմ ուժ գտնել rfc-ի համար նախագիծ գրելու համար:

Հոդվածի մեծ մասերը պատճենելիս տրամադրեք այս հոդվածի հղումը:
Ցանկացած այլ լեզվով թարգմանելիս տրամադրեք այս հոդվածի հղումը:
Կփորձեմ ինքս թարգմանել անգլերեն ու խաչհղումներ թողնել։


Source: www.habr.com

Добавить комментарий