ทำไมสองไซต์ที่มีซับเน็ตเดียวกันจึงไม่ใช่ LAN เดียว

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

โฮสต์ตัดสินใจก่อนเราเตอร์

โฮสต์ที่มีที่อยู่ 192.168.77.10/24 จะเทียบปลายทางกับพรีฟิกซ์ของตัวเอง สิ่งใดที่อยู่ในพรีฟิกซ์นั้นถืออยู่บนลิงก์โดยตรง โฮสต์จึงแก้ที่อยู่ชั้นลิงก์ของปลายทางเองโดยตรง ส่วนสิ่งใดที่อยู่นอกพรีฟิกซ์จะไปยังเกตเวย์เริ่มต้น

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

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

ARP เป็นคำถามของลิงก์ท้องถิ่น

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

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

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

เซกเมนต์ที่ยืดออกพาเฟรม ไม่ใช่เส้นทาง

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

ที่นี่เกตเวย์ระยะไกลไม่ได้จัดเส้นทางระหว่างสองซับเน็ตที่เหมือนกันเลย เฟรมข้ามชั้นใต้ที่จัดเส้นทาง IP ด้วยตัวเอง ขณะที่บริดจ์ขยายบทสนทนาอีเทอร์เน็ต

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

Proxy ARP คือการออกแบบที่สาม

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

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

มันไม่ได้ทำให้โปรโตคอลที่ไม่ใช่ IP จัดเส้นทางได้ตามอำเภอใจ และไม่ได้จำลองโดเมนกระจายสัญญาณอีเทอร์เน็ต ใช้เมื่อข้อกำหนดคือการแทนที่นั้นจริง ๆ ไม่ใช่ทางลัดสำหรับการเลื่อนการเปลี่ยนเลขที่อยู่

เลือกจากข้อกำหนด แล้วตรวจสอบ

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

ยืนยันว่าคุณมีการออกแบบแบบไหนจริง ๆ โดยถามโฮสต์ว่ามันทำอะไรกับปลายทาง:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

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