Listen, Bind และ BindSame ใน Tinyproxy: ที่อยู่ใดชนะ
Listen เลือกที่อยู่ที่รับไคลเอนต์ ส่วน Bind เลือกต้นทางของการเชื่อมต่อขาออก ทั้งสองไม่ได้ติดตั้งเส้นทาง จึงต้องตรวจสอบเส้นทางแยกต่างหาก
พร็อกซีตอบกลับ คำขอเสร็จสมบูรณ์ และถึงกระนั้น ปลายทางยังคงบันทึกที่อยู่ LAN. ไม่มีอะไรในบันทึกของพร็อกซีดูผิด และบรรทัดที่คุณแก้ไขก็คือบรรทัดที่เอกสารบอกให้แก้ บนโฮสต์ที่มีทั้งที่อยู่ LAN และที่อยู่ทันเนล คำสั่งสามตัวตัดสินว่าที่อยู่ใดปรากฏที่ใด และมีเพียงตัวเดียวที่เกี่ยวกับฝั่งขาออก หากอ่านผิดลำดับคุณจะไปอยู่ในตารางเส้นทางโดยไม่มีเหตุผล
อาการ: ปลายทางเห็นที่อยู่ LAN
ไคลเอนต์เชื่อมต่อกับพร็อกซีที่ที่อยู่ LAN และพร็อกซีเปิดการเชื่อมต่อของตนเองไปยังปลายทาง การเชื่อมต่อที่สองนั้นเลือกที่อยู่ต้นทางตามกฎของเคอร์เนล และโดยค่าเริ่มต้นคือสิ่งที่การค้นหาเส้นทางเลือก ปลายทางจึงบันทึกที่อยู่หลักของโฮสต์แม้ว่าทุกไบต์จะผ่านพร็อกซี ในแง่การส่งต่อไม่มีอะไรเสีย และนั่นคือเหตุผลที่บันทึกของพร็อกซีไม่มีอะไรจะกล่าว
ภาพสะท้อนของข้อบกพร่องนั้นเห็นได้ง่ายกว่า: ปักหมุดต้นทางขาออกไว้ที่ที่อยู่ทันเนล แล้วไคลเอนต์ LAN จะเข้าถึงตัวรับฟังไม่ได้เลย เวอร์ชันนั้นประกาศตัวเอง ส่วนเวอร์ชันแรกซ่อนอยู่หลังคำขอที่ทำงานได้ ทั้งสองเกิดจากการปฏิบัติต่อคำสั่งเดียวราวกับว่าตอบทั้งสองคำถาม
สามคำสั่ง สามที่อยู่ที่แตกต่าง
Listen ระบุที่อยู่ภายในเครื่องที่รับไคลเอนต์ของพร็อกซี Bind จัดหาที่อยู่ต้นทางสำหรับการเชื่อมต่อที่พร็อกซีสร้างออกไปภายนอก และ BindSame สั่งให้ใช้ที่อยู่ภายในเครื่องของการเชื่อมต่อที่เพิ่งรับมาใหม่ คำถามเหล่านี้แยกกันสามข้อ และบรรทัดเดียวตอบได้เพียงข้อเดียว การสับสนระหว่างกันคือสาเหตุปกติที่การเปลี่ยนแปลงดูเหมือนไม่ทำอะไร
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
อ่านการกำหนดค่าที่มีคำอธิบายประกอบซึ่งมาพร้อมเวอร์ชันที่ติดตั้ง เพราะค่าเริ่มต้นและไวยากรณ์ที่ยอมรับเปลี่ยนไประหว่างรุ่น โปรเจกต์มี การกำหนดค่าตัวอย่าง ที่จัดทำเอกสารทุกคำสั่งเคียงข้างกัน เปรียบเทียบไฟล์นั้นกับไฟล์บนดิสก์ ไม่ใช่กับคู่มือที่เขียนสำหรับดิสทริบิวชันอื่น
ตั้งค่าตัวรับฟังและต้นทางขาออกแยกจากกัน
ใช้โฮสต์ที่มีที่อยู่ LAN เป็น 192.168.50.10 และที่อยู่ทันเนลเป็น 10.90.0.3 หากไคลเอนต์ LAN ต้องเข้าถึงพร็อกซีขณะที่คำขอออกผ่านทันเนล สิ่งเหล่านี้เป็นการตัดสินใจสองอย่างที่เป็นอิสระต่อกัน และต้องเขียนทั้งสองอย่าง ชิ้นส่วนด้านล่างแสดงออกมาเพียงเท่านั้นและไม่มีอะไรอื่น
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noนี่ไม่ใช่การกำหนดค่าที่สมบูรณ์ จึงควรรักษาพอร์ตที่อนุมัติ การรับรองความถูกต้อง การควบคุมการเข้าถึงของไคลเอนต์ และข้อจำกัดปลายทาง ที่อยู่ทั้งสองต้องเป็นของโฮสต์นี้ภายในเนมสเปซเครือข่ายของ Tinyproxy เพราะค่า Bind ที่โพรเซสเป็นเจ้าของไม่ได้จะล้มเหลวตอนเชื่อมต่อ ไม่ใช่ตอนเริ่มทำงาน BindSame yes อธิบายนโยบายอีกแบบหนึ่ง ซึ่งที่อยู่ภายในเครื่องของการเชื่อมต่อที่รับมาจะกลายเป็นต้นทางขาออก ในรุ่นปัจจุบันสาขานั้นมีลำดับความสำคัญเหนือรายการ Bind และนั่นคือวิธีที่ต้นทางที่กำหนดไว้หายไปโดยไม่มีข้อผิดพลาด
ตรวจสอบเส้นทางที่ต้นทางบ่งชี้
การเลือกที่อยู่ต้นทางไม่ได้สร้างเส้นทาง ดังนั้นจึงต้องถามเคอร์เนลว่าจะทำอะไรกับต้นทางนั้นและปลายทางนั้น การค้นหาที่ระบุอินเทอร์เฟซทันเนลเป็นหลักฐานขั้นต่ำ และการค้นหาที่ระบุอินเทอร์เฟซ LAN หมายความว่าต้นทางไม่สามารถทำงานตามที่เขียนไว้ การค้นหาขึ้นกับบริบท โดยประเมินกฎนโยบายและตารางที่บังคับใช้ในเนมสเปซนั้น มันไม่ใช่การเชื่อมต่อ และไม่ได้บอกอะไรเกี่ยวกับสิ่งที่ NAT ในลำดับถัดไปจะนำเสนอต่อบริการ
ip -4 route get 203.0.113.25 from 10.90.0.3ใช้ที่อยู่สำหรับเอกสารในตัวอย่างและแทนที่ด้วยบริการที่คุณได้รับอนุญาตให้ทดสอบ รันการค้นหาภายในเนมสเปซของพร็อกซีเมื่อพร็อกซีทำงานในคอนเทนเนอร์ เพราะกฎของโฮสต์ไม่ใช่กฎที่โพรเซสมองเห็น เมื่อไม่มีเส้นทางทันเนลที่ตั้งใจไว้ ควรให้เจ้าของเครือข่ายแก้ไข แทนที่จะเพิ่มกฎเฉพาะปลายทางบนโฮสต์พร็อกซี อย่าล้างเส้นทางของโฮสต์หรือปิดใช้งานเส้นทางที่เซิร์ฟเวอร์ผลักดันเพื่อให้การค้นหาสำเร็จ แม้คู่มือเก่าจะทำเช่นนั้น เพราะการเปลี่ยนแปลงเหล่านั้นย้ายพฤติกรรม VPN ที่อนุมัติแล้วของทั้งโฮสต์เพื่อซ่อมเส้นทางพร็อกซีเพียงเส้นเดียว
ยืนยันต้นทางที่ปลายทาง
อ่านต้นทาง ณ จุดที่คำขอมาถึง ไม่ใช่จุดที่จากไป บันทึกแอปพลิเคชันของปลายทาง หรืออุปกรณ์ขอบที่อยู่ข้างหน้า จะบันทึกที่อยู่ที่เห็นจริง ขณะที่พร็อกซีบอกได้เพียงเจตนา ส่งคำขอใหม่หนึ่งครั้งผ่านตัวรับฟังที่ตั้งใจหลังการเปลี่ยนแปลง เพราะการเชื่อมต่อที่แคชไว้ไม่ได้พิสูจน์อะไรเกี่ยวกับการผูกใหม่ จากนั้นเปรียบเทียบที่อยู่ที่บันทึกไว้กับที่อยู่ที่คุณกำหนด
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl เป็นเพียงตัวสร้างทราฟฟิก ที่อยู่ที่ควรตรวจสอบคือที่อยู่ที่ฝั่งไกลบันทึกไว้ ไม่ใช่คู่ที่ curl บังเอิญเชื่อมต่อ หากทั้งสองไม่ตรงกัน ให้ตัดสินว่าความแตกต่างมาจากการเลือกต้นทางหรือจากการแปลงต่อไปตามเส้นทาง เพราะสิ่งเหล่านั้นแก้ไขในที่ต่างกัน วางแผนการเปลี่ยนที่อยู่และการรีสตาร์ทพร็อกซีไปด้วยกัน เพราะการผูกที่อยู่ที่ทันเนลไม่มีแล้วจะล้มเหลวอย่างเงียบ ๆ หลังการเชื่อมต่อใหม่ กำหนดพฤติกรรมของ DNS และ IPv6 แยกต่างหากด้วย เพราะชิ้นส่วน IPv4 ข้างต้นไม่ได้พิสูจน์อะไรเกี่ยวกับทั้งสอง