ทำไมรายการ FTP ถึงค้างอยู่หลัง VPN เกตเวย์ที่ทำ NAT
การล็อกอินและ PWD สำเร็จ แต่ LIST และ RETR หยุดเมื่อ NAT เขียนใหม่เฉพาะเฮดเดอร์ ดูว่าตัวช่วย FTP ต้องอยู่ตรงไหนและแก้โหมดพาสซีฟอย่างไร
การล็อกอินทำงาน PWD ทำงาน แล้ว LIST ก็ค้างจนกว่าไคลเอนต์จะยอมแพ้หรือเปลี่ยนไปใช้โหมดข้อมูลอื่น การแยกกันนั้นคือลายเซ็น การเชื่อมต่อควบคุมไปยังพอร์ต 21 ยังดีอยู่ แต่การเชื่อมต่อข้อมูลถูกสร้างจากที่อยู่หรือพอร์ตที่อีกฝั่งไปไม่ถึง หลัง VPN เกตเวย์ที่ทำ NAT ด้วย ต้นเหตุปกติคือคำสั่ง FTP ที่เพย์โหลดระบุที่อยู่ tunnel เช่น 10.8.0.6 การแปลเฮดเดอร์ไม่เคยแตะค่านั้นเลย
สิ่งที่ตามมาคือค่านั้นมาจากไหน และกล่องไหนได้รับอนุญาตให้เปลี่ยน
สิ่งที่พังคือเพย์โหลด ไม่ใช่ tunnel
FTP วางปลายทางของข้อมูลไว้ในสตรีมควบคุม ในโหมดแอกทีฟ ไคลเอนต์ส่ง PORT พร้อมที่อยู่และพอร์ตของตัวเอง แล้วเซิร์ฟเวอร์โทรกลับไปที่คู่นั้น ในโหมดพาสซีฟ เซิร์ฟเวอร์ตอบ 227 พร้อมคู่หนึ่ง แล้วไคลเอนต์โทรไปที่คู่นั้นแทน
ทั้งสองแบบมีข้อความชนิดเดียวกัน คือเชื่อมต่อกับที่อยู่นี้ ที่พอร์ตนี้ อุปกรณ์ที่เขียนใหม่เฉพาะเฮดเดอร์ IP และ TCP จะปล่อยข้อความนั้นไว้ตามเดิม ฝั่งหนึ่งจึงยังพยายามไปให้ถึงที่อยู่ที่มีอยู่เฉพาะอีกด้านของ tunnel การเชื่อมต่อข้อมูลหยุดหลังจากที่การเชื่อมต่อควบคุมถูกประกาศว่าดีแล้ว
สามโหมด สามเพย์โหลด
ตารางด้านล่างแสดงว่าสั่งให้ฝั่งไหนโทร และ 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 |
วางตัวช่วยไว้ตรงที่การแปลเกิดขึ้น
บนลินุกซ์ ตัวช่วย 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 ของ tunnel ลายเซ็นที่สองไม่ใช่ปัญหาเพย์โหลด และการตั้งค่าตัวช่วยไม่แก้มัน
FTP บน TLS ตัดเพย์โหลดที่ตัวช่วยอ่านออก กล่องกลางเขียนค่า PORT หรือ PASV ที่มันถอดรหัสไม่ได้ใหม่ไม่ได้ ตัวเลือกที่เหลือจึงเป็นพร็อกซีที่ปิด TLS เซิร์ฟเวอร์ที่ประกาศที่อยู่ที่เข้าถึงได้ในช่วงจำกัด หรือโปรโตคอลถ่ายโอนอื่น
ลำดับการตรวจสอบแบบสั้น
ทำงานจากอาการออกไปข้างนอก ยืนยันว่า LIST ล้มเหลวขณะ PWD สำเร็จ จับที่อยู่ในเพย์โหลด PORT หรือ 227 และถามว่าอุปกรณ์ไหนแปลที่อยู่นั้น ผูกตัวช่วยไว้ที่นั่น สังเกตรายการความคาดหวังระหว่างการถ่ายโอนหนึ่งครั้ง จากนั้นแก้โหมดพาสซีฟบนเซิร์ฟเวอร์และสะท้อนช่วงนั้นในกฎเกตเวย์
แยกความล้มเหลวของเส้นทางข้อมูลออกจากความล้มเหลวของการถ่ายโอนจำนวนมาก เพราะมันพาไปสู่การตั้งค่าที่ต่างกัน