ทำไมโฮสต์ LAN จึงส่ง ARP สำหรับที่อยู่ของไคลเอนต์ OpenVPN

ปัญหาการเข้าถึงระหว่างโฮสต์ LAN กับไคลเอนต์ VPN มักย้อนกลับไปที่แผนที่อยู่เองให้อินเทอร์เฟซบน 10.0.100.0/22 แก่โฮสต์นั้น แล้วมันจะถือว่าทุกที่อยู่ตั้งแต่ 10.0.100.0 ถึง 10.0.103.255 เชื่อมต่อโดยตรง รวมถึงพูลไคลเอนต์ที่วางไว้อย่างเงียบ ๆ บน 10.0.101.0/24คำตอบไม่เคยไปยังเราเตอร์ เพราะจากมุมมองของโฮสต์ไม่มีเราเตอร์เกี่ยวข้องแพ็กเก็ตถูกส่งถึงเพื่อนบ้านและถูกขอบนสาย

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

คำนำหน้า /22 ที่กลืน /24

อ่านคำนำหน้าเป็นช่วง ไม่ใช่สตริงคำนำหน้า /22 มี 1024 ที่อยู่ และ 10.0.100.0/22 ครอบตั้งแต่ 10.0.100.0 ถึง 10.0.103.255 ดังนั้นพูลบน 10.0.101.0/24 จึงอยู่ภายในทั้งหมดข้อผิดพลาดนี้รอดจากการตรวจทาน เพราะอ็อกเท็ตแรกของพูลดูต่างจากอ็อกเท็ตแรกของ LAN และมีเพียงอ็อกเท็ตที่สามที่เผยการซ้อนทับเขียนทั้งสองช่วงเป็นตัวเลขก่อนจะประกาศว่าแยกจากกัน

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

เชื่อมต่อโดยตรงหมายถึง ARP ไม่ใช่การกำหนดเส้นทาง

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

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

TUN, TAP และสิ่งที่แต่ละตัวบรรทุก

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

บันทึกว่าคำขอ ARP ปรากฏที่ใดและระบบใดส่งออกมาก่อนสรุปผู้ส่งบอกคุณว่าเชื่ออะไรเกี่ยวกับปลายทาง ไม่ใช่ว่าอุโมงค์ทำอะไร

ออกแบบพูลที่ไม่สามารถซ้อนทับได้

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

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

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