พร็อกซี SOCKS5 และ SOCKS4

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

สำหรับการตั้งค่าใหม่ SOCKS5 มักให้ตัวเลือกที่มีประโยชน์กว่า ทั้งรูปแบบที่อยู่ วิธีตรวจสอบสิทธิ์ และการรองรับ UDP ส่วน SOCKS4 ยังมีประโยชน์กับซอฟต์แวร์ที่ต้องใช้รุ่นเก่า การเลือกระหว่างโปรโตคอลเหล่านี้กับ HTTP อธิบายในพร็อกซี SOCKS กับ HTTP

แอปเชื่อมต่อผ่าน SOCKS อย่างไร

สมมติแอปเปิด https://example.com/ ผ่านพร็อกซี SOCKS5 แอปจะติดต่อพร็อกซีก่อน ขอให้เปิดการเชื่อมต่อเว็บไซต์ แล้วจึงรับส่งข้อมูลเว็บ มีสี่ขั้นตอนดังนี้

1. แอปเชื่อมต่อชื่อโฮสต์หรือ IP และพอร์ตที่พร็อกซีรอรับผ่าน TCP
2. แอปกับพร็อกซีเลือกวิธีเข้าถึง หากวิธีนั้นต้องใช้ข้อมูลรับรอง แอปจะส่งให้พร็อกซีตรวจ
3. แอปส่งคำขอ SOCKS CONNECT พร้อมที่อยู่และพอร์ตปลายทาง พร็อกซีตรวจเงื่อนไขสิทธิ์ พยายามเชื่อมต่อไปข้างหน้า แล้วรายงานผล
4. เมื่อได้รับคำตอบสำเร็จ แอปจึงสื่อสารกับปลายทางผ่านพร็อกซี สำหรับเว็บไซต์ HTTPS แอปสร้าง TLS กับเว็บไซต์และตรวจใบรับรองก่อนส่งคำขอเว็บ

พอร์ตสองหมายเลขเป็นของคนละเซิร์ฟเวอร์ พร็อกซีตัวอย่างอาจรอรับที่ proxy.example:1080 ขณะที่เว็บไซต์อยู่ที่ example.com:443 พอร์ต 1080 เป็นค่าที่นิยมสำหรับ SOCKS แต่บริการใช้พอร์ตอื่นได้ ให้ใช้พอร์ตที่กำหนดให้พร็อกซีของคุณ ไม่ใช่นำไปแทนพอร์ตปลายทาง

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

CONNECT เป็นคำสั่งภายใน SOCKS ที่มีรูปแบบข้อความของตัวเอง ต่างจากเมธอด HTTP CONNECT นอกจากนี้ SOCKS กำหนด BIND สำหรับแอปที่ต้องให้เซิร์ฟเวอร์เชื่อมกลับผ่านพร็อกซี เช่น active FTP โดย BIND ต้องรองรับแยกและไม่ใช้กับคำขอเว็บไซต์หรือ API ปกติ

SOCKS4, SOCKS4a และ SOCKS5 ต่างกันอย่างไร

SOCKS4 เปิด TCP ไปที่อยู่ IPv4 ส่วน SOCKS4a เพิ่มการส่งชื่อโฮสต์ให้พร็อกซีค้น IP ผ่าน DNS และ SOCKS5 เพิ่มทางเลือกตรวจสอบสิทธิ์ รับ IPv4, IPv6 และชื่อโฮสต์ รวมทั้งกำหนดวิธีส่งต่อ UDP

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

SOCKS5 ระบุปลายทาง IPv6 ในคำขอได้ แต่พร็อกซีต้องเข้าถึงเซิร์ฟเวอร์ IPv6 นั้นได้ด้วย การเชื่อมต่อสองฝั่งอาจใช้ IP คนละรุ่น แอปติดต่อพร็อกซีผ่าน IPv4 ขณะที่พร็อกซีติดต่อปลายทางผ่าน IPv6 ได้

SOCKS4a เป็นส่วนขยายของ SOCKS4 ไม่ใช่ชื่ออื่นของทุกการเชื่อมต่อ SOCKS4 หากไคลเอนต์เก่าส่งได้เฉพาะ IPv4 การเลือก SOCKS4 ไม่ได้เพิ่ม DNS ระยะไกลให้ SOCKS4a ต้องรองรับทั้งสองฝั่ง โดยปกติ SOCKS5 เป็นตัวเลือกง่ายกว่าเมื่อทั้งคู่รองรับ การเลือก SOCKS4 ไม่ได้ทำให้ชื่อเสียงหรือความเร็ว IP ขาออกดีขึ้นด้วยตัวเอง

ใครแปลงชื่อปลายทาง

ก่อนเชื่อมต่อเซิร์ฟเวอร์ด้วยชื่อ ต้องแปลงชื่อเป็น IP SOCKS5 รับได้ทั้งผลค้นหรือชื่อโดยตรง การตั้งค่า DNS ของไคลเอนต์กำหนดว่าจะส่งแบบใด

หากใช้ DNS ในเครื่อง แอปถามตัวแก้ชื่อที่ตั้งไว้หา reports.example สมมติได้คำตอบ 203.0.113.27 แอปจึงขอเชื่อมต่อ SOCKS ไป 203.0.113.27:443 การค้นเกิดที่ฝั่งไคลเอนต์แล้ว แม้การเชื่อมต่อเว็บถัดไปผ่านพร็อกซี

หากใช้ DNS ฝั่งพร็อกซี แอปส่ง reports.example:443 โดยไม่ค้นปลายทางในเครื่องก่อน พร็อกซีค้น IP ผ่าน DNS แล้วเปิดการเชื่อมต่อ ชื่อโฮสต์ไปถึงพร็อกซีเป็นส่วนหนึ่งของคำขอ SOCKS

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

ใน curl คำสั่งสองรายการต่อไปนี้เลือก DNS สองโหมด

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

socks5:// ให้ curl แปลงชื่อเว็บไซต์ในเครื่อง ส่วน socks5h:// ส่งชื่อให้พร็อกซี ทั้งคู่ใช้ SOCKS5 ตัว h หมายถึงให้พร็อกซีแปลงชื่อโฮสต์ตามไวยากรณ์ URL ของไคลเอนต์นี้ ไม่ได้เปลี่ยน SOCKS5 เป็น HTTPS หรือเพิ่มการเข้ารหัส แอปอื่นอาจใช้ช่องเลือกหรือเลือก DNS ระยะไกลอัตโนมัติ แทนชื่อโฮสต์และพอร์ตตัวอย่างด้วยข้อมูลบริการของคุณ พร้อมข้อมูลตรวจสอบสิทธิ์ที่ต้องใช้

การส่งชื่อโดเมนในคำขอ SOCKS5 TCP ไม่ต้องรองรับ UDP relay พร็อกซีค้นชื่อด้วยการตั้งค่า DNS ของตัวเอง ต่างจากการขอให้ SOCKS5 ขนส่งแพ็กเก็ต UDP ของไคลเอนต์

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

การตรวจสอบสิทธิ์และการเข้ารหัส

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

ตกลงวิธีตรวจสอบสิทธิ์ไม่ได้ต่างจากรหัสผ่านถูกปฏิเสธ เพราะกรณีแรกยังไม่เกิดการแลกรหัสผ่าน ไคลเอนต์ที่ไม่รองรับชื่อผู้ใช้/รหัสผ่านใช้จุด SOCKS5 ที่รับเฉพาะรหัสผ่านไม่ได้ เพียงเพราะมีการตั้งค่า SOCKS5 ส่วน SOCKS4 มีช่อง user ID แต่ไม่มีการแลกรหัสผ่านมาตรฐานแบบเดียวกัน อย่างไรก็ตามเซิร์ฟเวอร์ยังใช้กฎสิทธิ์ได้

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

ระหว่างส่งต่อ SOCKS ปกติ HTTPS ป้องกันการรับส่งของแอปกับเว็บไซต์เมื่อเปิดตรวจใบรับรองและไม่มีการดัก TLS โปรโตคอลแอปที่ไม่เข้ารหัสก็ยังไม่เข้ารหัสผ่านตัวส่งต่อ การรองรับ SOCKS5 หรือมีรหัสผ่านเพียงอย่างเดียวไม่ได้รับประกันทราฟฟิกเข้ารหัส

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

SOCKS5 ขนส่ง TCP และ UDP อย่างไร

TCP ให้สตรีมไบต์ตามลำดับ คำขอเบราว์เซอร์ การเรียก API หรือเซสชัน SSH ใช้การเชื่อมต่อ SOCKS TCP ได้เมื่อไคลเอนต์รองรับเส้นทางและพร็อกซีอนุญาตปลายทาง การสำเร็จบนพอร์ตเว็บ 443 ไม่ได้ยืนยันว่าพอร์ตแอปอื่นใช้ได้

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

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

SOCKS มีประโยชน์ที่ไหน

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

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

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

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

การตั้งค่าและการทดสอบที่มีประโยชน์

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

ข้อมูลรับรองพร็อกซีให้สิทธิ์ใช้ตัวกลาง ส่วนล็อกอินเว็บให้สิทธิ์เว็บไซต์ จึงอยู่คนละการตั้งค่า ใน curl --proxy-user ให้ข้อมูลพร็อกซี ส่วน --user ให้ข้อมูลปลายทาง หากเข้าถึงด้วย IP รายการอนุญาตต้องตรงกับ IP ต้นทางที่พร็อกซีเห็น ซึ่งอาจเปลี่ยนเมื่อไคลเอนต์เปลี่ยนเครือข่าย

เลือกโหมด DNS ที่ตั้งใจแล้วตรวจข้อยกเว้น ปลายทางในรายการยกเว้นอาจข้ามพร็อกซีที่ตั้งไว้ ใน curl NO_PROXY อาจทำให้เกิดเช่นนี้ ส่วน --noproxy "" ล้างข้อยกเว้นสำหรับการเรียกครั้งเดียวเมื่อตั้งใจทดสอบเส้นทางพร็อกซี

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

แล้วลองงานจริง IP ที่เปลี่ยนยืนยันเส้นทางคำขอที่ทดสอบ แต่ไม่ได้วัดทุกวิธีขนส่งหรือยืนยันว่าอีกเว็บไซต์จะตอบอย่างไร ทดสอบ UDP หรือ IPv6 แยกเมื่อจำเป็น และประเมินเวลาตอบสนองกับความเสถียรด้วยภาระงานที่เป็นตัวแทน

หาจุดผิดพลาดตามขั้นเชื่อมต่อ

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

หาก HTTPS ที่ตรวจใบรับรองสำเร็จและเว็บไซต์คืนหน้าล็อกอิน CAPTCHA หรือปฏิเสธสิทธิ์ แสดงว่า SOCKS ส่งการรับส่งนั้นแล้ว ควรตรวจคำตอบเว็บไซต์กับพฤติกรรมแอป แต่หากคำขอแสดง IP สาธารณะปกติของคุณ ให้ตรวจพร็อกซีที่เลือกและข้อยกเว้นในโปรแกรมนั้น