🥇Multivan en routering op Mikrotik RouterOS

Inleiding

De aanleiding om dit artikel te schrijven, naast het verlangen naar roem, was de verontrustende frequentie van vragen over dit onderwerp in gespecialiseerde groepen van de Nederlandstalige Telegramgemeenschap. Het artikel is gericht op beginnende beheerders van Mikrotik RouterOS (hierna ROS). Het behandelt alleen multicast, met een focus op routering. Als bonus zijn er minimaal noodzakelijke instellingen voor een veilige en handige werking. Degenen die een diepgaande verkenning van onderwerpen zoals wachtrijen, load balancing, VLAN's, bridges, meertraps diepgaande kanaalanalyse en dergelijke zoeken, kunnen beter hun tijd en moeite niet verspillen met lezen.

Brongegevens

Als proefpersoon is gekozen voor een vijfpoortenrouter van Mikrotik met ROS versie 6.45.3. Deze zal verkeer tussen twee lokale netwerken (LAN1 en LAN2) en drie providers (ISP1, ISP2, ISP3) routeren. De verbinding met ISP1 heeft een statisch 'grijs' adres, ISP2 een 'wit' adres dat via DHCP wordt verkregen, en ISP3 een 'wit' adres met PPPoE-authenticatie. Het aansluitschema is weergegeven in de afbeelding:

De taak is om de router 'MTK' in te stellen volgens het schema, zodat:

Automatische overschakeling naar de reserveprovider wordt gegarandeerd. De hoofdprovider is ISP2, de eerste reserve is ISP1, de tweede reserve is ISP3.
De toegang van LAN1 naar het internet alleen via ISP1 wordt georganiseerd.
Er moet een mogelijkheid zijn om verkeer van lokale netwerken naar het internet te routeren via de gekozen provider op basis van een address-list.
Er moet een mogelijkheid zijn om diensten vanuit het lokale netwerk naar het internet te publiceren (DSTNAT).
Configureer de firewallfilter voor een minimaal aanvaardbare beveiliging vanaf het internet.
De router moet in staat zijn om eigen verkeer via een van de drie providers te verzenden, afhankelijk van het gekozen bronadres.
Zorg voor routering van antwoordpakketten naar de verbinding waarvandaan ze zijn gekomen (inclusief LAN).

Opmerking. We zullen de router 'from scratch' instellen om te garanderen dat er geen verrassingen zijn in de variërende startconfiguraties 'out of the box' van versie tot versie. Als configuratietool is gekozen voor Winbox, waar de wijzigingen visueel zullen worden weergegeven. De instellingen worden ingevoerd via commando's in de Winbox-terminal. De fysieke aansluiting voor configuratie wordt gemaakt via een directe verbinding met de Ether5-interface.

Een paar overpeinzingen over wat een multiwan is, of het een probleem is of dat slimme mensen er een samenzwering omheen spinnen.

Een nieuwsgierige en oplettende admin die zo'n of een vergelijkbare configuratie zelf instelt, zal plotseling beseffen dat het eigenlijk al goed werkt. Jawel, zonder al die gebruikerstabellen voor routering en andere route regels die de meeste artikelen over dit onderwerp kleur geven. Laten we het testen?

Kunnen we de adressering op de interfaces en de standaard gateways instellen? Ja:

Op ISP1 hebben we het adres en de gateway ingesteld met afstand=2 en check-gateway=ping.
Bij ISP2 is de DHCP-clientconfiguratie standaard — de afstand is dus gelijk aan één.
Bij ISP3 in de instellingen van de PPPoE-client bij add-default-route=yes zetten we default-route-distance=3.

Vergeet niet NAT voor de uitgang in te stellen:

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

Uiteindelijk worden gebruikers in LAN vrolijk door de hoofdprovider ISP2 geleid en is er redundantie van de verbinding door middel van het mechanisme check gateway Zie opmerking 1

Punt 1 van de taak is gerealiseerd. Waar is de multiwan met zijn labels? Nee...

Verder. We moeten specifieke clients vanuit LAN via ISP1 uitzenden:

/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

Punten 2 en 3 van de taak zijn gerealiseerd. Labels, markeringen, route regels, waar zijn jullie?!

Moet je toegang geven tot de favoriete OpenVPN-server met het adres 172.17.17.17 voor clients uit het internet? Alstublieft:

/ip cloud set ddns-enabled=yes

Geef aan de clients als peer het outputresultaat: “:put [ip cloud get dns-name]”

We stellen de poortforwarding vanuit het internet in:

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

Punt 4 is klaar.

We configureren de firewall en andere beveiligingsmaatregelen voor punt 5, terwijl we genieten van het feit dat het voor de gebruikers al werkt en we ons naar de container met onze favoriete drank begeven...
Ah! We zijn de tunnels vergeten.

Is de L2TP-client, ingesteld volgens een gegoogeld artikel, verbonden met de favoriete Nederlandse VDS? Ja.
Is de L2TP-server met IPsec actief en maken de clients verbinding via de DNS-naam uit IP Cloud (zie boven)? Ja.
Leunend achterover in mijn stoel, nippend aan mijn drankje, kijk ik lui naar punten 6 en 7 van de taak. Denkend — hebben we dat nodig? Het werkt immers al (s)... Dus, als het eigenlijk niet nodig is, is dit het. De multiwan is gerealiseerd.

Wat is een multiwan? Het is de verbinding van meerdere internetverbindingen met één router.

Verder hoef je het artikel niet te lezen, want wat kan er nog meer zijn behalve opschepping van twijfelachtige toepasbaarheid?

Met degenen die zijn gebleven, die interesse hebben in de punten 6 en 7 van de taak, en ook het verlangen naar perfectie voelen, duiken we dieper.

De belangrijkste taak van de implementatie van de multiwan is een correcte routering van het verkeer. Dat wil zeggen: ongeacht via welke (of welke) Zie opmerking 3 provider kanaal(len) de standaardroute op onze router kijkt, moet deze een antwoord teruggeven naar precies dat kanaal waar het pakket vandaan kwam. De taak is duidelijk. Maar wat is het probleem? In een eenvoudige lokale netwerkomgeving is de taak dezelfde, maar niemand maakt zich druk over extra instellingen en ondervindt geen problemen. Het verschil is dat elke routbare knoop op het internet beschikbaar is via elk van onze kanalen, en niet via een strikt specifiek kanaal, zoals in een eenvoudige lokale omgeving. En het “probleem” is dat als we een verzoek ontvangen op IP-adres ISP3, ons antwoord zal vertrekken via kanaal ISP2, omdat dat de standaardgateway is. Het zal worden afgeworpen door de provider als ongeldig. We hebben het probleem vastgesteld. Hoe op te lossen?

We splitsen de oplossing in drie fasen:

Voorbereidende configuratie. In deze fase worden de basisinstellingen van de router ingesteld: lokaal netwerk, firewall, address lists, hairpin NAT, enz.
Multiwan. In deze fase worden de benodigde verbindingen gemarkeerd en gesorteerd in de routeringtabel.
Verbinden met ISP. In deze fase worden de interfaces ingesteld die verbinding met het internet mogelijk maken, en wordt de routering en het mechanisme voor het redunderen van internetkanalen ingeschakeld.

1. Voorbereidende configuratie

1.1. We wissen de configuratie van de router met het commando:

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

we stemmen in met “Dangerous! Reset anyway? [y/N]:” en, na de herstart, verbinden we via Winbox op MAC. In deze fase zijn de configuratie en de gebruikersdatabase gewist.

1.2. We creëren een nieuwe gebruiker:

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

we loggen in als deze gebruiker en verwijderen de standaardgebruiker:

/user remove admin

Opmerking. Het verwijderen en niet uitschakelen van de standaardgebruiker beschouwt de auteur als veiliger en raadt dit aan.

1.3. We creëren basis interface lists voor gemakkelijke bediening in de firewall, discovery-instellingen en andere MAC-servers:

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

We ondertekenen de interfaces met opmerkingen

/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 vullen de interface lists 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 is de moeite waard om begrijpelijke opmerkingen te schrijven; de tijd die hieraan besteed wordt, bespaart veel moeite tijdens het troubleshooten en vergemakkelijkt het begrip van de configuratie.

De auteur acht het noodzakelijk om, ter beveiliging, de interface ether3 toe te voegen aan de interface lijst "WAN", ondanks het feit dat er geen IP-protocol overheen zal lopen.

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

1.4. Verberg de router voor detectie van omringende netwerken en beheer vanuit de netwerken van de providers op basis van MAC-adressen:

/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. Creëer een minimaal aantal firewall-filterregels voor de bescherming van de router:

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

(deze regel zorgt voor toestemming voor gevestigde en verwante verbindingen, die zowel vanuit aangesloten netwerken als de router zelf zijn geïnitieerd)

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

(ping en niet alleen ping. Alle ICMP-verkeer is toegestaan op inkomend. Zeer nuttig voor het opsporen van MTU-problemen)

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

(de sluitregel voor de input-keten verbiedt al het andere dat van het internet binnenkomt)

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

(deze regel staat gevestigde en verwante verbindingen toe die door de router heen gaan)

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

(deze regel reset verbindingen met connection-state=invalid die door de router gaan. Dit wordt sterk aanbevolen door Mikrotik, maar kan in enkele zeldzame gevallen 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

(deze regel verbiedt pakketten die van het internet komen en de dstnat-procedure niet hebben doorlopen, om door de router te gaan. Dit beschermt lokale netwerken tegen kwaadwillenden die, binnen hetzelfde broadcast-domein als onze externe netwerken, onze externe IP's als gateway willen opgeven en zo onze lokale netwerken willen onderzoeken.)

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

1.6. Maak een lijst met niet-routerbare 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 van adressen en netwerken die niet in het internet worden gerouteerd en dus zullen we dit ook naleven.)

Opmerking. De lijst kan veranderen, dus ik raad aan om regelmatig de actualiteit 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 zijn er dynamische servers hebben prioriteit boven statisch ingestelde. Een verzoek om het hostname wordt naar de eerste server in de volgorde van de lijst gestuurd. Als de huidige server niet beschikbaar is, wordt overgestapt naar de volgende server. De timeout is lang — meer dan 5 seconden. Terugkeren naar de ‘gevallen server’ gebeurt automatisch niet zodra deze weer operationeel is. Gezien dit algoritme en de aanwezigheid van een multivan, raadt de auteur aan om servers die door providers worden geleverd niet te gebruiken.

1.8. Stel het lokale netwerk in.
1.8.1. Configureer statische IP-adressen op de interfaces van lokale netwerken:

/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. Stel route regels in voor onze lokale netwerken via de hoofdroutingstabel:

/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 eenvoudige en snelle manieren om toegang te krijgen tot de adressen van lokale netwerken met bronnen van externe IP-adressen van de routerinterfaces, waarvoor geen standaardroute bestaat.

1.8.3. Zet Hairpin NAT aan 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. Dit maakt het mogelijk om via een extern IP toegang te krijgen tot onze middelen (dstnat) terwijl we binnen het netwerk zijn.

2. Eigenlijk de implementatie van de juiste multivan

Om de taak 'antwoord geven van waaruit gevraagd is' op te lossen, gebruiken we twee instrumenten van ROS: connection mark en routing mark. Connection mark laat ons de gewenste verbinding markeren en later met deze markering werken als voorwaarde voor toepassing routing mark. En al met routing mark kan gewerkt worden in ip route en route regels. We hebben de instrumenten begrepen, nu moeten we beslissen welke verbindingen te markeren — stap één, en waar precies te markeren — stap twee.

Met de eerste is het eenvoudig — we moeten alle verbindingen markeren die op de router vanuit het Internet komen via de overeenkomstige verbinding. In ons geval zouden dit drie markeringen zijn (aantal verbindingen): 'conn_isp1', 'conn_isp2' en 'conn_isp3'.

De nuance met de tweede is dat binnenkomende verbindingen van twee soorten zullen zijn: transit en die welke voor de router zelf bestemd zijn. Het mechanisme van connection mark werkt in de tabel mangle. Laten we de beweging van een pakket beschouwen aan de hand van een vereenvoudigd diagram, vriendelijk samengesteld door specialisten van de site mikrotik-trainings.com (geen reclame):

Volgen we de pijlen, dan zien we dat het pakket dat binnenkomt in “input interface”, de keten “Prerouting” doorloopt en pas daarna wordt gesplitst in transit en lokaal in het blok “Routing Decision”. Daarom, om twee vliegen in één klap te slaan, betrekken we Connection Mark in de tabel Mangle Prerouting ketens Prerouting.

Opmerking. In ROS worden de labels “Routing mark” vermeld in de sectie Ip/Routes/Rules als “Table”, en in andere secties als “Routing Mark”. Dit kan enige verwarring veroorzaken, maar in wezen is het hetzelfde, en het is gelijk aan rt_tables in iproute2 op Linux.

2.1. We markeren inkomende verbindingen van elke provider:

/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 te voorkomen dat al gemarkeerde verbindingen opnieuw worden gemarkeerd, gebruik ik de voorwaarde connection-mark=no-mark in plaats van connection-state=new, omdat ik dit als correcter beschouw, evenals de afwijzing van drop invalid verbindingen in de inputfilter.

passthrough=no — omdat bij deze implementatiemethode de re-markering wordt uitgesloten en voor versnelling kan worden gestopt met het doorlopen van regels na de eerste overeenkomst.

Houd er rekening mee dat we momenteel niet ingrijpen in de routering. We zijn nu alleen bezig met voorbereidende stappen. De volgende fase van implementatie zal de verwerking van transitverkeer zijn dat terugkomt via een geconfigureerde verbinding van de ontvanger in het lokale netwerk. Dus, met betrekking tot de pakketten die (zie diagram) door de router zijn gegaan op de volgende route:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” en bij hun ontvanger in het lokale netwerk zijn aangekomen.

Belangrijk! In ROS is er geen logische scheiding tussen externe en interne interfaces. Als we het pad van het antwoordpakket volgen volgens het gegeven diagram, dan zal het dezelfde logische route volgen als de aanvraag:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” gewoon voor de aanvraag “Input Interface” was de ISP-interface, en voor het antwoord — LAN

2.2. We sturen het responsieve transitverkeer via 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 uit het lokale netwerk en dst-address-type=!local dat geen bestemming heeft aan de adressen van de router zelf.

Hetzelfde geldt voor lokale pakketten die op de router zijn aangekomen via de route:

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

Belangrijk! Het antwoord zal het volgende pad volgen:

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

2.3. We sturen het responsieve lokale verkeer via 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 deze fase kan de taak om het antwoord te verzenden via het kanaal van het internet, van waaruit de aanvraag kwam, als voltooid worden beschouwd. Alles is gemarkeerd, gelabeld en klaar om te worden gerouteerd.
Een uitstekende ‘neven’ effect van deze configuratie is de mogelijkheid om DSNAT-poortdoorsturing te gebruiken met beide (ISP2, ISP3) providers tegelijkertijd. Niet bij allemaal, want bij ISP1 hebben we een niet-routerend adres. Dit effect is belangrijk, bijvoorbeeld voor een mailserver met twee MX-records, die naar verschillende internetkanalen kijken.

Om de nuances van lokale netwerken met externe IP's van de router op te lossen, gebruiken we oplossingen uit secties 1.8.2 en 3.1.2.6.

Daarnaast kunnen we het hulpmiddel met labels inzetten om het punt 3 van de taak op te lossen. We implementeerden het als volgt:

2.4. We sturen het verkeer van lokale clients uit de routeringlijsten naar de bijbehorende 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

Uiteindelijk ziet het er ongeveer zo uit:

3. We configureren de verbinding met ISP en gebruiken merkgebaseerde routering.

3.1. We configureren de verbinding met ISP1:
3.1.1. We configureren het statische IP-adres:

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

3.1.2. We configureren de statische routering:
3.1.2.1. We voegen de ‘nood’ standaardroute toe:

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

Opmerking. Deze route stelt verkeer van lokale processen in staat om de Route Decision-fase door te gaan, ongeacht de status van de verbindingen van een van de providers. De nuance van uitgaand lokaal verkeer is dat om een pakket ergens heen te sturen, er een actieve route naar de standaardgateway in de hoofdtabel van de routering moet zijn. Als die er niet is, wordt het pakket gewoon vernietigd.

Als uitbreiding van het hulpmiddel check gateway voor een diepere analyse van de status van de verbinding stel ik voor om de methode van recursieve routes te gebruiken. Het idee van de methode is dat we de router vragen om een pad naar zijn gateway niet rechtstreeks, maar via een tussenliggende gateway te zoeken. De ‘controle’ gateways zijn 4.2.2.1, 4.2.2.2 en 4.2.2.3 voor respectievelijk ISP1, ISP2 en ISP3.

3.1.2.2. Route naar het ‘controle’ 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 scope-waarde naar de standaard in ROS target scope, zodat we later 4.2.2.1 kunnen gebruiken als recursieve gateway. Ik benadruk: de scope van de route naar het ‘controle’ adres moet kleiner of gelijk zijn aan de target scope van de route die naar de controle verwijst.

3.1.2.3. Standaard recursieve route voor verkeer zonder routing mark:

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

Opmerking. De waarde distance=2 wordt gebruikt omdat ISP1 volgens de voorwaarden van de taak als eerste back-up is opgegeven.

3.1.2.4. Standaard recursieve route voor verkeer met routing mark ‘to_isp1’:

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

Opmerking. Hier beginnen we eindelijk te profiteren van het voorbereidende werk dat in punt 2 is verricht.

Via deze route wordt al het verkeer met de markering 'to_isp1' naar de gateway van de eerste provider geleid, ongeacht welke standaardgateway momenteel actief is voor de hoofdtable.

3.1.2.5. De eerste reserve recursieve standaardroute voor gemarkeerd verkeer van de providers ISP2 en 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

Opmerking. Deze routes zijn onder andere nodig voor het reserveren van verkeer van lokale netwerken die deel uitmaken van het adreslijst 'to_isp*'.

3.1.2.6. We schrijven de route voor lokaal routerverkeer naar het 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 punt 1.8.2, wordt de toegang tot het juiste kanaal met de gedefinieerde bron verzekerd. Dit is cruciaal voor het opzetten van tunnels, waarin het IP-adres van de lokale zijde wordt opgegeven (EoIP, IP-IP, GRE). Aangezien de regels in ip route rules van boven naar beneden worden uitgevoerd, tot de eerste overeenstemming van voorwaarden, moet deze regel na de regels uit punt 1.8.2 komen.

3.1.3. We schrijven een 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. NAT toepassen op al het uitgaande verkeer, behalve datgene wat valt onder de IPsec-beleidsregels. Ik probeer action=masquerade niet zonder dringende noodzaak te gebruiken. Het is trager en intensiever qua middelen dan src-nat, omdat het voor elke nieuwe verbinding het adres voor NAT berekent.

3.1.4. We sturen klanten op de lijst die geen toegang hebben via andere providers onmiddellijk naar de gateway van provider 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

Opmerking. action=route heeft een hogere prioriteit en wordt eerder toegepast dan de andere routeringsregels.

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

3.2. We configureren de verbinding met ISP2.

Aangezien provider ISP2 zijn instellingen via DHCP verstrekt, is het verstandig om de benodigde wijzigingen te doen met een script dat wordt gestart 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:

Opmerking. Het eerste deel van het script wordt uitgevoerd bij succesvolle huurontvangst, het tweede deel na het vrijgeven van de huur.Zie opmerking 2.

3.3. We configureren de verbinding met provider ISP3.

Aangezien provider dynamische instellingen levert, is het verstandig om de benodigde wijzigingen te doen met scripts die worden gestart na het opzetten en na het neerval van de ppp-interface.

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:

Opmerking. String
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
maakt het mogelijk om hernoemingen in de interface correct te verwerken, omdat het met de code werkt en niet met de weergegeven naam.

3.3.2. Laten we nu een PPP-verbinding maken met behulp van het profiel:

/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

Als laatste stap stellen we de klok in:

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

Voor degenen die tot het einde hebben gelezen

De voorgestelde manier van het implementeren van een multivan is een persoonlijke voorkeur van de auteur en is niet de enige mogelijkheid. De ROS-toolkit is uitgebreid en flexibel, wat aan de ene kant moeilijkheden voor beginners met zich meebrengt, maar aan de andere kant de reden van de populariteit is. Leer, experimenteer, ontdek nieuwe tools en oplossingen. Bijvoorbeeld, in deze implementatie van de multivan kan het hulpmiddel vervangen worden door Check-gateway met recursieve routes voor Netwatch.

Opmerkingen

Check-gateway is een mechanisme dat het mogelijk maakt om een route te deactiveren na twee opeenvolgende mislukte toegangspunten op de beschikbaarheid van de gateway. De controle gebeurt om de 10 seconden, plus een responstimeout. Totale timing van de omschakeling ligt tussen de 20 en 30 seconden. Als deze omschakeltiming niet voldoende is, is er een optie om het hulpmiddel te gebruiken Netwatch, waar de controle-timer handmatig kan worden ingesteld. Het mechanisme Check-gateway werpt geen foutmeldingen op bij periodiek pakketverlies in de verbinding.
Belangrijk! Deactivering van de hoofdroutes heeft de deactivatie van alle andere routes tot gevolg die erop verwijzen. Dus voor hen is het niet nodig om check-gateway=ping op te geven.
Soms komt het voor dat er een storing optreedt in de werking van DHCP, wat eruitziet als een klant die vastzit in de status renew. In dat geval werkt het tweede deel van het script niet, maar het is niet schadelijk voor het verkeer, omdat de status de overeenkomstige recursieve route volgt.
ECMP (Equal Cost Multi-Path) is in ROS mogelijk om een route met meerdere gateways en dezelfde afstand op te geven. In dat geval zullen verbindingen worden verdeeld over de verbindingen met behulp van een round-robin-algoritme, evenredig aan het aantal opgegeven gateways.

Voor de inspiratie om het artikel te schrijven, hulp bij het vormen van de structuur en het plaatsen van accenten — een persoonlijke dank aan Evgeny @jscar

Bron: habr.com