Vì sao danh sách FTP bị treo sau một cổng VPN có làm NAT
Đăng nhập và PWD thành công trong khi LIST và RETR dừng lại khi NAT chỉ viết lại phần đầu. Xem trợ lý FTP phải nằm ở đâu và cách sửa chế độ bị động.
Đăng nhập chạy được, PWD chạy được, rồi LIST treo cho đến khi máy khách bỏ cuộc hoặc chuyển sang chế độ dữ liệu khác. Sự tách biệt đó chính là dấu hiệu: kết nối điều khiển tới cổng 21 vẫn khỏe, trong khi kết nối dữ liệu được dựng từ một địa chỉ hoặc cổng mà phía bên kia không thể chạm tới. Sau một cổng VPN cũng làm NAT, thủ phạm thường gặp là một lệnh FTP mà phần tải của nó nêu một địa chỉ đường hầm như 10.8.0.6. Việc dịch phần đầu không bao giờ chạm tới giá trị đó.
Phần tiếp theo là giá trị đó đến từ đâu, và chiếc hộp nào được phép thay đổi nó.
Thứ bị hỏng là phần tải, không phải đường hầm
FTP đặt điểm cuối dữ liệu vào bên trong luồng điều khiển. Ở chế độ chủ động, máy khách gửi PORT kèm địa chỉ và cổng của chính nó, và máy chủ gọi ngược lại cặp đó. Ở chế độ bị động, máy chủ trả lời 227 kèm một cặp, và máy khách gọi cặp đó thay vào đó.
Cả hai dạng đều mang cùng một kiểu tuyên bố: hãy kết nối tới địa chỉ này, trên cổng này. Một thiết bị chỉ viết lại phần đầu IP và TCP sẽ để nguyên tuyên bố, nên một phía vẫn tiếp tục cố chạm tới một địa chỉ chỉ tồn tại ở phía bên kia của đường hầm. Kết nối dữ liệu dừng lại sau khi kết nối điều khiển đã được tuyên bố là khỏe.
Ba chế độ, ba phần tải
Bảng dưới đây cho thấy phía nào được yêu cầu gọi, và một NAT chỉ viết lại phần đầu có thể làm gì về việc đó.
Hãy đọc cột cuối như thứ hỏng trước tiên. Ở chế độ chủ động, máy chủ là bên gọi tới một địa chỉ riêng; ở chế độ bị động là máy khách; với FTPS, phần tải là văn bản đã mã hóa và chiếc hộp trung gian còn ít thứ hơn để làm việc.
| 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 |
Đặt trợ lý ở nơi việc dịch diễn ra
Trên Linux, việc viết lại phần tải do trợ lý nf_conntrack_ftp thực hiện. Nó theo dõi kết nối điều khiển, học cổng đã thương lượng, tạo một kỳ vọng cho luồng dữ liệu và trên một hộp NAT, nó viết lại địa chỉ và cổng bên trong phần tải. Nó chỉ giúp trên thiết bị dịch địa chỉ của máy khách. Nạp nó trên máy khách, hoặc trên một bộ định tuyến chỉ chuyển tiếp luồng, không thay đổi gì trong phiên.
Ba lệnh này cho biết mô-đun có mặt hay không, đã được gắn hay chưa, và có một kỳ vọng trong khi phiên mở hay không:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpNạp mô-đun không giống như gắn nó. Các nhân từ 4.7 trở đi đi kèm net.netfilter.nf_conntrack_helper=0, nên trợ lý chờ một quy tắc rõ ràng, ví dụ iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Nếu danh sách kỳ vọng vẫn trống trong khi thử một lần truyền, thứ cần kiểm tra là việc gắn, không phải mô-đun.
Chế độ bị động: hãy nói cho máy chủ biết cần quảng bá gì
Chế độ bị động dễ làm cho tất định hơn vì có thể nói cho máy chủ biết cần đặt gì vào câu trả lời 227. Trong vsftpd đó là pasv_address, cùng với pasv_min_port và pasv_max_port; ProFTPD dùng MasqueradeAddress và PassivePorts. Hãy đặt những thứ đó trước, vì một địa chỉ được quảng bá đúng sẽ bỏ đi nhu cầu viết lại bất cứ thứ gì ở phía đó.
Sau đó để đúng dải cổng đó đi qua cổng VPN, ví dụ -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, để quy tắc khớp với điều máy chủ quảng bá.
Hai thiết lập phải khớp nhau. Một máy chủ được yêu cầu quảng bá 30000-30100 trong khi cổng VPN cho phép 40000-40100 sẽ hỏng theo cách ít hữu ích nhất: cuộc trò chuyện điều khiển trông vẫn khỏe và mọi kết nối dữ liệu chết. Hãy so các con số trước khi gỡ lỗi bất cứ thứ gì khác.
Hai dấu hiệu hỏng, và điều FTPS loại bỏ
Treo trên LIST chỉ vào kết nối dữ liệu đầu tiên của phiên, nơi cả việc viết lại địa chỉ lẫn kỳ vọng đều phải hoạt động. Treo trên RETR sau một LIST chạy được chỉ vào chính lần truyền, tức là dải bị động hoặc MTU của đường hầm. Dấu hiệu thứ hai đó không phải vấn đề phần tải, và các thiết lập trợ lý sẽ không sửa nó.
FTP trên TLS loại bỏ phần tải mà trợ lý đọc. Một hộp trung gian không thể viết lại giá trị PORT hay PASV mà nó không thể giải mã, nên các lựa chọn còn lại là một proxy kết thúc TLS, một máy chủ quảng bá địa chỉ chạm tới được trong một dải giới hạn, hoặc một giao thức truyền khác.
Một trình tự kiểm tra ngắn
Hãy làm việc từ triệu chứng ra ngoài. Xác nhận LIST hỏng trong khi PWD thành công, bắt lấy địa chỉ bên trong phần tải PORT hoặc 227, và hỏi thiết bị nào dịch địa chỉ đó. Gắn trợ lý ở đó, theo dõi danh sách kỳ vọng trong một lần truyền, rồi sửa chế độ bị động trên máy chủ và phản chiếu dải vào quy tắc của cổng VPN.
Giữ lỗi trên đường dữ liệu tách khỏi lỗi khi truyền hàng loạt, vì chúng dẫn bạn tới các thiết lập khác nhau.