Postfix, VPN și un smarthost: coada nu este firewall

Ținerea corespondenței în coadă până când urcă VPN-ul este o problemă de planificare, iar soluția obișnuită este oprirea Postfix, schimbarea main.cf și pornirea din nou. Funcționează, și este forma greșită, pentru că amestecă două cerințe: când trebuie încercată livrarea și ce cale de rețea o poate duce. A doua este o decizie a firewall-ului, și nicio directivă Postfix nu o poate lua. Odată separate, fiecare are un răspuns mic și verificabil.

Păstrați stabilă destinația relay-ului, blocați livrarea directă la granița rețelei și lăsați coada să aștepte.

Două cerințe pe care oamenii le contopesc într-una

Relay-ul îi spune lui Postfix unde să predea corespondența; relayhost = [smtp.corp.example]:587 numește un host și un port, iar parantezele suprimă selecția bazată pe MX pentru următorul salt. Calea îi spune nucleului unde au voie să meargă pachetele. Un relayhost corect fără restricție de cale tot lasă Postfix să ajungă direct la internet când tabelul de rutare permite, iar un firewall corect cu un relayhost greșit trimite corespondența în locul greșit. Niciunul nu o implică pe cealaltă.

Hărțile de transport, suprascrierile pe expeditor și relay-urile de rezervă merită fiecare aceeași lectură. Un relayhost stabil nu este dovada că fiecare rută de livrare configurată îl folosește, iar o rută de rezervă care ocolește relay-ul este aceeași defecțiune într-un camuflaj mai bun.

Ce face de fapt defer_transports

defer_transports reține mesajele pentru transporturile numite, astfel încât nicio încercare de livrare nu se face până când o trecere a cozii nu le atinge. Este un control de planificare, iar o golire a cozii îl anulează; aceasta este concepția, nu un defect. Folosiți numele reale ale transporturilor din master.cf, pentru că un transport personalizat sau un transport relay numit separat nu este acoperit doar pentru că programul său vorbește și SMTP. Reîncercarea obișnuită este alt mecanism: cu o cale fail-closed, încercările de livrare pur și simplu eșuează și rămân în coadă, fără nicio directivă de amânare.

Defecțiunile permanente nu așteaptă politicos. Un destinatar prost sau o acreditare respinsă ricoșează sau rămâne ca eroare dură în loc să aștepte până apare tunelul, așa că o coadă plină de corespondență amânată nu este automat o coadă sigură.

Impuneți calea la nivelul rețelei

Restricția aparține graniței ieșirii locale sau interiorului unui spațiu de nume de rețea izolat. Trebuie să acopere adresele reale ale relay-ului, transportul și portul, inclusiv IPv6 dacă este activat, pentru că o regulă care blochează TCP 25 nu face nimic pentru un relay pe 587 sau 465. Țineți loopback-ul și căile de trimitere locală separate, ca să funcționeze în continuare coada însăși. Politica ar trebui să rămână închisă când ruta tunelului dispare sau reapare sub alt nume de interfață.

Un eveniment de ridicare a interfeței nu dovedește că relay-ul este accesibil prin ea. De aceea un cârlig care verifică legătura și apoi golește coada este o comoditate, nu o garanție: legătura se poate schimba între verificare și încercarea de livrare.

Dovediți-o cu un singur mesaj inofensiv

Trimiteți un mesaj inofensiv cu VPN-ul oprit, apoi inspectați postqueue -p pentru motivul amânării și ID-ul cozii. Restabiliți calea dorită și cereți o trecere controlată a cozii, urmărind dacă mesajul iese prin relay și nu în altă parte. Apoi întrerupeți din nou calea în mijlocul zborului și confirmați că mesajul se întoarce în coadă. Revedeți maximal_queue_lifetime înainte de a decide cât poate dura o întrerupere, pentru că o valoare zero înseamnă o încercare, nu o păstrare nelimitată.

Monitorizați vârsta cozii și utilizarea discului. O politică ce așteaptă VPN-ul devine o întrerupere de corespondență dacă nimeni nu observă că coada crește de vineri.

Înregistrați împreună relay-ul, transportul, regula de firewall și durata de viață. Acele patru descriu aranjamentul; oricare dintre ele singur descrie o presupunere.