Multivan en routing op Mikrotik RouterOS

Introductie

Het opnemen van het artikel, naast ijdelheid, werd ingegeven door de deprimerende frequentie van vragen over dit onderwerp in de profielgroepen van de Russisch sprekende telegramgemeenschap. Het artikel is bedoeld voor beginnende Mikrotik RouterOS-beheerders (hierna ROS genoemd). Het behandelt alleen de multivan, met de nadruk op routing. Als bonus zijn er minimaal voldoende instellingen om een ​​veilige en gemakkelijke bediening te garanderen. Degenen die op zoek zijn naar onthulling van de onderwerpen wachtrijen, load balancing, vlans, bruggen, meertraps diepe analyse van de toestand van het kanaal en dergelijke - kunnen geen tijd en moeite verspillen aan lezen.

Initiële gegevens

Als proefpersoon werd een vijfpoorts Mikrotik-router met ROS-versie 6.45.3 geselecteerd. Het zal verkeer routeren tussen twee lokale netwerken (LAN1 en LAN2) en drie providers (ISP1, ISP2, ISP3). Het kanaal naar ISP1 heeft een statisch "grijs" adres, ISP2 - "wit", verkregen via DHCP, ISP3 - "wit" met PPPoE-autorisatie. Het aansluitschema wordt weergegeven in de afbeelding:

Multivan en routing op Mikrotik RouterOS

De taak is om de MTK-router te configureren op basis van het schema, zodat:

  1. Zorg voor automatische overstap naar een back-up provider. De hoofdaanbieder is ISP2, de eerste reserve is ISP1, de tweede reserve is ISP3.
  2. Organiseer LAN1-netwerktoegang tot internet alleen via ISP1.
  3. Bied de mogelijkheid om verkeer van lokale netwerken naar internet te routeren via de geselecteerde provider op basis van de adreslijst.
  4. Zorg voor de mogelijkheid om services van het lokale netwerk naar internet te publiceren (DSTNAT)
  5. Stel een firewallfilter in om de minimaal voldoende beveiliging van internet te bieden.
  6. De router kan zijn eigen verkeer via elk van de drie providers afgeven, afhankelijk van het gekozen bronadres.
  7. Zorg ervoor dat antwoordpakketten worden gerouteerd naar het kanaal waar ze vandaan kwamen (inclusief LAN).

Opmerking. We zullen de router "from scratch" configureren om te garanderen dat er geen verrassingen zijn in de startconfiguraties "out of the box" die van versie tot versie veranderen. Er is gekozen voor Winbox als configuratietool, waar wijzigingen visueel worden weergegeven. De instellingen zelf worden ingesteld door opdrachten in de Winbox-terminal. De fysieke verbinding voor configuratie wordt gemaakt door een directe verbinding met de Ether5-interface.

Een beetje redeneren over wat een multivan is, is het een probleem of zijn sluwe slimme mensen rond het weven van complotnetwerken

Een nieuwsgierige en oplettende beheerder die in zijn eentje zo'n of een soortgelijk schema opzet, beseft ineens dat het al normaal werkt. Ja, ja, zonder je aangepaste routeringstabellen en andere routeregels, waar de meeste artikelen over dit onderwerp vol mee staan. Laten we het controleren?

Kunnen we adressering configureren op interfaces en standaard gateways? Ja:

Op ISP1 zijn het adres en de gateway geregistreerd afstand=2 и check-gateway=ping.
Op ISP2, de standaard DHCP-clientinstelling - dienovereenkomstig is de afstand gelijk aan één.
Op ISP3 in de instellingen van de pppoe-client wanneer add-default-route=ja neerzetten standaard-routeafstand=3.

Vergeet niet NAT te registreren bij de uitgang:

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

Als gevolg hiervan hebben gebruikers van lokale sites plezier met het downloaden van katten via de belangrijkste ISP2-provider en is er een kanaalreservering met behulp van het mechanisme poort controleren Zie noot 1

Punt 1 van de taak is uitgevoerd. Waar is de multivan met zijn sporen? Nee…

Verder. U moet specifieke clients vrijgeven van het LAN via ISP1:

/ip firewall mangel add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=ja route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangel add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=geen route-dst=100.66.66.1 src-address=192.168.88.0/24

Punten 2 en 3 van de taak zijn uitgevoerd. Labels, stempels, routeregels, waar ben je?!

Wilt u toegang geven tot uw favoriete OpenVPN-server met het adres 172.17.17.17 voor clients van internet? Alsjeblieft:

/ip cloud set ddns-enabled=ja

Als peer geven we de opdrachtgever het output resultaat: “:put [ip cloud krijg dns-naam]"

Wij registreren portforwarding vanaf internet:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-lijst=WAN-protocol=udp naar-adressen=172.17.17.17

Artikel 4 is klaar.

We hebben een firewall en andere beveiliging opgezet voor punt 5, tegelijkertijd zijn we blij dat alles al werkt voor gebruikers en reiken we naar een container met een favoriet drankje ...
A! Tunnels zijn vergeten.

l2tp-client, geconfigureerd door google artikel, is gestegen naar je favoriete Nederlandse VDS? Ja.
l2tp-server met IPsec is gestegen en clients door DNS-naam van IP Cloud (zie hierboven.) vastklampen? Ja.
Achterover leunend in onze stoel, nippend aan een drankje, denken we lui na over punt 6 en 7 van de opdracht. We denken - hebben we het nodig? Toch werkt het zo (c) ... Dus als het nog steeds niet nodig is, dan is dat het. Multivan geïmplementeerd.

Wat is een multivan? Dit is het aansluiten van meerdere internetkanalen op één router.

Je hoeft het artikel niet verder te lezen, want wat kan er anders zijn dan opschepperij van twijfelachtige toepasbaarheid?

Voor degenen die blijven, die geïnteresseerd zijn in punt 6 en 7 van de taak, en ook de kriebels van perfectionisme voelen, duiken we dieper.

De belangrijkste taak bij het implementeren van een multivan is de juiste verkeersroutering. Namelijk: ongeacht welke (of welke) Zie. opmerking 3 de kanalen van de ISP kijken naar de standaardroute op onze router, het zou een antwoord moeten terugsturen naar het exacte kanaal waar het pakket vandaan kwam. De taak is duidelijk. Waar is het probleem? Inderdaad, in een eenvoudig lokaal netwerk is de taak hetzelfde, maar niemand stoort zich aan aanvullende instellingen en voelt geen problemen. Het verschil is dat elk routeerbaar knooppunt op internet toegankelijk is via elk van onze kanalen, en niet via een strikt specifiek kanaal, zoals in een eenvoudig LAN. En het "probleem" is dat als er een verzoek bij ons binnenkomt voor het IP-adres van ISP3, het antwoord in ons geval via het ISP2-kanaal zal gaan, aangezien de standaardgateway daarheen wordt geleid. Verlaat en wordt door de provider weggegooid als onjuist. Het probleem is geïdentificeerd. Hoe het op te lossen?

De oplossing is verdeeld in drie fasen:

  1. Voorinstelling. In dit stadium worden de basisinstellingen van de router ingesteld: lokaal netwerk, firewall, adreslijsten, hairpin NAT, etc.
  2. Multivan. In dit stadium worden de benodigde verbindingen gemarkeerd en gesorteerd in routeringstabellen.
  3. Verbinding maken met een ISP. In dit stadium worden de interfaces die verbinding met internet bieden, geconfigureerd, de routering en het reserveringsmechanisme voor internetkanalen geactiveerd.

1. Voorinstelling

1.1. We wissen de routerconfiguratie met het commando:

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

eens zijn met "Gevaarlijk! Toch resetten? [j/N]:” en na het opnieuw opstarten maken we verbinding met Winbox via MAC. In dit stadium worden de configuratie en het gebruikersbestand gewist.

1.2. Maak een nieuwe gebruiker aan:

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

log eronder in en verwijder de standaard:

/user remove admin

Opmerking. Het is het verwijderen en niet uitschakelen van de standaardgebruiker die de auteur als veiliger beschouwt en aanbeveelt voor gebruik.

1.3. We maken basisinterfacelijsten voor het gemak van werken in een firewall, detectie-instellingen en andere MAC-servers:

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

Interfaces ondertekenen met commentaar

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

en vul de interfacelijsten in:

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

Opmerking. Het schrijven van begrijpelijke opmerkingen is de moeite waard om hieraan te besteden, plus het vergemakkelijkt het oplossen van problemen en het begrijpen van de configuratie aanzienlijk.

De auteur acht het om veiligheidsredenen noodzakelijk om de ether3-interface toe te voegen aan de “WAN”-interfacelijst, ondanks het feit dat het ip-protocol er niet doorheen gaat.

Vergeet niet dat nadat de PPP-interface is geactiveerd op ether3, deze ook moet worden toegevoegd aan de interfacelijst "WAN"

1.4. We verbergen de router voor buurtdetectie en controle van providernetwerken via 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. We creëren de minimaal voldoende set firewallfilterregels om de router te beschermen:

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

(de regel geeft toestemming voor gevestigde en gerelateerde verbindingen die worden geïnitieerd vanuit zowel verbonden netwerken als de router zelf)

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

(ping en niet alleen ping. Alle icmp is toegestaan. Erg handig voor het vinden van MTU-problemen)

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

(de regel die de invoerketen sluit, verbiedt al het andere dat van internet komt)

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

(de regel staat gevestigde en gerelateerde verbindingen toe die door de router gaan)

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

(de regel reset verbindingen met connection-state=invalid die door de router gaan. Het wordt sterk aanbevolen door Mikrotik, maar in sommige zeldzame situaties kan het nuttig verkeer blokkeren)

/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

(de regel verbiedt pakketten die van internet komen en de dstnat-procedure niet hebben doorstaan ​​om door de router te gaan. Dit zal lokale netwerken beschermen tegen indringers die, omdat ze zich in hetzelfde uitzenddomein bevinden als onze externe netwerken, onze externe IP's registreren als een gateway en probeer zo onze lokale netwerken te "verkennen".)

Opmerking. Laten we aannemen dat de netwerken LAN1 en LAN2 vertrouwd zijn en dat het verkeer tussen en van hen niet wordt gefilterd.

1.6. Maak een lijst met een lijst van niet-routeerbare netwerken:

/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

(Dit is een lijst met adressen en netwerken die niet naar internet kunnen worden gerouteerd en dienovereenkomstig zullen worden gevolgd.)

Opmerking. De lijst is aan verandering onderhevig, dus ik raad u aan om regelmatig de relevantie te controleren.

1.7. Stel DNS in voor de router zelf:

/ip dns set servers=1.1.1.1,8.8.8.8

Opmerking. In de huidige versie van ROS hebben dynamische servers voorrang op statische. Het naamomzettingsverzoek wordt naar de eerste server in volgorde in de lijst verzonden. De overgang naar de volgende server wordt uitgevoerd wanneer de huidige niet beschikbaar is. De time-out is groot - meer dan 5 seconden. Terugkeren, wanneer de "gevallen server" wordt hervat, gebeurt niet automatisch. Gezien dit algoritme en de aanwezigheid van een multivan raadt de auteur aan geen gebruik te maken van servers van providers.

1.8. Zet een lokaal netwerk op.
1.8.1. We configureren statische IP-adressen op LAN-interfaces:

/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. We stellen de regels voor routes naar onze lokale netwerken in via de hoofdroutetabel:

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

Opmerking. Dit is een van de snelle en gemakkelijke manieren om toegang te krijgen tot LAN-adressen met bronnen van externe IP-adressen van routerinterfaces die niet via de standaardroute gaan.

1.8.3. Schakel Hairpin NAT in voor LAN1 en 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

Opmerking. Hierdoor hebt u toegang tot uw bronnen (dstnat) via een extern IP-adres terwijl u zich binnen het netwerk bevindt.

2. Eigenlijk de uitvoering van de zeer correcte multivan

Om het probleem van "antwoorden waar ze vandaan komen" op te lossen, zullen we twee ROS-tools gebruiken: verbinding merk и routeringsmarkering. verbinding merk kunt u de gewenste aansluiting markeren en vervolgens werken met dit label als voorwaarde voor het aanvragen routeringsmarkering. En al met routeringsmarkering mogelijk om in te werken ip-route и route regels. We hebben de tools bedacht, nu moet je beslissen welke verbindingen je wilt markeren - een keer, precies waar je wilt markeren - twee.

Bij de eerste is alles eenvoudig: we moeten alle verbindingen markeren die vanaf internet via het juiste kanaal naar de router komen. In ons geval zijn dit drie labels (op basis van het aantal kanalen): "conn_isp1", "conn_isp2" en "conn_isp3".

De nuance met de tweede is dat inkomende verbindingen van twee soorten zullen zijn: doorvoer en verbindingen die bedoeld zijn voor de router zelf. Het verbindingsmarkeringsmechanisme werkt in de tabel mangrove. Overweeg de beweging van het pakket op een vereenvoudigd diagram, vriendelijk samengesteld door de specialisten van de bron mikrotik-trainings.com (geen advertenties):

Multivan en routing op Mikrotik RouterOS

Als we de pijlen volgen, zien we dat het pakket aankomt op "input interface”, gaat door de keten “Voorrouteren” en pas dan wordt het verdeeld in transit en lokaal in het blok “Routing besluit". Daarom gebruiken we om twee vliegen in één klap te slaan Verbinding Mark in de tafel Mangel Pre-routing kettingen Voorrouteren.

opmerking. In ROS worden "Routing mark"-labels weergegeven als "Table" in de sectie Ip/Routes/Rules en als "Routing Mark" in andere secties. Dit kan enige begripsverwarring veroorzaken, maar in feite is dit hetzelfde en is het een analoog van rt_tables in iproute2 op linux.

2.1. We markeren inkomende verbindingen van elk van de providers:

/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

Opmerking. Om reeds gemarkeerde verbindingen niet te markeren, gebruik ik de voorwaarde connection-mark=no-mark in plaats van connection-state=new omdat ik denk dat dit correcter is, evenals de afwijzing van ongeldige verbindingen in het invoerfilter.


passthrough=no - omdat bij deze implementatiemethode opnieuw markeren is uitgesloten en u, om te versnellen, de opsomming van regels na de eerste match kunt onderbreken.

Houd er rekening mee dat we ons op geen enkele manier bemoeien met routering. Nu zijn er alleen voorbereidingsfasen. De volgende implementatiefase is de verwerking van transitverkeer dat via de tot stand gebrachte verbinding terugkeert vanaf de bestemming in het lokale netwerk. Die. die pakketjes die (zie het schema) onderweg door de router zijn gegaan:

“Input Interface”=>”Prerouting”=>”Routing Beslissing”=>”Forward”=>”Post Routing”=>”Output Interface” en kwamen bij hun geadresseerde in het lokale netwerk.

Belangrijk! In ROS is er geen logische indeling in externe en interne interfaces. Als we het pad van het antwoordpakket volgen volgens het bovenstaande diagram, volgt het hetzelfde logische pad als het verzoek:

“Input Interface”=>”Prerouting”=>”Routing Beslissing”=>”Forward”=>”Post Routing”=>”Output Interface” gewoon voor een verzoek"Input Interface” was de ISP-interface, en voor het antwoord - LAN

2.2. We leiden responstransitverkeer naar de bijbehorende routeringstabellen:

/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

Opmerking. in-interface-list=!WAN - we werken alleen met verkeer van het lokale netwerk en dst-address-type=!local dat niet het bestemmingsadres heeft van het adres van de interfaces van de router zelf.

Hetzelfde geldt voor lokale pakketten die onderweg naar de router zijn gekomen:

“Invoerinterface”=>”Voorrouting”=>”Routebeslissing”=>”Invoer”=>”Lokaal proces”

Belangrijk! Het antwoord gaat op de volgende manier:

”Lokaal Proces”=>”Routebeslissing”=>”Uitvoer”=>”Na Routing”=>”Uitvoerinterface”

2.3. We sturen lokaal antwoordverkeer naar de bijbehorende routeringstabellen:

/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

In dit stadium kan de taak van het voorbereiden van het verzenden van een antwoord naar het internetkanaal waar het verzoek vandaan kwam, als opgelost worden beschouwd. Alles is gemarkeerd, gelabeld en klaar om te worden gerouteerd.
Een uitstekend "neveneffect" van deze opstelling is de mogelijkheid om tegelijkertijd met DSNAT-poortdoorschakeling van beide (ISP2, ISP3) providers te werken. Helemaal niet, aangezien we op ISP1 een niet-routeerbaar adres hebben. Dit effect is bijvoorbeeld belangrijk voor een mailserver met twee MX'en die naar verschillende internetkanalen kijken.

Om de nuances van de werking van lokale netwerken met externe IP-routers te elimineren, gebruiken we de oplossingen uit paragrafen. 1.8.2 en 3.1.2.6.

Bovendien kunt u een hulpmiddel met markeringen gebruiken om paragraaf 3 van het probleem op te lossen. We implementeren het als volgt:

2.4. We leiden verkeer van lokale klanten van de routeringslijsten naar de juiste tabellen:

/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

Als resultaat ziet het er ongeveer zo uit:

Multivan en routing op Mikrotik RouterOS

3. Breng een verbinding tot stand met de ISP en schakel branded routing in

3.1. Maak een verbinding met ISP1:
3.1.1. Configureer een statisch IP-adres:

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

3.1.2. Stel statische routering in:
3.1.2.1. Voeg een standaard "noodroute" toe:

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

Opmerking. Via deze route kan verkeer van lokale processen de routebeslissingsfase passeren, ongeacht de status van de links van een van de providers. De nuance van uitgaand lokaal verkeer is dat de hoofdrouteringstabel een actieve route naar de standaardgateway moet hebben om het pakket in ieder geval ergens heen te laten gaan. Zo niet, dan wordt het pakket gewoon vernietigd.

Als gereedschapsuitbreiding poort controleren Voor een diepere analyse van de kanaalstatus raad ik aan om de recursieve routemethode te gebruiken. De essentie van de methode is dat we de router vertellen om niet rechtstreeks, maar via een tussenliggende gateway naar een pad naar zijn gateway te zoeken. 4.2.2.1, 4.2.2.2 en 4.2.2.3 zullen worden gekozen als dergelijke "test" gateways voor respectievelijk ISP1, ISP2 en ISP3.

3.1.2.2. Route naar het “verificatie” adres:

/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

Opmerking. We verlagen de bereikwaarde naar de standaard in ROS-doelbereik om 4.2.2.1 in de toekomst als een recursieve gateway te gebruiken. Ik benadruk: het bereik van de route naar het "test" -adres moet kleiner zijn dan of gelijk zijn aan het beoogde bereik van de route die naar het testadres zal verwijzen.

3.1.2.3. Recursieve standaardroute voor verkeer zonder routeringsmarkering:

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

Opmerking. De waarde distance=2 wordt gebruikt omdat ISP1 is gedeclareerd als de eerste back-up volgens de taakvoorwaarden.

3.1.2.4. Recursieve standaardroute voor verkeer met routeringsmarkering "to_isp1":

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

Opmerking. Eigenlijk beginnen we hier eindelijk de vruchten te plukken van het voorbereidende werk dat in paragraaf 2 is uitgevoerd.


Op deze route wordt al het verkeer met de gemarkeerde route "to_isp1" omgeleid naar de gateway van de eerste provider, ongeacht welke standaardgateway momenteel actief is voor de hoofdtabel.

3.1.2.5. Eerste fallback recursieve standaardroute voor ISP2 en ISP3 getagd verkeer:

/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

Opmerking. Deze routes zijn onder meer nodig om verkeer te reserveren van lokale netwerken die lid zijn van de adressenlijst “to_isp*”'

3.1.2.6. We registreren de route voor het lokale verkeer van de router naar internet via ISP1:

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

Opmerking. In combinatie met de regels uit paragraaf 1.8.2 geeft het toegang tot het gewenste kanaal met een bepaalde bron. Dit is van cruciaal belang voor het bouwen van tunnels die het IP-adres aan de lokale zijde specificeren (EoIP, IP-IP, GRE). Aangezien de regels in ip-routeregels van boven naar beneden worden uitgevoerd, tot de eerste overeenkomst van de voorwaarden, zou deze regel na de regels van clausule 1.8.2 moeten zijn.

3.1.3. We registreren de NAT-regel voor uitgaand verkeer:

/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

Opmerking. NATim alles wat uitgaat, behalve wat in het IPsec-beleid komt. Ik probeer action=masquerade niet te gebruiken, tenzij absoluut noodzakelijk. Het is langzamer en meer middelenintensief dan src-nat omdat het het NAT-adres voor elke nieuwe verbinding berekent.

3.1.4. We sturen klanten van de lijst die geen toegang hebben via andere providers rechtstreeks naar de gateway van de ISP1-provider.

/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

Opmerking. action=route heeft een hogere prioriteit en wordt toegepast vóór andere routeringsregels.


place-before=0 - plaatst onze regel als eerste in de lijst.

3.2. Maak een verbinding met ISP2.

Aangezien de ISP2-provider ons de instellingen via DHCP geeft, is het redelijk om de nodige wijzigingen aan te brengen met een script dat start wanneer de DHCP-client wordt geactiveerd:

/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

Het script zelf in het Winbox-venster:

Multivan en routing op Mikrotik RouterOS
Opmerking. Het eerste deel van het script wordt geactiveerd wanneer de lease succesvol is verkregen, het tweede - nadat de lease is vrijgegeven.Zie noot 2

3.3. We zetten een verbinding op met de ISP3 provider.

Omdat de instellingenprovider ons dynamisch geeft, is het redelijk om de nodige wijzigingen aan te brengen met scripts die starten nadat de ppp-interface is verhoogd en na de val.

3.3.1. Eerst configureren we het profiel:

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

Het script zelf in het Winbox-venster:

Multivan en routing op Mikrotik RouterOS
Opmerking. rij
/ip firewall mangle set [vind commentaar="Verbind met ISP3"] in-interface=$"interface";
stelt u in staat om het hernoemen van de interface correct af te handelen, aangezien het werkt met zijn code en niet met de weergavenaam.

3.3.2. Maak nu met behulp van het profiel een ppp-verbinding:

/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

Laten we als laatste stap de klok instellen:

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

Voor wie tot het einde leest

De voorgestelde manier om een ​​multivan te implementeren is de persoonlijke voorkeur van de auteur en is niet de enige mogelijke. De ROS-toolkit is uitgebreid en flexibel, wat aan de ene kant moeilijkheden veroorzaakt voor beginners en aan de andere kant de reden is voor zijn populariteit. Leer, probeer, ontdek nieuwe tools en oplossingen. Zo is het als toepassing van de opgedane kennis mogelijk om de tool te vervangen in deze uitvoering van de multivan check-gateway met recursieve routes naar netwatch.

Opmerkingen

  1. check-gateway - een mechanisme waarmee u de route kunt deactiveren na twee opeenvolgende mislukte controles van de gateway op beschikbaarheid. De controle wordt elke 10 seconden uitgevoerd, plus de responstime-out. In totaal ligt de werkelijke schakeltijd in het bereik van 20-30 seconden. Als een dergelijk schakelmoment niet voldoende is, is er een optie om de tool te gebruiken netwatch, waar de controletimer handmatig kan worden ingesteld. check-gateway werkt niet bij intermitterend pakketverlies op de link.

    Belangrijk! Als u een primaire route deactiveert, worden alle andere routes die ernaar verwijzen, gedeactiveerd. Daarom voor hen om aan te geven check-gateway=ping niet nodig.

  2. Het komt voor dat er een storing optreedt in het DHCP-mechanisme, dat lijkt op een client die vastzit in de vernieuwingsstatus. In dit geval zal het tweede deel van het script niet werken, maar het voorkomt niet dat het verkeer correct loopt, aangezien de status de corresponderende recursieve route volgt.
  3. ECMP (Gelijke kosten Multi-Path) - in ROS is het mogelijk om een ​​route in te stellen met meerdere gateways en dezelfde afstand. In dit geval worden verbindingen verdeeld over kanalen met behulp van het round robin-algoritme, in verhouding tot het aantal gespecificeerde gateways.

Voor de aanzet om het artikel te schrijven, hulp bij het vormgeven van de structuur en plaatsing van accenten - persoonlijke dankbaarheid aan Evgeny @jscar

Bron: www.habr.com