Bevezetés
A cikk írására, a hiúságon kívül, az a zavaró gyakoriság sarkallt, amellyel kérdések merültek fel e témában a rusznyelvű Telegram közösség szakmai csoportjaiban. A cikk a Mikrotik RouterOS (továbbiakban ROS) kezdő adminisztrátorainak szól. Csak a multiláncokat tárgyalja, a hangsúlyt a routingra helyezve. Bónuszként tartalmazza a minimálisan szükséges beállításokat a biztonságos és kényelmes működés biztosításához. Azok, akik a sorok, terheléselosztás, VLAN-ok, hídkapcsolatok, több lépcsős mélyreható csatornanalízis és hasonlók témáit keresik — ne pazarolják az idejüket és energiájukat az olvasásra.
Forrásadatok
Kísérleti alanyként egy ötpontos Mikrotik routert választottunk a 6.45.3-as ROS verzióval. Ez a router forgalmat fog irányítani két helyi hálózat között (LAN1 és LAN2), valamint három szolgáltató (ISP1, ISP2, ISP3) között. Az ISP1 felé statikus "szürke" IP-cím, az ISP2 felé "fehér", DHCP-n keresztül kapott cím, az ISP3 felé pedig "fehér" PPPoE azonosítással. A kapcsolási séma az alábbi ábrán látható:
A cél egy olyan router beállítása az ábra alapján, hogy:
- Automatikus váltás biztosítása a tartalék 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ózat internetkapcsolatának biztosítása kizárólag az ISP1-en keresztül.
- Lehetővé tenni a helyi hálózatok forgalmának irányítását az internet felé a választott szolgáltató alapján az address-list segítségével.
- Lehetővé tenni a helyi hálózaton lévő szolgáltatások közzétételét az interneten (DSTNAT).
- Tűzfal-szűrő beállítása, amely biztosítja a minimálisan szükséges védelmet az internet felől.
- A router képes legyen saját forgalmát bármelyik szolgáltatón keresztül irányítani a választott forráscím alapján.
- A válaszcsomagok irányítása a csatornába, ahonnan érkeztek (beleértve a LAN-t is).
Megjegyzés. A routert "tisztán" fogjuk beállítani, hogy garantáljuk a meglepetések hiányát az egyes verziókból származó "do boót" induló konfigurációk változásai között. A beállítási eszköz a Winbox, ahol a változások vizuálisan lesznek megjelenítve. A beállításokat a Winbox terminálban lesznek megadva. A beállítás fizikai kapcsolata közvetlen kapcsolat a Ether5 interfésszel.
Néhány gondolat arról, hogy mi az a multiwan, probléma ez vagy csak okos emberek készítenek titkos terveket körülötte.
A kíváncsi és figyelmes adminisztrátor, aki önállóan konfigurál egy ilyen vagy hasonló sémát, váratlanul észreveszi, hogy az már most jól működik. Igen, igen, anélkül a felhasználói útválasztó táblák nélkül és egyéb route rules nélkül, amelyekből a legtöbb cikk ezen a téren készül. Ellenőrizzük?
Be tudjuk állítani az interfészek címzését és az alapértelmezett átjárókat? Igen:
Az ISP1-nek megadtuk a címet és az átjárót distance=2 és check-gateway=ping.
Az ISP2-nél az alapértelmezett dhcp kliens beállítása esetén a distance egyenlő lesz egy.
Az ISP3-nál a pppoe kliens beállításoknál add-default-route=yes beállítása default-route-distance=3.
Ne felejtsük el beállítani a NAT-ot a kimenetre:
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN
Ennek eredményeként a lokális felhasználók mókásan csatlakoznak az alapvető ISP2 szolgáltatóhoz, és van csatorna-tartalék a check gateway Lásd a megjegyzést 1
Az 1. feladat megvalósult. Hol van a multiwan a címkéivel? Nincs…
Tovább. Ki kell engednünk bizonyos klienseket a LAN-ból ISP1-en keresztül:
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=no route-dst=100.66.66.1 src-address=192.168.88.0/24
A 2. és 3. feladat megvalósult. Címkék, márkák, route rules, hol vagytok?!
Hozzáférést kell adni a kedvenc OpenVPN szerverhez a 172.17.17.17 címmel az internetes kliensek számára? Kérem:
/ip cloud set ddns-enabled=yes
A klienseknek mint peer adjuk meg a kimenetet: “:put [ip cloud get dns-name]”
Beállítjuk a port továbbítását az internetről:
/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17
A 4. pont elkészült.
Beállítjuk a tűzfalat és egyéb biztonsági intézkedéseket az 5. ponthoz, miközben örülünk annak, hogy a felhasználóknál már minden működik, és nyúlunk a kedvenc italunkhoz.
Ó! A tunelről még megfeledkeztünk.
Az l2tp kliens, amelyet a neten talált cikk alapján állítottunk be, kapcsolódik a kedvenc holland VDS-hez? Igen.
Az l2tp szerver IPsec-sel felállt, és a kliensek DNS név alapján az IP Cloud-ból (lásd fent) kapcsolódnak? Igen.
Hátradőlve a székben, kortyolgatva az italunkat, lustán nézzük a 6. és 7. feladatot. Gondolkodunk — vajon szükség van erre? Mert úgyis működik… Nos, ha valóban nem szükséges, akkor ennyi. A multiwan megvalósítva.
Mi az a multiwan? Több internetcsatorna összekapcsolása egy routerhez.
Tovább a cikket nem érdemes olvasni, mivel mi más lehet ott, mint a kétes alkalmazhatóságú dicsekvés?
A maradékokkal, akik érdeklődnek a feladat 6 és 7. pontjai iránt, és érzik a perfecciónizmus kényszerét, merülünk el mélyebbre.
A multivan megvalósításának legfontosabb feladata a forgalom helyes irányítása. Nevezetesen: függetlenül attól, hogy a szolgáltató melyik (vagy mely) hivatkozása van beállítva az alapértelmezett útvonalunkon, válasznak pontosan abba a csatornába kell érkeznie, ahonnan a csomag érkezett. A feladat világos. Hol a probléma? Hiszen egy egyszerű helyi hálózaton ugyanaz a feladat áll fenn, de senki sem foglalkozik további beállításokkal, és senki nem érzi a feszültséget. A különbség abban rejlik, hogy bármely irányítható csomópont az Interneten keresztül elérhető az összes csatornán, nem pedig szigorúan egy adott csatornán, mint egy egyszerű lokálisan. A „probléma” pedig az, hogy ha egy kérés érkezett egy ISP3 IP címre, akkor ebben az esetben a válasz az ISP2 csatornán keresztül eltávozik, mivel az alapértelmezett átjáró arra van beállítva. El fog tűnni, és a szolgáltató visszautasítja, mint helytelen. A problémát megállapítottuk. Hogyan oldjuk meg?
A megoldást három szakaszra osztjuk:
- Előkészítő beállítás. Ebben a fázisban az alapvető beállítások, például a helyi hálózat, a tűzfal, a címjegyzékek, a hairpin NAT stb. lesznek megadva.
- Multivan. Ebben a szakaszban a szükséges kapcsolatokat meg kell címkézni és a routing táblákba rendezni.
- ISP-hez való csatlakozás. Ebben a szakaszban be lesznek állítva az internetkapcsolatot biztosító interfészek, és aktiválják az irányítást és a csatornák tartalékmechanizmusát.
1. Előkészítő beállítás
1.1. Tisztítjuk a router konfigurációját a következő parancs segítségével:
/system reset-configuration skip-backup=yes no-defaults=yeselfogadjuk a “Dangerous! Reset anyway? [y/N]:” és a reboot után MAC alapján csatlakozunk Winbox-szal. Ezen a szakaszon a konfiguráció és a felhasználói adatbázis törölve van.
1.2. Új felhasználó létrehozása:
/user add group=full name=knight password=ultrasecret comment=”Not horse”bejelentkezünk és töröljük az alapértelmezettet:
/user remove adminMegjegyzés. A szakértő szerint az alapértelmezett felhasználó eltávolítása a lehetségesen biztonságosabb, és ajánljuk az alkalmazását.
1.3. Alapvető interface lists létrehozása a tűzfal, a discovery beállítások és más MAC szerverek operálásának megkönnyítésére:
/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"Megjegyzéseket fűzünk az interfészekhez
/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 kitöltjük az interface lists-t:
/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. Érdemes értelmes megjegyzéseket fűzni, mivel ez megkönnyíti a hibaelhárítást és a konfiguráció megértését.
A szerző szükségesnek tartja, hogy a biztonság érdekében hozzáadjuk a "WAN" interfész lista "ether3" interfészét, annak ellenére, hogy ezen keresztül nem fog működni az ip protokoll.
Ne feledjük, hogy miután az ether3 interfész aktiválva van PPP-n, azt is hozzá kell adni a "WAN" interfész listához.
1.4. A router elrejtése a szomszédság és a szolgáltatók által történő kezelés elől MAC-cím alapján:
/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=LAN1.5. Létrehozunk egy minimális, de elegendő tűzfalszabálycsomagot a router védelme érdekében:
/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow"
connection-state=established,related,untracked(A szabály engedélyezi a létesített és kapcsolt kapcsolatok forgalmát, amelyet mind a csatlakoztatott hálózatok, mind a router indított.)
/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp(Ping és nem csak ping. Az összes icmp forgalom engedélyezve van befelé. Nagyon hasznos az MTU problémák keresésében.)
/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN(A záró input lánc szabály megtilt minden mást, ami az internetről érkezik.)
/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étesített és kapcsolt forgalmat, amely áthalad a routeren.)
/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid(A szabály visszaállítja a kapcsolatokat, amelyeket connection-state=invalid alapján a routeren átvezetnek. Ezt a Mikrotik ajánlja, de néhány ritka esetben hasznos forgalmat blokkolhat.)
/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 a routeren való áthaladást azoknak a csomagoknak, amelyek az internetről érkeznek és nem mentek át dstnat eljáráson. Ez megóvja a helyi hálózatokat a támadóktól, akik, ugyanazon a széles spektrumú tartományon belül, mint a külső hálózataink, megpróbálják a külső IP-nket átállítani, így próbálják "felfedezni" a helyi hálózatainkat.)
Megjegyzés. Tegyük fel, hogy a LAN1 és LAN2 hálózatok megbízhatóak, és így a közöttük zajló forgalmat nem szűrjük.
1.6. Létrehozunk egy listát az útvonal nélküli hálózatok felsorolásá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 egy címek és hálózatok listája, amelyek nem kerülnek routingra az interneten, így mi is követni fogjuk ezt.)
Megjegyzés. A lista változhat, ezért javaslom, hogy időszakosan ellenőrizze az aktualitását.
1.7. Konfiguráljuk a DNS-t magának a routernek:
/ip dns set servers=1.1.1.1,8.8.8.8Megjegyzés. A jelenlegi ROS verzióban a dinamikus szerverek Előnyben részesítik a statikusan megadottak előtt. A név feloldására tett kérés az első szerverhez kerül, a lista sorrendje szerint. A következő szerverre akkor lépünk át, ha a jelenlegi nem elérhető. Az időtúllépés hosszú — 5 másodpercnél hosszabb. A „leállt szerver” működésének helyreállításakor a visszatérés automatikusan nem történik meg. Figyelembe véve ezt az algoritmust és a multiplexelés jelenlétét, a szerző javasolja, hogy ne használjunk olyan szervereket, amelyeket a szolgáltatók adnak meg.
1.8. Helyi hálózat beállítása.
1.8.1. Statikus IP-címek konfigurálása a helyi hálózati 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. Útvonali szabályok megadása helyi hálózatainkhoz a fő routing táblán keresztül:
/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 egyszerű és gyors módja annak, hogy hozzáférjünk a helyi hálózatok címeihez, a router interfészeinek külső IP-címeivel, amelyek mentén nem áll fönn az alapértelmezett útvonal.
1.8.3. Hairpin NAT engedélyezése LAN1 és LAN2-nek:
/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.0Megjegyzés. Ez lehetővé teszi, hogy a külső IP-n keresztül hozzáférjünk saját erőforrásainkhoz (dstnat), miközben a hálózaton belül vagyunk.
2. Tehát a megfelelő multiplexelés megvalósítása
A „válaszolni arra, ahonnan megkérdezték” feladat megoldására két eszközt fogunk használni ROS-ban: connection mark és routing mark. Connection mark lehetővé teszi a kívánt kapcsolat megjelölését, és a jövőben ezzel a jelöléssel dolgozhatunk a szabályozás feltételeként routing mark. Ezzel kapcsolatban pedig routing mark lehet dolgozni ip route és route rules. Az eszközökkel tisztában vagyunk, most meg kell határoznunk, hogy mely kapcsolatokat kell megjelölnünk — ez az egyik, és hogy hol kell jelölni — ez a kettő.
Az első viszonylag egyszerű — meg kell jelölnünk minden kapcsolatot, amely az Internetből érkezik a routerhez a megfelelő csatornán. Ebben az esetben három jelölés lesz (csatornák számának megfelelően): „conn_isp1”, „conn_isp2” és „conn_isp3”.
A második variáció abban rejlik, hogy a bejövő kapcsolatok kétféle lesznek: tranzitszerűek és azok, amelyek közvetlenül a routerhez tartoznak. A connection mark mechanizmus a mangletáblában működik. Vizsgáljuk meg a csomag mozgását egy egyszerűsített diagramon, amelyet a mikrotik-trainings.com szakértői készítettek (nem reklám):
A nyilak mentén haladva látjuk, hogy a „input interface” interfészen érkező csomag a „Prerouting” láncán halad át, majd csak utána oszlik meg tranzit és helyi csomagra a „Routing Decision” blokkban. Ezért a két legyet egy csapásra eltalálva, aktiváljuk a Connection Mark a táblázatban Mangle Prerouting láncokat. Prerouting.
Megjegyzés. A ROS-ban a “Routing mark” címkék az Ip/Routes/Rules szekcióban “Table” néven szerepelnek, míg a többi szekcióban “Routing Mark”-ként hivatkoznak rájuk. Ez kis zűrzavart okozhat a megértésben, de lényegében ugyanazt jelentik, és az iproute2-vel működő linuxos rt_tables analógja.
2.1. Megjelöljük a bejövő kapcsolatokat a szolgáltatóktól:
/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=noMegjegyzés. Annak érdekében, hogy ne jelöljük meg a már címkézett kapcsolatokat, a connection-mark=no-mark feltételt használom a connection-state=new helyett, mert helyesebbnek tartom, akárcsak a drop invalid kapcsolatok elhagyását a bemeneti szűrőben.
passthrough=no — mert ennek a megvalósítási módnak a keretein belül a megjelölés kizárva van, és gyorsítás érdekében a szabályok átvizsgálását is megszakíthatjuk, amint egy egyezést találunk.
Figyelembe kell venni, hogy egyelőre nem avatkozunk bele a forgalom irányításába. Jelenleg csak előkészítő lépések zajlanak. A következő lépés a már létrejött kapcsolaton visszatérő tranzitforgalom kezelése lesz a helyi hálózaton. Azaz azoknak a csomagoknak, amelyek (lásd a diagramot) a következő úton mentek át a routeren:
“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” és eljutottak a címzettjükhöz a helyi hálózaton.
Fontos! A ROS-ban nincs logikai megkülönböztetés a külső és belső interfészek között. Ha követjük a válasz csomag mozgását a megadott diagram szerint, akkor ugyanazon a logikai úton halad, mint a kérelem:
“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” csak a kérelem esetén “Input Interface” ISP interfész volt, míg a válasz esetén — LAN
2.2. A visszajövő tranzitforgalmat a megfelelő irányító táblák szerint 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=noMegjegyzés. in-interface-list=!WAN — csak a helyi hálózatból származó forgalmat kezeljük, és dst-address-type=!local, ami nem rendelkezik a router interfészek helyi célcímével.
Ugyanez vonatkozik a helyi csomagokra is, amelyek a routerre érkeztek ezen az úton:
“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Input”=>”Local Process”
Fontos! A válasz a következő úton megy:
”Local Process”=>”Routing Decision”=>”Output”=>”Post Routing”=>”Output Interface”
2.3. A visszajövő helyi forgalmat a megfelelő irányító táblák szerint 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=noEzen a ponton a válasz elküldésére való előkészítést az internet irányába, ahonnan a kérés érkezett, befejezettnek tekinthetjük. Minden be van jelölve, meg van címkézve, és kész a forgalom irányítására.
Egy ilyen beállítás remek „mellékhatása”, hogy a DSNAT porttovábbítás képes párhuzamosan működni mindkét (ISP2, ISP3) szolgáltatóval. Nem mindenhol, mivel ISP1-nél nem rendelkezünk irányítható címmel. Ez a hatás fontos például egy olyan levelezőszerver esetében, amelynek két MX rekordja van, amelyek különböző internetes csatornákra mutatnak.
A helyi hálózatok problémáinak megoldásához külső IP routerrel a 1.8.2 és 3.1.2.6 pontokból vett megoldásokat alkalmazzuk.
Ezenkívül eszközként címkézéseket is fel lehet használni a feladat 3. pontjának megoldásához. Így valósítjuk meg:
2.4. Az forgalmat a helyi kliensektől a megfelelő routing táblákba 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_ISP3Végül ez körülbelül így néz ki:
3. Az ISP-hez való csatlakozást konfiguráljuk és címkézés általi irányítást alkalmazunk.
3.1. Az ISP1-hez való csatlakozás beállítása:
3.1.1. Statikus IP-cím konfigurálása:
/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"3.1.2. Statikus irányítás beállítása:
3.1.2.1. „Katasztrófa” alapértelmezett útvonal hozzáadása:
/ip route add comment="Emergency route" distance=254 type=blackholeMegjegyzés. Ez az útvonal lehetővé teszi a helyi folyamatok forgalmának Route Decision fázisban való áthaladását, függetlenül bármelyik szolgáltató csatornáinak állapotától. A kiinduló helyi forgalom szempontjából a lényeg az, hogy ahhoz, hogy egy csomag elinduljon valamilyen irányba, az alapértelmezett átjáróhoz irányító aktív útvonalnak jelen kell lennie az alap routing táblában. Ha ez hiányzik, akkor a csomag egyszerűen megsemmisül.
Mint eszköz kiterjesztése check gateway a csatorna állapotának mélyebb elemzéséhez javaslom a rekurzív útvonalak alkalmazását. A módszer lényege, hogy a routernek nem közvetlenül, hanem egy köztes átjárón keresztül kell keresnie az útvonalat a saját átjárójához. Az ilyen „ellenőrző” átjárók a 4.2.2.1, 4.2.2.2 és 4.2.2.3 címet kapják, amelyek az ISP1, ISP2 és ISP3 számára vannak kijelölve.
3.1.2.2. Út a „tesztelő” címhez:
/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=10Megjegyzés. A scope értékét a ROS target scope alapértelmezettjére csökkentjük, hogy a 4.2.2.1-et a későbbi rekurzív átjáróként használhassuk. Hangsúlyozom: a „tesztelő” címhez tartozó útvonal scope-jának kisebbnek vagy egyenlőnek kell lennie annak az útvonalnak a target scope-jával, amely hivatkozik a tesztelőre.
3.1.2.3. Alapértelmezett rekurzív útvonal a routing mark nélküli forgalom számára:
/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1Megjegyzés. A distance=2 értéket azért használjuk, mert ISP1 a feladat feltételei szerint elsődleges tartalék.
3.1.2.4. Alapértelmezett rekurzív útvonal a „to_isp1” routing markkal rendelkező forgalom számára:
/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1
routing-mark=to_isp1Megjegyzés. Itt végre elkezdjük kihasználni a 2. pontban elvégzett előkészítő munka gyümölcseit.
Ezen az útvonalon minden, „to_isp1” útvonalcímmel rendelkező forgalom az első szolgáltató átjárójára lesz irányítva, függetlenül attól, hogy melyik az éppen aktív átjáró a fő táblában.
3.1.2.5. Az első biztonsági rekurzív alapértelmezett útvonal a ISP2 és ISP3 címkézett forgalma 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_isp3Megjegyzés. Ezek az útvonalak szükségesek a helyi hálózatokból származó forgalom biztonsági tartalékaihoz, amelyek az „to_isp*” címjegyzék tagjaiból állnak.
3.1.2.6. Az útvonal beállítása a router helyi forgalmához az ISP1-en keresztül az internetre:
/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1Megjegyzés. Az 1.8.2-es pontból származó szabályokkal kombinálva biztosítva van a szükséges csatornához való hozzáférés a megadott forrással. Ez kritikus a tunnelt kialakításához, ahol meg van adva a helyi oldal IP-címe (EoIP, IP-IP, GRE). Mivel az ip route rules-ban a szabályok felülről lefelé, az első feltétel teljesüléséig kerülnek végrehajtásra, ezért ezt a szabályt a 1.8.2-es pontban szereplő szabályok után kell elhelyezni.
3.1.3. NAT szabály megadása az outgoing forgalom számára:
/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.2Megjegyzés. NAT minden outgoing forgalomra, kivéve azon forgalmakra, amelyek IPsec politikába esnek. Igazán nem szeretek action=masquerade-ot használni szükségtelen esetekben. Ez lassabban és erőforrás-igényesebben működik, mint a src-nat, mivel minden új kapcsolatnál kiszámítja a NAT-hoz szükséges címet.
3.1.4. Azokat az ügyfeleket, akiknek meg van tiltva a hozzáférés más szolgáltatókon keresztül, 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=0Megjegyzés. action=route magasabb prioritást élvez és korábban érvényesül, mint más irányítási szabályok.
place-before=0 — helyezi a szabályunkat az első helyre a listán.
3.2. Kapcsolat beállítása az ISP2-vel.
Mivel az ISP2 szolgáltató DHCP-n keresztül adja meg a beállításainkat, ésszerű, ha a szükséges módosításokat egy IDHCP kliens aktiválásakor elinduló szkripttel végezzük:
/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=noA script maga a Winbox ablakban:
Megjegyzés. A script első része a bérlet sikeres megkapásakor aktiválódik, a második pedig a bérlet felszabadításakor.Lásd a 2. megjegyzést
3.3. Kapcsolat beállítása az ISP3 szolgáltatóval.
Mivel a szolgáltató dinamikusan adja meg a beállításokat, ésszerű, ha a szükséges módosításokat olyan szkriptekkel végezzük, amelyek az interfész ppp felépítése és leesése után indulnak.
3.3.1. Először a profilt állítjuk be:
/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"A script maga a Winbox ablakban:
Megjegyzés. A sor
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
lehetővé teszi az interfész átnevezésének helyes feldolgozását, mivel a kóddal dolgozik, nem a megjelenített névvel.
3.3.2. Most, a profilt használva, létrehozunk 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_clientUtolsó 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.orgAzoknak, akik a végéig eljutottak
A javasolt multivan megvalósítás egyéni ízlése az alkotónak, és nem az egyetlen lehetséges megoldás. A ROS eszközkészlete széleskörű és rugalmas, ami egyrészt nehézségeket okoz a kezdők számára, másrészt népszerűségének oka. Tanulmányozza, próbálja ki, fedezzen fel új eszközöket és megoldásokat. Például a megszerzett tudás alkalmazásaként a jelenlegi multivan megvalósításban fel lehet cserélni az eszközt. Check-gateway rekurzív útvonalakkal Netwatch.
Megjegyzések
- Check-gateway — egy mechanizmus, amely lehetővé teszi, hogy deaktiválja az útvonalat két egymást követő sikertelen átjáróellenőrzés után. Az ellenőrzés 10 másodpercenként történik, plusz a válasz időtúllépése. Összességében a tényleges váltási idő 20-30 másodperc között mozog. Ha ez a váltási idő nem elegendő, lehetőség van arra, hogy igénybe vegye az eszközt. Netwatch, ahol a vizsgálati időzítőt manuálisan lehet megadni. A mechanizmus Check-gateway nem aktiválódik periódikus csomagvesztés esetén a csatornán.
Fontos! Az alapértelmezett útvonal deaktiválása minden egyéb útvonal deaktiválását vonja maga után, amely erre hivatkozik. Ezért ezeket nem szükséges megadni. check-gateway=ping nincs szükség.
- Előfordul, hogy a DHCP működése során hiba lép fel, amely úgy néz ki, hogy a kliens megakadt a renew állapotában. Ebben az esetben a script második része nem fog működni, de a forgalom helyes áthaladását nem akadályozza, mivel az állapotot a megfelelő rekurzív útvonal figyeli.
- ECMP (Equal Cost Multi-Path) — a ROS-ban lehetőség van útvonalat megadni több átjáróval és azonos távolsággal. Ebben az esetben a kapcsolatok a csatornák között round robin algoritmussal oszlanak el, arányosan az megadott átjárók számához.
A cikk megírásának inspirációjáért, a szerkezet megformálásáért és a hangsúlyok elhelyezéséért — személyes köszönetet mondok Jevgenyijnek.
Forrás: habr.com
