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:
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:
i dodamo firewall filter:
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:
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:
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.
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.
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štenje action=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
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će
Dropanjem `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.
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