UDP และ QUIC ผ่านพร็อกซี

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

ดูการเลือกโปรโตคอลในภาพรวมที่พร็อกซี SOCKS กับ HTTP บทความนี้อธิบายเส้นทาง UDP ผ่านพร็อกซี สิ่งที่ QUIC ต้องการจากเส้นทาง และวิธีตรวจว่าแอปใช้การขนส่งกับ IP ขาออกที่ตั้งใจ

UDP, QUIC และ HTTP/3 ทำอะไร

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

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

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

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

HTTP/3 ขนส่ง HTTP ผ่าน QUIC ขณะที่ HTTP/1.1 และ HTTP/2 ปกติใช้ TCP ทั้งสามรองรับเว็บไซต์ HTTPS ได้ ดังนั้น https:// ในที่อยู่ไม่ได้ระบุรุ่น HTTP หรือยืนยันว่าใช้ UDP

การเข้ารหัสเป็นอีกคุณสมบัติหนึ่ง UDP ไม่เข้ารหัสข้อมูล QUIC ใช้ TLS 1.3 สร้างการป้องกันทราฟฟิกแอป แอป UDP ทั่วไปอาจใช้กลไกความปลอดภัยอื่นหรือส่งเนื้อหาแบบไม่เข้ารหัส การส่งผ่านพร็อกซีไม่ได้เพิ่มการป้องกันนั้นโดยอัตโนมัติ

SOCKS5 ขนส่ง UDP อย่างไร

SOCKS5 กำหนด UDP relay คือบริการที่รับดาตาแกรมจากไคลเอนต์ ส่งเนื้อหาไปปลายทาง และคืนคำตอบ ไคลเอนต์จัดการส่งต่อนี้ผ่าน TCP ก่อน จากนั้นสายควบคุมกับเส้นทางดาตาแกรมอยู่คู่กัน

1. ไคลเอนต์เชื่อมต่อเซิร์ฟเวอร์ SOCKS5 ผ่าน TCP และทำขั้นตอนตรวจสอบสิทธิ์ที่ตกลง
2. จากนั้นขอ UDP ASSOCIATE หากพร็อกซียอมรับ คำตอบจะให้ที่อยู่และพอร์ต UDP ของ relay
3. ไคลเอนต์ส่งดาตาแกรมไปยัง relay พร้อมส่วนหัว SOCKS ที่ระบุปลายทาง ตัว relay ลบส่วนหัวก่อนส่งเนื้อหาต่อ และเมื่อมีคำตอบจะเพิ่มส่วนหัว SOCKS ก่อนส่งดาตาแกรมคืนไคลเอนต์
4. ไคลเอนต์เปิด TCP ควบคุมค้างขณะใช้ relay การปิดสายนี้ยุติการส่งต่อ UDP ที่จัดไว้ ความสัมพันธ์ระหว่างสายควบคุมกับการส่งต่อ UDP เรียกว่า UDP association

Relay อาจใช้ที่อยู่หรือพอร์ตต่างจาก TCP ที่ป้อนในการตั้งค่าพร็อกซี การส่ง UDP ดิบไปจุดที่คุ้นเคยนั้นไม่ใช่การแลกข้อความ SOCKS5 ไคลเอนต์ที่ทำได้เฉพาะ CONNECT ใช้ SOCKS5 กับ TCP ได้ แต่ไม่มีขั้นตอนที่ต้องใช้ในที่นี้ ส่วน SOCKS4 ไม่ได้กำหนด UDP relay นี้

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

พร็อกซี HTTP ส่งต่อ UDP ได้หรือไม่

คำขอ HTTP CONNECT ปกติขอให้พร็อกซีเปิด TCP ไปปลายทางและส่งสตรีมไบต์ ไม่ได้สร้างการส่งต่อ UDP การใช้ TLS เชื่อมไปพร็อกซี HTTPS ป้องกันการเชื่อมต่อนั้น แต่ไม่ได้เปลี่ยนชนิดทันเนลที่ขอ

HTTP มีกลไกทันเนล UDP เพิ่มที่เรียกทั่วไปว่า CONNECT-UDP ซึ่งพัฒนาเป็นส่วนหนึ่งของ MASQUE เมื่อไคลเอนต์และเซิร์ฟเวอร์เข้ากันได้ ไคลเอนต์ขอทันเนลไปปลายทาง UDP พร็อกซีส่งดาตาแกรมไปปลายทางและนำคำตอบกลับ ทั้งสองฝั่งต้องรองรับโดยชัดเจน

บนการเชื่อมต่อไคลเอนต์ถึงพร็อกซี HTTP Datagrams ขนส่งในเฟรม QUIC DATAGRAM ได้เมื่อรองรับ HTTP/3 และส่วนขยายที่ต้องใช้ หรือขนส่งใน capsules ซึ่งเป็นข้อความแบ่งกรอบในสตรีม HTTP ที่เชื่อถือได้ รวมถึง HTTP/2 บน TCP ในกรณีหลังพร็อกซียังส่ง UDP ไปปลายทาง แม้ช่วงแรกใช้ TCP

ทางเลือกนี้มีผลต่อเวลา หาก TCP ทำข้อมูลหาย ไบต์ภายหลังอาจรอกู้คืน ทำให้ดาตาแกรมที่อยู่ข้างในล่าช้า ทันเนลอาจทำงานได้แต่ไม่เหมาะกับงานเรียลไทม์เฉพาะ การกรอกที่อยู่พร็อกซี http:// ในโปรแกรมเพียงอย่างเดียวไม่เปิดกลไก UDP เพิ่มเหล่านี้

การเชื่อมต่อใดใช้ QUIC

คำว่า “QUIC proxy” ต้องมีบริบท อาจบอกการขนส่งที่ใช้ติดต่อพร็อกซี หรือการเชื่อมต่อของแอปไปปลายทาง ซึ่งเป็นคนละส่วนของการรับส่ง

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

ทำไมการรองรับของแอปจึงสำคัญ

โปรแกรมต้องทำวิธีส่งต่อที่บริการเสนอ ช่อง SOCKS5 ไม่ได้บอกว่ารองรับ UDP ASSOCIATE หรือไม่ เช่นเดียวกับโปรแกรมอาจรองรับ HTTP/3 แบบตรง แต่ให้พร็อกซีได้เฉพาะ TCP

Chrome เป็นตัวอย่างชัดเจน SOCKS5 ในตัวส่งคำขอ URL ที่ใช้ TCP และไม่ส่งต่อ UDP ผ่าน SOCKS5 การโหลดหน้าด้วยการตั้งค่านั้นจึงทดสอบ UDP relay ของบริการไม่ได้ ข้อจำกัดนี้เป็นของโหมดไคลเอนต์เฉพาะ ไคลเอนต์อื่นหรือซอฟต์แวร์กำหนดเส้นทางภายนอกอาจมีความสามารถต่างกัน

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

โปรแกรมที่เปลี่ยนเส้นทางทราฟฟิกของแอปอื่นส่ง UDP ผ่านพร็อกซีได้ หากรองรับ UDP และวิธีส่งต่อของบริการ การเปลี่ยนเส้นทาง TCP อย่างเดียวไม่พอ หากใช้ส่วนต่อประสานเครือข่ายเสมือน กฎเส้นทางกำหนดว่าทราฟฟิกใดเข้าไป ต้องทดสอบทั้งชุด ได้แก่ แอป โปรแกรมกำหนดเส้นทาง และจุดพร็อกซี

การใช้วิธีสำรอง ความล้มเหลว และการเชื่อมต่อโดยตรง

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

การเปลี่ยนไป HTTP ที่ใช้ TCP เรียกว่า fallback ช่วยให้ท่องเว็บปกติได้เมื่อ QUIC ใช้ไม่ได้ ไคลเอนต์เปิดการเชื่อมต่ออีกแบบ ไม่ใช่ QUIC เปลี่ยนเป็น TCP เอง การปิด QUIC จึงอาจช่วยให้เว็บแอปใช้ TCP ที่พร้อมได้ แต่ไม่เพิ่ม UDP ให้คุณสมบัติที่จำเป็นต้องใช้

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

ทำไม UDP หยุดทำงานหลังตั้งค่าสำเร็จได้

กฎพอร์ตและเส้นทางกลับ

พอร์ต TCP 443 กับ UDP 443 เป็นคนละการขนส่ง การอนุญาตแบบหนึ่งไม่เปิดอีกแบบ สำหรับ SOCKS5 ไคลเอนต์ต้องติดต่อจุด UDP relay ที่ได้รับ และ relay ต้องติดต่อพอร์ต UDP ปลายทางได้ HTTP/3 ใช้พอร์ตอื่นนอกจาก 443 ได้ จึงต้องตรวจจุดที่แอปใช้จริง

คำตอบต้องกลับผ่าน relay ไฟร์วอลล์ และ NAT ที่แปลงที่อยู่และมักแปลงพอร์ตระหว่างเครือข่ายด้วย การส่งดาตาแกรมออกอย่างเดียวไม่พิสูจน์ว่าเส้นทางกลับทำงาน การเปลี่ยนเครือข่ายอาจเปลี่ยน IP สาธารณะหรือการจับคู่พอร์ตของไคลเอนต์ SOCKS5 relay ต้องปฏิเสธดาตาแกรมจาก IP ต้นทางอื่นที่ไม่ตรงบันทึก UDP association ดังนั้นที่อยู่เปลี่ยนอาจต้องสร้างการผูกใหม่

ช่วงหยุดและสถานะหมดอายุ

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

ขนาดดาตาแกรมและ MTU

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

เส้นทาง QUIC ต้องส่งเนื้อหา UDP อย่างน้อย 1,200 ไบต์ โดยไม่รวมส่วนหัว IP และ UDP ไคลเอนต์เติมดาตาแกรมที่มีแพ็กเก็ต QUIC Initial ให้เนื้อหาไม่น้อยกว่าขนาดนี้ ส่วนหัวพร็อกซีในช่วงไคลเอนต์ถึงพร็อกซีต้องใช้พื้นที่เพิ่ม นี่ไม่ใช่คำแนะนำให้ตั้ง MTU อินเทอร์เฟซเป็น 1,200 แต่เป็นเหตุผลที่ DNS สั้น ๆ ไปกลับได้ ขณะที่การเริ่มเชื่อมต่อ QUIC ที่ใหญ่กว่าผ่านไม่ได้

ความล่าช้า การสูญหาย และภาระ

สำหรับเสียงหรือเกม เวลาไปถึงอาจสำคัญเท่ากับการถึง ความล่าช้าที่แปรผัน แพ็กเก็ตหาย และขีดจำกัดอัตราแพ็กเก็ตทำให้ UDP relay ที่ยังทำงานมีปัญหาได้ แบนด์วิดท์อย่างเดียวอธิบายเงื่อนไขเหล่านี้ไม่ครบ พร็อกซีเพิ่มอีกส่วนในเส้นทาง และอาจทำให้เร็วขึ้นหรือช้าลงตามเครือข่ายกับภาระงาน

ตรวจสอบ UDP และ HTTP/3 ผ่านพร็อกซีอย่างไร

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

1. เลือกปลายทางที่ตอบทราฟฟิกที่ต้องการ ใช้เซิร์ฟเวอร์แอปจริงหรือตัวตอบ UDP ที่ควบคุมได้ สำหรับ HTTP/3 เลือกปลายทางที่ทราบว่ารองรับ การเงียบจากพอร์ต UDP ใดก็ได้ไม่บอกว่าพังตรงไหน
2. ยืนยันว่า relay หรือทันเนลได้รับการยอมรับ สำหรับ SOCKS5 ดูผล UDP ASSOCIATE กับที่อยู่และพอร์ต relay ที่คืน สำหรับทันเนล HTTP UDP ให้ยืนยันว่ารับทันเนลแล้ว การตรวจสอบสิทธิ์อย่างเดียวไม่ครอบคลุมขั้นนี้
3. ทำคำขอและรับคำตอบให้ครบ ตัวตอบที่ควบคุมได้อาจคืนตัวระบุคำขอและบันทึก IP ต้นทางที่เห็น เพื่อทดสอบขาออกของ UDP ครั้งนั้น การตรวจ IP ผ่านเว็บแยกครอบคลุมเฉพาะคำขอของตัวเอง
4. สำหรับ HTTP/3 ยืนยันโปรโตคอลที่การรับส่งกับปลายทาง ดู HTTP/3 หรือ h3 ในบันทึกการเชื่อมต่อของไคลเอนต์หรือเซิร์ฟเวอร์พร้อมหลักฐานเส้นทางพร็อกซี หากไคลเอนต์ทดสอบมีโหมด HTTP/3 เท่านั้น จะเปิดเผยความล้มเหลวที่ fallback อัตโนมัติอาจซ่อนไว้
5. ทดสอบซ้ำในเงื่อนไขเกี่ยวข้อง ทั้งขนาดดาตาแกรมจริง ทราฟฟิกต่อเนื่อง และช่วงพักแล้วเริ่มใหม่ หากห้ามส่งตรง ให้ทดสอบเมื่อพร็อกซีใช้ไม่ได้ด้วย เก็บรุ่นไคลเอนต์และการตั้งค่าคู่กับผล

การจับแพ็กเก็ตช่วยระบุเส้นทางได้ SOCKS5 UDP มาตรฐานส่งดาตาแกรมไป relay ที่ตกลง ส่วนทันเนล HTTP UDP อาจใช้ TCP ชั้นนอก ดังนั้นการไม่เห็น UDP ในช่วงแรกอย่างเดียวไม่พอจะบอกว่าล้มเหลว

DNS ระยะไกลกับ ping ทดสอบคนละอย่าง พร็อกซีอาจค้นชื่อสำหรับ TCP โดยไม่ได้ส่ง UDP ของแอป ส่วน ping ปกติใช้ ICMP ทั้งคู่ไม่แทนคำขอและคำตอบ UDP ที่สังเกตบนเส้นทางพร็อกซีที่ต้องการ

เมื่อใดควรเลือกรองรับ UDP

เริ่มจากทราฟฟิกที่งานต้องใช้ งานเว็บและ API บน HTTP/1.1 หรือ HTTP/2 อาจใช้พร็อกซี TCP อย่างเดียวได้ครบ แต่การทดสอบ HTTP/3 สื่อ UDP และคุณสมบัติอื่นที่ต้องใช้ UDP จำเป็นต้องมี relay หรือทันเนลที่เหมาะและไคลเอนต์ที่ใช้งานได้

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