ფოსტის გაგზავნა ვერ ხერხდება VPN-ის დაკავშირებისას: იპოვეთ ეტაპი

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

ეტაპი 1: დააკლასიფიცირეთ ხარვეზი რწმუნებებზე შეხებამდე

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

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

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

ეტაპი 2: დაადასტურეთ საბოლოო წერტილი და TLS რეჟიმი

შეტყობინებების გაგზავნა დამოუკიდებელი სერვისია, არა იგივე, რაც სერვერიდან სერვერზე გადაცემა. დაადასტურეთ ჰოსტის სახელი, პორტი და TLS რეჟიმი პროვაიდერის გაგზავნის დოკუმენტაციიდან, რადგან სხვა ფოსტის კონფიგურაციიდან ნასესხები ნაცნობი პორტი მტკიცებულება არ არის. პორტი 587 ელოდება ღია ტექსტის მისალმებას და შემდეგ STARTTLS-ს, ხოლო პორტი 465 ელოდება TLS-ს პირველი ბაიტიდან.

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

ორი შემოწმებიდან არასწორის გაშვება ზუსტად ის შეცდომაა, რომელსაც კლიენტი უშვებს, როცა მეორე რეჟიმზეა კონფიგურირებული. თუ იმპლიციტური TLS-ის შემოწმება 587-ზე იჭედება, ან STARTTLS-ის შემოწმება 465-ზე ვერ ხერხდება, პორტი და რეჟიმი არ ემთხვევა. შეასწორეთ რეჟიმი კლიენტში სერთიფიკატის შემოწმების გამორთვის ნაცვლად, რაც კონფიგურაციის შეცდომას გაუმოწმებელ კავშირად აქცევს. ეს გაყოფა საკმარისად ძველია სტანდარტიზაციისთვის: იმპლიციტური TLS 465 პორტზე არის წყობა, რომელიც აღწერილია RFC 8314-ში.

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

ეტაპი 3: შეადარეთ ბილიკები ანგარიშის შეცვლის გარეშე

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

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

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

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

ეტაპი 4: გაგზავნეთ ერთი უვნებელი შეტყობინება და ჩაწერეთ პასუხი

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

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

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