EoIP บนลิงก์ VPN LTE: สร้างห้องแล็บ RouterOS ขนาดเล็ก

EoIP รับเฟรม Ethernet ทั้งเฟรม ห่อด้วย GRE แล้วส่งไปยังที่อยู่ปลายทางที่กำหนดไว้ ผลลัพธ์จึงทำงานเหมือนสายเคเบิลไม่ใช่เหมือนเส้นทาง สิ่งที่ออกจากเราเตอร์คือโปรโตคอล IP 47 โดยมีเฟรมเดิมเป็นเพย์โหลด การออกอากาศ ARP และโปรโตคอลที่ไม่ใช่ IP จึงผ่านได้ทั้งหมด GRE ไม่ได้เพิ่มความลับใด ๆ ของตัวเอง และเฟรมยังคงอ่านได้สำหรับทุกสิ่งที่เห็นแพ็กเก็ตชั้นนอก ข้อเท็จจริงข้อเดียวนี้กำหนดลำดับของห้องแล็บนี้: สร้างเส้นทางที่เข้ารหัสก่อน แล้วจึงบรรทุก Ethernet ไว้ข้างใน

EoIP ห่ออะไร และไม่ห่ออะไร

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

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

สำหรับบริการ IP ที่มีการกำหนดเส้นทาง VPN ที่กำหนดเส้นทาง เป็นดีไซน์ที่เล็กกว่าและเป็นสิ่งที่ควรเลือกใช้ จะลงไปชั้นสองก็ต่อเมื่ออุปกรณ์จำเป็นต้องเห็นเฟรม Ethernet จากอีกไซต์จริง ๆ

ข้อกำหนดเบื้องต้น: ชั้นล่างที่เข้ารหัสและพอร์ตที่ไม่ได้ใช้สองพอร์ต

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

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

Hub tunnel address:    10.44.7.1/32
LTE tunnel address:    10.44.7.2/32
Lab ports:             ether7 on both routers, unused
Test hosts:            192.168.77.11/24 and 192.168.77.12/24

ค่าเหล่านี้เป็นตัวอย่างไม่ใช่ข้อบังคับ ต้องอยู่บนอินเทอร์เฟซของทันเนลและถูกกำหนดเส้นทางผ่านเส้นทางที่ป้องกัน นโยบายไฟร์วอลล์บนเราเตอร์ทั้งสองต้องอนุญาต GRE ระหว่างที่อยู่ทันเนลทั้งสอง และ GRE คือโปรโตคอล IP 47 ไม่ใช่พอร์ต TCP หรือ UDP หมายเลข 47 ดีไซน์นี้ไม่เคยเปิดเผย GRE ดิบให้ WAN ใดเลย

สร้างคู่ทันเนลด้วย ID ที่ตรงกัน

ปลายทั้งสองเป็นอินเทอร์เฟซลอจิคัลเดียวที่นิยามไว้สองครั้ง ทุกฟิลด์ระบุตัวตนจึงต้องตรงกัน บนฮับ:

/interface eoip add name=eoip-lab local-address=10.44.7.1 remote-address=10.44.7.2 tunnel-id=37 mac-address=02:1A:2B:00:00:01

บนเราเตอร์ LTE ที่อยู่สลับกันและ MAC ต่างกัน:

/interface eoip add name=eoip-lab local-address=10.44.7.2 remote-address=10.44.7.1 tunnel-id=37 mac-address=02:1A:2B:00:00:02

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

คู่มือ EoIP ปัจจุบัน อธิบายฟิลด์ปลายทางและ ID ของทันเนล และระบุชัดว่า EoIP คือ Ethernet บน GRE ไม่มีสิ่งใดในคำสั่งนั้นเข้ารหัสอะไรเลย การตรวจสอบชั้นล่างจึงต้องมาก่อน

บริดจ์เฉพาะพอร์ตทดสอบ

บริดจ์คือสิ่งที่เปลี่ยนทันเนลให้เป็นเซกเมนต์ และองค์ประกอบของมันคือขอบเขตความปลอดภัยทั้งหมด บนฮับ:

/interface bridge add name=br-eoiphub protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:01
/interface bridge port add bridge=br-eoiphub interface=ether7
/interface bridge port add bridge=br-eoiphub interface=eoip-lab

บนเราเตอร์ LTE:

/interface bridge add name=br-eoiplte protocol-mode=rstp auto-mac=no admin-mac=02:1A:2B:00:01:02
/interface bridge port add bridge=br-eoiplte interface=ether7
/interface bridge port add bridge=br-eoiplte interface=eoip-lab

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

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

ประมาณการค่าใช้จ่ายส่วนเกินก่อนขยาย LAN

EoIP บน IPv4 เพิ่มหัว Ethernet, GRE และ IP ชั้นนอกรอบเพย์โหลดที่บรรทุก สำหรับกรณีไม่มีแท็ก MikroTik ระบุ 42 ไบต์ ชั้นล่างที่มี MTU IP ใช้งานได้ 1400 ไบต์จึงเหลือ 1358 ไบต์สำหรับเฟรมชั้นใน ตัวเลขนั้นเป็นงบประมาณไม่ใช่ค่า MSS สากล และไม่ได้บังคับให้โฮสต์ที่อยู่ในบริดจ์ส่งเฟรมเล็กลง

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

/interface eoip print detail where name=eoip-lab
/interface bridge host print where bridge=br-eoiphub
/ping 192.168.77.12 count=4 interface=br-eoiphub

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

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