ไคลเอนต์ VPN ที่มีที่อยู่ LAN ไม่ได้อยู่บน LAN

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

ความเชื่อผิด: คำนำหน้าเดียวกันหมายถึงเซกเมนต์เดียวกัน

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

เมื่อเซิร์ฟเวอร์ส่งไปยัง 10.50.0.200 มันจะเปรียบเทียบปลายทางกับมาสก์ของตัวเอง ตัดสินว่าที่อยู่นั้นเป็น on-link และถามเซกเมนต์ภายในสำหรับที่อยู่ฮาร์ดแวร์ที่เป็นเจ้าของ คำขอนั้นออกไปทางอินเทอร์เฟซ Ethernet และไคลเอนต์ VPN ไม่ได้อยู่ที่นั่นเพื่อรับฟัง

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

โฮสต์ภายในทำอะไรกับที่อยู่จริง ๆ

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

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

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

proxy ARP จัดหาฮอปถัดไปอย่างไร

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

เอกสาร ARP ของ RouterOSจาก MikroTik อธิบายการใช้งานนั้นสำหรับไคลเอนต์ dial-in ที่ยืมพื้นที่ที่อยู่ของ LAN ที่เชื่อมต่ออยู่ กลไกนี้เป็นการซ่อมแซมการแก้ไขเพื่อนบ้าน และมันทำงานได้เพราะเกตเวย์อยู่บนทั้งสองเส้นทางจริง ๆ

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

อ่านชื่อโหมดของแพลตฟอร์มอย่างระมัดระวัง RouterOS แยก proxy-arp ออกจาก local-proxy-arp และตัวหลังจัดการทราฟฟิกที่เข้าออกผ่านอินเทอร์เฟซเดียวกัน ทั้งสองไม่ใช่การสะกดที่ใช้แทนกันได้ และการเปิดทั้งสองโดยไม่แยกแยะก็ไม่ใช่ทางลัด

สิ่งที่ proxy ARP ไม่ให้คุณ

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

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

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

เปรียบเทียบกับพูลที่กำหนดเส้นทางแยกต่างหาก

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

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

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