🥇Multivlan og routing på Mikrotik RouterOS

Introduktion

Artiklen blev skrevet ikke kun af stolthed, men også af den nedslående hyppighed af spørgsmål om dette emne i de russisktalende Telegram-grupper. Artiklen henvender sig til nye administratorer af Mikrotik RouterOS (herefter ROS). Den fokuserer kun på multicast med vægt på routing. Som en bonus indeholder den de minimumsindstillinger, der er nødvendige for at sikre en sikker og brugervenlig drift. De, der søger dybere information om køer, belastningsbalancering, VLAN, broering, multistadie dybdegående analyse af kanaltilstande og lignende, bør ikke spilde tid og kræfter på at læse videre.

Kildedata

Som testobjekt er der valgt en femporte router Mikrotik med ROS version 6.45.3. Den vil rute trafik mellem to lokale netværk (LAN1 og LAN2) og tre udbydere (ISP1, ISP2, ISP3). Kanalen til ISP1 har en statisk "grå" adresse, ISP2 har en "hvid" adresse, der modtages via DHCP, og ISP3 har en "hvid" adresse med PPPoE-godkendelse. Diagrammet over tilslutningen er vist på billedet:

Opgaven er at konfigurere routeren "MTK" baseret på diagrammet, så den:

Sikrer automatisk skift til den sekundære udbyder. Primær udbyder er ISP2, første reserve er ISP1, anden reserve er ISP3.
Organiserer udgangen af LAN1-netværket til internettet kun gennem ISP1.
Overvejer muligheden for at rute trafik fra lokale netværk til internettet gennem den valgte udbyder baseret på address-list.
Overvejer muligheden for at offentliggøre tjenester fra det lokale netværk til internettet (DSTNAT).
Konfigurerer firewall-filteret for at sikre minimums sikkerhed mod internettet.
Routeren skal kunne sende sin egen trafik gennem en hvilken som helst af de tre udbydere, afhængigt af den valgte kildeadresse.
Sikrer rute for svarpakker til den kanal, de kom fra (inklusive LAN).

Bemærkning. Vi vil konfigurere routeren "fra bunden" for at sikre, at der ikke opstår overraskelser i de startkonfigurationer, der ændrer sig fra version til version. Winbox er valgt som konfigurationsværktøj, hvor ændringerne vil blive vist visuelt. Selve indstillingerne vil blive angivet med kommandoer i Winbox-terminalen. Den fysiske tilslutning til konfigurationen sker via direkte forbindelse til Ether5-interfacet.

Nogle overvejelser om, hvad en multivan er, om det er et problem, eller om det bare er snedige folk, der væver konspirationer omkring det.

En nysgerrig og opmærksom admin, der selv konfigurerer en sådan eller lignende ordning, indser pludselig, at det faktisk kører fint. Ja, ja, uden alle de brugerdefinerede routing-tabeller og andre route rules, som de fleste artikler om dette emne vrimler med. Skal vi tjekke?

Kan vi konfigurere adressering på interfaces og gateways som standard? Ja:

På ISP1 har vi indtastet adressen og gatewayen med distance=2 og check-gateway=ping.
På ISP2 er standardindstillingen for DHCP-klienten — derfor vil distance være lig med én.
På ISP3 i PPPoE-klientens indstillinger med add-default-route=yes sætter vi default-route-distance=3.

Glem ikke at konfigurere NAT til udgangen:

/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN

Som resultat har brugerne af lokalnetværket kattene, der festligt loader via hovedudbyderen ISP2, og der er redundans i kanalen ved hjælp af mekanismen check gateway Se note 1

Opgave 1 er gennemført. Hvor er multivan med sine mærker? Nej...

Lad os gå videre. Vi skal frigive specifikke klienter fra LAN gennem ISP1:

/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

Opgaverne 2 og 3 er gennemført. Mærker, markeringer, route rules, hvor er I?!

Skal vi give adgang til den elskede OpenVPN-server med adressen 172.17.17.17 for klienter fra internettet? Selvfølgelig:

/ip cloud set ddns-enabled=yes

Vi giver klienterne som peer resultatet af output: ":put [ip cloud get dns-name]”

Vi konfigurerer port forwarding fra internettet:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17

Opgave 4 er klar.

Vi konfigurerer firewall og andet sikkerhed til opgave 5, mens vi samtidig glæder os over, at brugerne allerede har alt til at virke, og vi strækker os efter beholderen med vores yndlingsdrik...
Åh! Vi glemte tunnelerne.

Er L2TP-klienten, konfigureret efter en google-artikel, oppe til den elskede hollandske VDS? Ja.
Er L2TP-serveren med IPsec oppe, og kan klienter forbinde via DNS-navnet fra IP Cloud (se ovenfor)? Ja.
Lænende tilbage på stolen, sippe vores drik, kigger vi doven på opgaverne 6 og 7. Tænker — er det nødvendigt? Det kører jo fint (s)... Så hvis vi ikke behøver det, så er det her slut. Multivan er implementeret.

Hvad er en multivan? Det er tilslutning af flere internetkanaler til en router.

Derefter kan artiklen ikke læses videre, da hvad ellers kan der være udover pralerier af tvivlsom anvendelighed?

Med dem, der er tilbage, som er interesseret i punkterne 6 og 7 i opgaven, og som også føler kløen fra perfektionismen, dykker vi dybere.

Den vigtigste opgave ved implementeringen af multilan er korrekt r routing af trafikken. Nemlig: uanset hvilket (eller hvilke) se Kanaler udbyderen ser standardruten på vores router, skal den returnere svaret netop til den kanal, som pakken kom ind fra. Opgaven er klar. Hvor er problemet? For i et simpelt lokalt netværk er opgaven den samme, men ingen bekymrer sig om ekstra indstillinger og oplever ikke problemer. Forskellen er, at enhver routbar enhed på internettet er tilgængelig via hver af vores kanaler og ikke kun gennem en bestemt, som i et simpelt lokalnet. Og “problemet” er, at hvis vi modtager en forespørgsel på IP-adressen ISP3, vil svaret i vores tilfælde gå gennem ISP2-kanalen, da den er konfigureret som standardgateway. Det vil blive sendt og afvist af udbyderen som ugyldigt. Problemet er identificeret. Hvordan skal vi løse det?

Løsningen opdeles i tre faser:

Forberedende opsætning. I denne fase vil de grundlæggende indstillinger for routeren blive konfigureret: lokalt netværk, firewall, address lists, hairpin NAT osv.
Multilan. I denne fase vil de nødvendige forbindelser blive markeret og sorteret i routingtables.
Forbindelse til ISP. I denne fase vil interfaces, der muliggør internetforbindelse, blive konfigureret, routing aktiveres og mekanismen for backupkanaler til internettet implementeres.

1. Forberedende opsætning

1.1. Ryd konfigurationen af routeren ved hjælp af kommandoen:

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

vi accepterer med “Dangerous! Reset anyway? [y/N]:” og, efter genstart, forbinder vi ved hjælp af Winbox over MAC. På dette tidspunkt er konfigurationen og databaseoplysningerne ryddet.

1.2. Opret en ny bruger:

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

log ind under denne og fjern den standard:

/user remove admin

Bemærkning. Det er netop fjernelsen og ikke deaktiveringen af den standardbruger, som forfatteren anser for mere sikker og anbefaler til brug.

1.3. Opret grundlæggende interface lists for nemmere betjening i firewallen, discovery-indstillinger og andre MAC-servere:

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

Vi skriver kommentarer til interfaces

/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"

og udfylder interface lists:

/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"

Bemærkning. Det er værd at bruge tid på at skrive klare kommentarer, da det væsentligt letter fejlfinding og forståelse af konfigurationen.

For security reasons, the author finds it necessary to add the ether3 interface to the 'WAN' interface list, even though no IP protocol will be transmitted over it.

Don't forget that after the PPP interface is brought up on ether3, it also needs to be added to the 'WAN' interface list.

1.4. Conceal the router from being detected and managed from provider networks by MAC:

/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. Create a minimally sufficient set of firewall filter rules to protect the router:

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

(this rule allows established and related connections initiated both from connected networks and by the router itself)

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

(ping and not just ping. All ICMP is allowed inbound. Very useful for finding MTU issues)

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

(the closing input chain rule denies everything else coming from the Internet)

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

(this rule allows established and related connections that pass through the router)

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

(this rule drops connections with connection-state=invalid passing through the router. It is highly recommended by MikroTik, but can, in rare situations, block useful traffic)

/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

(this rule denies packets coming from the Internet that have not passed the dstnat procedure from passing through the router. This protects local networks from intruders who, being in the same broadcast domain as our external networks, would try to 'explore' our local networks by setting our external IPs as gateways)

Bemærkning. Assuming that the LAN1 and LAN2 networks are trusted and traffic between them and from them is not filtered.

1.6. Create a list of non-routable networks:

/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

(This is a list of addresses and networks that are not routed to the Internet and, consequently, we will follow this as well.)

Bemærkning. The list may change, so I advise periodically checking its relevance.

1.7. Configure DNS for the router itself:

/ip dns set servers=1.1.1.1,8.8.8.8

Bemærkning. In the current version of ROS, dynamic servere har prioritet over statisk angivne. Anmodningen om at opnå navnet sendes til den første server i rækkefølge fra listen. Overgangen til næste server sker ved utilgængelighed af den nuværende. Timeout er stor — over 5 sek. Tilbagevenden ved genoptagelse af arbejdet af den "nedlagte server" sker ikke automatisk. Under hensyntagen til denne algoritme og tilstedeværelsen af multiwan anbefales det ikke at bruge servere, der leveres af udbydere.

1.8. Indstiller lokalnetværket.
1.8.1. Konfigurerer statiske IP-adresser på interface af lokale netværk:

/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. Angiver rute-regler til vores lokale netværk gennem den principale rutetabel:

/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"

Bemærkning. Dette er en af de enkle og hurtige måder at få adgang til adresserne i lokale netværk med kilder fra de eksterne IP-adresser af routerens interfaces, som der ikke er nogen standardrute til.

1.8.3. Aktiverer Hairpin NAT for LAN1 og LAN2:

/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

Bemærkning. Dette tillader adgang til sine ressourcer (dstnat) via den eksterne IP, mens man er inde i netværket.

2. Egentlig implementering af den korrekte multiwan

For at løse opgaven "at svare der, hvor der blev spurgt" vil vi bruge to værktøjer fra ROS: connection mark og routing mark. Connection mark giver mulighed for at markere det ønskede forbindelsen og derefter arbejde med denne markering som betingelse for anvendelse routing mark. Og allerede med routing mark kan man arbejde med ip route og route rules. Vi har forstået værktøjerne, nu skal vi løse hvilke forbindelser der skal markeres — én, hvor præcist at markere — to.

Med det første er det klart — vi skal markere alle forbindelser, der kommer ind på routeren fra internettet via den relevante kanal. I vores tilfælde vil der være tre markeringer (i takt med antallet af kanaler): "conn_isp1", "conn_isp2" og "conn_isp3".

Nuancen med det andet er, at indgående forbindelser vil være af to typer: transit og dem, der er beregnet til selve routeren. Mekanismen connection mark fungerer i tabellen mangle. Lad os gennemgå pakkeleveringen i et forsimplet diagram venligst samlet af specialisterne fra mikrotik-trainings.com (ikke reklame):

Følger vi pile, ser vi, at pakken, der kommer ind i "input interface", passerer gennem kæden "Prerouting" og først derefter opdeles i transit og lokal i blokken "Routing Decision". Derfor, for at dræbe to fluer med ét smæk, inddrager vi Connection Mark i tabellen Mangle Prerouting kæderne Prerouting.

Bemærkning. I ROS er mærkerne “Routing mark” angivet i sektionen Ip/Routes/Rules som “Table”, mens de i øvrige sektioner benævnes “Routing Mark”. Dette kan skabe en vis forvirring, men i bund og grund er det det samme og svarer til rt_tables i iproute2 på linux.

2.1. Vi mærker indgående forbindelser fra hver af udbyderne:

/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

Bemærkning. For at undgå at mærke forbindelser, der allerede er mærket, bruger jeg betingelsen connection-mark=no-mark i stedet for connection-state=new, fordi jeg finder det mere korrekt, ligesom jeg afviser drop invalid forbindelser i inputfilteret.

passthrough=no — fordi i denne implementeringsmetode er re-mærkning udelukket, og for at accelerere kan vi bryde gennemgangen af reglerne etter det første match.

Det skal bemærkes, at vi i øjeblikket ikke blander os i routing. Vi er kun i forberedelsesfasen. Det næste skridt i implementeringen vil være behandling af den transittrafik, der vender tilbage via den etablerede forbindelse fra modtageren i det lokale netværk. Dvs. de pakker, der (se diagrammet) har passeret gennem routeren på vej:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” og nåede deres modtagere i det lokale netværk.

Vigtigt! I ROS er der ikke nogen logisk opdeling mellem eksterne og interne grænseflader. Hvis man følger stien for den svarende pakke på det angivne diagram, vil den følge den samme logiske vej som forespørgslen:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” bare for forespørgslen “Input Interface” var ISP-grænsefladen, mens for svaret — LAN

2.2. Vi sender den svarende transittrafik via de relevante routing-tabeller:

/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

Bemærkning. in-interface-list=!WAN — vi arbejder kun med trafik fra det lokale netværk og dst-address-type=!local, som ikke har destinationsadressen for routerens egne grænseflader.

Det samme gælder for lokale pakker, der kom til routeren via stien:

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

Vigtigt! Svaret vil følge denne vej:

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

2.3. Vi sender den svarende lokale trafik via de relevante routing-tabeller:

/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

På dette stadium kan opgaven med at forberede svaret til den internetkanal, hvorigennem forespørgslen blev sendt, betragtes som løst. Alt er mærket, ommærket og klar til at blive routet.
En glimrende "bivirkning" ved denne opsætning er muligheden for at arbejde med DSNAT port forwarding fra begge (ISP2, ISP3) udbydere samtidig. Ikke alle, da ISP1 har en ikke-ruterbar adresse. Denne effekt er vigtig for eksempel for en mailserver med to MX'er, der peger på forskellige internetkanaler.

For at håndtere nuancerne i lokale netværk med eksterne IP-adresser på routeren bruger vi løsninger fra punkterne 1.8.2 og 3.1.2.6.

Derudover kan vi anvende et værktøj med mærkning til at tackle punkt 3 i opgaven. Vi implementerer det således:

2.4. Vi sender trafik fra lokale klienter fra routingslisterne til de relevante tabeller:

/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

Som resultat ser det omtrent sådan her ud:

3. Vi konfigurerer forbindelsen til ISP og aktiverer routing baseret på mærker.

3.1. Vi konfigurerer forbindelsen til ISP1:
3.1.1. Konfigurerer statisk IP-adresse:

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

3.1.2. Konfigurerer statisk routing:
3.1.2.1. Tilføjer en "nødrute" som standard:

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

Bemærkning. Denne rute tillader trafik fra lokale processer at passere Route Decision uafhængigt af tilstanden af kanalerne fra nogen af udbyderne. Aforeningen ved udgående lokal trafik er, at for at en pakke skal bevæge sig, skal der være en aktiv rute til gatewayen i den primære routingtabel. Hvis den ikke findes, vil pakken simpelthen blive destrueret.

Som en udvidelse af værktøjet check gateway til en dybere analyse af kanalens tilstand foreslår jeg at bruge metoden med rekursive ruter. Essensen af metoden er, at vi beder routeren om at søge efter en rute til sin gateway ikke direkte, men gennem en mellem-gateway. De "kontrol" gateways, der vælges, er 4.2.2.1, 4.2.2.2 og 4.2.2.3 henholdsvis for ISP1, ISP2 og ISP3.

3.1.2.2. Ruten til "kontrol" adressen:

/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

Bemærkning. Vi reducerer scopet til standard i ROS target scope, så vi senere kan bruge 4.2.2.1 som en rekursiv gateway. Jeg understreger: scopet for ruten til "kontrol" adressen skal være mindre end eller lig med target scope for den rute, der henviser til kontrol.

3.1.2.3. Rekursiv rute som standard for trafik uden routing mark:

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

Bemærkning. Værdien distance=2 bruges, fordi ISP1 i opgavens betingelser er angivet som den første backup.

3.1.2.4. Rekursiv rute som standard for trafik med routing mark "to_isp1":

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

Bemærkning. Her begynder vi endelig at drage fordel af det forberedende arbejde, der blev udført i punkt 2.

Al trafik, der har mærket ruten "to_isp1", vil blive dirigeret til gatewayen for den første udbyder, uanset hvilken gateway der i øjeblikket er aktiv som standard for hovedtabellen.

3.1.2.5. Den første backup-rekursiv rute, der er standard for den mærkede trafik fra udbyderne ISP2 og ISP3:

/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

Bemærkning. Disse ruter er også nødvendige for at reserve trafik fra lokale netværk, der er medlemmer af address list "to_isp*".

3.1.2.6. Definer ruten for lokal trafik til internettet gennem ISP1:

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

Bemærkning. I kombination med reglerne fra punkt 1.8.2 sikres adgangen til den ønskede kanal med den specificerede kilde. Dette er kritisk for opbygningen af tunneler, hvor den lokale sides IP-adresse angives (EoIP, IP-IP, GRE). Da reglerne i ip route rules udføres fra toppen og nedad, indtil den første betingelse opfyldes, skal denne regel være efter reglerne fra punkt 1.8.2.

3.1.3. Definer en NAT-regel for udgående trafik:

/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

Bemærkning. NAT er for alt udgående, undtagen det, der falder ind under IPsec-politikker. Jeg forsøger ikke at bruge action=masquerade uden absolut nødvendighed. Det fungerer langsommere og er mere ressourcekrævende end src-nat, da det for hver ny forbindelse beregner adressen til NAT.

3.1.4. Send kunderne fra listen, der har forbud mod adgang gennem de andre udbydere, direkte til gatewayen for udbyderen ISP1.

/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

Bemærkning. action=route har en højere prioritet og anvendes før de andre ruter.

place-before=0 — sætter vores regel først i listen.

3.2. Konfigurer forbindelse til ISP2.

Da udbyder ISP2 giver os indstillingerne via DHCP, er det rimeligt at lave de nødvendige ændringer med et script, der starter ved aktivering af DHCP-klienten:

/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

Scriptet i Winbox-vinduet:

Bemærkning. Den første del af scriptet aktiveres ved succesfuld leje, den anden - efter borttagelse af leje.Se note 2

3.3. Konfigurer forbindelse til udbyder ISP3.

Da udbyderen giver os dynamiske indstillinger, er det rimeligt at lave de nødvendige ændringer med scripts, der starter efter aktiveringen og efter deaktivering af ppp-interfacet.

3.3.1. Først konfigurerer vi profilen:

/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"

Scriptet i Winbox-vinduet:

Bemærkning. Streng
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
giver korrekt håndtering af omdøbning af grænsefladen, da den arbejder med dens kode og ikke det viste navn.

3.3.2. Nu, ved hjælp af profilen, opretter vi en ppp-forbindelse:

/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

Som det sidste touch, lad os indstille klokkerne:

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

For dem, der læste til slut

Den foreslåede metode til implementering af multivlan er et personligt valg fra forfatteren og er ikke den eneste mulige. ROS-værktøjet er omfattende og fleksibelt, hvilket både kan skabe udfordringer for begyndere og er årsagen til populariteten. Udforsk, prøv, og opdag nye værktøjer og løsninger. For eksempel kan den opnåede viden anvendes til at erstatte værktøjet i denne multivlan-implementering. Check-gateway med rekursive ruter til Netwatch.

Noter

Check-gateway — en mekanisme, der muliggør deaktivering af ruten efter to på hinanden følgende mislykkede kontroller af gatewayens tilgængelighed. Kontrollen udføres hvert 10. sekund plus timeout for svar. I alt ligger den faktiske tidsramme for omstilling mellem 20-30 sekunder. Hvis denne omstillings tidsramme ikke er tilstrækkelig, er der mulighed for at bruge værktøjet Netwatch, hvor kontrollens timer kan indstilles manuelt. Mekanismen Check-gateway aktiveres ikke ved periodiske tab af pakker i kanalen.
Vigtigt! Deaktivering af hovedruten medfører deaktivering af alle andre ruter, der henviser til den. Derfor er det ikke nødvendigt at angive check-gateway=ping for dem.
Nogle gange opstår der en fejl i DHCP-arbejdsprocessen, som ser ud som om klienten sidder fast i renewal-tilstand. I så fald vil den anden del af scriptet ikke køre, men det vil ikke hindre trafikken i at flyde korrekt, da tilstanden overvåges af den tilsvarende rekursive rute.
ECMP (Equal Cost Multi-Path) — i ROS er der mulighed for at angive en rute med flere gateways og samme distance. I så fald vil forbindelserne blive fordelt over kanalerne ved hjælp af round robin-algoritmen, proportionalt i forhold til antallet af angivne gateways.

For inspiration til at skrive artiklen, hjælp med at forme dens struktur og fremhæve fokus — en personlig tak til Evgeny @jscar

Kilde: habr.com