რატომ ჩერდება FTP სიები NAT-ის მქონე VPN კარიბჭის მიღმა
შესვლა და PWD წარმატებით მუშაობს, მაშინ როცა LIST და RETR იჩერება, თუ NAT მხოლოდ თავსართებს გადაწერს. ნახეთ, სად უნდა იყოს FTP დამხმარე და როგორ გამოასწოროთ პასიური რეჟიმი.
შესვლა მუშაობს, PWD მუშაობს, შემდეგ კი LIST იჩერება მანამ, სანამ კლიენტი დანებდება ან სხვა მონაცემთა რეჟიმზე გადავა. ეს გაყოფა სწორედ ნიშანია: 21 პორტთან საკონტროლო კავშირი ჯანმრთელია, ხოლო მონაცემთა კავშირი ისეთი მისამართიდან ან პორტიდან შენდება, რომელსაც მეორე მხარე ვერ აღწევს. NAT-საც აკეთებელი VPN კარიბჭის მიღმა ჩვეულებრივი დამნაშავეა FTP ბრძანება, რომლის დატვირთვაც ასახელებს გვირაბის მისამართს, მაგალითად 10.8.0.6-ს. თავსართების თარგმნა ამ მნიშვნელობას არასოდეს ეხება.
შემდეგ მოდის, საიდან მოდის ეს მნიშვნელობა და რომელ ყუთს აქვს მისი შეცვლის უფლება.
ტყდება დატვირთვა და არა გვირაბი
FTP მონაცემების ბოლო წერტილს საკონტროლო ნაკადის შიგნით ათავსებს. აქტიურ რეჟიმში კლიენტი აგზავნის PORT-ს საკუთარი მისამართითა და პორტით, და სერვერი უკან იძახებს ამ წყვილს. პასიურ რეჟიმში სერვერი პასუხობს 227-ით და წყვილით, ხოლო კლიენტი სამაგიეროდ იმას იძახებს.
ორივე ფორმა ერთი ტიპის განცხადებას ატარებს: დაუკავშირდი ამ მისამართს, ამ პორტზე. მოწყობილობა, რომელიც მხოლოდ IP და TCP თავსართებს გადაწერს, განცხადებას ხელუხლებლად ტოვებს, ამიტომ ერთი მხარე განაგრძობს მცდელობას მიაღწიოს მისამართს, რომელიც მხოლოდ გვირაბის მეორე მხარეს არსებობს. მონაცემთა კავშირი ჩერდება მას შემდეგ, რაც საკონტროლო კავშირი უკვე ჯანმრთელად გამოცხადდა.
სამი რეჟიმი, სამი დატვირთვა
ქვემოთ მოცემული ცხრილი გვიჩვენებს, რომელ მხარეს ეუბნებიან დარეკვას და რა შეუძლია გააკეთოს მხოლოდ თავსართების გადამწერ NAT-ს ამ საკითხში.
წაიკითხეთ ბოლო სვეტი როგორც ის, რაც პირველი ვარდება. აქტიურ რეჟიმში სერვერი რეკავს კერძო მისამართზე, პასიურში კლიენტი, ხოლო FTPS-ში დატვირთვა დაშიფრული ტექსტია და შუამავალ ყუთს კიდევ ნაკლები აქვს სამუშაოდ.
| Mode | Value in the control stream | Who dials whom | Header-only NAT leaves |
|---|---|---|---|
| Active (PORT) | client address and port | server dials the client | a server dialing an unreachable tunnel address |
| Passive (227) | server address and port | client dials the server | a client dialing an address it cannot route to |
| FTPS | the same values, inside TLS | as above | ciphertext, so no rewrite happens at all |
დააყენეთ დამხმარე იქ, სადაც თარგმნა ხდება
Linux-ზე დატვირთვის გადაწერას აკეთებს დამხმარე nf_conntrack_ftp. ის აკვირდება საკონტროლო კავშირს, სწავლობს შეთანხმებულ პორტს, ქმნის მოლოდინს მონაცემთა ნაკადისთვის და NAT ყუთზე გადაწერს დატვირთვის შიგნით არსებულ მისამართსა და პორტს. ის ეხმარება მხოლოდ იმ მოწყობილობაზე, რომელიც კლიენტის მისამართს თარგმნის. მისი კლიენტზე ან მხოლოდ ნაკადის გამტარებელ როუტერზე ჩატვირთვა სესიაში არაფერს ცვლის.
ეს სამი ბრძანება გვიჩვენებს, არის თუ არა მოდული, მიბმულია თუ არა და არსებობს თუ არა მოლოდინი ღია სესიის დროს:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpმოდულის ჩატვირთვა იგივე არ არის, რაც მისი მიბმა. 4.7-დან მოყოლებული ბირთვები მოდის net.netfilter.nf_conntrack_helper=0-ით, ამიტომ დამხმარე ელოდება გამოკვეთილ წესს, მაგალითად iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. თუ მოლოდინების სია ცარიელი რჩება გადაცემის ცდის დროს, შესამოწმებელი მიბმაა და არა მოდული.
პასიური რეჟიმი: უთხარით სერვერს, რა გამოაცხადოს
პასიური რეჟიმის დეტერმინისტულად გაკეთება უფრო ადვილია, რადგან სერვერს შეიძლება ვუთხრათ, რა ჩასვას 227 პასუხში. vsftpd-ში ეს არის pasv_address, pasv_min_port-სა და pasv_max_port-თან ერთად, ხოლო ProFTPD იყენებს MasqueradeAddress-სა და PassivePorts-ს. ჯერ ეს დააყენეთ, რადგან სწორად გამოცხადებული მისამართი აუქმებს იმ მხარეს რაიმეს გადაწერის საჭიროებას.
შემდეგ გაატარეთ ზუსტად ის პორტების დიაპაზონი კარიბჭეში, მაგალითად -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, რომ წესი დაემთხვეს იმას, რასაც სერვერი აცხადებს.
ორი პარამეტრი უნდა შეთანხმდეს. სერვერი, რომელსაც ეუბნებიან გამოაცხადოს 30000-30100, მაშინ როცა კარიბჭე 40000-40100-ს უშვებს, ყველაზე ნაკლებად სასარგებლო გზით ვარდება: საკონტროლო საუბარი ჯანმრთელად გამოიყურება და ყოველი მონაცემთა კავშირი იღუპება. შეადარეთ რიცხვები, სანამ სხვა რამეს გამართავთ.
ორი მარცხის ნიშანი და რას აცილებს FTPS
LIST-ზე ჩერება მიუთითებს სესიის პირველ მონაცემთა კავშირზე, სადაც მისამართის გადაწერაც და მოლოდინიც უნდა იმუშაოს. RETR-ზე ჩერება მომუშავე LIST-ის შემდეგ მიუთითებს თავად გადაცემაზე, ანუ პასიურ დიაპაზონზე ან გვირაბის MTU-ზე. ეს მეორე ნიშანი დატვირთვის პრობლემა არ არის და დამხმარის პარამეტრები მას არ გამოასწორებს.
FTP TLS-ზე აცილებს იმ დატვირთვას, რომელსაც დამხმარე კითხულობს. შუამავალი ყუთი ვერ გადაწერს PORT ან PASV მნიშვნელობას, რომლის გაშიფვრაც არ შეუძლია, ამიტომ რჩება TLS-ის დამამთავრებელი პროქსი, სერვერი, რომელიც აცხადებს მისაწვდომ მისამართს შეზღუდულ დიაპაზონში, ან სხვა გადაცემის პროტოკოლი.
შემოწმებების მოკლე თანმიმდევრობა
იმუშავეთ სიმპტომიდან გარეთ. დაადასტურეთ, რომ LIST ვარდება, მაშინ როცა PWD წარმატებულია, დაიჭირეთ მისამართი PORT-ის ან 227-ის დატვირთვაში და ჰკითხეთ, რომელი მოწყობილობა თარგმნის ამ მისამართს. მიამაგრეთ დამხმარე იქ, დააკვირდით მოლოდინების სიას ერთი გადაცემის განმავლობაში, შემდეგ გაასწორეთ პასიური რეჟიმი სერვერზე და აისახეთ დიაპაზონი კარიბჭის წესში.
მონაცემთა გზის მარცხი ცალკე შეინახეთ მასობრივი გადაცემის მარცხისგან, რადგან ისინი სხვადასხვა პარამეტრებამდე მიგიყვანენთ.