พื้นฐานของ Static Routing ใน Mikrotik RouterOS

การกำหนดเส้นทางเป็นกระบวนการค้นหาเส้นทางที่ดีที่สุดสำหรับการส่งแพ็กเก็ตผ่านเครือข่าย TCP/IP อุปกรณ์ใดๆ ที่เชื่อมต่อกับเครือข่าย IPv4 จะมีกระบวนการและตารางเส้นทาง

บทความนี้ไม่ใช่ HOWTO แต่จะอธิบายการกำหนดเส้นทางแบบคงที่ใน RouterOS พร้อมตัวอย่าง ฉันจงใจละเว้นการตั้งค่าที่เหลือ (เช่น srcnat สำหรับการเข้าถึงอินเทอร์เน็ต) ดังนั้นการทำความเข้าใจเนื้อหาจึงจำเป็นต้องมีความรู้ระดับหนึ่งเกี่ยวกับเครือข่ายและ RouterOS

การสลับและการกำหนดเส้นทาง

การสลับคือกระบวนการแลกเปลี่ยนแพ็กเก็ตภายในส่วน Layer2 หนึ่งส่วน (Ethernet, ppp, ...) หากอุปกรณ์เห็นว่าผู้รับแพ็กเก็ตอยู่บนซับเน็ตอีเทอร์เน็ตเดียวกันกับอุปกรณ์ อุปกรณ์จะเรียนรู้ที่อยู่ mac โดยใช้โปรโตคอล arp และส่งแพ็กเก็ตโดยตรงโดยผ่านเราเตอร์ การเชื่อมต่อ ppp (แบบจุดต่อจุด) สามารถมีผู้เข้าร่วมได้เพียงสองคน และแพ็กเก็ตจะถูกส่งไปยังที่อยู่เดียว 0xff

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

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

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

การกำหนดเส้นทางใน RouterOS และ PacketFlow

ฟังก์ชันเกือบทั้งหมดที่เกี่ยวข้องกับการกำหนดเส้นทางแบบคงที่อยู่ในแพ็คเกจ ระบบ. ถุงพลาสติก การกำหนดเส้นทาง เพิ่มการรองรับสำหรับอัลกอริทึมการกำหนดเส้นทางแบบไดนามิก (RIP, OSPF, BGP, MME), ตัวกรองการกำหนดเส้นทาง และ BFD

เมนูหลักสำหรับตั้งค่าเส้นทาง: [IP]->[Route]. โครงร่างที่ซับซ้อนอาจกำหนดให้แพ็กเก็ตต้องติดฉลากล่วงหน้าด้วยเครื่องหมายการกำหนดเส้นทางใน: [IP]->[Firewall]->[Mangle] (ห่วงโซ่ PREROUTING и OUTPUT).

มีสามตำแหน่งใน PacketFlow ที่มีการตัดสินใจกำหนดเส้นทางแพ็กเก็ต IP:

1. แพ็กเก็ตเส้นทางที่เราเตอร์ได้รับ ในขั้นตอนนี้ จะมีการตัดสินใจว่าแพ็กเก็ตจะไปที่กระบวนการในเครื่องหรือจะถูกส่งต่อไปยังเครือข่าย ได้รับแพคเกจการขนส่ง เอาท์พุทแบบ
2. การกำหนดเส้นทางแพ็กเก็ตขาออกในเครื่อง รับแพ็กเก็ตขาออก เอาท์พุทแบบ
3. ขั้นตอนการกำหนดเส้นทางเพิ่มเติมสำหรับแพ็กเก็ตขาออก ช่วยให้คุณเปลี่ยนการตัดสินใจกำหนดเส้นทางใน [Output|Mangle]

• เส้นทางแพ็กเก็ตในบล็อก 1, 2 ขึ้นอยู่กับกฎใน [IP]->[Route]
• เส้นทางแพ็กเก็ตในจุดที่ 1, 2 และ 3 ขึ้นอยู่กับกฎใน [IP]->[Route]->[Rules]
• เส้นทางแพ็คเกจในบล็อก 1, 3 สามารถรับอิทธิพลได้ [IP]->[Firewall]->[Mangle]

RIB, FIB, แคชการกำหนดเส้นทาง

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

แบบมีเงื่อนไขเราสามารถสันนิษฐานได้ว่า [IP]->[Route] แสดง RIB

ฐานข้อมูลการส่งต่อ

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

ในการตัดสินใจกำหนดเส้นทาง ตาราง FIB จะใช้ข้อมูลต่อไปนี้เกี่ยวกับแพ็กเก็ต IP:

• ที่อยู่ต้นทาง
• ที่อยู่ปลายทาง
• อินเทอร์เฟซแหล่งที่มา
• เครื่องหมายบอกเส้นทาง
• ข้อกำหนดในการให้บริการ (DSCP)

การเข้าสู่แพ็คเกจ FIB จะต้องผ่านขั้นตอนต่อไปนี้:

• แพ็คเกจนี้มีไว้สำหรับกระบวนการเราเตอร์ในเครื่องหรือไม่
• แพ็กเก็ตอยู่ภายใต้กฎ PBR ของระบบหรือผู้ใช้หรือไม่
  • ถ้าใช่ แพ็กเก็ตจะถูกส่งไปยังตารางเส้นทางที่ระบุ
• แพ็คเก็ตถูกส่งไปยังตารางหลัก

แบบมีเงื่อนไขเราสามารถสันนิษฐานได้ว่า [IP]->[Route Active=yes] แสดงความตอแหล

แคชการกำหนดเส้นทาง
กลไกการแคชเส้นทาง เราเตอร์จดจำตำแหน่งที่แพ็กเก็ตถูกส่งและหากมีแพ็กเก็ตที่คล้ายกัน (สันนิษฐานว่ามาจากการเชื่อมต่อเดียวกัน) ก็จะปล่อยให้แพ็กเก็ตไปตามเส้นทางเดียวกันโดยไม่ต้องตรวจสอบใน FIB แคชเส้นทางจะถูกล้างเป็นระยะ

สำหรับผู้ดูแลระบบ RouterOS นั้นไม่ได้สร้างเครื่องมือสำหรับดูและจัดการ Routing Cache แต่เมื่อสามารถปิดใช้งานได้ใน [IP]->[Settings].

กลไกนี้ถูกลบออกจากเคอร์เนล linux 3.6 แต่ RouterOS ยังคงใช้เคอร์เนล 3.3.5 บางที Routing cahce อาจเป็นสาเหตุหนึ่ง

เพิ่มกล่องโต้ตอบเส้นทาง

[IP]->[Route]->[+]

1. Subnet ที่คุณต้องการสร้างเส้นทาง (ค่าเริ่มต้น: 0.0.0.0/0)
2. IP ของเกตเวย์หรืออินเทอร์เฟซที่จะส่งแพ็กเก็ต (อาจมีหลายรายการ ดู ECMP ด้านล่าง)
3. ตรวจสอบความพร้อมใช้งานของเกตเวย์
4. ประเภทบันทึก
5. ระยะทาง (เมตริก) สำหรับเส้นทาง
6. ตารางเส้นทาง
7. IP สำหรับแพ็กเก็ตขาออกในเครื่องผ่านเส้นทางนี้
8. วัตถุประสงค์ของ Scope และ Target Scope เขียนไว้ท้ายบทความ

ธงประจำเส้นทาง

• X - เส้นทางถูกปิดใช้งานโดยผู้ดูแลระบบ (disabled=yes)
• A - เส้นทางที่ใช้ในการส่งแพ็กเก็ต
• D - เพิ่มเส้นทางแบบไดนามิก (BGP, OSPF, RIP, MME, PPP, DHCP, Connected)
• C - ซับเน็ตเชื่อมต่อโดยตรงกับเราเตอร์
• S - เส้นทางคงที่
• r,b,o,m - เพิ่มเส้นทางโดยหนึ่งในโปรโตคอลการกำหนดเส้นทางแบบไดนามิก
• B,U,P - เส้นทางการกรอง (ปล่อยแพ็กเก็ตแทนการส่ง)

สิ่งที่ต้องระบุในเกตเวย์: ที่อยู่ IP หรืออินเทอร์เฟซ

ระบบอนุญาตให้คุณระบุทั้งสองอย่างในขณะที่ไม่สาบานและไม่ให้คำแนะนำหากคุณทำอะไรผิด

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

อินเตอร์เฟซ
ทุกอย่างซับซ้อนกว่าและพฤติกรรมของเราเตอร์ขึ้นอยู่กับประเภทของอินเทอร์เฟซ:

• การเชื่อมต่อ PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) จะถือว่ามีผู้เข้าร่วมเพียงสองคนเท่านั้น และแพ็กเก็ตจะถูกส่งไปยังเกตเวย์เพื่อส่งเสมอ หากเกตเวย์ตรวจพบว่าผู้รับคือตัวมันเอง ก็จะโอนแพ็กเก็ตไปยัง กระบวนการในท้องถิ่น
  
• อีเธอร์เน็ตถือว่ามีผู้เข้าร่วมจำนวนมากและจะส่งคำขอไปยังอินเทอร์เฟซ arp พร้อมที่อยู่ของผู้รับแพ็กเก็ต ซึ่งเป็นพฤติกรรมที่คาดหวังและค่อนข้างปกติสำหรับเส้นทางที่เชื่อมต่อ
  แต่เมื่อคุณพยายามใช้อินเทอร์เฟซเป็นเส้นทางสำหรับเครือข่ายย่อยระยะไกล คุณจะได้รับสถานการณ์ต่อไปนี้: เส้นทางทำงานอยู่ ping ไปยังเกตเวย์ผ่าน แต่ไม่ถึงผู้รับจากเครือข่ายย่อยที่ระบุ หากคุณดูอินเทอร์เฟซผ่าน sniffer คุณจะเห็นคำขอ arp พร้อมที่อยู่จากเครือข่ายย่อยระยะไกล
  

พยายามระบุที่อยู่ IP เป็นเกตเวย์ทุกครั้งที่ทำได้ ข้อยกเว้นคือเส้นทางที่เชื่อมต่อ (สร้างขึ้นโดยอัตโนมัติ) และอินเทอร์เฟซ PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*)

OpenVPN ไม่มีส่วนหัว PPP แต่คุณสามารถใช้ชื่ออินเทอร์เฟซ OpenVPN เพื่อสร้างเส้นทางได้

เส้นทางที่เฉพาะเจาะจงมากขึ้น

กฎการกำหนดเส้นทางพื้นฐาน เส้นทางที่อธิบายเครือข่ายย่อยที่เล็กกว่า (โดยมีซับเน็ตมาสก์ที่ใหญ่ที่สุด) จะมีความสำคัญเหนือกว่าในการตัดสินใจกำหนดเส้นทางของแพ็กเก็ต ตำแหน่งของรายการในตารางเส้นทางไม่เกี่ยวข้องกับตัวเลือก - กฎหลักมีความเฉพาะเจาะจงมากขึ้น

เส้นทางทั้งหมดจากรูปแบบที่ระบุใช้งานได้ (อยู่ใน FIB) ชี้ไปยังเครือข่ายย่อยที่แตกต่างกันและไม่ขัดแย้งกัน

หากหนึ่งในเกตเวย์ใช้งานไม่ได้ เส้นทางที่เกี่ยวข้องจะถือว่าไม่ได้ใช้งาน (ลบออกจาก FIB) และแพ็กเก็ตจะถูกค้นหาจากเส้นทางที่เหลือ

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

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

การเข้าใจเส้นทางที่เฉพาะเจาะจงมากขึ้นเป็นพื้นฐานของอุปกรณ์ TCP/IP ใดๆ

ระยะทาง

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

หากมีหลายเส้นทางไปยังเครือข่ายย่อยเดียวกันที่มีเมตริกเดียวกัน เราเตอร์จะเพิ่มเพียงเส้นทางเดียวในตาราง FIB ซึ่งนำทางโดยตรรกะภายใน

เมตริกสามารถรับค่าได้ตั้งแต่ 0 ถึง 255:

• 0 - เมตริกสำหรับเส้นทางที่เชื่อมต่อ ผู้ดูแลระบบไม่สามารถตั้งค่าระยะทาง 0 ได้
• 1-254 - เมตริกสำหรับผู้ดูแลระบบสำหรับการตั้งค่าเส้นทาง เมตริกที่มีค่าต่ำกว่าจะมีลำดับความสำคัญสูงกว่า
• 255 - เมตริกสำหรับผู้ดูแลระบบในการตั้งค่าเส้นทาง ซึ่งแตกต่างจาก 1-254 เส้นทางที่มีเมตริก 255 จะยังคงใช้งานไม่ได้และไม่ตกอยู่ใน FIB
• เมตริกเฉพาะ เส้นทางที่ได้รับจากโปรโตคอลการกำหนดเส้นทางแบบไดนามิกมีค่าเมตริกมาตรฐาน

ตรวจสอบเกตเวย์

ตรวจสอบเกตเวย์เป็นส่วนเสริมของ MikroTik RoutesOS สำหรับตรวจสอบความพร้อมใช้งานของเกตเวย์ผ่าน icmp หรือ arp ทุกๆ 10 วินาที (ไม่สามารถเปลี่ยนแปลงได้) คำขอจะถูกส่งไปยังเกตเวย์ หากไม่ได้รับการตอบกลับสองครั้ง จะถือว่าเส้นทางไม่พร้อมใช้งานและถูกลบออกจาก FIB หากเกตเวย์การตรวจสอบปิดใช้งาน เส้นทางการตรวจสอบจะดำเนินต่อไป และเส้นทางจะเปิดใช้งานอีกครั้งหลังจากตรวจสอบสำเร็จหนึ่งครั้ง

ตรวจสอบเกตเวย์จะปิดใช้งานรายการที่มีการกำหนดค่าและรายการอื่นๆ ทั้งหมด (ในตารางเส้นทางและเส้นทาง ecmp ทั้งหมด) ด้วยเกตเวย์ที่ระบุ

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

VPN และโปรโตคอลทันเนลส่วนใหญ่มีเครื่องมือในตัวสำหรับตรวจสอบกิจกรรมการเชื่อมต่อ การเปิดใช้งานการตรวจสอบเกตเวย์สำหรับสิ่งเหล่านี้เป็นการโหลดเพิ่มเติม (แต่น้อยมาก) ในประสิทธิภาพของเครือข่ายและอุปกรณ์

เส้นทาง ECMP

Equal-Cost Multi-Path - การส่งแพ็กเก็ตไปยังผู้รับโดยใช้หลายเกตเวย์พร้อมกันโดยใช้อัลกอริธึม Round Robin

ผู้ดูแลระบบสร้างเส้นทาง ECMP โดยการระบุหลายเกตเวย์สำหรับเครือข่ายย่อยหนึ่งเครือข่าย (หรือโดยอัตโนมัติ หากมีเส้นทาง OSPF ที่เทียบเท่ากันสองเส้นทาง)

ECMP ใช้สำหรับโหลดบาลานซ์ระหว่างสองแชนเนล ตามทฤษฎีแล้ว หากมีสองแชนเนลในเส้นทาง ecmp ดังนั้นแชนเนลขาออกสำหรับแต่ละแพ็กเก็ตควรแตกต่างกัน แต่กลไกแคชการกำหนดเส้นทางจะส่งแพ็กเก็ตจากการเชื่อมต่อไปตามเส้นทางที่แพ็กเก็ตแรกใช้ ด้วยเหตุนี้ เราจึงได้รับการปรับสมดุลตามการเชื่อมต่อ (การปรับสมดุลการโหลดต่อการเชื่อมต่อ)

หากคุณปิดใช้งาน Routing Cache แพ็กเก็ตในเส้นทาง ECMP จะถูกแชร์อย่างถูกต้อง แต่มีปัญหากับ NAT กฎ NAT ประมวลผลเฉพาะแพ็กเก็ตแรกจากการเชื่อมต่อ (ส่วนที่เหลือจะถูกประมวลผลโดยอัตโนมัติ) และกลายเป็นว่าแพ็กเก็ตที่มีที่อยู่ต้นทางเดียวกันออกจากอินเทอร์เฟซที่แตกต่างกัน

ตรวจสอบเกตเวย์ไม่ทำงานในเส้นทาง ECMP (บั๊กของ RouterOS) แต่คุณสามารถหลีกเลี่ยงข้อจำกัดนี้ได้โดยสร้างเส้นทางการตรวจสอบเพิ่มเติมที่จะปิดใช้งานรายการใน ECMP

การกรองด้วยวิธีการกำหนดเส้นทาง

ตัวเลือก Type กำหนดสิ่งที่ต้องทำกับแพ็คเกจ:

• unicast - ส่งไปยังเกตเวย์ที่ระบุ (อินเทอร์เฟซ)
• หลุมดำ - ทิ้งแพ็กเก็ต
• ห้ามไม่สามารถเข้าถึงได้ - ละทิ้งแพ็กเก็ตและส่งข้อความ icmp ไปยังผู้ส่ง

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

สองสามตัวอย่าง

เพื่อรวบรวมสิ่งพื้นฐานเกี่ยวกับการกำหนดเส้นทาง

เราเตอร์ตามบ้านทั่วไป

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. เส้นทางคงที่ไปที่ 0.0.0.0/0 (เส้นทางเริ่มต้น)
2. เส้นทางเชื่อมต่อบนอินเทอร์เฟซกับผู้ให้บริการ
3. เส้นทางเชื่อมต่อบนอินเทอร์เฟซ LAN

เราเตอร์ตามบ้านทั่วไปที่มี PPPoE

1. เส้นทางคงที่ไปยังเส้นทางเริ่มต้น เพิ่มโดยอัตโนมัติ มีการระบุไว้ในคุณสมบัติการเชื่อมต่อ
2. เส้นทางเชื่อมต่อสำหรับการเชื่อมต่อ PPP
3. เส้นทางเชื่อมต่อบนอินเทอร์เฟซ LAN

เราเตอร์ตามบ้านทั่วไปที่มีสองผู้ให้บริการและความซ้ำซ้อน

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. เส้นทางคงที่ไปยังเส้นทางเริ่มต้นผ่านผู้ให้บริการรายแรกที่มีการตรวจสอบความพร้อมใช้งานของเมตริก 1 และเกตเวย์
2. เส้นทางคงที่ไปยังเส้นทางเริ่มต้นผ่านผู้ให้บริการรายที่สองพร้อมเมตริก 2
3. เส้นทางที่เชื่อมต่อ

การรับส่งข้อมูลไปยัง 0.0.0.0/0 ต้องผ่าน 10.10.10.1 ในขณะที่เกตเวย์นี้ใช้งานได้ มิฉะนั้นจะเปลี่ยนเป็น 10.20.20.1

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

เราเตอร์ตามบ้านทั่วไปที่มีผู้ให้บริการสองราย ความซ้ำซ้อนและ ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. เส้นทางคงที่สำหรับการตรวจสอบเกตเวย์การแฮ็ก
2. เส้นทาง ECMP
3. เส้นทางที่เชื่อมต่อ

เส้นทางที่จะตรวจสอบเป็นสีน้ำเงิน (สีของเส้นทางที่ไม่ได้ใช้งาน) แต่จะไม่รบกวนการตรวจสอบเกตเวย์ RoS เวอร์ชันปัจจุบัน (6.44) ให้ความสำคัญกับเส้นทาง ECMP โดยอัตโนมัติ แต่จะเป็นการดีกว่าหากเพิ่มเส้นทางทดสอบไปยังตารางเส้นทางอื่นๆ (ตัวเลือก routing-mark)

บน Speedtest และไซต์อื่นๆ ที่คล้ายกัน จะไม่มีการเพิ่มความเร็ว (ECMP แบ่งทราฟฟิกตามการเชื่อมต่อ ไม่ใช่ตามแพ็กเก็ต) แต่แอปพลิเคชัน p2p ควรดาวน์โหลดเร็วขึ้น

การกรองผ่านการกำหนดเส้นทาง

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. เส้นทางคงที่ไปยังเส้นทางเริ่มต้น
2. เส้นทางคงที่ไปยัง 192.168.200.0/24 ผ่านอุโมงค์ ipip
3. ห้ามเส้นทางคงที่ไปยัง 192.168.200.0/24 ผ่านเราเตอร์ ISP

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

เส้นทางวนรอบ
Routing loop - สถานการณ์เมื่อแพ็กเก็ตทำงานระหว่างเราเตอร์ก่อนที่ ttl จะหมดอายุ โดยปกติแล้วเป็นผลมาจากข้อผิดพลาดในการกำหนดค่าในเครือข่ายขนาดใหญ่จะได้รับการปฏิบัติโดยการนำโปรโตคอลการกำหนดเส้นทางแบบไดนามิกไปใช้ในเครือข่ายขนาดเล็กด้วยความระมัดระวัง

ดูเหมือนว่านี้:

ตัวอย่าง (ง่ายที่สุด) ของวิธีรับผลลัพธ์ที่คล้ายกัน:

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

การกำหนดเส้นทางฐานนโยบายและตารางการกำหนดเส้นทางเพิ่มเติม

เมื่อเลือกเส้นทาง เราเตอร์จะใช้เพียงฟิลด์เดียวจากส่วนหัวของแพ็กเก็ต (ที่อยู่ Dst.) ซึ่งเป็นการกำหนดเส้นทางพื้นฐาน การกำหนดเส้นทางตามเงื่อนไขอื่นๆ เช่น ที่อยู่ต้นทาง ประเภทของการรับส่งข้อมูล (ToS) การปรับสมดุลโดยไม่มี ECMP เป็นของ Policy Base Routing (PBR) และใช้ตารางการกำหนดเส้นทางเพิ่มเติม

เส้นทางที่เฉพาะเจาะจงมากขึ้น เป็นกฎการเลือกเส้นทางหลักภายในตารางเส้นทาง

ตามค่าเริ่มต้น กฎการกำหนดเส้นทางทั้งหมดจะถูกเพิ่มลงในตารางหลัก ผู้ดูแลระบบสามารถสร้างตารางเส้นทางเพิ่มเติมและแพ็กเก็ตเส้นทางเพิ่มเติมได้โดยพลการ กฎในตารางต่างๆ จะไม่ขัดแย้งกัน หากแพ็คเกจไม่พบกฎที่เหมาะสมในตารางที่ระบุ แพ็คเกจนั้นจะไปที่ตารางหลัก

ตัวอย่างที่มีการแจกจ่ายผ่านไฟร์วอลล์:

• 192.168.100.10 -> 8.8.8.8
  1. การรับส่งข้อมูลจาก 192.168.100.10 ได้รับการติดป้ายกำกับ ผ่าน-isp1 в [Prerouting|Mangle]
  2. ที่ขั้นตอนการกำหนดเส้นทางในตาราง ผ่าน-isp1 ค้นหาเส้นทางไปยัง 8.8.8.8
  3. พบเส้นทาง การจราจรถูกส่งไปยังเกตเวย์ 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. การรับส่งข้อมูลจาก 192.168.200.20 ได้รับการติดป้ายกำกับ ผ่าน-isp2 в [Prerouting|Mangle]
  2. ที่ขั้นตอนการกำหนดเส้นทางในตาราง ผ่าน-isp2 ค้นหาเส้นทางไปยัง 8.8.8.8
  3. พบเส้นทาง การจราจรถูกส่งไปยังเกตเวย์ 10.20.20.1
• หากหนึ่งในเกตเวย์ (10.10.10.1 หรือ 10.20.20.1) ไม่สามารถใช้งานได้ แพ็กเก็ตจะไปที่ตาราง หลัก และจะมองหาเส้นทางที่เหมาะสมที่นั่น

ปัญหาคำศัพท์

RouterOS มีปัญหาเกี่ยวกับคำศัพท์บางอย่าง
เมื่อทำงานกับกฎใน [IP]->[Routes] มีการระบุตารางเส้นทางแม้ว่าจะเขียนว่าป้ายกำกับ:

В [IP]->[Routes]->[Rule] ทุกอย่างถูกต้องในเงื่อนไขป้ายกำกับในการดำเนินการตาราง:

วิธีส่งแพ็คเก็ตไปยังตารางเส้นทางเฉพาะ

RouterOS มีเครื่องมือหลายอย่าง:

• กฎใน [IP]->[Routes]->[Rules]
• ป้ายบอกเส้นทาง (action=mark-routing) ใน [IP]->[Firewall]->[Mangle]
• วีอาร์เอฟ

กฎระเบียบ [IP]->[Route]->[Rules]
กฎจะถูกประมวลผลตามลำดับ หากแพ็กเก็ตตรงกับเงื่อนไขของกฎ ก็จะไม่ผ่านต่อไป

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

กฎประกอบด้วยเงื่อนไขและการกระทำ:

• เงื่อนไข. ทำซ้ำรายการสัญญาณที่มีการตรวจสอบแพ็คเกจใน FIB ซ้ำโดยมีเพียง ToS เท่านั้นที่ขาดหายไป
• กิจกรรม
  • ค้นหา - ส่งแพ็คเก็ตไปที่ตาราง
  • ค้นหาเฉพาะในตาราง - ล็อคแพ็คเกจในตารางหากไม่พบเส้นทางแพ็คเกจจะไม่ไปที่ตารางหลัก
  • วาง - วางแพ็คเก็ต
  • ไม่สามารถเข้าถึงได้ - ละทิ้งแพ็กเก็ตที่มีการแจ้งเตือนจากผู้ส่ง

ใน FIB ทราฟฟิกไปยังกระบวนการโลคัลจะถูกประมวลผลโดยไม่ผ่านกฎ [IP]->[Route]->[Rules]:

เครื่องหมาย [IP]->[Firewall]->[Mangle]
ป้ายกำกับการกำหนดเส้นทางช่วยให้คุณสามารถตั้งค่าเกตเวย์สำหรับแพ็กเก็ตโดยใช้เงื่อนไขไฟร์วอลล์เกือบทุกชนิด:

ในทางปฏิบัติ เนื่องจากไม่ใช่ทั้งหมดที่เหมาะสม และบางส่วนอาจทำงานไม่เสถียร

มีสองวิธีในการติดฉลากบรรจุภัณฑ์:

• ใส่ทันที เครื่องหมายบอกเส้นทาง
• ใส่ก่อน เครื่องหมายการเชื่อมต่อแล้วขึ้นอยู่กับ เครื่องหมายการเชื่อมต่อ ที่จะนำ เครื่องหมายบอกเส้นทาง

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

ตัวอย่างการใช้งาน

มาดูตัวอย่างการใช้ Policy Base Routing กัน ซึ่งง่ายกว่ามากในการแสดงว่าเหตุใดจึงจำเป็นต้องใช้ทั้งหมดนี้

MultiWAN และส่งคืนทราฟฟิกขาออก (Output)
ปัญหาทั่วไปเกี่ยวกับการกำหนดค่า MultiWAN: Mikrotik พร้อมใช้งานจากอินเทอร์เน็ตผ่านผู้ให้บริการที่ "ใช้งานอยู่" เท่านั้น

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

อีกประเด็นที่น่าสนใจ หากมีการกำหนดค่า nat ต้นทาง "แบบง่าย" บนอินเทอร์เฟซ ether1: /ip fi nat add out-interface=ether1 action=masquerade แพ็คเกจจะออนไลน์ด้วย src. address=10.10.10.100 ซึ่งทำให้ทุกอย่างแย่ลงไปอีก

มีหลายวิธีในการแก้ไขปัญหา แต่วิธีใดวิธีหนึ่งจะต้องใช้ตารางเส้นทางเพิ่มเติม:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

ใช้ [IP]->[Route]->[Rules]
ระบุตารางเส้นทางที่จะใช้สำหรับแพ็กเก็ตที่มี IP ต้นทางที่ระบุ

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

สามารถใช้ action=lookupแต่สำหรับการรับส่งข้อมูลขาออกภายในเครื่อง ตัวเลือกนี้จะไม่รวมการเชื่อมต่อจากอินเทอร์เฟซที่ไม่ถูกต้องโดยสิ้นเชิง

• ระบบสร้างแพ็กเก็ตตอบกลับด้วย Src ที่อยู่: 10.20.20.200
• ตรวจสอบขั้นตอนการตัดสินใจกำหนดเส้นทาง (2) [IP]->[Routes]->[Rules] และแพ็คเก็ตจะถูกส่งไปยังตารางเส้นทาง over-isp2
• ตามตารางเส้นทาง แพ็กเก็ตจะต้องถูกส่งไปยังเกตเวย์ 10.20.20.1 ผ่านอินเทอร์เฟซ ether2

วิธีนี้ไม่จำเป็นต้องใช้ Connection Tracker ซึ่งแตกต่างจากการใช้ตาราง Mangle

ใช้ [IP]->[Firewall]->[Mangle]
การเชื่อมต่อเริ่มต้นด้วยแพ็คเก็ตขาเข้า ดังนั้นเราจึงทำเครื่องหมาย (action=mark-connection) สำหรับแพ็กเก็ตขาออกจากการเชื่อมต่อที่ทำเครื่องหมายไว้ ให้ตั้งค่าป้ายกำกับการกำหนดเส้นทาง (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

หากมีการกำหนดค่าหลาย ips บนอินเทอร์เฟซเดียว คุณสามารถเพิ่มเงื่อนไขได้ dst-address เพื่อให้แน่ใจว่า.

• แพ็กเก็ตเปิดการเชื่อมต่อบนอินเทอร์เฟซ ether2 แพคเกจเข้าสู่ [INPUT|Mangle] ซึ่งระบุว่าให้ทำเครื่องหมายแพ็กเก็ตทั้งหมดจากการเชื่อมต่อเป็น จาก-isp2
• ระบบสร้างแพ็กเก็ตตอบกลับด้วย Src ที่อยู่: 10.20.20.200
• ในขั้นตอน Routing Decision(2) แพ็กเก็ตตามตารางเส้นทางจะถูกส่งไปยังเกตเวย์ 10.20.20.1 ผ่านอินเทอร์เฟซ ether1 คุณสามารถตรวจสอบได้โดยเข้าสู่ระบบแพ็คเกจ [OUTPUT|Filter]
• ที่เวที [OUTPUT|Mangle] มีการตรวจสอบฉลากการเชื่อมต่อ จาก-isp2 และแพ็กเก็ตจะได้รับป้ายกำกับเส้นทาง over-isp2
• ขั้นตอนการปรับการกำหนดเส้นทาง (3) ตรวจสอบว่ามีป้ายกำกับการกำหนดเส้นทางหรือไม่ และส่งไปยังตารางกำหนดเส้นทางที่เหมาะสม
• ตามตารางเส้นทาง แพ็กเก็ตจะต้องถูกส่งไปยังเกตเวย์ 10.20.20.1 ผ่านอินเทอร์เฟซ ether2

MultiWAN และส่งคืนทราฟฟิก dst-nat

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

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

สาระสำคัญของปัญหาจะเหมือนกัน วิธีแก้ปัญหาคล้ายกับตัวเลือก Firewall Mangle จะใช้เชนอื่นเท่านั้น:

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

แผนภาพไม่แสดง NAT แต่ฉันคิดว่าทุกอย่างชัดเจน

MultiWAN และการเชื่อมต่อขาออก

คุณสามารถใช้ความสามารถของ PBR เพื่อสร้างการเชื่อมต่อ VPN (SSTP ในตัวอย่าง) หลายรายการจากอินเทอร์เฟซเราเตอร์ที่แตกต่างกัน

ตารางเส้นทางเพิ่มเติม:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

เครื่องหมายบรรจุภัณฑ์:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

กฎ NAT อย่างง่าย มิฉะนั้นแพ็กเก็ตจะปล่อยให้อินเทอร์เฟซมี Src ที่ไม่ถูกต้อง ที่อยู่:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

การแยกวิเคราะห์:

• เราเตอร์สร้างกระบวนการ SSTP สามกระบวนการ
• ในขั้นตอนการตัดสินใจกำหนดเส้นทาง (2) เส้นทางจะถูกเลือกสำหรับกระบวนการเหล่านี้ตามตารางเส้นทางหลัก จากเส้นทางเดียวกัน แพ็กเก็ตจะได้รับ Src ที่อยู่ที่เชื่อมโยงกับอินเทอร์เฟซ ether1
• В [Output|Mangle] แพ็กเก็ตจากการเชื่อมต่อที่แตกต่างกันจะได้รับฉลากที่แตกต่างกัน
• แพ็กเก็ตเข้าสู่ตารางที่ตรงกับเลเบลในขั้นการปรับการกำหนดเส้นทาง และรับเส้นทางใหม่สำหรับการส่งแพ็กเก็ต
• แต่แพ็คเกจยังมี Src. ที่อยู่จาก ether1 บนเวที [Nat|Srcnat] ที่อยู่จะถูกแทนที่ตามอินเทอร์เฟซ

น่าสนใจบนเราเตอร์คุณจะเห็นตารางการเชื่อมต่อต่อไปนี้:

ตัวติดตามการเชื่อมต่อใช้งานได้ก่อนหน้านี้ [Mangle] и [Srcnat]ดังนั้นการเชื่อมต่อทั้งหมดจึงมาจากที่อยู่เดียวกัน หากคุณดูรายละเอียดเพิ่มเติม Replay Dst. Address จะมีที่อยู่หลังจาก NAT:

บนเซิร์ฟเวอร์ VPN (ฉันมีบนม้านั่งทดสอบ) คุณจะเห็นว่าการเชื่อมต่อทั้งหมดมาจากที่อยู่ที่ถูกต้อง:

คอยตามทาง
มีวิธีที่ง่ายกว่า คุณสามารถระบุเกตเวย์เฉพาะสำหรับแต่ละที่อยู่:

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

แต่เส้นทางดังกล่าวจะส่งผลกระทบต่อการจราจรขาออกไม่เพียง นอกจากนี้ หากคุณไม่ต้องการการรับส่งข้อมูลไปยังเซิร์ฟเวอร์ VPN เพื่อผ่านช่องทางการสื่อสารที่ไม่เหมาะสม คุณจะต้องเพิ่มกฎอีก 6 ข้อใน [IP]->[Routes]с type=blackhole. ในเวอร์ชันก่อนหน้า - กฎ 3 ข้อใน [IP]->[Route]->[Rules].

การกระจายการเชื่อมต่อของผู้ใช้ตามช่องทางการสื่อสาร

งานง่ายๆ ในชีวิตประจำวัน อีกครั้ง จำเป็นต้องใช้ตารางเส้นทางเพิ่มเติม:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

การใช้ [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

หากใช้งาน action=lookupจากนั้นเมื่อปิดใช้งานช่องทางใดช่องทางหนึ่งการรับส่งข้อมูลจะไปที่ตารางหลักและผ่านช่องทางที่ใช้งานได้ จำเป็นหรือไม่ขึ้นอยู่กับงาน

การใช้เครื่องหมายใน [IP]->[Firewall]->[Mangle]
ตัวอย่างง่ายๆ ด้วยรายการที่อยู่ IP โดยหลักการแล้วสามารถใช้เงื่อนไขได้เกือบทุกอย่าง คำเตือนเพียงข้อเดียวของเลเยอร์ 7 แม้ว่าเมื่อจับคู่กับป้ายกำกับการเชื่อมต่อแล้ว อาจดูเหมือนว่าทุกอย่างทำงานได้อย่างถูกต้อง แต่การรับส่งข้อมูลบางส่วนจะยังคงไปผิดทาง

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

คุณสามารถ "ล็อก" ผู้ใช้ในตารางเส้นทางเดียวได้ [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

ไม่ว่าจะผ่าน [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

ถอยโปร dst-address-type=!local
เงื่อนไขเพิ่มเติม dst-address-type=!local จำเป็นที่การรับส่งข้อมูลจากผู้ใช้จะไปถึงกระบวนการในเครื่องของเราเตอร์ (dns, winbox, ssh, ...) หากเครือข่ายย่อยหลายเครือข่ายเชื่อมต่อกับเราเตอร์ จำเป็นต้องตรวจสอบให้แน่ใจว่าทราฟฟิกระหว่างเครือข่ายเหล่านั้นไม่ได้ไปที่อินเทอร์เน็ต เช่น การใช้ dst-address-table.

ในตัวอย่างโดยใช้ [IP]->[Route]->[Rules] ไม่มีข้อยกเว้นดังกล่าว แต่ทราฟฟิกเข้าถึงกระบวนการในเครื่อง ความจริงก็คือการเข้าสู่แพ็คเกจ FIB ที่ทำเครื่องหมายไว้ [PREROUTING|Mangle] มีป้ายชื่อเส้นทางและเข้าสู่ตารางเส้นทางอื่นที่ไม่ใช่หลักซึ่งไม่มีส่วนต่อประสานในเครื่อง ในกรณีของกฎการกำหนดเส้นทาง ขั้นแรกให้ตรวจสอบว่าแพ็กเก็ตมีไว้สำหรับกระบวนการในเครื่องหรือไม่ และเฉพาะที่ขั้นตอน User PBR เท่านั้นที่จะไปที่ตารางเส้นทางที่ระบุ

การใช้ [IP]->[Firewall]->[Mangle action=route]
การกระทำนี้ใช้ได้เฉพาะใน [Prerouting|Mangle] และอนุญาตให้คุณกำหนดทิศทางการรับส่งข้อมูลไปยังเกตเวย์ที่ระบุโดยไม่ต้องใช้ตารางเส้นทางเพิ่มเติม โดยระบุที่อยู่เกตเวย์โดยตรง:

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

การกระทำ route มีลำดับความสำคัญต่ำกว่ากฎการกำหนดเส้นทาง ([IP]->[Route]->[Rules]). ในกรณีของเครื่องหมายเส้นทาง ทุกอย่างขึ้นอยู่กับตำแหน่งของกฎ ถ้ากฎด้วย action=route คุ้มกว่า action=mark-routeแล้วมันจะถูกนำไปใช้ (โดยไม่คำนึงถึงแฟล็ก passtrough) มิฉะนั้นจะทำเครื่องหมายเส้นทาง
มีข้อมูลน้อยมากในวิกิเกี่ยวกับการดำเนินการนี้ และข้อสรุปทั้งหมดได้รับจากการทดลอง ไม่ว่าในกรณีใด ฉันไม่พบตัวเลือกเมื่อใช้ตัวเลือกนี้ให้ข้อได้เปรียบเหนือตัวเลือกอื่นๆ

การปรับสมดุลไดนามิกตาม PPC

Per Connection Classifier - เป็นอะนาล็อกที่ยืดหยุ่นกว่าของ ECMP ซึ่งแตกต่างจาก ECMP โดยจะแบ่งทราฟฟิกตามการเชื่อมต่ออย่างเข้มงวดกว่า (ECMP ไม่รู้อะไรเลยเกี่ยวกับการเชื่อมต่อ แต่เมื่อจับคู่กับ Routing Cache จะได้สิ่งที่คล้ายกัน)

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

ตัวอย่างที่มีสามที่อยู่:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

ตัวอย่างของการกระจายการรับส่งข้อมูลแบบไดนามิกโดย src.address ระหว่างสามช่อง:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

เมื่อทำเครื่องหมายเส้นทางมีเงื่อนไขเพิ่มเติม: in-interface=br-lanโดยไม่ต้องอยู่ภายใต้ action=mark-routing ทราฟฟิกการตอบสนองจากอินเทอร์เน็ตจะเข้ามาและตามตารางเส้นทางจะกลับไปที่ผู้ให้บริการ

การเปลี่ยนช่องทางการติดต่อสื่อสาร

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

โดยทั่วไปแล้วจะใช้สคริปต์เพื่อตรวจสอบความพร้อมใช้งานของที่อยู่ IP บนอินเทอร์เน็ตผ่านช่องทางการสื่อสารบางช่องทางในขณะที่เลือกสิ่งที่น่าเชื่อถือเช่น google dns: 8.8.8.8 8.8.4.4. แต่ในชุมชน Mikrotik มีการดัดแปลงเครื่องมือที่น่าสนใจกว่านี้

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

ถึงเวลาทำความเข้าใจตัวเลือกขอบเขต / ขอบเขตเป้าหมายในข้อกำหนดทั่วไปและวิธีเชื่อมโยงเส้นทางกับอินเทอร์เฟซ:

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

เมื่อมีเส้นทางวนซ้ำ ทุกอย่างจะเกิดขึ้นเหมือนเดิม แต่ในสองขั้นตอน:

• 1-3 เพิ่มอีกหนึ่งเส้นทางในเส้นทางที่เชื่อมต่อ ซึ่งสามารถเข้าถึงเกตเวย์ที่ระบุได้
• 4-6 ค้นหาเส้นทางที่เชื่อมต่อกับเกตเวย์ "กลาง"

การปรับเปลี่ยนทั้งหมดด้วยการค้นหาแบบเรียกซ้ำเกิดขึ้นใน RIB และเฉพาะผลลัพธ์สุดท้ายเท่านั้นที่โอนไปยัง FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

ตัวอย่างของการใช้ recursive routing เพื่อสลับเส้นทาง

การกำหนดค่า:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

คุณสามารถตรวจสอบว่าแพ็คเก็ตจะถูกส่งไปยัง 10.10.10.1:

ตรวจสอบเกตเวย์ไม่รู้เรื่องการกำหนดเส้นทางแบบเรียกซ้ำและเพียงแค่ส่ง ping ไปยังที่อยู่ 8.8.8.8 ซึ่ง (ตามตารางหลัก) สามารถเข้าถึงได้ผ่านเกตเวย์ 10.10.10.1

หากสูญเสียการสื่อสารระหว่าง 10.10.10.1 และ 8.8.8.8 เส้นทางจะถูกตัดการเชื่อมต่อ แต่แพ็กเก็ต (รวมถึงการทดสอบ ping) ไปยัง 8.8.8.8 จะดำเนินต่อไปจนถึง 10.10.10.1:

หากลิงก์ไปยัง ether1 หายไป สถานการณ์ที่ไม่พึงประสงค์เกิดขึ้นเมื่อแพ็กเก็ตก่อน 8.8.8.8 ผ่านผู้ให้บริการรายที่สอง:

นี่เป็นปัญหาหากคุณใช้ NetWatch เพื่อเรียกใช้สคริปต์เมื่อ 8.8.8.8 ไม่พร้อมใช้งาน หากลิงก์เสีย NetWatch จะทำงานผ่านช่องทางการสื่อสารสำรองและถือว่าทุกอย่างปกติดี แก้ไขได้โดยการเพิ่มเส้นทางตัวกรองเพิ่มเติม:

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

มีอยู่ในhabré บทความซึ่งจะพิจารณาสถานการณ์กับ NetWatch ในรายละเอียดเพิ่มเติม

และใช่ เมื่อใช้การจองดังกล่าว ที่อยู่ 8.8.8.8 จะถูกเดินสายไปยังหนึ่งในผู้ให้บริการ ดังนั้นการเลือกเป็นแหล่งข้อมูล DNS จึงไม่ใช่ความคิดที่ดี

คำสองสามคำเกี่ยวกับการกำหนดเส้นทางและการส่งต่อเสมือน (VRF)

เทคโนโลยี VRF ได้รับการออกแบบมาเพื่อสร้างเราเตอร์เสมือนหลายตัวภายในเครื่องเดียว เทคโนโลยีนี้ใช้กันอย่างแพร่หลายโดยผู้ให้บริการโทรคมนาคม (มักจะใช้ร่วมกับ MPLS) เพื่อให้บริการ L3VPN แก่ลูกค้าที่มีซับเน็ตแอดเดรสทับซ้อนกัน:

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

ตัวอย่างการกำหนดค่า vrf:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

จากอุปกรณ์ที่เชื่อมต่อกับ ether2 เราจะเห็นว่า ping ไปที่ที่อยู่เราเตอร์จาก vrf อื่น (และนี่เป็นปัญหา) ในขณะที่ ping ไม่ได้ไปที่อินเทอร์เน็ต:

ในการเข้าถึงอินเทอร์เน็ต คุณต้องลงทะเบียนเส้นทางเพิ่มเติมที่เข้าถึงตารางหลัก (ในศัพท์เฉพาะของ vrf นี่เรียกว่าการรั่วไหลของเส้นทาง):

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

การรั่วไหลของเส้นทางมี XNUMX วิธี: การใช้ตารางเส้นทาง: 172.17.0.1@main และใช้ชื่ออินเทอร์เฟซ: 172.17.0.1%wlan1.

และกำหนดจุดกลับรถเข้า-ออก [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

เครือข่ายย่อยที่มีที่อยู่เดียวกัน
การจัดระเบียบการเข้าถึงเครือข่ายย่อยที่มีที่อยู่เดียวกันบนเราเตอร์เดียวกันโดยใช้ VRF และ netmap:

การกำหนดค่าพื้นฐาน:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

กฎไฟร์วอลล์:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

กฎการกำหนดเส้นทางสำหรับการรับส่งข้อมูลขากลับ:

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

การเพิ่มเส้นทางที่ได้รับผ่าน dhcp ไปยังตารางเส้นทางที่กำหนด
VRF อาจน่าสนใจหากคุณต้องการเพิ่มเส้นทางแบบไดนามิกโดยอัตโนมัติ (เช่น จากไคลเอนต์ dhcp) ไปยังตารางเส้นทางเฉพาะ

การเพิ่มส่วนต่อประสานกับ vrf:

/ip route vrf
add interface=ether1 routing-mark=over-isp1

กฎสำหรับการส่งทราฟฟิก (ขาออกและขนส่ง) ผ่านตาราง over-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

เส้นทางปลอมเพิ่มเติมสำหรับการกำหนดเส้นทางขาออกไปทำงาน:

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

เส้นทางนี้จำเป็นเท่านั้นเพื่อให้แพ็กเก็ตขาออกในเครื่องสามารถผ่านการตัดสินใจกำหนดเส้นทาง (2) ก่อนหน้านี้ได้ [OUTPUT|Mangle] และรับป้ายกำกับการกำหนดเส้นทาง หากมีเส้นทางอื่นที่ใช้งานอยู่บนเราเตอร์ก่อน 0.0.0.0/0 ในตารางหลัก ก็ไม่จำเป็น

โซ่ connected-in и dynamic-in в [Routing] -> [Filters]

การกรองเส้นทาง (ขาเข้าและขาออก) เป็นเครื่องมือที่มักจะใช้ร่วมกับโปรโตคอลการกำหนดเส้นทางแบบไดนามิก (ดังนั้นจึงใช้ได้หลังจากติดตั้งแพ็คเกจเท่านั้น การกำหนดเส้นทาง) แต่มีเครือข่ายที่น่าสนใจสองเครือข่ายในตัวกรองขาเข้า:

• เชื่อมต่อเข้า - กรองเส้นทางที่เชื่อมต่อ
• ไดนามิกอิน - กรองเส้นทางไดนามิกที่ได้รับจาก PPP และ DCHP

การกรองช่วยให้คุณไม่เพียงแค่ละทิ้งเส้นทาง แต่ยังสามารถเปลี่ยนตัวเลือกต่างๆ ได้อีกด้วย: ระยะทาง, เครื่องหมายกำหนดเส้นทาง, ความคิดเห็น, ขอบเขต, ขอบเขตเป้าหมาย, ...

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

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

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

ฉันไม่รู้ว่าทำไม อาจเป็นข้อผิดพลาด แต่ถ้าคุณสร้าง vrf สำหรับอินเทอร์เฟซ ppp เส้นทางไปยัง 0.0.0.0/0 จะยังคงเข้าสู่ตารางหลัก มิฉะนั้นทุกอย่างจะง่ายยิ่งขึ้น

ปิดใช้งานเส้นทางที่เชื่อมต่อ
บางครั้งจำเป็นต้องใช้:

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

เครื่องมือดีบัก

RouterOS มีเครื่องมือมากมายสำหรับการดีบักการกำหนดเส้นทาง:

• [Tool]->[Tourch] - อนุญาตให้คุณดูแพ็กเก็ตบนอินเทอร์เฟซ
• /ip route check - ช่วยให้คุณเห็นว่าเกตเวย์ใดที่จะส่งแพ็กเก็ตไป ไม่ทำงานกับตารางเส้นทาง
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping และติดตามโดยใช้ตารางเส้นทางที่ระบุ
• action=log в [IP]->[Firewall] - เครื่องมือที่ยอดเยี่ยมที่ช่วยให้คุณติดตามเส้นทางของแพ็กเก็ตตามการไหลของแพ็กเก็ต การกระทำนี้มีอยู่ในเชนและตารางทั้งหมด

ที่มา: will.com