Postfix, VPN და smarthost: რიგი firewall არ არის

ფოსტის რიგში შენახვა მანამ, სანამ VPN აიწევს, დაგეგმვის პრობლემაა, და ჩვეულებრივი გადაწყვეტაა Postfix-ის გაჩერება, main.cf-ის შეცვლა და ხელახლა გაშვება. ეს მუშაობს, და ეს არასწორი ფორმაა, რადგან ორ მოთხოვნას ურევს: როდის უნდა ვცადოთ მიწოდება, და რომელი ქსელური გზა შეიძლება ატარებდეს მას. მეორე firewall-ის გადაწყვეტილებაა, და ვერც ერთი Postfix დირექტივა ვერ მიიღებს მას. როცა ორივე გაიყოფა, თითოეულს აქვს პატარა და შემოწმებადი პასუხი.

შეინარჩუნეთ რელეს დანიშნულება სტაბილური, დაბლოკეთ პირდაპირი მიწოდება ქსელის საზღვარზე, და მიეცით რიგს ლოდინის საშუალება.

ორი მოთხოვნა, რომელსაც ხალხი ერთში აერთიანებს

რელე Postfix-ს ეუბნება, სად გადასცეს ფოსტა; relayhost = [smtp.corp.example]:587 ასახელებს ჰოსტს და პორტს, ხოლო ფრჩხილები თრგუნავს MX-ზე დაფუძნებულ არჩევას ამ შემდეგი ნაბიჯისთვის. გზა ეუბნება ბირთვს, სად შეიძლება წავიდეს პაკეტები. სწორი relayhost გზის შეზღუდვის გარეშე მაინც აძლევს Postfix-ს საშუალებას პირდაპირ მიაღწიოს ინტერნეტს, როცა მარშრუტიზაციის ცხრილი ამას უშვებს, და სწორი firewall არასწორი relayhost-ით ფოსტას არასწორ ადგილას აგზავნის. არც ერთი არ გულისხმობს მეორეს.

ტრანსპორტის რუკები, გამგზავნის მიხედვით გადაფარვები და სარეზერვო რელეები თითოეული იმავე წაკითხვას იმსახურებს. სტაბილური relayhost არ არის მტკიცებულება, რომ ყველა კონფიგურირებული მიწოდების გზა იყენებს მას, ხოლო რელეს გვერდის ავლით მიმავალი სარეზერვო გზა იგივე ხარვეზია უკეთეს შენიღბვაში.

რას აკეთებს defer_transports სინამდვილეში

defer_transports იკავებს შეტყობინებებს დასახელებული ტრანსპორტებისთვის, ასე რომ მიწოდების ცდა არ ხდება მანამ, სანამ რიგის ერთი გავლა არ შეეხება მათ. ეს დაგეგმვის კონტროლია, და რიგის გაწმენდა მას სძლევს; ეს კონსტრუქციაა და არა დეფექტი. გამოიყენეთ master.cf-ის ნამდვილი ტრანსპორტის სახელები, რადგან მორგებული ტრანსპორტი ან ცალკე დასახელებული რელე-ტრანსპორტი არ იფარება მხოლოდ იმიტომ, რომ მისი პროგრამაც SMTP-ზე საუბრობს. ჩვეულებრივი ხელახალი ცდა სხვა მექანიზმია: fail-closed გზის შემთხვევაში მიწოდების ცდები უბრალოდ ვარდება და რჩება რიგში, გადავადების დირექტივის გარეშე.

მუდმივი ხარვეზები თავაზიანად არ ელოდება. ცუდი მიმღები ან უარყოფილი სერტიფიკატი უკან ბრუნდება ან მყარ შეცდომად რჩება იმის ნაცვლად, რომ დაჯდეს გვირაბის გამოჩენამდე, ამიტომ გადავადებული ფოსტით სავსე რიგი ავტომატურად უსაფრთხო რიგი არ არის.

აიძულეთ გზა ქსელის დონეზე

შეზღუდვა ეკუთვნის ლოკალური გამოსავლის საზღვარს ან იზოლირებული ქსელური სახელების სივრცის შიგნით. მან უნდა დაფაროს რელეს ნამდვილი მისამართები, ტრანსპორტი და პორტი, მათ შორის IPv6, თუ ჩართულია, რადგან TCP 25-ის დამბლოკავი წესი არაფერს აკეთებს 587 ან 465 პორტზე მდგარი რელესთვის. გამოყავით loopback და ლოკალური გაგზავნის გზები, რათა თავად რიგმა გააგრძელოს მუშაობა. პოლიტიკა დახურული უნდა დარჩეს, როცა გვირაბის გზა ქრება ან სხვა ინტერფეისის სახელით ხელახლა ჩნდება.

ინტერფეისის აწევის მოვლენა არ ამტკიცებს, რომ რელე მისი მეშვეობით ხელმისაწვდომია. ამიტომ ბმულის შემოწმების შემდეგ რიგის გაწმენდის კაუჭი კომფორტია და არა გარანტია: ბმული შეიძლება შეიცვალოს შემოწმებასა და მიწოდების ცდას შორის.

დაამტკიცეთ ერთი უვნებელი შეტყობინებით

გაგზავნეთ ერთი უვნებელი შეტყობინება VPN-ის გამორთული მდგომარეობით, შემდეგ შეამოწმეთ postqueue -p გადავადების მიზეზისა და რიგის ID-ისთვის. აღადგინეთ განზრახული გზა და მოითხოვეთ რიგის კონტროლირებული გავლა, აკვირდებით, გადის თუ არა შეტყობინება რელეს მეშვეობით და არა სხვაგან. შემდეგ ხელახლა გაწყვიტეთ გზა ფრენის შუაში და დაადასტურეთ, რომ შეტყობინება უბრუნდება რიგს. სანამ გადაწყვეტთ, რამდენ ხანს შეიძლება გაგრძელდეს შეფერხება, გადახედეთ maximal_queue_lifetime-ს, რადგან ნულოვანი მნიშვნელობა ერთ ცდას ნიშნავს და არა შეუზღუდავ შენახვას.

აკონტროლეთ რიგის ასაკი და დისკის გამოყენება. VPN-ის მომლოდინე პოლიტიკა ფოსტის შეფერხებად იქცევა, თუ ვერავინ შეამჩნევს, რომ რიგი პარასკევიდან იზრდება.

ერთად ჩაწერეთ რელე, ტრანსპორტი, firewall-ის წესი და სიცოცხლის ხანგრძლივობა. ეს ოთხი აღწერს მოწყობას; რომელიმე მათგანი ცალკე მხოლოდ ვარაუდს აღწერს.