Dante SOCKS ผ่าน VPN: อุโมงค์เต็มรูปแบบหรือกำหนดเส้นทางตามต้นทาง

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

สองการออกแบบ สองรัศมีความเสียหายที่ต่างกัน

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

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

ความแคบนั้นคือข้อจำกัดด้วย: การออกแบบนี้ทำงานเฉพาะเมื่อแพ็กเก็ตขาออกของพร็อกซีมีที่อยู่นั้นจริง ๆ

สิ่งที่การตั้งค่า external ของ Dante ทำ

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

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

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

การสร้างตารางที่เลือกตามต้นทาง

สำหรับที่อยู่ TUN 10.90.0.2/24 ที่มีเพียร์ที่เข้าถึงได้ที่ 10.90.0.1 และหมายเลขตารางที่ไม่มีอย่างอื่นใช้ การจัดวางมีลักษณะดังนี้:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

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

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

จุดที่กฎต้นทางรั่ว

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

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

IPv6 ต้องการกฎและเส้นทางของตนเอง เพราะการจัดวาง IPv4 ไม่ได้พิสูจน์อะไรเกี่ยวกับมัน

เลือกตามความล้มเหลวที่คุณทนได้

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

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

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