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

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

ჯერ გამოყავით ორი კავშირი

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

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

წაიკითხეთ მისამართი PASV პასუხში

გაუშვეთ დეტალური კლიენტი და წაიკითხეთ პასუხი, ვიდრე გამოიცნოთ. curl -v ftp://user@host/ ბეჭდავს PASV ხაზს იმ მისამართითა და პორტით, რომელიც სერვერს სურს, და სწორედ ამ მისამართზე უკავშირდება კლიენტი შემდეგ. თუ ეს კერძო მისამართია, რომელიც გვირაბის კლიენტის მხარეს არაფერს ნიშნავს, მონაცემების კავშირი არსან არ მიდის, სანამ მართვის არხი ჯანსაღი რჩება.

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

შეამოწმეთ პორტების დიაპაზონი და გვირაბის პოლიტიკა

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

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

იცოდეთ, როდის ეხმარება EPSV ან სარეზერვო გზა

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

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

დაადასტურეთ სიით და გადაცემით

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

ამ დროს FTP, FTPS და SFTP გონებაში ცალ-ცალკე შეინახეთ. პასიური პორტის ცვლილება SFTP-ის პარამეტრი არ არის, და შესწორება პროტოკოლებს შორის არ გადადის.

დაკავშირებული სტატიები