End-to-End ในเครือข่ายหมายความว่าอะไรจริง ๆ

เมื่อผู้คนพูดว่าการเชื่อมต่อเป็น "end to end" พวกเขาหมายความว่าข้อมูลเดินทางจากแอปพลิเคชันต้นทางดั้งเดิมไปยังแอปพลิเคชันปลายทางโดยไม่มี middlebox บางตัวเขียนใหม่หรือยุติมันอย่างเงียบ ๆ ระหว่างทาง ฟังดูง่ายจนกว่าคุณจะเริ่มติดตามเส้นทางของแพ็กเก็ตจริง ผ่าน NAT firewalls load balancers และ proxies

หลักการ end-to-end

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

TCP เป็นตัวอย่างที่ชัดเจนที่สุด Routers ตรงกลางไม่ติดตามหมายเลขลำดับหรือยอมรับ segments นั่นคือหน้าที่ของทั้งสองโฮสต์ที่รัน TCP stacks เลเยอร์เครือข่าย (IP) เพียงแค่ทำการส่งมอบแบบ best-effort และ TCP ที่แต่ละด้านแก้ไขสิ่งที่หายไปหรือเรียงลำดับใหม่

จุดที่ end-to-end ขาดหายไปในปัจจุบัน

เครือข่ายสมัยใหม่ละเมิดหลักการนี้อย่างต่อเนื่อง โดยปกติเป็นเหตุผลการดำเนินการที่สมควร:

• NAT เขียนใหม่ IP ต้นทางและ port ดังนั้นแพ็กเก็ตที่เซิร์ฟเวอร์เห็นจึงไม่ใช่แพ็กเก็ตที่ client ส่ง
• TLS-terminating proxies และ load balancers (เช่น AWS ALB หรือ nginx reverse proxy) สิ้นสุด TCP/TLS session หนึ่งและเริ่มต้นอันใหม่ จุดปลายจริงของ client คือ proxy ไม่ใช่ app server
• Stateful firewalls ติดตามสถานะการเชื่อมต่อและสามารถลดแพ็กเก็ตที่ไม่ตรงกับลำดับที่คาดไว้ เพื่อให้ตัวเองแทรกตัวเข้าไปในการสนทนาอย่างมีประสิทธิ
• CGNAT บนเครือข่าย ISP หมายความว่าลูกค้าหลายรายใช้ IP สาธารณะหนึ่งตัว ทำลายสมมติฐานที่ว่า IP แมปกับโฮสต์ตัวเดียว

เรื่องนี้มีความสำคัญจริง ๆ เมื่อคุณ debug หากผู้ใช้รายงาน "การเชื่อมต่อขาดหายไป" คุณจำเป็นต้องรู้ว่ามันขาดหายไปที่แล็ปท็อปของพวกเขา home router ISP CDN edge node load balancer หรือ origin server หลักการ end-to-end บังคับให้คุณติดตามห่วงโซ่ทั้งหมดแทนที่จะเพียงตรวจสอบบันทึกเซิร์ฟเวอร์ของคุณเอง

การทดสอบการเชื่อมต่อ end-to-end

เครื่องมือบางตัวที่แสดงเส้นทางจริง ไม่ใช่เพียงแค่สำเร็จ/ล้มเหลว:

# ติดตามเส้นทาง hop ต่อ hop
traceroute 8.8.8.8

# บน Linux MTR ให้สถิติต่อเนื่องต่อ hop
mtr google.com

# ตรวจสอบปัญหา MTU ที่แยกส่วนหรือลดแพ็กเก็ตอย่างเงียบ ๆ
ping -M do -s 1472 8.8.8.8

คำสั่งสุดท้ายนั้นควรรู้จักดี Path MTU discovery failures เป็นปัญหาคลาสสิก "ดูเหมือนการเชื่อมต่อ end-to-end แต่จริง ๆ แล้วไม่ใช่" แพ็กเก็ตขนาดเล็กเช่น TCP SYN ผ่านได้ดี แต่เมื่อคุณส่งเพย์โหลดขนาดเต็ม hop บางตัวตรงกลางลดมันอย่างเงียบ ๆ เพราะมันใหญ่เกินไป และ ICMP "fragmentation needed" ถูกบล็อกโดย firewall การเชื่อมต่อค้างไว้และทุกคนโทษแอปพลิเคชัน

สำหรับ TCP โดยเฉพาะ tcpdump หรือ ss -ti ที่ทั้งสองด้านบอกคุณว่าทั้งสองโฮสต์เห็นด้วยว่าพวกเขามีการเชื่อมต่อแบบเปิดหรือไม่:

ss -ti dst 203.0.113.5

หากด้านหนึ่งคิดว่าการเชื่อมต่อเป็น ESTABLISHED และอีกด้านหนึ่งแสดงว่าไม่มี สิ่งใดบางอย่างตรงกลาง (โดยปกติคือ firewall หมดเวลาการเชื่อมต่อไม่ใช้งาน) ได้ฆ่ามันอย่างเงียบ ๆ

เหตุใดเรื่องนี้จึงสำคัญสำหรับความปลอดภัย

การเข้ารหัส end-to-end เป็นเวอร์ชันที่เกี่ยวข้องกับความปลอดภัยของแนวคิดเดียวกันนี้ TLS ระหว่าง browser และ CDN edge ไม่เหมือนกับ TLS ระหว่าง browser และ origin server ของคุณ หาก CDN ยุติ TLS และส่งต่อ plaintext (หรือการเชื่อมต่อ TLS ใหม่) ไปยัง backend ของคุณ คุณมี hops เข้ารหัสแยกสองตัว ไม่ใช่ช่องเข้ารหัสต่อเนื่องตัวเดียว นั่นโอเค สำหรับกรณีการใช้งานส่วนใหญ่ แต่หากคุณจัดการกับบางสิ่งที่ละเอียดอ่อน คุณจำเป็นต้องรู้ว่าการถอดรหัสเกิดขึ้นที่ใด และใครสามารถดู plaintext ได้ที่แต่ละ hop

ตรรมชาติเดียวกันนี้ใช้กับ VPNs "full tunnel" VPN ให้คุณการเข้ารหัส end-to-end จากอุปกรณ์ของคุณไปยังโหนดออกทาง VPN แต่การเชื่อมต่อจากโหนดออกทางไปยังเซิร์ฟเวอร์ปลายทางจริงคือ hop แยกต่างหากพร้อมกับคุณสมบัติความปลอดภัยของตัวเอง

ข้อสรุปทางปฏิบัติ

เมื่อมีคนพูดว่าเส้นทางเครือข่ายเป็น end to end ให้ถาม: end to end ระหว่างจุดสองจุดใด ตรงกัน client และ load balancer load balancer และ app server การตั้งชื่อจุดปลายจริงจะเปลี่ยนข้อเรียกร้องเครือข่ายที่คลุมเครือเป็นสิ่งที่คุณสามารถทดสอบได้ด้วยการจับแพ็กเก็ต

หากคุณต้องการเจาะลึกการติดตามการรับส่งข้อมูลจริงและการอ่านแพ็กเก็ตจับภาพ ให้ดู Wireshark และ TCP/IP fundamentals segments บนแพลตฟอร์ม DEFENSE_GRID ของ Korra Studio