Bazele rutării statice în Mikrotik RouterOS

Rutarea este procesul de găsire a celei mai bune căi pentru transmiterea pachetelor prin rețelele TCP/IP. Orice dispozitiv conectat la o rețea IPv4 conține un proces și tabele de rutare.

Acest articol nu este un HOWTO, descrie rutarea statică în RouterOS cu exemple, am omis în mod deliberat restul setărilor (de exemplu, srcnat pentru accesarea Internetului), așa că înțelegerea materialului necesită un anumit nivel de cunoaștere a rețelelor și RouterOS.

Comutare și rutare

Comutarea este procesul de schimb de pachete în cadrul unui segment Layer2 (Ethernet, ppp, ...). Dacă dispozitivul vede că destinatarul pachetului se află pe aceeași subrețea Ethernet cu acesta, învață adresa mac folosind protocolul arp și transmite pachetul direct, ocolind routerul. O conexiune ppp (punct la punct) poate avea doar doi participanți și pachetul este întotdeauna trimis la o singură adresă 0xff.

Rutarea este procesul de transfer de pachete între segmentele Layer2. Dacă un dispozitiv dorește să trimită un pachet al cărui destinatar se află în afara segmentului Ethernet, se uită în tabelul său de rutare și transmite pachetul către gateway, care știe unde să trimită pachetul în continuare (sau poate să nu știe expeditorul original al pachetului). nu este conștient de acest lucru).

Cel mai simplu mod de a te gândi la un router este ca un dispozitiv conectat la două sau mai multe segmente Layer2 și capabil să treacă pachete între ele prin determinarea celei mai bune rute din tabelul de rutare.

Dacă înțelegi totul, sau știi deja, atunci citește mai departe. În rest, vă recomand cu tărie să vă familiarizați cu un mic, dar foarte încăpător articole.

Rutare în RouterOS și PacketFlow

Aproape toate funcționalitățile legate de rutarea statică sunt în pachet sistem. Punga de plastic rutare adaugă suport pentru algoritmi de rutare dinamică (RIP, OSPF, BGP, MME), filtre de rutare și BFD.

Meniul principal pentru configurarea rutei: [IP]->[Route]. Schemele complexe pot necesita ca pachetele să fie preetichetate cu un marcaj de rutare în: [IP]->[Firewall]->[Mangle] (lanţuri PREROUTING и OUTPUT).

Există trei locuri pe PacketFlow unde se iau deciziile de rutare a pachetelor IP:

1. Pachetele de rutare primite de router. În această etapă, se decide dacă pachetul va merge în procesul local sau va fi trimis mai departe în rețea. Pachetele de tranzit primesc Interfață de ieșire
2. Dirijarea pachetelor locale de ieșire. Pachetele de ieșire primesc Interfață de ieșire
3. Pas suplimentar de rutare pentru pachetele de ieșire, vă permite să modificați decizia de rutare în [Output|Mangle]

• Calea pachetului din blocurile 1, 2 depinde de regulile din [IP]->[Route]
• Calea pachetului în punctele 1, 2 și 3 depinde de regulile din [IP]->[Route]->[Rules]
• Calea pachetului din blocurile 1, 3 poate fi influențată folosind [IP]->[Firewall]->[Mangle]

RIB, FIB, cache de rutare

Baza de informații de rutare
Baza în care rutele sunt colectate din protocoale de rutare dinamică, rute din ppp și dhcp, rute statice și conectate. Această bază de date conține toate rutele, cu excepția celor filtrate de administrator.

Condițional, putem presupune că [IP]->[Route] afișează RIB.

Baza de informații de redirecționare

Baza în care sunt adunate cele mai bune rute din RIB. Toate rutele din FIB sunt active și sunt folosite pentru a trimite pachete. Dacă ruta devine inactivă (dezactivată de administrator (sistem) sau interfața prin care ar trebui să fie trimis pachetul nu este activă), ruta este eliminată din FIB.

Pentru a lua o decizie de rutare, tabelul FIB utilizează următoarele informații despre un pachet IP:

• Sursa adresei
• Adresa de destinație
• interfata sursa
• Marca de rutare
• ToS (DSCP)

Intrarea în pachetul FIB trece prin următoarele etape:

• Pachetul este destinat unui proces de ruter local?
• Este pachetul supus regulilor PBR de sistem sau de utilizator?
  • Dacă da, atunci pachetul este trimis la tabelul de rutare specificat
• Pachetul este trimis la masa principală

Condițional, putem presupune că [IP]->[Route Active=yes] afișează FIB.

Cache de rutare
Mecanismul de stocare în cache a rutei. Routerul își amintește unde au fost trimise pachetele și dacă există altele asemănătoare (probabil de la aceeași conexiune) le lasă să meargă pe aceeași rută, fără a verifica în FIB. Cache-ul rutei este șters periodic.

Pentru administratorii RouterOS, ei nu au creat instrumente pentru vizualizarea și gestionarea cache-ului de rutare, dar atunci când acesta poate fi dezactivat în [IP]->[Settings].

Acest mecanism a fost eliminat din kernel-ul linux 3.6, dar RouterOS încă folosește kernel-ul 3.3.5, poate că Routing cahce este unul dintre motive.

Dialog de adăugare a rutei

[IP]->[Route]->[+]

1. Subrețea pentru care doriți să creați o rută (implicit: 0.0.0.0/0)
2. IP-ul gateway-ului sau interfața către care va fi trimis pachetul (pot fi mai multe, vezi ECMP mai jos)
3. Verificare disponibilitate Gateway
4. Tipul de înregistrare
5. Distanța (metrică) pentru o rută
6. Tabel de rutare
7. IP pentru pachetele locale de ieșire prin această rută
8. Scopul Scope și Target Scope este scris la sfârșitul articolului.

Steaguri de traseu

• X - Ruta este dezactivată de administrator (disabled=yes)
• A - Ruta este folosită pentru a trimite pachete
• D - Rută adăugată dinamic (BGP, OSPF, RIP, MME, PPP, DHCP, Conectat)
• C - Subrețeaua este conectată direct la router
• S - Traseu static
• r,b,o,m - Rută adăugată de unul dintre protocoalele de rutare dinamică
• B,U,P - Rută de filtrare (elimină pachete în loc să transmită)

Ce să specificați în gateway: adresa IP sau interfață?

Sistemul vă permite să le specificați pe ambele, în timp ce nu înjură și nu oferă indicii dacă ați greșit cu ceva.

adresa IP
Adresa gateway-ului trebuie să fie accesibilă prin Layer2. Pentru Ethernet, aceasta înseamnă că routerul trebuie să aibă o adresă din aceeași subrețea pe una dintre interfețele ip active, pentru ppp, că adresa gateway-ului este specificată pe una dintre interfețele active ca adresă de subrețea.
Dacă condiția de accesibilitate pentru Layer2 nu este îndeplinită, ruta este considerată inactivă și nu intră în FIB.

interfață
Totul este mai complicat, iar comportamentul routerului depinde de tipul de interfață:

• Conexiunea PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN *) presupune doar doi participanți și pachetul va fi întotdeauna trimis către gateway pentru transmitere, dacă gateway-ul detectează că destinatarul este el însuși, atunci va transfera pachetul către procesul său local.
  
• Ethernet presupune prezența multor participanți și va trimite cereri către interfața arp cu adresa destinatarului pachetului, acest lucru este de așteptat și un comportament destul de normal pentru rutele conectate.
  Dar atunci când încercați să utilizați interfața ca rută pentru o subrețea la distanță, veți obține următoarea situație: ruta este activă, trece ping către gateway, dar nu ajunge la destinatar din subrețeaua specificată. Dacă te uiți la interfață printr-un sniffer, vei vedea cereri arp cu adrese dintr-o subrețea la distanță.
  

Încercați să specificați adresa IP ca gateway ori de câte ori este posibil. Excepție fac rutele conectate (create automat) și interfețele PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*).

OpenVPN nu conține un antet PPP, dar puteți utiliza numele interfeței OpenVPN pentru a crea o rută.

Traseu mai specific

Regula de bază de rutare. Ruta care descrie subrețeaua mai mică (cu cea mai mare mască de subrețea) are prioritate în decizia de rutare a pachetului. Poziția intrărilor în tabelul de rutare nu este relevantă pentru alegere - regula principală este Mai specifică.

Toate rutele din schema specificată sunt active (situate în FIB). indică diferite subrețele și nu intră în conflict între ele.

Dacă unul dintre gateway-uri devine indisponibil, ruta asociată va fi considerată inactivă (eliminată din FIB) și pachetele vor fi căutate din rutele rămase.

Rutei cu subrețeaua 0.0.0.0/0 primește uneori o semnificație specială și este numită „Ruta implicită” sau „Poarta de ultimă instanță”. De fapt, nu este nimic magic în el și include pur și simplu toate adresele IPv4 posibile, dar aceste nume descriu bine sarcina sa - indică poarta de acces unde să trimită pachete pentru care nu există alte rute mai precise.

Masca de subrețea maximă posibilă pentru IPv4 este /32, această rută indică o anumită gazdă și poate fi utilizată în tabelul de rutare.

Înțelegerea rutei mai specifice este fundamentală pentru orice dispozitiv TCP/IP.

Distanţă

Distanțele (sau valorile) sunt necesare pentru filtrarea administrativă a rutelor către o singură subrețea accesibilă prin mai multe gateway-uri. O rută cu o metrică mai mică este considerată prioritară și va fi inclusă în FIB. Dacă o rută cu o metrică mai mică încetează să mai fie activă, atunci va fi înlocuită cu o rută cu o metrică mai mare în FIB.

Dacă există mai multe rute către aceeași subrețea cu aceeași metrică, routerul va adăuga doar una dintre ele la tabelul FIB, ghidat de logica sa internă.

Valoarea poate lua o valoare de la 0 la 255:

• 0 - Metric pentru rutele conectate. Distanța 0 nu poate fi setată de administrator
• 1-254 - Valori disponibile administratorului pentru setarea rutelor. Valorile cu o valoare mai mică au o prioritate mai mare
• 255 - Metric disponibil pentru administrator pentru setarea rutelor. Spre deosebire de 1-254, o rută cu o metrică de 255 rămâne întotdeauna inactivă și nu intră în FIB
• metrici specifice. Rutele derivate din protocoalele de rutare dinamică au valori metrice standard

verificați gateway-ul

Verificați gateway-ul este o extensie MikroTik RoutesOS pentru verificarea disponibilității gateway-ului prin icmp sau arp. O dată la 10 secunde (nu poate fi schimbată), o cerere este trimisă către gateway, dacă răspunsul nu este primit de două ori, ruta este considerată indisponibilă și este eliminată din FIB. Dacă gateway-ul de verificare a fost dezactivat, ruta de verificare continuă și ruta va deveni activă din nou după o verificare reușită.

Verificați gateway-ul dezactivează intrarea în care este configurat și toate celelalte intrări (în toate tabelele de rutare și rutele ecmp) cu gateway-ul specificat.

În general, verificarea gateway-ului funcționează bine atâta timp cât nu există probleme cu pierderea pachetelor către gateway. Verificați gateway-ul nu știe ce se întâmplă cu comunicarea în afara gateway-ului verificat, acest lucru necesită instrumente suplimentare: scripturi, rutare recursivă, protocoale de rutare dinamică.

Cele mai multe protocoale VPN și tunel conțin instrumente încorporate pentru verificarea activității conexiunii, activarea verificării gateway-ului pentru acestea reprezintă o sarcină suplimentară (dar foarte mică) a rețelei și a performanței dispozitivului.

rute ECMP

Equal-Cost Multi-Path - trimiterea de pachete către destinatar folosind mai multe gateway-uri simultan folosind algoritmul Round Robin.

O rută ECMP este creată de administrator prin specificarea mai multor gateway-uri pentru o subrețea (sau automat, dacă există două rute OSPF echivalente).

ECMP este folosit pentru echilibrarea sarcinii între două canale, în teorie, dacă există două canale în ruta ecmp, atunci pentru fiecare pachet canalul de ieșire ar trebui să fie diferit. Dar mecanismul Routing cache trimite pachete de la conexiune de-a lungul rutei pe care l-a parcurs primul pachet, ca urmare, obținem un fel de echilibrare bazată pe conexiuni (per-connection loading balancing).

Dacă dezactivați Routing Cache, atunci pachetele din ruta ECMP vor fi partajate corect, dar există o problemă cu NAT. Regula NAT procesează doar primul pachet de la conexiune (restul sunt procesate automat) și rezultă că pachetele cu aceeași adresă sursă părăsesc interfețe diferite.

Verificați gateway-ul nu funcționează în rutele ECMP (error RouterOS). Dar puteți ocoli această limitare creând rute de validare suplimentare care vor dezactiva intrările în ECMP.

Filtrarea prin rutare

Opțiunea Tip determină ce să faci cu pachetul:

• unicast - trimite către gateway-ul specificat (interfață)
• blackhole - aruncați un pachet
• interzice, inaccesibil - aruncați pachetul și trimiteți un mesaj icmp expeditorului

Filtrarea este de obicei folosită atunci când este necesar pentru a securiza trimiterea pachetelor pe o cale greșită, desigur, puteți filtra acest lucru prin firewall.

Câteva exemple

Pentru a consolida lucrurile de bază despre rutare.

Router de acasă tipic

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. Rută statică la 0.0.0.0/0 (rută implicită)
2. Rută conectată pe interfața cu furnizorul
3. Rută conectată pe interfața LAN

Router de acasă tipic cu PPPoE

1. Rută statică la ruta implicită, adăugată automat. este specificat în proprietățile conexiunii
2. Rută conectată pentru conexiunea PPP
3. Rută conectată pe interfața LAN

Router de acasă tipic cu doi furnizori și redundanță

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. Rută statică către ruta implicită prin primul furnizor cu metrica 1 și verificarea disponibilității gateway-ului
2. Rută statică către ruta implicită prin al doilea furnizor cu metrica 2
3. Rute conectate

Traficul către 0.0.0.0/0 trece prin 10.10.10.1 în timp ce acest gateway este disponibil, altfel trece la 10.20.20.1

O astfel de schemă poate fi considerată o rezervare de canal, dar nu este lipsită de dezavantaje. Dacă are loc o întrerupere în afara gateway-ului furnizorului (de exemplu, în interiorul rețelei operatorului), routerul dumneavoastră nu va ști despre aceasta și va continua să considere ruta ca fiind activă.

Router de acasă tipic cu doi furnizori, redundanță și ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. Rute statice pentru verificarea gateway-ului chack
2. ruta ECMP
3. Rute conectate

Rutele de verificat sunt albastre (culoarea rutelor inactive), dar acest lucru nu interferează cu gateway-ul de verificare. Versiunea actuală (6.44) a RoS acordă prioritate automată rutei ECMP, dar este mai bine să adăugați rute de testare la alte tabele de rutare (opțiune routing-mark)

Pe Speedtest și alte site-uri similare, nu va exista o creștere a vitezei (ECMP împarte traficul pe conexiuni, nu pe pachete), dar aplicațiile p2p ar trebui să se încarce mai repede.

Filtrarea prin rutare

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. Rută statică către ruta implicită
2. Rută statică către 192.168.200.0/24 prin tunelul ipip
3. Interzicerea rutei statice la 192.168.200.0/24 prin routerul ISP

O opțiune de filtrare în care traficul tunelului nu va merge către routerul furnizorului atunci când interfața ipip este dezactivată. Asemenea scheme sunt rareori necesare, deoarece puteți implementa blocarea prin firewall.

Bucla de rutare
Bucla de rutare - o situație în care un pachet rulează între routere înainte ca ttl să expire. De obicei este rezultatul unei erori de configurare, în rețelele mari este tratată prin implementarea protocoalelor de rutare dinamică, în cele mici - cu grijă.

Arată ceva astfel:

Un exemplu (cel mai simplu) despre cum să obțineți un rezultat similar:

Exemplul de buclă de rutare nu are nicio utilitate practică, dar arată că routerele habar nu au despre tabelul de rutare al vecinului lor.

Rutarea de bază a politicilor și tabelele de rutare suplimentare

Atunci când alegeți o rută, routerul folosește un singur câmp din antetul pachetului (Adresa Dst.) - aceasta este rutarea de bază. Rutarea bazată pe alte condiții, cum ar fi adresa sursă, tipul de trafic (ToS), echilibrarea fără ECMP, aparține Policy Base Routing (PBR) și utilizează tabele de rutare suplimentare.

Traseu mai specific este regula principală de selecție a rutei din tabelul de rutare.

În mod implicit, toate regulile de rutare sunt adăugate la tabelul principal. Administratorul poate crea un număr arbitrar de tabele de rutare suplimentare și poate ruta pachete către acestea. Regulile din tabele diferite nu intră în conflict între ele. Dacă pachetul nu găsește o regulă potrivită în tabelul specificat, acesta va merge la tabelul principal.

Exemplu cu distribuție prin Firewall:

• 192.168.100.10 -> 8.8.8.8
  1. Traficul de la 192.168.100.10 este etichetat via-isp1 в [Prerouting|Mangle]
  2. La etapa de rutare din tabel via-isp1 caută o rută către 8.8.8.8
  3. Traseu găsit, traficul este trimis către gateway-ul 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Traficul de la 192.168.200.20 este etichetat via-isp2 в [Prerouting|Mangle]
  2. La etapa de rutare din tabel via-isp2 caută o rută către 8.8.8.8
  3. Traseu găsit, traficul este trimis către gateway-ul 10.20.20.1
• Dacă unul dintre gateway-uri (10.10.10.1 sau 10.20.20.1) devine indisponibil, atunci pachetul va merge la tabel principal și va căuta acolo un traseu potrivit

Probleme de terminologie

RouterOS are anumite probleme de terminologie.
Când lucrați cu reguli în [IP]->[Routes] este indicat tabelul de rutare, deși este scris că eticheta:

В [IP]->[Routes]->[Rule] totul este corect, în condiția etichetei din acțiunea tabelului:

Cum se trimite un pachet la o anumită tabelă de rutare

RouterOS oferă mai multe instrumente:

• Reguli în [IP]->[Routes]->[Rules]
• Marcatori de traseu (action=mark-routing) în [IP]->[Firewall]->[Mangle]
• VRF

regulament [IP]->[Route]->[Rules]
Regulile sunt procesate secvenţial, dacă pachetul se potriveşte cu condiţiile regulii, nu trece mai departe.

Regulile de rutare vă permit să extindeți posibilitățile de rutare, bazându-vă nu numai pe adresa destinatarului, ci și pe adresa sursă și pe interfața pe care a fost primit pachetul.

Regulile constau în condiții și o acțiune:

• Condiții. Repetați practic lista de semne prin care se verifică coletul în FIB, lipsește doar ToS.
• Activitate
  • căutare - trimite un pachet la o masă
  • căutare numai în tabel - blocați pachetul în tabel, dacă ruta nu este găsită, pachetul nu va merge la tabelul principal
  • drop - drop un pachet
  • inaccesibil - aruncați pachetul cu notificarea expeditorului

În FIB, traficul către procesele locale este procesat ocolind regulile [IP]->[Route]->[Rules]:

marcare [IP]->[Firewall]->[Mangle]
Etichetele de rutare vă permit să setați gateway-ul pentru un pachet folosind aproape orice condiții de firewall:

Practic, pentru că nu toate au sens, iar unele pot funcționa instabil.

Există două moduri de a eticheta un pachet:

• Imediat pus marca de rutare
• Pune pe primul loc marca de conexiune, apoi pe baza marca de conexiune a pune marca de rutare

Într-un articol despre firewall-uri am scris că a doua opțiune este de preferat. reduce sarcina pe CPU, în cazul marcajului rutelor - acest lucru nu este în întregime adevărat. Aceste metode de marcare nu sunt întotdeauna echivalente și sunt de obicei folosite pentru a rezolva diverse probleme.

Exemple de utilizare

Să trecem la exemplele de utilizare a rutei bazate pe politici, ele sunt mult mai ușor de arătat de ce este nevoie de toate acestea.

MultiWAN și returnare trafic de ieșire (Ieșire).
O problemă comună cu o configurație MultiWAN: Mikrotik este disponibil de pe Internet doar printr-un furnizor „activ”.

Router-ului nu-i pasă de la ce ip a venit cererea, la generarea unui răspuns, va căuta o rută în tabelul de rutare unde ruta prin isp1 este activă. Mai mult, un astfel de pachet va fi cel mai probabil filtrat pe drumul către destinatar.

Un alt punct interesant. Dacă o sursă „simplu” nat este configurată pe interfața ether1: /ip fi nat add out-interface=ether1 action=masquerade pachetul va intra online cu src. adresa=10.10.10.100, ceea ce face lucrurile și mai rău.

Există mai multe moduri de a remedia problema, dar oricare dintre ele va necesita tabele de rutare suplimentare:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

Folosi [IP]->[Route]->[Rules]
Specificați tabelul de rutare care va fi utilizat pentru pachetele cu IP sursă specificat.

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

Pot folosi action=lookup, dar pentru traficul de ieșire local, această opțiune exclude complet conexiunile de la interfața greșită.

• Sistemul generează un pachet de răspuns cu Src. Adresa: 10.20.20.200
• Verificarea pasului Decizia de rutare(2). [IP]->[Routes]->[Rules] iar pachetul este trimis la tabelul de rutare supra-isp2
• Conform tabelului de rutare, pachetul trebuie trimis către gateway-ul 10.20.20.1 prin interfața ether2

Această metodă nu necesită un Connection Tracker funcțional, spre deosebire de utilizarea tabelului Mangle.

Folosi [IP]->[Firewall]->[Mangle]
Conexiunea începe cu un pachet de intrare, așa că îl marchem (action=mark-connection), pentru pachetele de ieșire de la o conexiune marcată, setați eticheta de rutare (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Dacă sunt configurate mai multe ip-uri pe o singură interfață, puteți adăuga la condiție dst-address a fi sigur.

• Un pachet deschide conexiunea pe interfața ether2. Pachetul intră în [INPUT|Mangle] care spune să se marcheze toate pachetele de la conexiune ca de la-isp2
• Sistemul generează un pachet de răspuns cu Src. Adresa: 10.20.20.200
• În etapa de decizie de rutare(2), pachetul, în conformitate cu tabelul de rutare, este trimis către gateway-ul 10.20.20.1 prin interfața ether1. Puteți verifica acest lucru conectându-vă pachetele [OUTPUT|Filter]
• La scenă [OUTPUT|Mangle] eticheta de conectare este verificată de la-isp2 iar pachetul primește o etichetă de rută supra-isp2
• Pasul Ajustare rutare(3) verifică prezența unei etichete de rutare și o trimite la tabelul de rutare corespunzător
• Conform tabelului de rutare, pachetul trebuie trimis către gateway-ul 10.20.20.1 prin interfața ether2

MultiWAN și returnare trafic dst-nat

Un exemplu este mai complicat, ce trebuie făcut dacă există un server (de exemplu, web) în spatele routerului pe o subrețea privată și trebuie să oferiți acces la acesta prin oricare dintre furnizori.

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

Esența problemei va fi aceeași, soluția este similară cu opțiunea Firewall Mangle, vor fi folosite doar alte lanțuri:

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Diagrama nu arată NAT, dar cred că totul este clar.

MultiWAN și conexiuni de ieșire

Puteți utiliza capabilitățile PBR pentru a crea mai multe conexiuni vpn (SSTP în exemplu) de la diferite interfețe de router.

Tabele de rutare suplimentare:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

Marcajele pachetului:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

Reguli NAT simple, altfel pachetul va părăsi interfața cu Src greșit. abordare:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

parsarea:

• Routerul creează trei procese SSTP
• În etapa Decizie de rutare (2), o rută este selectată pentru aceste procese pe baza tabelului principal de rutare. De pe aceeași rută, pachetul primește Src. Adresă legată de interfața ether1
• В [Output|Mangle] pachetele de la diferite conexiuni primesc etichete diferite
• Pachetele intră în tabelele corespunzătoare etichetelor în etapa de ajustare a rutei și primesc o nouă rută pentru trimiterea pachetelor
• Dar pachetele au încă Src. Adresă de la ether1, pe scenă [Nat|Srcnat] adresa este înlocuită conform interfeței

Interesant, pe router veți vedea următorul tabel de conexiuni:

Connection Tracker funcționează mai devreme [Mangle] и [Srcnat], deci toate conexiunile provin de la aceeași adresă, dacă te uiți mai detaliat, atunci în Replay Dst. Address vor exista adrese după NAT:

Pe serverul VPN (am unul pe bancul de testare), puteți vedea că toate conexiunile provin de la adresele corecte:

Ține drumul
Există o modalitate mai ușoară, puteți pur și simplu să specificați o poartă specifică pentru fiecare dintre adrese:

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

Dar astfel de rute vor afecta nu numai traficul de ieșire, ci și de tranzit. În plus, dacă nu aveți nevoie de trafic către serverul vpn pentru a trece prin canale de comunicare nepotrivite, atunci va trebui să adăugați încă 6 reguli la [IP]->[Routes]с type=blackhole. În versiunea anterioară - 3 reguli în [IP]->[Route]->[Rules].

Distribuirea conexiunilor utilizatorilor pe canale de comunicare

Sarcini simple, de zi cu zi. Din nou, vor fi necesare tabele de rutare suplimentare:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

Utilizarea [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

Dacă utilizați action=lookup, atunci când unul dintre canale este dezactivat, traficul va merge la masa principală și va trece prin canalul de lucru. Dacă acest lucru este necesar sau nu, depinde de sarcină.

Folosind marcajele în [IP]->[Firewall]->[Mangle]
Un exemplu simplu cu liste de adrese IP. În principiu, pot fi folosite aproape orice condiții. Singura avertizare a stratului 7, chiar și atunci când este asociat cu etichete de conexiune, poate părea că totul funcționează corect, dar o parte din trafic va merge în continuare pe direcția greșită.

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

Puteți „bloca” utilizatorii într-un singur tabel de rutare [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

Ori prin [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

Retreat pro dst-address-type=!local
Condiție suplimentară dst-address-type=!local este necesar ca traficul de la utilizatori să ajungă la procesele locale ale routerului (dns, winbox, ssh, ...). Dacă la router sunt conectate mai multe subrețele locale, este necesar să vă asigurați că traficul dintre ele nu ajunge la Internet, de exemplu, folosind dst-address-table.

În exemplul folosind [IP]->[Route]->[Rules] nu există astfel de excepții, dar traficul ajunge la procesele locale. Cert este că intrarea în pachetul FIB marcat în [PREROUTING|Mangle] are o etichetă de rută și intră într-un tabel de rutare, altul decât principal, unde nu există o interfață locală. În cazul regulilor de rutare, mai întâi se verifică dacă pachetul este destinat unui proces local și doar în etapa User PBR merge la tabelul de rutare specificat.

Utilizarea [IP]->[Firewall]->[Mangle action=route]
Această acțiune funcționează numai în [Prerouting|Mangle] și vă permite să direcționați traficul către gateway-ul specificat fără a utiliza tabele de rutare suplimentare, specificând direct adresa gateway-ului:

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

efect route are o prioritate mai mică decât regulile de rutare ([IP]->[Route]->[Rules]). În cazul marcajelor de traseu, totul depinde de poziția regulilor, dacă regula cu action=route valorează mai mult decât action=mark-route, atunci va fi folosit (indiferent de steag passtrough), altfel marcand traseul.
Există foarte puține informații pe wiki despre această acțiune și toate concluziile au fost obținute experimental, în orice caz, nu am găsit opțiuni când folosirea acestei opțiuni oferă avantaje față de altele.

Echilibrare dinamică bazată pe PPC

Per Connection Classifier - este un analog mai flexibil al ECMP. Spre deosebire de ECMP, împarte traficul pe conexiuni mai strict (ECMP nu știe nimic despre conexiuni, dar atunci când este asociat cu Routing Cache, se obține ceva similar).

PCC ia câmpurile specificate din antetul ip, le convertește la o valoare de 32 de biți și împarte la numitor. Restul diviziunii este comparat cu cel specificat rest iar dacă se potrivesc, atunci se aplică acțiunea specificată. Mai mult. Sună nebunesc, dar funcționează.

Exemplu cu trei adrese:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

Un exemplu de distribuție dinamică a traficului prin src.address între trei canale:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

La marcarea rutelor, există o condiție suplimentară: in-interface=br-lan, fără ea sub action=mark-routing traficul de răspuns de pe Internet va primi și, în conformitate cu tabelele de rutare, va reveni la furnizor.

Schimbarea canalelor de comunicare

Verificarea ping-ului este un instrument bun, dar verifică doar conexiunea cu cel mai apropiat peer IP, rețelele de furnizori constau de obicei dintr-un număr mare de routere și o întrerupere a conexiunii poate apărea în afara celui mai apropiat peer, iar apoi există operatori de telecomunicații backbone care pot, de asemenea au probleme, în general, verificarea ping nu afișează întotdeauna informații actualizate despre accesul la rețeaua globală.
Dacă furnizorii și corporațiile mari au protocolul de rutare dinamică BGP, atunci utilizatorii de acasă și de la birou trebuie să-și dea seama în mod independent cum să verifice accesul la Internet printr-un anumit canal de comunicare.

De obicei, se folosesc scripturi care, printr-un anumit canal de comunicare, verifică disponibilitatea unei adrese IP pe Internet, alegând în același timp ceva de încredere, de exemplu, google dns: 8.8.8.8. 8.8.4.4. Dar în comunitatea Mikrotik, un instrument mai interesant a fost adaptat pentru asta.

Câteva cuvinte despre rutarea recursivă
Rutarea recursiva este necesară atunci când se construiește peering-ul Multihop BGP și a intrat în articolul despre elementele de bază ale rutare statică numai datorită utilizatorilor vicleni MikroTik care și-au dat seama cum să folosească rutele recursive asociate cu gateway-ul de verificare pentru a schimba canalele de comunicare fără scripturi suplimentare.

Este timpul să înțelegeți opțiunile domeniului de aplicare/țintă în termeni generali și modul în care ruta este legată de interfață:

1. Ruta caută o interfață pentru a trimite pachetul pe baza valorii sale domeniului și a tuturor intrărilor din tabelul principal cu valori țintă mai mici sau egale
2. Din interfețele găsite este selectată cea prin care puteți trimite un pachet către gateway-ul specificat
3. Interfața intrării conectate găsite este selectată pentru a trimite pachetul către gateway

În prezența unei rute recursive, totul se întâmplă la fel, dar în două etape:

• 1-3 Încă o rută se adaugă rutelor conectate, prin care se poate ajunge la poarta specificată
• 4-6 Găsirea rutei conectate la rută pentru gateway-ul „intermediar”.

Toate manipulările cu căutarea recursivă au loc în RIB și numai rezultatul final este transferat în FIB: 0.0.0.0/0 via 10.10.10.1 on ether1.

Un exemplu de utilizare a rutare recursivă pentru a comuta rutele

Configurare:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

Puteți verifica dacă pachetele vor fi trimise la 10.10.10.1:

Verificați gateway-ul nu știe nimic despre rutarea recursivă și pur și simplu trimite ping-uri către 8.8.8.8, care (pe baza tabelului principal) este accesibil prin gateway-ul 10.10.10.1.

Dacă există o pierdere a comunicării între 10.10.10.1 și 8.8.8.8, atunci ruta este deconectată, dar pachetele (inclusiv ping-urile de testare) la 8.8.8.8 continuă să treacă prin 10.10.10.1:

Dacă legătura cu ether1 este pierdută, atunci apare o situație neplăcută când pachetele înainte de 8.8.8.8 trec prin al doilea furnizor:

Aceasta este o problemă dacă utilizați NetWatch pentru a rula scripturi când 8.8.8.8 nu este disponibil. Dacă legătura este întreruptă, NetWatch va funcționa pur și simplu prin canalul de comunicare de rezervă și va presupune că totul este în regulă. Rezolvat prin adăugarea unei rute suplimentare de filtrare:

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

Există pe habré articol, unde situația cu NetWatch este considerată mai detaliat.

Și da, atunci când utilizați o astfel de rezervare, adresa 8.8.8.8 va fi conectată la unul dintre furnizori, așa că alegerea acesteia ca sursă dns nu este o idee bună.

Câteva cuvinte despre rutare și redirecționare virtuală (VRF)

Tehnologia VRF este concepută pentru a crea mai multe routere virtuale într-unul fizic, această tehnologie este utilizată pe scară largă de operatorii de telecomunicații (de obicei împreună cu MPLS) pentru a furniza servicii L3VPN clienților cu adrese de subrețea suprapuse:

Dar VRF în Mikrotik este organizat pe baza tabelelor de rutare și are o serie de dezavantaje, de exemplu, adresele IP locale ale routerului sunt disponibile de la toate VRF-urile, puteți citi mai multe по ссылке.

exemplu de configurare vrf:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

De pe dispozitivul conectat la ether2, vedem că ping merge la adresa routerului de la un alt vrf (și aceasta este o problemă), în timp ce ping nu merge la Internet:

Pentru a accesa Internetul, trebuie să înregistrați o rută suplimentară care accesează tabelul principal (în terminologia vrf, aceasta se numește ruta leaking):

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

Iată două moduri de scurgere a rutei: folosind tabelul de rutare: 172.17.0.1@main și folosind numele interfeței: 172.17.0.1%wlan1.

Și setați marcaj pentru traficul de întoarcere [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

Subrețele cu aceeași adresă
Organizarea accesului la subrețele cu aceeași adresare pe același router folosind VRF și netmap:

Configurație de bază:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

reguli pentru firewall:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

Reguli de rutare pentru traficul de retur:

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

Adăugarea rutelor primite prin dhcp la un anumit tabel de rutare
VRF poate fi interesant dacă trebuie să adăugați automat o rută dinamică (de exemplu, de la un client dhcp) la o anumită tabelă de rutare.

Adăugarea interfeței la vrf:

/ip route vrf
add interface=ether1 routing-mark=over-isp1

Reguli pentru trimiterea traficului (de ieșire și de tranzit) prin tabel supra-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

Rută suplimentară, falsă, pentru rutarea către serviciu:

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

Această rută este necesară doar pentru ca pachetele locale de ieșire să poată trece prin decizia de rutare (2) înainte [OUTPUT|Mangle] și obțineți eticheta de rutare, dacă există alte rute active pe router înainte de 0.0.0.0/0 în tabelul principal, aceasta nu este necesară.

lanț connected-in и dynamic-in в [Routing] -> [Filters]

Filtrarea rutei (inbound și outbound) este un instrument care este de obicei utilizat împreună cu protocoalele de rutare dinamică (și, prin urmare, disponibil numai după instalarea pachetului rutare), dar există două lanțuri interesante în filtrele de intrare:

• connect-in — filtrarea rutelor conectate
• dynamic-in - filtrarea rutelor dinamice primite de PPP și DCHP

Filtrarea vă permite nu numai să renunțați la rute, ci și să modificați o serie de opțiuni: distanță, marcaj de rutare, comentariu, domeniu de aplicare, domeniu țintă, ...

Acesta este un instrument foarte precis și dacă puteți face ceva fără Filtre de rutare (dar nu scripturi), atunci nu utilizați filtre de rutare, nu vă confundați pe voi și pe cei care vor configura routerul după dvs. În contextul rutării dinamice, filtrele de rutare vor fi folosite mult mai frecvent și mai productiv.

Setarea marcajului de rutare pentru rutele dinamice
Un exemplu de la un router de acasă. Am două conexiuni VPN configurate și traficul din ele ar trebui să fie împachetat în conformitate cu tabelele de rutare. În același timp, vreau ca rutele să fie create automat când interfața este activată:

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

Nu știu de ce, probabil o eroare, dar dacă creați un vrf pentru interfața ppp, atunci ruta către 0.0.0.0/0 va intra în continuare în tabelul principal. Altfel, totul ar fi și mai ușor.

Dezactivarea rutelor conectate
Uneori acest lucru este necesar:

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

Instrumente de depanare

RouterOS oferă o serie de instrumente pentru depanarea rutare:

• [Tool]->[Tourch] - vă permite să vizualizați pachete pe interfețe
• /ip route check - vă permite să vedeți la ce gateway va fi trimis pachetul, nu funcționează cu tabelele de rutare
• /ping routing-table=<name> и /tool traceroute routing-table=<name> - ping și urmărire folosind tabelul de rutare specificat
• action=log в [IP]->[Firewall] - un instrument excelent care vă permite să urmăriți traseul unui pachet de-a lungul fluxului de pachete, această acțiune este disponibilă în toate lanțurile și tabelele

Sursa: www.habr.com