Introducere
Decizia de a scrie acest articol a fost determinată, pe lângă vanitate, de frecvența descurajantă a întrebărilor pe această temă în grupurile specializate ale comunității de vorbitori de limba rusă de pe Telegram. Articolul se adresează administratorilor începători de Mikrotik RouterOS (denumit în continuare ROS). În el se discută doar despre multicast, punând accent pe rutare. Ca bonus, sunt incluse setările minime necesare pentru a asigura un lucru sigur și convenabil. Cei care caută detalii despre cozi, echilibrarea încărcării, VLAN-uri, bridge-uri, analize profunde ale stării canalului și alte subiecte similare — nu ar trebui să își piardă timpul și energia citind.
Datele originale
Pentru experiment, a fost ales un router Mikrotik cu cinci porturi, cu ROS versiunea 6.45.3. Acesta va ruta traficul între două rețele locale (LAN1 și LAN2) și trei furnizori de internet (ISP1, ISP2, ISP3). Canalul către ISP1 are o adresă „gri” statică, ISP2 — o adresă „albă” obținută prin DHCP, ISP3 — o adresă „albă” cu autorizare PPPoE. Schema de conectare este prezentată în imagine:
Sarcina este să configurăm routerul “MTK” conform schemei, astfel încât să:
- Asigurăm comutarea automată pe furnizorul de rezervă. Furnizorul principal — ISP2, primul rezerv — ISP1, al doilea rezerv — ISP3.
- Organizăm ieșirea rețelei LAN1 pe Internet doar prin ISP1.
- Prevedem posibilitatea de a ruta traficul din rețelele locale pe Internet prin furnizorul ales, pe baza address-list.
- Prevedem posibilitatea publicării serviciilor din rețeaua locală pe Internet (DSTNAT).
- Configurăm filtrul de firewall pentru a asigura o securitate minimă din partea Internetului.
- Routerul ar trebui să poată emite propriul trafic prin oricare dintre cei trei furnizori, în funcție de adresa sursă aleasă.
- Asigurăm rutarea pachetelor de răspuns în canalul din care au venit (inclusiv LAN).
Observație. Vom configura routerul „de la zero”, pentru a garanta absența surprizelor în configurațiile inițiale care se schimbă de la o versiune la alta „din cutie”. Ca instrument de configurare, am ales Winbox, care va afișa vizual modificările. Setările în sine vor fi introduse prin comenzi în terminalul Winbox. Conexiunea fizică pentru configurare se face printr-o conexiune directă la interfața Ether5.
Câteva considerații despre ce este un multivan, dacă este o problemă sau dacă există minți iscusite care țes conspiratii în jur.
Un administrator curios și atent, configurând singur un astfel de schemă sau similar, își dă brusc seama că totul funcționează normal. Da-da, fără aceste tabele de rutare personalizate și alte reguli de rutare cu care abundă majoritatea articolelor pe acest subiect. Să verificăm?
Putem configura adresarea pe interfețe și gateway-uri implicit? Da:
Pe ISP1 am configurat adresa și gateway-ul cu distance=2 și check-gateway=ping.
Pe ISP2, configurația clientului DHCP implicit — prin urmare, distanța va fi egală cu unu.
Pe ISP3, în setările clientului PPPoE, la add-default-route=yes setăm default-route-distance=3.
Nu uităm să scriem NAT pe ieșire:
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN
În final, utilizatorii din rețea se conectează vesel prin providerul principal ISP2 și există redundanță prin mecanismul check gateway Vezi nota 1
Punctul 1 al sarcinii este implementat. Unde este multivanul cu etichetele lui? Nu...
Mai departe. Trebuie să eliberăm clienți specifici din LAN prin 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
Punctele 2 și 3 ale sarcinii sunt implementate. Etichete, marcaje, reguli de rutare, unde sunteți?!
Trebuie să oferim acces la serverul nostru favorizat OpenVPN cu adresa 172.17.17.17 pentru clienții din Internet? Iată:
/ip cloud set ddns-enabled=yes
Clienților, ca peer, le dăm rezultatul ieșirii: “:put [ip cloud get dns-name]”
Configurăm redirecționarea portului din internet:
/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17
Punctul 4 este gata.
Configurăm firewall-ul și alte măsuri de securitate pentru punctul 5, bucurându-ne în același timp că utilizatorii au deja totul funcțional și ne întindem spre recipientul cu băutura preferată...
Ah! Am uitat de tuneluri.
Clientul l2tp, configurat conform unui articol căutat pe Google, s-a conectat la VDS-ul olandez favorizat? Da.
Serverul l2tp cu IPsec este activat și clienții se conectează prin numele DNS din IP Cloud (vezi mai sus.)? Da.
Avându-ne confortabil cu spatele în scaun, sorbind din băutură, privim cu lene punctele 6 și 7 ale sarcinii. Ne gândim — oare ne trebuie asta? Totul funcționează (cu)... Așadar, dacă nu este necesar, atunci aici se termină. Multivanul este implementat.
Ce este un multivan? Este conectarea mai multor canale de Internet la un singur router.
Articolul poate fi citit mai departe, deoarece ce altceva ar putea fi în afară de exibicionism cu aplicabilitate îndoielnică?
Cei care au rămas, cei interesați de punctele 6 și 7 ale sarcinii și care resimt mâncărimea perfecționismului, ne adâncim mai departe.
Principala provocare în implementarea multiwan-ului este rutarea corectă a traficului. Cu alte cuvinte: indiferent de canalul (sau canalele) de la furnizor pe care îl urmărește ruta implicită pe routerul nostru, acesta trebuie să returneze răspunsul exact pe canalul de pe care a venit pachetul. Sarcina este clară. Unde este problema? Într-o rețea locală simplă, sarcina este aceeași, dar nimeni nu se complică cu setări suplimentare și nu resimte vreo dificultate. Diferența este că orice nod rutabil din Internet este accesibil prin fiecare dintre canalele noastre, și nu prin unul strict specific, cum ar fi în rețeaua locală simplă. Și „dificultatea” constă în faptul că dacă primim o cerere pentru adresa IP a ISP3, atunci, în cazul nostru, răspunsul va pleca prin canalul ISP2, deoarece acolo este direcționat gateway-ul implicit. Acesta va pleca și va fi respins de furnizor ca fiind incorect. Problema a fost identificată. Cum o rezolvăm?
Vom împărți soluția în trei etape:
- Configurare preliminară. În această etapă, vor fi setate configurațiile de bază ale routerului: rețeaua locală, firewall-ul, listele de adrese, hairpin NAT etc.
- Multiwan. În această etapă, conexiunile necesare vor fi marcate și sortate în tabelele de rutare.
- Conectarea la ISP. În această etapă, vor fi configurate interfețele ce asigură conectarea la Internet, va fi activată rutarea și mecanismul de rezervare a canalelor de Internet.
1. Configurare preliminară
1.1. Curățăm configurația routerului cu comanda:
/system reset-configuration skip-backup=yes no-defaults=yessuntem de acord cu „Dangerous! Reset anyway? [y/N]:” și, după restart, ne conectăm cu Winbox pe MAC. În această etapă, configurația și baza de utilizatori sunt curățate.
1.2. Creăm un nou utilizator:
/user add group=full name=knight password=ultrasecret comment=”Not horse”ne autentificăm sub el și ștergem utilizatorul implicit:
/user remove adminObservație. Anume ștergerea și nu dezactivarea utilizatorului implicit este considerată de autor mai sigură și recomandată pentru utilizare.
1.3. Creăm listele de interfețe de bază pentru o operare mai ușoară în firewall, setările de descoperire și alte servere MAC:
/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"Documentăm interfețele cu comentarii
/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"și completăm listele de interfețe:
/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"
Observație. Este bine să scriem comentarii clare; timpul investit în acest lucru facilitează foarte mult depanarea și înțelegerea configurației.
Autorul consideră necesar, din motive de siguranță, să adauge în lista de interfețe „WAN” interfața ether3, chiar dacă prin aceasta nu va circula protocolul IP.
Nu uitați că, după ce interfața PPP va fi activată pe ether3, va trebui să o adăugăm de asemenea în lista de interfețe „WAN”.
1.4. Ascundem routerul de detectarea vecinătății și gestionarea din rețelele furnizorilor prin 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=LAN1.5. Creăm un set minim de reguli de filtrare a firewall-ului pentru a proteja routerul:
/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow"
connection-state=established,related,untracked(regula permite conexiuni stabilite și conexiuni înrudite, inițiate atât din rețelele conectate, cât și de router)
/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp(ping și nu numai ping. Tot ICMP este permis la intrare. Foarte util pentru a identifica problemele cu MTU)
/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN(regula de închidere a lanțului de input interzice tot ce vine din Internet)
/ip firewall filter add action=accept chain=forward
comment="Established, Related, Untracked allow"
connection-state=established,related,untracked(regula permite conexiuni stabilite și conexiuni înrudite care trec prin router)
/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid(regula resetează conexiunile cu state=invalid care trec prin router. Este recomandată insistent de Mikrotik, dar în unele situații rare poate bloca traficul util)
/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(regula interzice pachetelor care vin din Internet și nu au trecut prin procedura de dstnat să treacă prin router. Aceasta va proteja rețelele locale de atacatori care, aflându-se în același domeniu de difuzare cu rețelele noastre externe, ar putea să-și scrie IP-urile externe ca gateway și, astfel, să încerce să „exploreze” rețelele noastre locale.)
Observație. Să considerăm că rețelele LAN1 și LAN2 sunt de încredere și traficul dintre ele și de la ele nu este filtrat.
1.6. Creăm o listă cu rețelele nerețelizable:
/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(Aceasta este o listă de adrese și rețele care nu sunt rutate în Internet și, prin urmare, ne vom conforma și noi acesteia.)
Observație. Lista poate suferi modificări, așa că vă recomand să verificați periodic actualitatea.
1.7. Configurăm DNS pentru routerul însuși:
/ip dns set servers=1.1.1.1,8.8.8.8Observație. În versiunea actuală a ROS, dinamic servere au prioritate față de cele definite static. Cererea de rezolvare a numelui este trimisă primului server conform ordinii din listă. Trecerea la serverul următor se face în cazul în care cel curent nu este disponibil. Timeout-ul este mare — peste 5 sec. Întoarcerea automată, atunci când serverul 'căzut' își reia activitatea, nu se produce. Având în vedere acest algoritm și disponibilitatea mulitwan-ului, autorul recomandă să nu se utilizeze serverele oferite de furnizori.
1.8. Configurăm rețeaua locală.
1.8.1. Configurăm adrese IP statice pe interfețele rețelelor locale:
/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. Stabilim reguli de rutare către rețelele noastre locale prin tabela principală de rutare:
/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"Observație. Aceasta este una dintre metodele simple și rapide de a accesa adresele rețelelor locale prin sursele adreselor IP externe ale interfețelor routerului, prin care nu se face rutare implicit.
1.8.3. Activăm Hairpin NAT pentru LAN1 și 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.0Observație. Aceasta permite accesul prin IP-ul extern la resursele noastre (dstnat), aflându-ne în interiorul rețelei.
2. Practic, implementarea acelui corect multivan
Pentru a rezolva problema “a răspunde de unde a fost întrebat” vom folosi două instrumente ROS: mark de conexiune și mark de rutare. Mark-ul de conexiune permite marcare conexiunea dorită și utilizarea ulterioară a acestei etichete ca o condiție pentru aplicare mark de rutare. Iar deja cu mark de rutare se poate lucra în ip route și reguli de rutare. Cu instrumentele ne-am lămurit, acum trebuie să decidem ce conexiuni să marcăm — un, unde anume să marcăm — doi.
Cu primul este simplu — trebuie să marcăm toate conexiunile care vin la router din Internet pe canalul corespunzător. În cazul nostru, vor fi trei etichete (în funcție de numărul canalelor): “conn_isp1”, “conn_isp2” și “conn_isp3”.
Nuantă cu al doilea constă în faptul că conexiunile intrante vor fi de două tipuri: tranzit și cele destinate routerului însăși. Mecanismul mark-ului de conexiune funcționează în tabela mangle. Să analizăm mișcarea pachetului pe o diagramă simplificată, adunată cu amabilitate de specialiștii site-ului mikrotik-trainings.com (nu este publicitate):
Urmând săgețile, vedem că pachetul care ajunge în “input interface” trece prin lanțul “Prerouting” și abia apoi se împarte în tranzit și local în blocul “Routing Decision”. Prin urmare, pentru a ucide doi iepuri, implicăm Mark-ul de Conexiune din tabel Mangle Prerouting lanțuri Prerouting.
Observație. În ROS, etichetele „Routing mark” sunt specificate în secțiunea Ip/Routes/Rules ca „Table”, iar în celelalte secțiuni, ca „Routing Mark”. Aceasta poate crea ceva confuzie în înțelegere, dar, în esență, este același lucru, fiind un echivalent al rt_tables în iproute2 pe Linux.
2.1. Etichetăm conexiunile de intrare de la fiecare dintre furnizori:
/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=noObservație. Pentru a nu eticheta deja etichetate conexiuni, folosesc condiția connection-mark=no-mark în loc de connection-state=new, pentru că consider că este mai corect, așa cum se renunță la drop invalid conexiunile în filtrul input.
passthrough=no — pentru că, în acest mod de implementare, reetichetaerea este exclusă și pentru a accelera, se poate întrerupe căutarea regulilor după prima potrivire.
Trebuie să avem în vedere că, deocamdată, nu intervenim în routing. În prezent, se desfășoară doar etapele de pregătire. Următoarea etapă de implementare va fi procesarea traficului de tranzit, care se întoarce printr-o conexiune stabilită de la destinatar în rețeaua locală. Adică, a acelui pachete care (vezi diagramele) au trecut prin router pe calea:
„Input Interface”=>„Prerouting”=>„Routing Decision”=>„Forward”=>„Post Routing”=>„Output Interface” și au ajuns la destinatarul lor în rețeaua locală.
Important! În ROS nu există o împărțire logică între interfețele externe și interne. Dacă urmărim parcursul pachetului de răspuns pe diagrama dată, el va urma aceeași cale logică ca și cererea:
„Input Interface”=>„Prerouting”=>„Routing Decision”=>„Forward”=>„Post Routing”=>„Output Interface” pur și simplu pentru cererea „Input Interface” a fost interfața ISP, iar pentru răspuns — LAN
2.2. Direcționăm traficul de răspuns de tranzit prin tabelele corespunzătoare de routare:
/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=noObservație. in-interface-list=!WAN — lucrăm doar cu traficul din rețeaua locală și dst-address-type=!local care nu are adresa de destinație a interfețelor routerului.
La fel și pentru pachetele locale, care au ajuns la router pe calea:
„Input Interface”=>„Prerouting”=>„Routing Decision”=>„Input”=>„Local Process”
Important! Răspunsul va urma următoarea cale:
„Local Process”=>„Routing Decision”=>„Output”=>„Post Routing”=>„Output Interface”
2.3. Direcționăm traficul local de răspuns prin tabelele corespunzătoare de routare:
/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În această etapă, sarcina de a pregăti răspunsul pentru canalul Internet de la care a venit cererea poate fi considerată rezolvată. Totul este etichetat, marcat și gata să fie routat.
O „efect secundar“ excelent al acestei configurații este posibilitatea de a utiliza port forwarding DSNAT simultan de la ambele (ISP2, ISP3) furnizori. Nu pe toate, deoarece pe ISP1 avem o adresă nerutabilă. Acest efect este important, de exemplu, pentru un server de email cu două MX, care se uită pe canale diferite către internet.
Pentru a rezolva nuanțele funcționării rețelelor locale cu IP externe ale routerului, folosim soluțiile din punctele 1.8.2 și 3.1.2.6.
În plus, putem folosi un instrument de marcare și pentru soluționarea punctului 3 al sarcinii. Implementăm astfel:
2.4. Direcționăm traficul de la clienții locali din listele de rutare către tabelele corespunzătoare:
/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_ISP3Ca rezultat, arată aproximativ astfel:
3. Configurăm conexiunea la ISP și activăm rutarea pe marcaje
3.1. Configurăm conexiunea la ISP1:
3.1.1. Configurăm adresa IP statică:
/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"3.1.2. Configurăm rutarea statică:
3.1.2.1. Adăugăm o rută de urgență implicită:
/ip route add comment="Emergency route" distance=254 type=blackholeObservație. Această rută permite traficului de la procesele locale să treacă etapa de decizie de rutare, indiferent de starea canalelor oricăruia dintre furnizori. Nuanța traficului local ieșitor constă în faptul că, pentru ca un pachet să se deplaseze, în tabela principală de rutare trebuie să existe o rută activă către gateway-ul implicit. Dacă nu este, pachetul va fi pur și simplu distrus.
Ca o extensie a instrumentului check gateway pentru o analiză mai profundă a stării canalului, propun să folosim metoda rutelor recursive. Esența metodei constă în faptul că spunem routerului să caute un drum către gateway-ul său nu direct, ci printr-un gateway intermediar. Ca „gateway-uri de verificare” vor fi alese 4.2.2.1, 4.2.2.2 și 4.2.2.3, respectiv pentru ISP1, ISP2 și ISP3.
3.1.2.2. Ruta către adresa „de verificare”:
/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=10Observație. Scopul valorii este redus la valoarea implicită în ROS target scope, pentru a folosi în continuare 4.2.2.1 ca gateway recursiv. Sublinierez: scopul rutei către adresa „de verificare” trebuie să fie mai mic sau egal cu scopul țintă al rutei care va face referire la verificare.
3.1.2.3. Ruta recursivă implicită pentru traficul fără routing mark:
/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1Observație. Valoarea distance=2 este utilizată pentru că ISP1, conform cerințelor sarcinii, a fost declarat ca primul rezervat.
3.1.2.4. Ruta recursivă implicită pentru traficul cu routing mark „to_isp1“:
/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1
routing-mark=to_isp1Observație. Aici, în sfârșit, începem să folosim roadele muncii preparatorii efectuate în punctul 2.
Pe acest traseu, tot traficul care are marca route "to_isp1" va fi direcționat către gateway-ul primului provider, indiferent de care gateway este activ în prezent ca implicit pentru tabela principală.
3.1.2.5. Prima rută de rezervă recursivă implicită pentru traficul marcat al providerilor ISP2 și 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_isp3Observație. Aceste rute sunt necesare, inclusiv pentru rezervarea traficului din rețelele locale care sunt membri ai listei de adrese "to_isp*".
3.1.2.6. Configurăm ruta pentru traficul local al routerului către internet prin ISP1:
/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1Observație. Împreună cu regulile din punctul 1.8.2, asigurăm ieșirea pe canalul dorit cu sursa specificată. Aceasta este critică pentru construirea tunelurilor, în care se definește adresa IP a părții locale (EoIP, IP-IP, GRE). Deoarece regulile din ip route rules sunt executate de sus în jos, până la prima potrivire a condițiilor, această regulă trebuie să fie după regulile din punctul 1.8.2.
3.1.3. Configurăm o regulă NAT pentru traficul de ieșire:
/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.2Observație. NAT pentru tot traficul de ieșire, cu excepția celor care intră în politicile IPsec. Încerc să nu folosesc action=masquerade fără o necesitate extremă. Funcționează mai încet și mai consumator de resurse decât src-nat, deoarece pentru fiecare nouă conexiune calculează adresa pentru NAT.
3.1.4. Direcționăm clienții din lista căror le este interzisă ieșirea prin ceilalți provideri direct către gateway-ul providerului 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=0Observație. action=route are prioritate mai mare și se aplică înaintea altor reguli de rutare.
place-before=0 — plasează regula noastră prima în listă.
3.2. Configurăm conexiunea la ISP2.
Deoarece providerul ISP2 ne furnizează setările prin DHCP, este logic să facem modificările necesare printr-un script care pornește când clientul DHCP activează:
/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=noScriptul însuși în fereastra Winbox:
Observație. Prima parte a scriptului se activează la primirea cu succes a închirierii, iar a doua — după eliberarea acesteia.Vezi nota 2
3.3. Configurăm conexiunea la providerul ISP3.
Deoarece providerul ne furnizează setările în mod dinamic, este logic să facem modificările necesare prin scripturi care pornesc după activarea și dezactivarea interfeței ppp.
3.3.1. Mai întâi configurăm profilul:
/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"Scriptul însuși în fereastra Winbox:
Observație. Șirul
/ip firewall mangle set [find comment=«Connmark in from ISP3»] in-interface=$«interface»;
permite gestionarea corectă a redenumirii interfeței, deoarece lucrează cu codul său și nu cu numele afişat.
3.3.2. Acum, folosind profilul, creăm o conexiune ppp:
/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client user=isp3_clientCa ultim detaliu, să configurăm ceasurile:
/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.orgPentru cei care au citit până la final
Metoda sugerată de implementare a multivanului este o preferință personală a autorului și nu reprezintă singura variantă posibilă. Instrumentele ROS sunt extinse și flexibile, ceea ce, pe de o parte, provoacă dificultăți pentru începători, iar pe de altă parte, este motivul popularității sale. Studiați, experimentați, descoperiți noi instrumente și soluții. De exemplu, în această implementare a multivanului, instrumentul poate fi înlocuit. Check-gateway cu rute recursive pe Netwatch.
Note
- Check-gateway — mecanismul care permite dezactivarea unei rute după două verificări consecutive nereușite ale disponibilității gateway-ului. Verificarea se face o dată la 10 secunde, plus timeout-ul răspunsului. Deci, timpul efectiv de comutare este în intervalul 20-30 de secunde. Dacă un astfel de timp de comutare nu este suficient, există opțiunea de a folosi instrumentul Netwatch, unde timerul de verificare poate fi setat manual. Mecanismul Check-gateway nu se activează atunci când apar pierderi periodice de pachete în canal.
Important! Dezactivarea rutei principale implică dezactivarea tuturor celorlalte rute care depind de aceasta. Prin urmare, pentru ele nu este necesar să specificați check-gateway=ping nu este necesar.
- Se întâmplă ca în mecanismul de funcționare DHCP să apară o eroare, care se manifestă ca un client blocat în starea renew. În acest caz, a doua parte a scriptului nu va funcționa, dar nu va împiedica circulația corectă a traficului, deoarece starea este monitorizată de ruta recursivă corespunzătoare.
- ECMP (Equal Cost Multi-Path) — în ROS există posibilitatea de a defini o rută cu mai multe gateway-uri și aceeași distanță. În acest caz, conexiunile vor fi distribuite pe canale, folosind algoritmul round robin, proporțional cu numărul de gateway-uri specificate.
Pentru impulsul de a scrie articolul, ajutorul în formarea structurii acestuia și în stabilirea accentelor — o recunoștință personală lui Evgeniy
Sursa: habr.com
