VPN Pi หลายเราเตอร์: วางแต่ละเส้นทางบนอุปกรณ์ที่ตัดสินใจ
เราเตอร์ปลายทางเพิ่มซับเน็ตไคลเอนต์ที่สอง และอุปกรณ์ทั้งสี่เครื่องมีการตัดสินใจคนละหนึ่งอย่าง วางเส้นทาง ตรวจสอบต้นทาง แล้วทดสอบจากไคลเอนต์จริง
การวางกล่อง Wi-Fi ไว้หลัง Pi ทำให้การตัดสินใจเรื่องเส้นทางหนึ่งครั้งกลายเป็นสี่ครั้ง และแผนจะพังเมื่อทั้งสี่ถูกตัดสินบนอุปกรณ์เครื่องเดียว คำถามแรกไม่ใช่จะเพิ่มเส้นทางใด แต่คือกล่องใหม่ทำบริดจ์หรือเราเตอร์ เพราะคำตอบนั้นกำหนดว่ามีกี่ซับเน็ตและอุปกรณ์ใดต้องเรียนรู้เกี่ยวกับซับเน็ตเหล่านั้น เลือกโมเดลการเชื่อมต่อก่อน ทุกเส้นทางตามมาจากโมเดลนั้น
บริดจ์หรือเราเตอร์: ทางเลือกที่กำหนดจำนวน
บริดจ์วางไคลเอนต์ใหม่ไว้ในซับเน็ตเดียวกับที่ Pi ให้บริการอยู่แล้ว หนึ่งซับเน็ต หนึ่งอำนาจ DHCP และไม่มีการส่งต่อให้เราเตอร์ นี่คือการจัดวางที่ง่ายกว่าและถูกต้องเมื่อเครือข่ายไคลเอนต์แยกต่างหากไม่เคยเป็นข้อกำหนด ลิงก์แบบเราเตอร์เป็นการออกแบบที่ต่างออกไป กล่องเก็บซับเน็ตของตัวเอง และคำนำหน้านั้นต้องถูกพาไปทุกที่ที่ทราฟฟิกไป
ส่วนที่เหลือของแผนนี้ยังคงเราเตอร์ปลายทางและรักษาที่อยู่ต้นทางของไคลเอนต์ เป้าหมายคือเครือข่าย VPN ส่วนตัวหนึ่งเครือข่าย ไม่ใช่ทางออกอินเทอร์เน็ตเต็มรูปแบบ เขียนโมเดลก่อนที่อยู่ เพราะรายการด้านล่างเป็นเพียงตัวอย่างของการเชื่อมต่อแบบเราเตอร์
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24ใครตัดสินอะไร
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
แต่ละอุปกรณ์ตัดสินหนึ่งอย่าง และไม่มีใครตัดสินแทนอีกเครื่องได้ Pi ต้องมีสองรายการไม่ใช่หนึ่ง และเส้นทางขากลับคือสิ่งที่คนลืม ทราฟฟิกที่ส่งต่อมาถึงเครือข่ายส่วนตัวอย่างถูกต้องแล้วตายตอนขากลับ เพราะ Pi ไม่รู้ว่า 10.41.0.0/24 อยู่ที่ไหน นั่นดูเหมือนปัญหาไฟร์วอลล์และจริง ๆ คือเส้นทางที่หายไป
ฝั่งไกลก็ต้องมีเส้นทางของตัวเอง ถ้าบริการที่ปลายไกลไม่รู้ว่า 10.41.0.0/24 เข้าถึงได้ผ่านทันเนลของคุณ คำตอบจะหยุดที่ฮอปแรกที่ไม่มีคำตอบ เพิ่มทั้งสองทิศทางก่อนอ่านตัวกรองแพ็กเก็ต
ฮอปถัดไปมาจากการเชื่อมต่อ
ฮอปถัดไปต้องเป็นที่อยู่ในเครือข่ายที่อุปกรณ์เข้าถึงได้จริง ที่อยู่สาธารณะของคู่ VPN ไม่ใช่ฮอปถัดไปสำหรับซับเน็ตส่วนตัว และเครือข่ายบริการไกลก็ไม่ใช่ฮอปถัดไปเลย เส้นทางไปยังเกตเวย์ที่เข้าถึงไม่ได้ดูถูกต้องในรายการและทิ้งทุกแพ็กเก็ต ตรวจสอบว่าเกตเวย์ตอบสนองก่อนโทษปลายทาง
รักษา คู่ VPN ภายนอกของ Pi ให้เข้าถึงได้ผ่านเส้นทางชั้นล่างของมันเอง รายการนั้นแยกจากเส้นทางเพย์โหลด และการผสมกันทำให้เกิดทันเนลที่ไม่สามารถสร้างใหม่ได้หลังเส้นทางเปลี่ยน
เอกสารเส้นทางแบบสถิต ทำให้ความแตกต่างระหว่างปลายทางและเกตเวย์ชัดเจน แม้แต่ละแพลตฟอร์มตั้งชื่อเมนูต่างกัน อ่านเอกสารของอุปกรณ์ตรงหน้าคุณแทนการคัดลอกหน้าจอของผู้ขายรายอื่น คำสั่งด้านล่างแสดงรูปแบบของรายการบน Linux
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1การแปลทำอะไรกับต้นทาง
ถ้าเราเตอร์ปลายทางแปลไคลเอนต์เป็นที่อยู่ทรานซิตอยู่แล้ว Pi จะเห็นต้นทางที่แปลแล้วหนึ่งรายการแทนที่อยู่ของไคลเอนต์แต่ละเครื่อง นี่เป็นการออกแบบที่ต่างจากแบบที่รักษาต้นทางข้างต้น มันเปลี่ยนนโยบายตามต้นทาง การบันทึก และฝ่ายใดสามารถเริ่มการเชื่อมต่อได้ ทั้งสองแบบทำงานได้ พวกมันตอบคำถามต่างกัน
เมื่อบริการ VPN ต้นน้ำปฏิเสธที่จะเราเตอร์คำนำหน้าไคลเอนต์กลับ การแปลแคบ ๆ ที่ทางออกทันเนลของ Pi อาจเป็นวิธีแก้ชั่วคราวที่ชอบด้วยกฎหมาย นั่นไม่ใช่หลักฐานว่าเส้นทางที่หายไปไม่จำเป็น บันทึกว่าเครือข่ายไกลเห็นที่อยู่ใดจริงและได้เส้นทางขากลับแบบใด
การเลือกเส้นทาง การอนุญาตส่งต่อ และการแปลต้นทางยังคงเป็นสามงานแยกกัน การล้างเชน NAT ที่ใช้ร่วมกันหรืออนุญาตทุกอินเทอร์เฟซเพราะไคลเอนต์แบบมีสายหนึ่งเครื่องทำงานได้ คือวิธีที่การทดสอบที่ทำงานได้กลายเป็นตัวส่งต่อแบบเปิด
พิสูจน์จากเครื่องไคลเอนต์
ส่งคำขอจากเครื่องใน LAN ปลายทาง แล้วติดตามต้นทางออกไปและกลับมา ping ที่ Pi ส่งจะไม่ใช้เส้นทางขากลับปลายทางเลย ดังนั้น ping ที่สำเร็จจึงพิสูจน์ได้น้อยกว่าที่เห็น เพิ่มการทดสอบที่สองจากไคลเอนต์แบบมีสายใน LAN ของ Pi เองเพื่อให้เทียบสองเส้นทางได้ ทำซ้ำทั้งสองหลังรีบูตอุปกรณ์ใดก็ตาม
เส้นทางที่เพิ่มด้วยมือและการแปลที่ไม่เคยถูกบันทึกหายไปด้วยกัน จากนั้นคู่นั้นดูเหมือนข้อบกพร่องใหม่ ไม่ใช่งานที่ยังไม่เสร็จ
บันทึกโมเดลการเชื่อมต่อพร้อมเส้นทาง บริการส่วนตัวที่อนุญาต และการแปลใด ๆ ไว้ในบันทึกเดียว บันทึกนั้นคือสิ่งที่หยุดคนถัดไปไม่ให้ถือว่าการวางตำแหน่งไร้สายเป็นคำถามนโยบายเส้นทาง