Redsocks รับฟังบน loopback แต่ทราฟฟิก VPN ไม่เคยมาถึง

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

แพ็กเก็ตที่เปลี่ยนเส้นทางไปถึงที่ใดจริง

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

ดังนั้นก่อนแตะข้อมูลรับรองของชั้นบน ให้ยืนยันสองข้อ กฎเขียนใหม่ไปยังที่อยู่ภายในใด และซ็อกเก็ตพร็อกซีผูกกับที่อยู่ใด

อ่านตัวรับฟังและกฎการเปลี่ยนเส้นทางไปพร้อมกัน

พิมพ์ตารางซ็อกเก็ตและกฎ nat ในการรันครั้งเดียว เพราะกฎที่ชี้ไปยังพอร์ตที่ไม่มีใครเป็นเจ้าของดูเหมือนกฎที่ชี้ไปยังที่อยู่ผิด sudo ss -ltnp | grep redsocks แสดงที่อยู่ที่ผูกและกระบวนการที่เป็นเจ้าของ sudo iptables -t nat -S PREROUTING แสดงเป้าหมาย REDIRECT และ sudo iptables -t nat -L PREROUTING -v -n แสดงว่ามีสิ่งใดตรงกับมันหรือไม่

การกระโดดไปยังเชนผู้ใช้ชื่อ REDSOCKS ไม่เกิดประโยชน์ใด ๆ เว้นแต่เชนนั้นมีอยู่และมีข้อยกเว้นที่ตั้งใจไว้และการกระทำ REDIRECT อ่านเชนที่มันกระโดดไปด้วย sudo iptables -t nat -S REDSOCKS แทนการสมมติว่าชื่อทำงานนั้นเอง

จากนั้นเปรียบเทียบค่าสองค่า หากกฎเปลี่ยนเส้นทางไปยังที่อยู่เกตเวย์ที่พอร์ต 12345 และตัวรับฟังรายงาน 127.0.0.1:12345 ความไม่ตรงกันนั้นอธิบายความล้มเหลวได้โดยไม่ต้องวินิจฉัยเพิ่ม

ผูกอย่างแคบ แล้วจำกัดสิ่งที่เข้าถึงได้

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

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

พิสูจน์ด้วยการเชื่อมต่อใหม่จากไคลเอนต์

ทดสอบจากไคลเอนต์ VPN จริงด้วยการเชื่อมต่อ TCP ใหม่ ไม่ใช่จากเชลล์บนเกตเวย์ curl -sS -o /dev/null -w '%{http_code}\n' http://example.com บนไคลเอนต์ทดสอบเส้นทางที่เปลี่ยนเส้นทางตั้งแต่ต้นจนจบ

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

สุดท้าย จำไว้ว่าเส้นทางนี้ไม่ครอบคลุมอะไรบ้าง การเปลี่ยนเส้นทาง TCP ปกติของ redsocks ไม่ได้เปลี่ยน UDP, QUIC หรือ DNS เป็นทราฟฟิก SOCKS และปลายทางส่วนตัวมักต้องมีข้อยกเว้นที่ชัดเจน การทดสอบภายในที่สำเร็จพิสูจน์เพียงเส้นทาง loopback ที่ไม่เคยเป็นปัญหา