ตรวจสอบการตอบกลับ FTP ขั้นสุดท้ายก่อนเชื่อถือการอัปโหลด

ไคลเอนต์ FTP อาจยอมรับคำสั่ง put นานก่อนที่เซิร์ฟเวอร์จะได้รับไฟล์ และช่องว่างระหว่างสองเหตุการณ์นี้คือที่อยู่ของความลึกลับของการอัปโหลดส่วนใหญ่ ต้องมีสี่ขั้นตอนที่เสร็จสมบูรณ์: ไฟล์ในเครื่องถูกอ่าน เซิร์ฟเวอร์ยอมรับคำขอจัดเก็บ การเชื่อมต่อข้อมูลขนส่งไบต์ และการถ่ายโอนไปถึงการตอบกลับเชิงบวกขั้นสุดท้าย การเปรียบเทียบขั้นตอนมีประโยชน์กว่าการเปรียบเทียบไคลเอนต์ เพราะการเข้าสู่ระบบที่ได้ผลและชื่อไฟล์ที่ปรากฏต่างหยุดก่อนถึงเส้นชัย

การตอบกลับเบื้องต้นกับการตอบกลับขั้นสุดท้าย

สำหรับ STOR การตอบกลับ 125 หรือ 150 เป็นเพียงเบื้องต้น มันบอกว่าเซิร์ฟเวอร์ยินดีลองและกำลังเปิดการเชื่อมต่อข้อมูล ไม่ได้บอกว่าวัตถุมีอยู่ในรูปแบบสุดท้าย การดำเนินการจะสมบูรณ์ก็ต่อเมื่อการถ่ายโอนไปถึงการตอบกลับเชิงบวกของการทำให้สมบูรณ์ โดยทั่วไปคือ 226 หรือ 250 ในบริบทของการดำเนินการนั้น

426 หมายถึงการถ่ายโอนถูกยกเลิก และตัวเลขที่คำสั่งอื่นพิมพ์ออกมาไม่ใช่ผลลัพธ์ของการอัปโหลดนี้ อ่านการตอบกลับที่เป็นของ STOR นั้น ไม่ใช่ตัวเลขสุดท้ายบนหน้าจอ หากไคลเอนต์ออกก่อนที่การตอบกลับนั้นจะมาถึง คุณไม่มีหลักฐานการทำให้สมบูรณ์เลย

การเชื่อมต่อควบคุมกับการเชื่อมต่อข้อมูล

การพิสูจน์ตัวตนและการแสดงรายการไดเรกทอรีใช้การเชื่อมต่อควบคุม ไบต์ใช้การเชื่อมต่อข้อมูลแยกต่างหาก และปลายทางของการเชื่อมต่อนั้นถูกเจรจาต่อการถ่ายโอนแต่ละครั้ง การเข้าสู่ระบบที่สำเร็จพิสูจน์เส้นทางการควบคุม และไม่ได้บอกอะไรว่าที่อยู่ข้อมูลเข้าถึงได้จากไคลเอนต์หรือไม่

เมื่อเซิร์ฟเวอร์ไม่สามารถเปิดการเชื่อมต่อข้อมูลได้ ให้ตรวจสอบ ปลายทางที่เจรจาไว้และเส้นทางที่ได้รับอนุญาต โหมดพาสซีฟยังต้องมีที่อยู่ข้อมูลและพอร์ตที่ใช้งานได้ และไฟร์วอลล์หรืออุปกรณ์ NAT ระหว่างไคลเอนต์กับเซิร์ฟเวอร์อาจอนุญาตเซสชันควบคุมแต่ปิดกั้นช่วงข้อมูล เมื่อเซิร์ฟเวอร์ปฏิเสธคำขอจัดเก็บแทน ให้ดูชื่อเส้นทางระยะไกล สิทธิ์ หรือขีดจำกัดการจัดเก็บ ไม่มีสาขาใดได้รับการอธิบายด้วยการเชื่อมต่อควบคุมที่พิสูจน์ตัวตนแล้ว

FTP บน TLS กับ SFTP

FTP บน TLS ยังคงเป็น FTP: สองการเชื่อมต่อ การตอบกลับ FTP และการอัปเกรด TLS บนแต่ละการเชื่อมต่อ SFTP เป็นระบบย่อยของ SSH ที่มีการเชื่อมต่อเดียวและชุดคำสั่งที่แตกต่างอย่างสิ้นเชิง ทั้งสองใช้จุดประสงค์ร่วมกันและแทบไม่มีอย่างอื่นร่วมกัน การวินิจฉัยที่ข้ามระหว่างทั้งสองจึงมักเริ่มด้วยการเปรียบเทียบบันทึกที่ผิด

อย่าปิด TLS เพื่อให้ตัวช่วยตรงกลางตรวจสอบเซสชัน และอย่าถือว่าความล้มเหลวของ SFTP เป็นปัญหาการตอบกลับ FTP หากต้องการทดสอบด้วยสคริปต์ คู่มือ curl อธิบาย TLS แบบชัดเจน โหมดพาสซีฟ และตัวเลือกการอัปโหลด และเป็นแหล่งอ้างอิงว่าธงแต่ละตัวเปลี่ยนอะไรจริง

เลือกโปรโตคอลที่บริการเสนอจริงก่อนดีบัก เซิร์ฟเวอร์ที่พูดได้แค่ SFTP จะไม่สร้างการตอบกลับ 226 เลย ไม่ว่าไคลเอนต์จะถูกกำหนดค่าอย่างไร

ชื่อไฟล์ที่มองเห็นกับวัตถุที่จัดเก็บไว้

ชื่อไฟล์ที่มองเห็นอาจแทนวัตถุที่ไม่สมบูรณ์ โดยเฉพาะหลังการถ่ายโอนที่ถูกยกเลิกหรือไคลเอนต์ที่ออกไปตั้งแต่เนิ่นๆ ขอให้เจ้าของบริการเปรียบเทียบขนาดของไฟล์ทดสอบที่ตั้งใจและแฮชเนื้อหาที่เชื่อถือได้กับวัตถุที่จัดเก็บไว้เมื่อคาดว่าจะรักษาไบต์

โหมดไบนารีและ ASCII เป็นการเปรียบเทียบอีกอย่างที่เปลี่ยนผลลัพธ์ โหมด ASCII อาจแปลงการสิ้นสุดบรรทัด ไบต์ที่จัดเก็บจึงต่างจากไฟล์ในเครื่องแม้การถ่ายโอนจะสำเร็จ ใช้โหมดไบนารีสำหรับการตรวจสอบทีละไบต์ และอย่าเพิ่มตัวเลือกการแปลงเพื่อทำให้การถ่ายโอนที่ล้มเหลวดูแตกต่าง

STOR ทั่วไปสามารถแทนที่ไฟล์ที่มีอยู่ และสิทธิ์ในการเข้าสู่ระบบหรือแสดงรายการไดเรกทอรีไม่ได้ให้สิทธิ์ในการสร้างหรือแทนที่วัตถุในไดเรกทอรีนั้น ใช้ชื่อระยะไกลที่ไม่เคยใช้มาก่อนสำหรับการทดสอบ

สิ่งที่ต้องเปรียบเทียบก่อนลองใหม่

อย่าต่อท้าย ทำต่อ หรือทำซ้ำการอัปโหลดอย่างมืดบอดบนไฟล์บางส่วนที่ไม่แน่ใจ ตกลงกับเจ้าของว่าควรเริ่มใหม่ภายใต้ชื่อใหม่ ใช้ขั้นตอนการกู้คืนที่บริการรองรับ หรือลบวัตถุทดสอบที่ล้มเหลว

เขียนผลลัพธ์เป็นหนึ่งในสี่ข้อความ: การอ่านในเครื่องล้มเหลว การจัดเก็บถูกปฏิเสธ การถ่ายโอนข้อมูลถูกยกเลิก หรือการถ่ายโอนเสร็จสมบูรณ์และไบต์ที่จัดเก็บตรงกัน บันทึกนั้นเป็นผลลัพธ์ที่แข็งแรงกว่าการเปลี่ยนเชลล์ VPN และการตั้งค่า FTP พร้อมกันจนชื่อไฟล์ปรากฏ และบอกคนถัดไปว่าควรตรวจสอบขั้นตอนใด เก็บข้อความการตอบกลับที่ทำให้ปลอดภัยแล้วไว้กับข้อความนั้น จากนั้นการลองใหม่จึงเป็นการตัดสินใจ ไม่ใช่ปฏิกิริยา