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

สองที่อยู่ สองการอ้างสิทธิ์

เมื่อลูกค้าเชื่อมต่อ Access Server ให้ที่อยู่จากพูลที่กำหนด เช่น 10.90.0.0/24 การจัดสรรนั้นเป็นการเช่าสำหรับโฮสต์เดียว ไม่มีอะไรบอกว่าลูกค้ารายเดียวกันอยู่หน้า 10.60.0.0/24 ด้วย และเซิร์ฟเวอร์ไม่เดา: คำนำหน้า LAN เข้าถึงได้ผ่านลูกค้าเฉพาะเมื่อผู้ดูแลประกาศ

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

การตั้งค่าเกตเวย์ติดตั้งอะไรจริง

ใน Admin Web UI การประกาศเป็นคุณสมบัติของผู้ใช้: เปิด Configure VPN gateway ที่ผู้ใช้ connector และใส่คำนำหน้าจริงใน Network on the VPN client side ผู้ใช้รายนั้นพิสูจน์ตัวตนเหมือนคนอื่น จึงต้องมีนโยบายข้อมูลรับรองที่เหมาะกับอุปกรณ์ที่ไม่มีการดูแล

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

คำสั่งแบบ Community ที่แปะในไฟล์ที่สร้างขึ้นไม่ร่วมในรูปแบบนี้ ผลิตภัณฑ์เป็นเจ้าของตารางเส้นทางที่ส่ง บรรทัดที่แก้ด้วยมือจะถูกเขียนทับ

ทำให้เส้นทางย้อนกลับครบทั้งสองเครือข่าย

แผน: สำนักงานใหญ่ 10.40.0.0/24 สาขา 10.60.0.0/24 พูล VPN 10.90.0.0/24 และ Access Server ที่ที่อยู่ส่วนตัวด้านสำนักงานใหญ่ เราเตอร์ต้องมีเส้นทางสำหรับคำนำหน้าสาขาและพูล หากไม่มี คำตอบจะออกผ่านเกตเวย์เริ่มต้น ซึ่งทำให้เกิดการเชื่อมต่อแบบเปิดครึ่งหนึ่ง

ที่สาขา connector ต้องส่งต่อแพ็กเก็ตที่ไม่ได้ส่งมาหาตน: การส่งต่อ IP ในระบบปฏิบัติการและสิทธิ์ที่จำกัดเฉพาะอินเทอร์เฟซทันเนลและ LAN บน Linux คือ net.ipv4.ip_forward=1 พร้อมกฎ forward chain บน Windows คือ routing and remote access จากนั้นโฮสต์ต้องมีเส้นทางย้อนกลับ: connector เป็นเกตเวย์เริ่มต้น หรือเกตเวย์ที่มีอยู่มีเส้นทางเฉพาะ

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

อ่านความล้มเหลวเป็นเส้นทาง

ทดสอบตามลำดับ ก่อนอื่นบริการที่อนุญาตจาก Access Server ไปยังโฮสต์สาขา จากนั้นบริการเดียวกันจากโฮสต์ปกติของสำนักงานใหญ่ จากนั้นทิศทางตรงข้ามหากนโยบายอนุญาต หากอันแรกผ่านอันที่สองล้มเหลว ปัญหาคือเส้นทางหรือกฎ หากทั้งสองผ่านแต่ไม่มีคำตอบ ให้ตรวจการส่งต่อที่สาขาและเส้นทางย้อนกลับที่สำนักงานใหญ่

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

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

บทแนะนำ site-to-site ของ Access Server แสดงการตั้งค่าเดียวกันตามลำดับผลิตภัณฑ์

บทความที่เกี่ยวข้อง