Az úgy más. Én mentem nonstop, 4000 soros a korlátom.

Honor Magic 6 Pro | Lenovo Thinkpad X280 | Lenovo Thinkcentre M800

Egy ilyen kód az éppen aktuális router time-tól visszafelé 5 perccel írja ki a log-ot:

/log print where time>([/system clock get time] - 5m)

Ha az 5m helyére 24h-t írsz, akkor az elmúlt 24 óra log-ját kapod.
Ezt egy file író script-be helyezve és éjfélre időzítve mindig egy napi logot kapsz a file-ban.

[ Szerkesztve ]

Hmm, ez a sor csak ROS 6-ban működik elvárás szerint a ROS 7-ben nem

Végülis meg lehet csinálni, de elég pepecselős munka. A gondot az jelenti, hogy a ROS 7-ben a system clock külön mezőben kezeli a dátumot és az időt:

[admin@MikroTik] > /system clock print
time: 17:59:30
date: 2024-04-25
time-zone-autodetect: yes
time-zone-name: Europe/Budapest
gmt-offset: +02:00
dst-active: yes

Ezzel szemben a log-ban egyetlen mezőben szerepel együtt a dátum és az idő:
Time: Apr/25/2024 15:35:37

A logot lehet szűrni a Time mezőre (where <feltétel>), így ki lehet venni belőle egy adott napi tartalmat, de ha a script meg akarja tudni az aznapi dátumot a system clock.tól, akkor azt yyyy-mm-dd formátumban kapja, míg a logot Mon/DD/Year formátumban lehetne szűrni. Így kell bele egy dátum konverziót írni. Ráadásul a log Time mezőjét bontani is kell, dátumra és időre, az szerintem csak log soronként oldható meg, így kellene egy ciklus, ami soronként megnézi az adott log dátumát/idejét és eldönti, hogy kell-e.

Biztos meg lehet oldani ROS script-tel is, de szerintem egyszerűbb minden nap az egész lot-ot file-ba menteni és külső programmal kiszedni belőle az adott napi (vagy elmúlt 24 óra) adatokat.

[ Szerkesztve ]

Ennél még egyszerűbb sysloggal kiküldeni egy gépre és ott gyűjteni, akár valami erre való szoftverrel (graylog?), akár csak a journaldbe tolni a többi szemét közé.

Tegnap még működött...

Using Splunk to analyse MikroTik logs
[link]

[ Szerkesztve ]

Sziasztok,

Leirom gyorsan a gondomat:
adott egy rb3011uias ami kb 12 eves es megerett a cserere.
egy 1Gbit/100 Mbit net a bejovo de hamarosan duplazodik.
8 Vlant szolgal ki ez az eszkoz kb 35-40 tuzfal szaballyal.
Mogotte egy USG-Aggregation es USW-Pro-24-POE van Unifi sfp modulokkal.
Nem tudok donteni hogy CCR2004-16G-2S+PC vagy RB5009UG+S+IN.

Ti melyiket ajanlanatok?

[ Szerkesztve ]

A két eszköz nem egy kategória.
Az RB5009 soho router, a CCR professzionális.
A CCR:
- közel a duplája árban.
- kb. 2x annyi port
- nagyobb teljesítmény
- a paszív hűtésű erősen melegszik (állítólag), csak jól szellőző rackbe, ajánlott.
- a melegedést a nagyobb teljesítmény is alátámasztja

Tehát a zongorát és a pianínót akarjuk összehasonlítani.
- Valóban kell a sokkal több port?
- Valóban szükséges az 5009-nél nagyobb teljesítmény?
- Valóban nem számít az árkülönbség?

Ha csak a sávszél növekszik, és eddig a 3011 is bírta a strapát, és nem jelent meg újabb követelmény, akkor 4011 vagy 5009 is bőven elegendő.

Probléma nélkül megy 2000/1000-es neten az RB5009. Firewall IPV4 34 rules (gyári alap plusz néhány) NAT 17 szabály, megy rajt IPV6 is gyári tűzfal. Zerotier. Letöltés T optikán pppoe-n 1980 Mbit le 54% processzor terhelés, fel 915 Mbit 35% proc terhelés. Fasttrack nélkül. Azzal meg még annyira se eszi a processzort. 7.14.2. Ja és capsman is 3 wifinek. Az mondjuk nincs használva nagyon. Hát ha még telerakták volna 2.5G-ás portokkal is.

[ Szerkesztve ]

Koszonom,
Amit nem irtam hogy 10G-s halozat is lesz nagyobb napi adatforgalommal (5-600 GB).
Ez befolyasolja valamennyire?

Ezt a 3011-el nem tudtam meg tesztelni.

10G-t is tudsz használni 5009-en, egy DAC kell csak hozzá.

Talán elfér itt: Felkerült egy újabb írásom, mikrotik témában [link].

Köszi! Javítottam.

Szerintem a cikkben megjelent modszernel egyszerubb, ha olyan tuzfalszabalyokat hozunk reszre, amivel megfelelo sorrendben jelszavat adhatunk meg az ip cimunk felvetelehez. A jelszo pl. lehet ping csomag meret, vagy udp csomag cim+csomag meret, esetleg tobb egymas utan kovetkezo csomag merete. Pl. ha megpingeled a gepet, 1234 bajtos csomaggal akkor felkerul az A listara. Ha egy A listan levo gep kuld egy 3456-os portra egy 789 bajtos udp csomagot, akkor megnyitja a megfelelo portokat.

Ha valaki nagyon meno rendszert akar, akkor ugyanez a modszer egy mikrotik scripttel akar 2fa-hoz hasonlo generalt ugrokodos lehet, azaz az csomagmeretek es portszamok ido alapon egy algoritmusbol kalkulalhatoak, igy mindig masra van szukseg.

[ Szerkesztve ]

Hát, én egy Mikrotik optikai DAC-al használom, igaz csak 2.5G-n, egy switchre megy át. De van sima passzív DAC kábelem, azzal is ment. Nem hinném, hogy gond.

Igen.

Igen, ezt a megoldást is alkalmaztam már. Ezért inkább úgy fogalmaznék, hogy mindkettőnek van előnye és hátránya is.
A pingelős módszer, csomagmérettel variálva, különösen ha több lépcsős elég megbízható, de...
- Pl. a windowsos ping és a linuxos nem ugyanúgy kezeli a csomagméretet amikor paraméterként megadom.
- Ha egy egyszerű felhasználót akarok beengedni, egy sima PC-ről, akkor már nehezebb a dolgom (pl. minimum gyártanom kell neki egy .bat fájlt, ami megfelelő csomagméretekkel pingel)
- Egyszerűen a kényelmi szint más, ha csak beírok egy jelszót egy böngésző ablakban. Illetve ez esetben nem csak a saját IP-met tudom felvenni, hanem bármilyen IP-t, amit a form IPcím mezőjébe beírok.
- Ha a form-ot https-el érem el, akkor sokkal nehezebb a jelszót megszerezni (pl. a kommunikáció lehallgatásával), mint egy pingelés, vagy UDP csomag esetében.

A pingelős módszer tagadhatatlan előnye, hogy a routeren kívül gyakorlatilag semmi egyéb nem kell hozzá. Lehet, hogy kiegészítem majd ennek a leírásával is ezt a cikket.

Mióta a mikrotikre lehet dockert is telepíteni, elvileg ezzel is megoldható lenne a webszerver, és akkor a cikkben írt megoldás sem igényel további hardvert.

Ja, a dockeres dolog jopofa mikrotiken, viszont nyit is egy jo nagy biztonsagi rest, mert ha meghakkintjak a webszerver-t akkor onnantol mar nincsen rendes privilegium szeparacio a host OS-tol.

Nekem az jutott elsőre eszembe, hogy az IP felvételre miért egy magic UDP hívás volt a kézreálló megoldás, miért nem a routerOS REST API-ja. Persze jelszók, tokenek, stb kell oda is.

Tegnap még működött...

Hogyan csinálnád meg? Raksz be példát? Az API használatához authentikálni kell a routerbe, ha jól tévedek. Az UDP hívással kizárólag az IP felvétele valósul meg, a routerben gyakorlatilag semmihez sem fér hozzá a webszerver.
A pingeléssel "bekopogtatásnak" is megvan ugyanez az előnye.

Hali!

Az normális, hogy egy valamilyen Xeon procis Debian-on virtualizált X86-os RouterOS CHR egy WireGuard-on át indított speedtest-től 100%-ra járatja az egyik magot és a sebesség maximum 50 Mbps?

Egy Pentium N3540-es laptopot használtam régen WG szervernek, de megeröltetés nélkül átment rajta 300 Mbps (biztosan többet is bírt volna, csak ez a netem teteje).

üdv, adika4444

J1900-on próbáltam wireguard-ot, natívan, azzal kb. 850Mbit/s sebességet tudott, speedtest.net-el mérve (gigabites neten).

Szar a speedtest, ne hasznald, mert teves eredmenyre vezet.

[ Szerkesztve ]

A hsz. utolsó mondatával arra utaltam, hogy igen, autentikálni azt kell. Jelszót vagy tokent kezelni kell.
De ha nem push irányban gondolkozunk (ha már biztonság, meg DMZ, meg egyéb purdue model), akkor lementheted a felvételre szánt IP-t valahova, amit egy másik script (lehet routerosben is) felolvas, felvesz a listára percenként. Persze ezzel nem feltétlenül lett "egyszerűbb", viszont eltűnik a magic constant port a képletből, amivel amúgy kb bárrmi más is hívhat.

[ Szerkesztve ]

Tegnap még működött...

...a magic constant port a képletből, amivel amúgy kb bárrmi más is hívhat.
Azért nem tud más hívni a "magic constant port"-ot használva, mert a mikrotik ezt csak a NAS belső IP címéről fogadja el (forráscím), a csomag cél címe pedig a listára felvenni kívánt cím (és persze adott interfészre is lehet szűkíteni a kört.). Ha kintről próbál valaki olyan csomagot küldeni, aminek a cél-címe a saját címe, az a csomag el sem fog jutni a routerig, hiszen annak a csomagnak a számára nem az én mikrotikem lesz a gateway, ez csakis belső hálózatból induló csomagok esetén lesz így, amelyek a router mint gateway-nek szintén a belső címére érkeznek. Persze lehet, hogy hibás a gondolatmenetem, de hol hibás?
Ez szerintem inkább a webszerver felől támadható - ha azt meg tudja hekkelni valaki. Persze ezzel akkor is csak portot tud nyitni, de ezzel még közel sem fér hozzá a routerhez.

[ Szerkesztve ]

Sziasztok.
Az normális,hogy egy CRS326-24G-2S+RM os switch 72-fok on üzemel?Sima switchként van használva egy rack szekrényben.

Ez is azt erősíti, hogy valami zűr lesz. Xeon-on nem lehet normális esetben 50 Mbps a teteje... Köszi.

#22025Reggie0
A CLI verzióval csináltam, de itt a konkrét gond inkább az, hogy rommáhajtotta a CHR CPU-ját és ezt nem értem, hogy miért...

[ Szerkesztve ]

üdv, adika4444

Nekem is 70 fok a rack szekrenyben. A lepcsohazban 54 fok.

Maga a speedtest is rommahajtja.

Újabban a webes speedtest furcsa. Én az appot használom. Mármint windowsra van app.

Úgy értem, hogy bármilyen alkalmazás adott hoston, pl ez a port valakinek az eheti random torrent portja.

Van egy felhasználó szintű nevesített auth lépés, majd egy véletlenül is előidézhető lépés. De akár szándékosan, lásd fenti eset.. Ez nem fér össze a fejemben. Persze nem állítom, hogy kritikus hiba lenne, vagy könnyen kihasználható... Habár a te leírásaid sokunknak arany sztenderd.

Ha már itt tartunk, lehetne a php login egyben a mikrotikre is login, akár valamilyen fix átalakítás után. Úgy tárolni se kell.

[ Szerkesztve ]

Tegnap még működött...

Köszi

Így már értem, köszönöm, hogy felhívtad erre a figyelmem!
Ki is egészítettem a leírást a weblapon (remélem nem gond, hogy megemlítettelek).

Ja és a login: a weblapon levő PHP csak egy példa. Ezt célszű olyan formában elkészíteni, hogy a jelszót ne tárolja el közvetlenül, hanem valamilyen kódolt formában, és egy külön fájlban. Amúgy szándékosan nem akarok olyan logint készíteni aminek bármi köze lenne a routerhez.

[ Szerkesztve ]