เราเตอร์ตามนโยบายเทียบกับ SOCKS: ชั้นไหนกันแน่ที่พร็อกซีทราฟฟิก

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

การกำหนดเส้นทาง DNAT และ SOCKS เปลี่ยนสิ่งที่แตกต่างกัน

เส้นทางตามนโยบายเขียนการตัดสินใจชั้น 3 ใหม่. สองบรรทัดเพียงพอที่จะส่งทราฟฟิกของไคลเอนต์หนึ่งรายไปยังฮอปถัดไปที่เลือกไว้:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

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

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

กรณีแรก: แอปสามารถพูด SOCKS ได้เอง

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

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

กรณีที่สอง: อะแดปเตอร์ที่แปลงโฟลว์ IP เป็นเซสชันพร็อกซี

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

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

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

กรณีที่สาม: โฮสต์เป็นเกตเวย์ที่กำหนดเส้นทางจริง ๆ

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

ทั้งสามกรณีแยกจากกันอย่างรวดเร็ว ตรวจสอบว่าอะไรกำลังรับฟังจริง ๆ แล้วดูไบต์แรกที่ไปถึงโฮสต์:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

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

เลือกชั้นด้วยคำถามสี่ข้อ

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

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