🥇Multivan és útválasztás a Mikrotik RouterOS-en

Bevezetés

A cikk átvételét a hiúság mellett az is indokolta, hogy az orosz ajkú táviratközösség profilcsoportjaiban lehangolóan kérdezősködtek ebben a témában. A cikk a kezdő Mikrotik RouterOS (a továbbiakban: ROS) rendszergazdáknak szól. Csak a multivannal foglalkozik, hangsúlyt fektetve az útválasztásra. Bónuszként a minimálisan elegendő beállítás biztosítja a biztonságos és kényelmes működést. Azok, akik a sorok, terheléselosztás, vlanok, hidak, a csatorna állapotának többlépcsős mélyelemzése és hasonló témáinak nyilvánosságra hozatalát keresik, nem vesztegetik az időt és az erőfeszítést az olvasásra.

Nyers adatok

Tesztalanyaként egy 6.45.3-as ROS verziójú, ötportos Mikrotik routert választottak. Két helyi hálózat (LAN1 és LAN2) és három szolgáltató (ISP1, ISP2, ISP3) között irányítja majd a forgalmat. Az ISP1 felé irányuló csatorna statikus "szürke" címmel rendelkezik, ISP2 - "fehér", DHCP-n keresztül, ISP3 - "fehér" PPPoE jogosultsággal. A bekötési rajz az ábrán látható:

A feladat az MTK útválasztó konfigurálása a séma alapján úgy, hogy:

Biztosítson automatikus váltást egy biztonsági mentési szolgáltatóra. A fő szolgáltató az ISP2, az első tartalék az ISP1, a második tartalék az ISP3.
A LAN1 hálózati hozzáférést csak az ISP1-en keresztül szervezze meg az internethez.
Lehetővé teszi a forgalom helyi hálózatokról az Internetre irányítását a kiválasztott szolgáltatón keresztül a címlista alapján.
Lehetőséget biztosít a szolgáltatások közzétételére a helyi hálózatról az internetre (DSTNAT)
Állítson be tűzfalszűrőt, hogy a minimális és elegendő biztonságot nyújtsa az internetről.
Az útválasztó a választott forráscímtől függően a három szolgáltató bármelyikén keresztül kiadhatja a saját forgalmat.
Győződjön meg arról, hogy a válaszcsomagok arra a csatornára vannak irányítva, amelyről érkeztek (beleértve a LAN-t is).

Megjegyzés. Az útválasztót „a nulláról” konfiguráljuk, hogy garantáljuk a meglepetések elkerülését a „dobozból” induló konfigurációkban, amelyek verzióról verzióra változnak. A Winboxot választották konfigurációs eszköznek, ahol a változások vizuálisan megjelennek. Magukat a beállításokat a Winbox terminál parancsai állítják be. A konfigurációhoz szükséges fizikai kapcsolat az Ether5 interfészhez való közvetlen csatlakozással történik.

Egy kis okoskodás arról, hogy mi is az a multivan, probléma-e, vagy ravasz okos emberek szőnek összeesküvés hálózatokat

Egy érdeklődő és figyelmes adminisztrátor, aki önállóan állít fel ilyen vagy hasonló sémát, hirtelen rájön, hogy az már normálisan működik. Igen, igen, az egyéni útválasztási táblák és egyéb útvonalszabályok nélkül, amelyekkel a témában a legtöbb cikk tele van. Ellenőrizzük?

Beállíthatjuk a címzést az interfészeken és az alapértelmezett átjárókon? Igen:

Az ISP1-en a cím és az átjáró regisztrálva lett távolság=2 и check-gateway=ping.
Az ISP2-n az alapértelmezett dhcp kliens beállítás - ennek megfelelően a távolság eggyel lesz egyenlő.
Az ISP3-on a pppoe kliens beállításaiban, amikor add-default-route=yes tegye alapértelmezett-útvonal-távolság=3.

Ne felejtse el regisztrálni a NAT-ot a kilépésnél:

/ip tűzfal nat add action=masquerade chain=srcnat out-interface-list=WAN

Ennek eredményeként a helyi webhelyek felhasználói szórakoztatják a macskák letöltését a fő ISP2 szolgáltatón keresztül, és van egy csatornafoglalás a mechanizmus segítségével. ellenőrizze az átjárót Lásd az 1. megjegyzést

A feladat 1. pontja megvalósul. Hol van a multivan a jelzéseivel? Nem…

További. Adott ügyfeleket kell felszabadítania a LAN-ról az ISP1-en keresztül:

/ip tűzfal mangle add action=route chain=előútválasztás dst-address-list=!BOGONS
passthrough=igen route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip tűzfal mangle add action=route chain=előútválasztás dst-address-list=!BOGONS
passthrough=nincs route-dst=100.66.66.1 src-address=192.168.88.0/24

A feladat 2. és 3. pontja megvalósult. Címkék, bélyegzők, útvonalszabályok, hol vagy?!

Hozzáférést kell adnia kedvenc OpenVPN-szerveréhez a 172.17.17.17 címmel az internetről érkező ügyfelek számára? Kérem:

/ip cloud set ddns-enabled=yes

Partnerként a következő kimeneti eredményt adjuk meg az ügyfélnek: ":put [ip cloud get dns-name]"

Internetről port-továbbítást regisztrálunk:

/ip tűzfal nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protokoll=udp to-addresses=172.17.17.17

Elkészült a 4. tétel.

Az 5. ponthoz tűzfalat és egyéb biztonságot állítottunk fel, egyben örülünk, hogy már minden működik a felhasználóknak, és egy edény után nyúlunk kedvenc italával...
A! Az alagutak feledésbe merültek.

A google cikk által konfigurált l2tp-client a kedvenc holland VDS-jévé nőtte ki magát? Igen.
Az l2tp-szerver IPsec-cel emelkedett, és az IP-felhőből származó DNS-nevű kliensek (lásd fent) ragaszkodnak? Igen.
A széken hátradőlve, egy italt kortyolgatva lustán mérlegeljük a feladat 6. és 7. pontját. Azt gondoljuk – szükségünk van rá? Mindazonáltal ez így működik (c) ... Szóval, ha még mindig nincs rá szükség, akkor ennyi. Multivan megvalósítva.

Mi az a multivan? Ez több internetes csatorna csatlakoztatása egy útválasztóhoz.

Nem kell tovább olvasni a cikket, mert mi lehet a kétes alkalmazhatóság mutogatása mellett?

Azok számára, akik maradnak, akiket érdekel a feladat 6. és 7. pontja, és érzi is a perfekcionizmus viszketését, mélyebbre merülünk.

A multivan megvalósításának legfontosabb feladata a megfelelő forgalomirányítás. Mégpedig: függetlenül attól, hogy melyik (vagy melyik) Lásd. 3. megjegyzés: az internetszolgáltató csatornái megnézik az alapértelmezett útvonalat az útválasztónkon, és választ kell adnia arra a csatornára, amelyről a csomag érkezett. A feladat egyértelmű. Hol a probléma? Valójában egy egyszerű helyi hálózatban a feladat ugyanaz, de senki sem zavarja a további beállításokat, és nem érez gondot. A különbség az, hogy az Internet bármely irányítható csomópontja minden csatornánkon keresztül elérhető, és nem egy szigorúan meghatározott csatornán keresztül, mint egy egyszerű LAN-ban. A „baj” pedig az, hogy ha az ISP3 IP-címére érkezett hozzánk egy kérés, akkor esetünkben az ISP2 csatornán keresztül fog menni a válasz, hiszen az alapértelmezett átjáró oda van irányítva. Elhagyja, és a szolgáltató eldobja, mint hibás. A problémát azonosították. Hogyan lehet megoldani?

A megoldás három szakaszra oszlik:

Előbeállítás. Ebben a szakaszban az útválasztó alapbeállításai kerülnek megadásra: helyi hálózat, tűzfal, címlisták, hajtű NAT stb.
Multivan. Ebben a szakaszban a szükséges kapcsolatokat megjelöljük és útválasztási táblázatokba rendezzük.
Csatlakozás egy internetszolgáltatóhoz. Ebben a szakaszban megtörténik az internetkapcsolatot biztosító interfészek konfigurálása, az útválasztás és az internetes csatornafoglalási mechanizmus aktiválása.

1. Előbeállítás

1.1. Töröljük a router konfigurációját a következő paranccsal:

/system reset-configuration skip-backup=yes no-defaults=yes

Egyetértek "Veszélyes! Amúgy reset? [i/N]:” és újraindítás után MAC-on keresztül csatlakozunk a Winboxhoz. Ebben a szakaszban a konfiguráció és a felhasználói bázis törlődik.

1.2. Új felhasználó létrehozása:

/user add group=full name=knight password=ultrasecret comment=”Not horse”

jelentkezz be alatta és töröld az alapértelmezettet:

/user remove admin

Megjegyzés. A szerző az alapértelmezett felhasználó eltávolítását és nem letiltását tartja biztonságosabbnak, és javasolja a használatát.

1.3. Alapszintű interfészlistákat készítünk a tűzfalban való működés, a felderítési beállítások és más MAC-szerverek kényelme érdekében:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

A felületek aláírása megjegyzésekkel

/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"

és töltse ki az interfész listákat:

/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2 
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN  comment="LAN1"
/interface list member add interface=ether5 list=LAN  comment="LAN2"

Megjegyzés. Az érthető megjegyzések írása megéri az erre fordított időt, ráadásul nagyban megkönnyíti a hibaelhárítást és a konfiguráció megértését.

A szerző biztonsági okokból szükségesnek tartja az ether3 interfész hozzáadását a „WAN” interfész listához, annak ellenére, hogy az ip protokoll nem megy át rajta.

Ne felejtse el, hogy miután a PPP interfész fel lett emelve az ether3-on, azt is hozzá kell adni a „WAN” interfészlistához.

1.4. Elrejtjük az útválasztót a szomszédság észlelése és a szolgáltatói hálózatok vezérlése elől MAC-on keresztül:

/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

1.5. Létrehozzuk a minimálisan elegendő tűzfalszűrő szabálykészletet az útválasztó védelméhez:

/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow" 
connection-state=established,related,untracked

(a szabály engedélyt ad a létrehozott és kapcsolódó kapcsolatokra, amelyek mind a csatlakoztatott hálózatokról, mind magáról az útválasztóról indulnak)

/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp

(ping és nem csak ping. Minden icmp engedélyezett. Nagyon hasznos az MTU problémák megtalálásához)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN

(a beviteli láncot lezáró szabály tilt minden mást, ami az internetről származik)

/ip firewall filter add action=accept chain=forward 
comment="Established, Related, Untracked allow" 
connection-state=established,related,untracked

(a szabály engedélyezi a létrehozott és kapcsolódó kapcsolatokat, amelyek áthaladnak az útválasztón)

/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid

(a szabály alaphelyzetbe állítja a routeren áthaladó connect-state=invalid kapcsolatokat. A Mikrotik kifejezetten ajánlja, de bizonyos ritka esetekben blokkolhatja a hasznos forgalmat)

/ip firewall filter add action=drop chain=forward comment="Drop all from WAN not DSTNATed"  
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

(a szabály megtiltja, hogy az internetről érkező és a dstnat eljáráson át nem menő csomagok áthaladjanak az útválasztón. Ez megvédi a helyi hálózatokat a behatolóktól, akik külső hálózatainkkal egy szórási tartományban lévén, külső IP-címeinket egy átjárót, és így próbálja „felfedezni” helyi hálózatainkat.)

Megjegyzés. Tételezzük fel, hogy a LAN1 és LAN2 hálózatok megbízhatóak, és a közöttük, illetve a belőlük érkező forgalom nincs szűrve.

1.6. Hozzon létre egy listát a nem irányítható hálózatok listájával:

/ip firewall address-list
add address=0.0.0.0/8 comment=""This" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"
 list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS

(Ez azoknak a címeknek és hálózatoknak a listája, amelyek nem irányíthatók az internetre, és ennek megfelelően követjük.)

Megjegyzés. A lista változhat, ezért azt tanácsolom, hogy rendszeresen ellenőrizze a relevanciát.

1.7. Állítsa be a DNS-t magának az útválasztónak:

/ip dns set servers=1.1.1.1,8.8.8.8

Megjegyzés. A ROS jelenlegi verziójában a dinamikus szerverek elsőbbséget élveznek a statikusakkal szemben. A névfeloldási kérés elküldésre kerül a lista első kiszolgálójának. A következő szerverre való áttérés akkor történik meg, ha a jelenlegi nem elérhető. Az időkorlát nagy - több mint 5 másodperc. A visszatérés, amikor a „leesett szerver” folytatódik, nem történik meg automatikusan. Tekintettel erre az algoritmusra és egy multivan jelenlétére, a szerző azt javasolja, hogy ne használja a szolgáltatók által biztosított szervereket.

1.8. Helyi hálózat beállítása.
1.8.1. Statikus IP-címeket konfigurálunk a LAN interfészeken:

/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. A helyi hálózatainkhoz vezető útvonalak szabályait a fő útválasztási táblázaton keresztül állítjuk be:

/ip route rule add dst-address=192.168.88.0/24 table=main comment=”to LAN1”
/ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

Megjegyzés. Ez az egyik gyors és egyszerű módja a LAN-címek elérésének olyan router-interfészek külső IP-címeiből, amelyek nem az alapértelmezett útvonalon mennek keresztül.

1.8.3. Hajtű NAT engedélyezése LAN1 és LAN2 számára:

/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN1" 
out-interface=ether4 src-address=192.168.88.0/24 to-addresses=192.168.88.254
/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN2" 
out-interface=ether5 src-address=172.16.0.0/23 to-addresses=172.16.1.0

Megjegyzés. Ez lehetővé teszi az erőforrások (dstnat) elérését egy külső IP-címen keresztül, miközben a hálózaton belül van.

2. Valójában a nagyon helyes multivan megvalósítása

A „válaszolás, ahonnan kérdezett” probléma megoldásához két ROS-eszközt fogunk használni: csatlakozási jel и útválasztó jel. csatlakozási jel lehetővé teszi, hogy megjelölje a kívánt csatlakozást, majd ezzel a címkével dolgozzon az alkalmazás feltételeiként útválasztó jel. És már vele útválasztó jel be lehet dolgozni ip útvonal и útvonalszabályok. Kitaláltuk az eszközöket, most el kell dönteni, hogy melyik csatlakozásokat jelölje meg - egyszer, pontosan hol - kettőt.

Az elsőnél minden egyszerű - meg kell jelölnünk az összes olyan kapcsolatot, amely az internetről érkezik a routerhez a megfelelő csatornán keresztül. Esetünkben ez három címke lesz (a csatornák száma szerint): „conn_isp1”, „conn_isp2” és „conn_isp3”.

A második árnyalat az, hogy a bejövő kapcsolatok kétféleek lesznek: tranzit és azok, amelyeket magának az útválasztónak szánnak. A csatlakozási jelölés mechanizmusa a táblázatban működik mángorló. Tekintsük a csomag mozgását egy egyszerűsített diagramon, amelyet a mikrotik-trainings.com erőforrás szakemberei állítottak össze (nem reklám):

A nyilakat követve azt látjuk, hogy a csomag a következő címre érkezik:bemeneti interfész", átmegy a láncon"Előzetes útválasztás"és csak ezután osztják fel tranzitra és helyire a blokkban"Útválasztási döntés". Ezért arra használjuk, hogy két legyet egy csapásra megöljünk Csatlakozási jel az asztalban Mangle Pre-routing láncok Előzetes útválasztás.

megjegyzés. A ROS-ban az „Útvonaljel” címkék „Táblázat” néven szerepelnek az Ip/Routes/Rules részben, és „Útvonaljel”-ként a többi szakaszban. Ez némi zavart okozhat a megértésben, de valójában ez ugyanaz, és az rt_tables analógja az iproute2-ben linuxon.

2.1. Az egyes szolgáltatóktól bejövő kapcsolatokat megjelöljük:

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1  new-connection-mark=conn_isp1 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2  new-connection-mark=conn_isp2 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3  new-connection-mark=conn_isp3 passthrough=no

Megjegyzés. Hogy ne jelöljem ki a már megjelölt kapcsolatokat, a connect-state=new helyett a connection-mark=no-mark feltételt használom, mert szerintem ez a helyesebb, valamint a bemeneti szűrőben az érvénytelen kapcsolatok visszautasítása.

passthrough=no - mert ennél a megvalósítási módnál az újrajelölés kizárt, és a gyorsítás érdekében az első egyezés után megszakíthatja a szabályok felsorolását.

Nem szabad megfeledkezni arról, hogy az útválasztásba még semmilyen módon nem avatkozunk bele. Most már csak a felkészülés szakaszai vannak. A megvalósítás következő szakasza a tranzit forgalom feldolgozása lesz, amely a helyi hálózatban lévő célállomásról a létrehozott kapcsolaton keresztül tér vissza. Azok. azok a csomagok, amelyek (lásd az ábrát) áthaladtak az útválasztón:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” és eljutott címzettjükhöz a helyi hálózaton.

Fontos! A ROS-ben nincs logikai felosztás külső és belső interfészekre. Ha a fenti diagram szerint követjük a válaszcsomag útvonalát, akkor az ugyanazt a logikai utat fogja követni, mint a kérés:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” csak kérésre"bemeneti csatlakozók” volt az ISP interfész, a válasz pedig a LAN

2.2. A válasz tranzit forgalmat a megfelelő útválasztási táblákra irányítjuk:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP1" connection-mark=conn_isp1 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP2" connection-mark=conn_isp2 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP3" connection-mark=conn_isp3 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp3 passthrough=no

Megjegyzés. in-interface-list=!WAN - csak a helyi hálózat és a dst-address-type=!local forgalommal dolgozunk, amely nem rendelkezik magának az útválasztónak az interfészeinek címének célcímével.

Ugyanez vonatkozik a helyi csomagokra, amelyek az útválasztóhoz érkeztek:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Input”=>”Local Process”

Fontos! A válasz a következőképpen fog megtörténni:

”Local Process”=>”Routing Decision”=>”Output”=>”Post Routing”=>”Output Interface”

2.3. A helyi forgalmat a megfelelő útválasztási táblákra irányítjuk:

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP1" connection-mark=conn_isp1 dst-address-type=!local 
new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP2" connection-mark=conn_isp2 dst-address-type=!local 
new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP3" connection-mark=conn_isp3 dst-address-type=!local 
new-routing-mark=to_isp3 passthrough=no

Ebben a szakaszban megoldottnak tekinthető az a feladat, hogy előkészítsék a válasz küldését arra az internetes csatornára, amelyről a kérés érkezett. Minden meg van jelölve, fel van címkézve, és készen áll a továbbításra.
Ennek a beállításnak egy kiváló „mellékhatása” az a képesség, hogy egyidejűleg mindkét (ISP2, ISP3) szolgáltató DSNAT-port továbbításával dolgozhat. Egyáltalán nem, mivel az ISP1-en van egy nem irányítható címünk. Ez a hatás fontos például egy két MX-vel rendelkező levelezőszerver esetében, amelyek különböző internetes csatornákat néznek.

A helyi hálózatok külső IP-útválasztókkal történő működésének árnyalatainak kiküszöbölésére a bekezdésekből származó megoldásokat használjuk. 1.8.2. és 3.1.2.6.

Ezenkívül egy jelölésekkel ellátott eszközt használhat a probléma 3. bekezdésének megoldására. Így valósítjuk meg:

2.4. A helyi ügyfelektől érkező forgalmat az útválasztási listákból a megfelelő táblákhoz irányítjuk:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1 
passthrough=no src-address-list=Via_ISP1

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP2" dst-address-list=!BOGONS new-routing-mark=to_isp2 
passthrough=no src-address-list=Via_ISP2

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3 
passthrough=no src-address-list=Via_ISP3

Ennek eredményeként valahogy így néz ki:

3. Hozzon létre kapcsolatot az internetszolgáltatóval, és engedélyezze a márkás útválasztást

3.1. Csatlakozás beállítása az ISP1-hez:
3.1.1. Állítson be egy statikus IP-címet:

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Statikus útválasztás beállítása:
3.1.2.1. Adjon hozzá egy alapértelmezett "vészhelyzeti" útvonalat:

/ip route add comment="Emergency route" distance=254 type=blackhole

Megjegyzés. Ez az útvonal lehetővé teszi, hogy a helyi folyamatokból származó forgalom áthaladjon az útvonal döntési szakaszán, függetlenül a szolgáltatók hivatkozásainak állapotától. A kimenő helyi forgalom árnyalata, hogy ahhoz, hogy a csomag legalább valahová elmozduljon, a fő útválasztási táblának aktív útvonallal kell rendelkeznie az alapértelmezett átjáróhoz. Ha nem, akkor a csomag egyszerűen megsemmisül.

Szerszámbővítésként ellenőrizze az átjárót A csatorna állapotának mélyebb elemzéséhez a rekurzív útvonal módszer használatát javaslom. A módszer lényege, hogy azt mondjuk a routernek, hogy ne közvetlenül, hanem egy köztes átjárón keresztül keressen utat az átjárójához. A 4.2.2.1, 4.2.2.2 és 4.2.2.3 ilyen „teszt” átjáróként lesz kiválasztva az ISP1, ISP2 és ISP3 számára.

3.1.2.2. Útvonal az „ellenőrzési” címre:

/ip route add check-gateway=ping comment="For recursion via ISP1"  
distance=1 dst-address=4.2.2.1 gateway=100.66.66.1 scope=10

Megjegyzés. Csökkentjük a hatókör értékét az alapértelmezett értékre a ROS célhatókörében, hogy a jövőben a 4.2.2.1-et rekurzív átjáróként használhassuk. Hangsúlyozom: a „teszt” címhez vezető útvonal hatókörének kisebbnek vagy egyenlőnek kell lennie a tesztcímre hivatkozó útvonal célhatókörével.

3.1.2.3. Rekurzív alapértelmezett útvonal a forgalom számára útvonaljel nélkül:

/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1

Megjegyzés. A távolság=2 érték használatos, mert az ISP1 az első biztonsági másolatként van deklarálva a feladat feltételei szerint.

3.1.2.4. Rekurzív alapértelmezett útvonal a forgalom számára „to_isp1” útvonaljellel:

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 
routing-mark=to_isp1

Megjegyzés. Igazából itt kezdjük végre élvezni a 2. bekezdésben elvégzett előkészítő munka gyümölcsét.

Ezen az útvonalon a „to_isp1” útvonallal rendelkező összes forgalom az első szolgáltató átjárójára lesz irányítva, függetlenül attól, hogy a főtáblához jelenleg melyik alapértelmezett átjáró aktív.

3.1.2.5. Az első tartalék rekurzív alapértelmezett útvonal az ISP2 és ISP3 címkével ellátott forgalom számára:

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp2
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp3

Megjegyzés. Ezekre az útvonalakra többek között szükség van a „to_isp*” címlistán szereplő helyi hálózatok forgalmának lefoglalásához.

3.1.2.6. Regisztráljuk az útvonalat a router helyi forgalmához az Internethez az ISP1-en keresztül:

/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1

Megjegyzés. Az 1.8.2. bekezdés szabályaival kombinálva hozzáférést biztosít a kívánt csatornához egy adott forrással. Ez kritikus fontosságú a helyi oldali IP-címet (EoIP, IP-IP, GRE) meghatározó alagutak építésekor. Mivel az ip útvonalszabályokban szereplő szabályok felülről lefelé, a feltételek első egyezéséig futnak, akkor ennek a szabálynak az 1.8.2. pont szabályai után kell lennie.

3.1.3. Regisztráljuk a NAT szabályt a kimenő forgalomhoz:

/ip firewall nat add action=src-nat chain=srcnat comment="NAT via ISP1"  
ipsec-policy=out,none out-interface=ether1 to-addresses=100.66.66.2

Megjegyzés. NATimáljon mindent, ami kialszik, kivéve azt, ami az IPsec-házirendekbe kerül. Igyekszem nem az action=masquerade-t használni, hacsak nem feltétlenül szükséges. Lassabb és erőforrásigényesebb, mint az src-nat, mert minden új kapcsolathoz kiszámítja a NAT-címet.

3.1.4. A listáról azokat az ügyfeleket, akiknek tilos más szolgáltatón keresztül elérni, közvetlenül az ISP1 szolgáltató átjárójára küldjük.

/ip firewall mangle add action=route chain=prerouting comment="Address List via ISP1 only" 
dst-address-list=!BOGONS passthrough=no route-dst=100.66.66.1 
src-address-list=Via_only_ISP1 place-before=0

Megjegyzés. Az action=route magasabb prioritású, és más útválasztási szabályok előtt kerül alkalmazásra.

place-before=0 - a szabályunkat az első helyre helyezi a listában.

3.2. Hozzon létre kapcsolatot az ISP2-vel.

Mivel az ISP2 szolgáltató DHCP-n keresztül adja meg a beállításokat, ésszerű a szükséges változtatásokat egy olyan szkripttel elvégezni, amely a DHCP kliens indításakor indul el:

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if ($bound=1) do={r
    n    /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 
           dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=10r
    n    /ip route add comment="Unmarked via ISP2" distance=1 gateway=4.2.2.2;r
    n    /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 
           routing-mark=to_isp2;r
    n    /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 
           routing-mark=to_isp1;r
    n    /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 
           routing-mark=to_isp3;r
    n    /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
           out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2" 
           place-before=1;r
    n    if ([/ip route rule find comment="From ISP2 IP to Inet"] ="") do={r
    n        /ip route rule add comment="From ISP2 IP to Inet" 
               src-address=$"lease-address" table=to_isp2 r
    n    } else={r
    n       /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=no 
              src-address=$"lease-address"r
    n    }      r
    n} else={r
    n   /ip firewall nat remove  [find comment="NAT via ISP2"];r
    n   /ip route remove [find comment="For recursion via ISP2"];r
    n   /ip route remove [find comment="Unmarked via ISP2"];r
    n   /ip route remove [find comment="Marked via ISP2 Main"];r
    n   /ip route remove [find comment="Marked via ISP1 Backup1"];r
    n   /ip route remove [find comment="Marked via ISP3 Backup2"];r
    n   /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=yesr
    n}r
    n" use-peer-dns=no use-peer-ntp=no

Maga a szkript a Winbox ablakban:

Megjegyzés. A szkript első része akkor aktiválódik, amikor a bérlet sikeresen megtörtént, a második - a bérlet feladása után.Lásd az 2. megjegyzést

3.3. Kapcsolatot létesítünk az ISP3 szolgáltatóval.

Mivel a beállítások szolgáltatója ad nekünk dinamikát, a szükséges változtatásokat a ppp interfész felemelése és bukása után induló szkriptekkel célszerű elvégezni.

3.3.1. Először konfiguráljuk a profilt:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client 
on-down="/ip firewall nat remove  [find comment="NAT via ISP3"];r
    n/ip route remove [find comment="For recursion via ISP3"];r
    n/ip route remove [find comment="Unmarked via ISP3"];r
    n/ip route remove [find comment="Marked via ISP3 Main"];r
    n/ip route remove [find comment="Marked via ISP1 Backup2"];r
    n/ip route remove [find comment="Marked via ISP2 Backup2"];r
    n/ip route rule set [find comment="From ISP3 IP to Inet"] disabled=yes;" 
on-up="/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 
    dst-address=4.2.2.3/32 gateway=$"remote-address" scope=10r
    n/ip route add comment="Unmarked via ISP3" distance=3 gateway=4.2.2.3;r
    n/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 
    routing-mark=to_isp3;r
    n/ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp1;r
    n/ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp2;r
    n/ip firewall mangle set [find comment="Connmark in from ISP3"] 
    in-interface=$"interface";r
    n/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
    out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3" 
    place-before=1;r
    nif ([/ip route rule find comment="From ISP3 IP to Inet"] ="") do={r
    n   /ip route rule add comment="From ISP3 IP to Inet" src-address=$"local-address" 
    table=to_isp3 r
    n} else={r
    n   /ip route rule set [find comment="From ISP3 IP to Inet"] disabled=no 
    src-address=$"local-address"r
    n};r
    n"

Maga a szkript a Winbox ablakban:

Megjegyzés. Vonal
/ip tűzfal mangle set [find comment="Connmark in from ISP3"] in-interface=$"interfész";
lehetővé teszi az interfész átnevezésének helyes kezelését, mivel az a kódjával működik, és nem a megjelenített névvel.

3.3.2. Most a profil használatával hozzon létre egy ppp kapcsolatot:

/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no 
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client user=isp3_client

Utolsó simításként állítsuk be az órát:

/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

Azoknak, akik a végéig elolvasták

A multivan megvalósításának javasolt módja a szerző személyes preferenciája, és nem az egyetlen lehetséges módja. A ROS eszköztár kiterjedt és rugalmas, ami egyrészt nehézségeket okoz a kezdőknek, másrészt pedig népszerűségének az oka. Tanuljon, próbáljon ki, fedezzen fel új eszközöket és megoldásokat. Például a megszerzett tudás alkalmazásaként lehetőség van a multivan ezen megvalósításában az eszköz cseréjére check-gateway rekurzív útvonalakkal netwatch.

Megjegyzések

check-gateway - egy olyan mechanizmus, amely lehetővé teszi az útvonal deaktiválását az átjáró elérhetőségének két egymást követő sikertelen ellenőrzése után. Az ellenőrzés 10 másodpercenként egyszer megtörténik, plusz a válaszidőtúllépés. Összességében a tényleges kapcsolási időzítés 20-30 másodperc tartományban van. Ha az ilyen kapcsolási időzítés nem elegendő, lehetőség van az eszköz használatára netwatch, ahol az időzítő manuálisan beállítható. check-gateway nem indít el szakaszos csomagvesztést a linken.
Fontos! Egy elsődleges útvonal deaktiválásával az összes többi útvonal deaktiválódik, amely arra hivatkozik. Ezért nekik jelezni check-gateway=ping nem szükséges.
Előfordul, hogy a DHCP-mechanizmusban hiba lép fel, ami úgy néz ki, mint egy kliens, amely a megújítási állapotban ragadt. Ebben az esetben a szkript második része nem fog működni, de nem akadályozza meg a forgalom helyes bejárását, mivel az állapot követi a megfelelő rekurzív útvonalat.
ECMP (Equal Cost Multi-Path) - ROS-ban lehetőség van több átjáróval és azonos távolsággal rendelkező útvonal beállítására. Ebben az esetben a kapcsolatok elosztásra kerülnek a csatornák között a körmérkőzéses algoritmus segítségével, a megadott átjárók számának arányában.

A cikk megírásának ösztönzéséért, segítségért a szerkezet kialakításában és az ékezetek elhelyezésében - személyes köszönet Jevgenyijnek @jscar

Forrás: will.com

Multivan és útválasztás Mikrotik RouterOS-en