Nekoliko uobičajenih postavki / scenarija do kojih dodjemo googlanjem, a koja su pogrešna ili nisu optimalna, te vode do opterećenja procesora, i drugih nepravilnosti u radu Mikrotik rutera. Svaka postavka je sa primjerima i rješenjem problema.
Sama rješenja, naravno, mogu služiti kao reference za konfiguraciju datih postavki.
Layer 7
Inače kada se radi o RegEX rijetko možete pronaći konkretna rješenja – postavke na netu, i nabasati ćete na moguću postavku blokiranja npr youtube i facebook-a po sedmom lajeru koja izgleda ovako otprilike:
# firewall layer7-protocol regex input:
/ip firewall layer7-protocol
add name=youtube regexp="^.+(youtube).*\$"
add name=facebook regexp="^.+(facebook).*\$"
# firewall filter drop input:
/ip firewall filter
add action=drop chain=forward layer7-protocol=facebook
add action=drop chain=forward layer7-protocol=youtube
Problem
Visoki CPU load, povećana latencija, gubitak paketa, jitter, youtube i facebook nisu blokirani, iz sljedećih razloga:
- Svaka konekcija se provjerava svaki puta nanovo
- Layer7 se provjerava na pogrešnom mijestu i naspram ukupnog prometa
Dijagnozu možete napraviti sa komandom /tool profile.
Layer7 je protokol koji pretražuje šablone u ICMP/TCP/UDP stream-ovima. Na ovaj način pokrenut skuplja slijedećih 10 paketa ili 2KB konkecije i traži šablon u prikupljenim podacima, te svi Layer7 šabloni koje možete pronaći na netu su upravo dizajnirani da rade samo sa tih prvih 10 paketa odnosno 2KB konekcije.
Riješenje
Problem rješavamo prerutiranjem markiranih konekcija unutar firewall mangle konfiguracije:
/ip firewall mangle
add action=mark-connection chain=prerouting protocol=udp dst-port=53 connection-mark=no-mark layer7-protocol=youtube new-connection-mark=youtube_konekcija passthrough=yes
add action=mark-packet chain=prerouting connection-mark=youtube_konekcija new-packet-mark=youtube_paket
i dodamo firewall filter:
/ip firewall filter
add action=drop chain=forward packet-mark=youtube_paket
add action=drop chain=input packet-mark=youtube_paket
Iste postavke ponovimo i za facebook jer smo youtube i facebook uzeli za primjer 🙊.
Queues ne funkcioniše pravilno
Česta i pogrešna postavka ograničenja prometa:
/ip address
add address=10.0.0.1/24 interface=ether-prvi
add address=10.0.1.1/24 interface=ether-drugi
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related
add chain=forward action=accept connection-state=established,related
/queue simple
add max-limit=10M/10M dst=10.0.0.2/32
add max-limit=10M/10M dst=10.0.0.3/32
add max-limit=10M/10M dst=10.0.0.4/32
Problem
Queues rade sa uključenim/tool torch ili ako je fasttrack isključen, ali i tada dohvata samo download promet. Promet unutar lokalne mreže je također ograničen. Analiza preko queues brojača sa fasttrack-connection pravilom.
- Fasttrack pravilo je specificiran za sav promet
- Simple queue `target` mora biti specificiran (postavka cilja je jedina koja određuje simple queue direkciju)
- ako `target` nije određen (ako je 0.0.0.0/0) sav promet će biti dohvaćen u download sekciji
- simple queue `dst` postavka je samo dodatni filter, ne određuje direkciju
Riješenje
Sljedeća konfiguracija otklanja navedeni problem:
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related in-interface=ether-prvi out-interface=ether-drugi
add chain=forward action=fasttrack-connection connection-state=established,related in-interface=ether-drugi out-interface=ether-prvi
add chain=forward action=accept connection-state=established,related
/queue simple
add max-limit=10M/10M target=10.0.0.2/32
add max-limit=10M/10M target=10.0.0.3/32
add max-limit=10M/10M target=10.0.0.4/32
Opterećenje na PPPoE serveru 1
3000 pppoe-klijenata u 10.0.0.0/20 mreži konkektovani kroz 172.16.x.0/24 mreže do drugih servera sa 10.x.0.0/20 PPPoE klijent mrežom. Svi PPPoE serveri i gateway u istoj backbone regiji sa redistribuiranim konektovanim rutama.
/routing ospf network
add network=172.16.1.0/24 area=backbone
add network=10.0.0.0/20 area=backbone
Problem
CPU operećen, PPPoE klijenti se diskonektuju, klijenti ne mogu dosegnuti predviđenu brzinu interneta, ponekada se ne mogu niti konektovati.Dijagnoza sa /tool profile prikazuje “routing” proces zakucan, na jednoj CPU jezgri, do 100% cijelo vrijeme, i ostale jezgre dostižu 100% sa ppp i networking procesima.
OSPF je spamovan sa PPPoE klijent /32 route update.
Za bolje shvatanje problema evo par natuknica odnosa OSPF i PPPoE:
- Svi dinamički routing protokoli (update routing tabela i protokol kalkulacije) su limitirani na jednu jezgru
- Svaki put kada se pppoe-client konektuje / diskonektuje kreira ili briše /32 rutu, te ako je ona dio OSPF mreže inicira OSPF update
- Svaki put kada se pppoe-client konektuje / diskonektuje pppoe-interface se dodaje ili briše sa OSPF interfejsa, ovo također inicira OSPF update
Riješenje
Pasivni OSPF interfejs i STUB regioni.
/routing ospf area
add area-id=0.0.0.1 authentication=none name=pppoe1 type=stub
/routing ospf network
add area=pppoe1 network=10.0.0.0/20
/routing ospf area range
add advertise=yes area=pppoe1 range=10.0.0.0/20
/routing ospf interface
add interface=all passive=yes
Opterećenje na PPPoE serveru 2
3000 pppoe-klijenata u 10.0.0.0/20 mreži. Statička javna IP adresa na javnom interfejsu. Masquerade pravilo. Nema drugog firewall-a.Problem
CPU operećen, PPPoE klijenti se diskonektuju, klijenti ne mogu dosegnuti predviđenu brzinu interneta, ponekada se ne mogu niti konektovati. Dijagnoza sa /tool profile prikazuje dominaciju firewall procesa. Razlog je nepravilno korištenjeaction=masquerade.Firewall NAT
action=masquerade je jedinstvena podverzija action=srcnat, i dizajnirana je za korištenje u situacijama gdje imamo nasumične promjene javne IP adrese, odnosno ako je javna IP dinamička.Svaki put kada se interfejs diskonektuje i / ili je adresa promjenjena ruter će tražiti i čistiti tracking konekcije konekcija relativnih za taj interfejs kako bi popravio vrijeme oporavka.
Riješenje
/ip firewall nat
add action=src-nat chain=srcnat out-interface=<Javni> to-addresses=<Javna_IP>
Kada smo već kod action=masquerade evo još jedan scenarij:
Leak lokalne IP adrese u javnu mrežu
Multi gateway uređaj sa policy routing i failover. Statička javna IP adresa na javnom interfejsu.action=masquerade firewall filter pravilo na svakom javnom interfejsu. Problem
Nakon failover paketi sa privatnom adresom kao izvornom cure u javnu mrežu. Dijagnoza sa/tool sniffer. Nepravilno korištenje action=masquerade ili nedovoljan broj safeguard.
Kako smo već spomenuli, na diskonekciji svi relativni connection tracking unosi se brišu, i slijedeći paket iz svake očišćene konekcije doći će u firewall kao novi
connection-state=new, pa se paketi rutiraju kroz alternativne rute kreirajući nove konekcije. Kada se primarni link vrati rutiranje se oporavlja na primarnom linku te paketi koji pripadaju postojećoj konekciji se šalju preko primarnog interfejsa bez maskiranja. Riješenje
`action=src-nat` umjesto `action=masquerade` kada god je to mogućeDropanjem `connection-state=invalid` paketa
Dropanjem `connection-state=new` paketa sa javnog interfejsa koji nemaju destinaciju `connection-nat-state=!dstnat`
Kreiranje backup blackhole rute za svaki `routing-mark`
Cache DNS Javni DNS server, javna adresa na Internet interfejsu.
/ip dns
set allow-remote-requests=yes servers=8.8.8.8
/ip firewall nat
add action=masquerade chain=srcnat out-interface=Internet
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related
Problem
Visok CPU load, velika količina nepoznatog prometa na javnom interfejsu.Dijagnoza sa
/tool torch i /tool profile
Ruter koristi javni otvoreni DNS resolver. Odgovara na rekursivne upite za hostove izvan svoje domene i koristi se u DNS amplifikacijskim napadima.
Riješenje
/ip firewall filter
add action=reject chain=input dst-port=53
protocol=udp reject-with=icmp-port-unreachable
add action=reject chain=input dst-port=53
protocol=tcp reject-with=icmp-port-unreachable
