Hirdetés
- AMD Navi Radeon™ RX 9xxx sorozat
- 3D nyomtatás
- Házimozi belépő szinten
- Régi CPU újrakiadásával ünnepelné a Socket AM4 tizedik évfordulóját az AMD
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- TCL LCD és LED TV-k
- Bambu Lab 3D nyomtatók
- Milyen billentyűzetet vegyek?
- Vezetékes FEJhallgatók
-
PROHARDVER!
Mikrotik routerekkel foglalkozó téma. Mikrotik router típusok, hardverek, router beállítások, programozás (scriptek írása), frissítés, és minden Mikrotik routerrel kapcsolatos beszélgetés helye.
Új hozzászólás Aktív témák
-
user12
őstag
Legújabb, áprilisi newletter, új LTE7 eszközökkel
-
user12
őstag
RouterOS 7.21.4 LONG TERM release
What's new in 7.21.4 (2026-Apr-21 09:49):
bgp - fixed stability issue when non-existent output select-chain was specified;
bgp-vpn - allow modifying scopes with routing filters;
bgp-vpn - fixed non-working import filter after reboot;
bgp-vpn - use target scope for imported route;
bridge - fixed missing dynamic "switch-cpu" VLAN entry in WiFi setup;
bridge - fixed performance regression in complex setups with vlan-filtering (introduced in v7.20);
console - removed the "reset" command from shared settings menus (IP/IPv6/Bridge/L3HW/Neighbor-Discovery/Connection-Tracking);
container - fixed issue where the container might not start after upgrading if root-dir was not set;
container - improved error message if a container fails to start;
defconf - fixed L009 configuration (introduced in v7.21);
ethernet - fixed false excessive broadcast warning (introduced in v7.20);
firewall - improved system stability;
ipsec - improved aes256-ctr stability on L009;
ipsec - removed modp8192 proposal on MIPS architectures;
ipv6,ra - use received prefix when RA on-link flag is 0;
isis - improved stability with fragmented CSNP;
l2tp - improved system stability on TILE architecture;
l3hw - fixed missing VLAN counters after reboot (introduced in v7.21);
l3hw - fixed stability issue (introduced in v7.21);
leds - fixed default LED configuration for CCR2004-1G-12S+2XS;
log - do not provide non-existent logging topics for configuration;
lte - fixed framed route support for the first APN;
lte - fixed missing automatic redial when cellular connectivity is lost for R11e-LTE;
lte - fixed user set MTU not applied to LTE interface;
lte - override the "auto" or 0 MTU in "interface" menu to 1500;
ospf - fixed typos in log messages;
ospf - improved stability on configuration change;
ovpn - fixed OVPN push routes;
poe-out - firmware update for CRS354-48P-4S+2Q+ (the update will cause a brief power interruption to poe-out interfaces);
poe-out - fixed rare PoE-Out firmware upgrade failure on CRS354-48P-4S+2Q+;
ptp - allow manual domain configuration for 802.1AS profile;
ptp - set DSCP (EF) for the default profile when using IPv4;
qos-hw - display queue0 limits for CPU port;
qos-hw - fixed "offline" tx-manager ability to queue at least one packet (introduced in v7.21);
qos-hw - prohibit setting CPU port with "offline" tx-manager;
route - added SLAAC route redistribution for IPv6 capable routing protocols;
route - do not set blackhole flag for synthetic routes;
route - improved service stability when removing routes;
routerboard - fixed applying settings via WinBox on devices with fixed CPU frequency;
routing-filter - added possibility to match SLAAC and bgp-mpls-vpn route types;
ssh - make login process asynchronous;
switch - fixed stability issue when changing bridge multicast-router property on CRS1xx/2xx (introduced in v7.19);
system - added FCC Part 15 Compliance label to "System/Regulatory" menu;
system - improved stability for internal RouterOS service communication;
system - improved system stability;
system - improved upgrade service stability when the server is unreachable;
system - included full certificate chain to Windows executables;
user - properly apply login delay (introduced in v7.20);
wifi-mediatek - fixed communication issues on 802.11ax access points with Intel clients;
wifi-mediatek - fixed HE capabilities IE on 2GHz band;
winbox - fixed "Remote AS" setting under the "Routing/BGP/Connections" menu;
winbox - fixed "Src/Dst Address Type" under the "IP/Firewall/NAT" menu;
winbox - fixed L3HW default value for VLAN interface (introduced in v7.21);
winbox - properly display multiple bands for multi-link interface clients under registration table;
winbox - rearrange filter wizard parameters in tabs;
www - improved service stability when cancelling REST API sessions; -
válasz
Kicsirics77
#26542
üzenetére
Megnéztem a sajátommal, de ugyan az a jelenség.
-
Sziasztok,
Történt a napokban, hogy egy hAP Ac3-nál elment a wifi. Elmentem megnézni (5-6 éve én konfiguráltam), hogy mi a gond. Beléptem Winbox-al nem találtam semmi furcsát, gondoltam csinálok rajta egy frissítést. Azóta nem bootol be, úgy tünik mintha boot loopba került volna. Netinstall segít ezen a problémán, úgy hogy a konfig megmaradjon? CAPsMAN ezen fut és van még 2 eszköz ami erre csatlakozott, nem sok kedvem van / lenne újra konfigolni az egész lakást
-
Ezt én is csináltam egy darabig. Ip-ket visszakeresgéltem logokban és megnéztem portok mik nyitottak. Voltak kamerarandszerek, routerek, nasok defaulton hagyva szétferőzve. Eléggé rossz volt látni konkrétan családi ház kameráit... Megválltoztattam a jelszavakat random generáltra majd lekapcsoltam a fenébe amit lehetett. Aztán jelentgettem is az incidenskezelőnél vagy mi a neve most, volt amit megcsináltak párat de utána meg leszarták az egészet. Feladtam én is. Dolgozzanak inkább az etikus hekkerek.
-
user12
őstag
A napokban felröppent APT28-as műveletekkel kapcsolatosan került ki egy közlemény a Mikrotik fórumra:
(változatas nélkül idezem az eredeti oldalról, link alább)“Based on currently available information, MikroTik devices are not being compromised through newly discovered vulnerabilities. Instead, these campaigns appear to target devices with outdated firmware or weak security configurations, similar to many other networking products in the industry when the user becomes the attack vector.
At this time, we have no evidence of any active, unpatched vulnerabilities affecting MikroTik RouterOS.
We strongly recommend all users follow standard security best practices:
Keep RouterOS updated to the latest version (v7)Use strong, unique passwordsDo not expose management interfaces to untrusted networksRegularly review device configuration and access settings
MikroTik continues to monitor the situation closely and will provide updates if any new information becomes available.” -
Reggie0
félisten
Volt egy tuzfalgyarto ceg akik pont ezt csinaltak automatizaltan. A sok spammer pedig halalra dosolta a ceget, mert nagyon bevalt a szoftver es az ISP-k igy tiltogattak rendesen az IP-ket.
Most ha arm-os mikrotiked van akkor lehet ra felhuzni egy docker-t amit beallitasz remote loggingra es az automatizaltan tudja szurni ezeket es feldobalni a tiltasokat. Regebben erre csak kulso gep/rpi igenybevetelevel volt lehetoseg.
-
mrots
tag
válasz
ncc1701
#26519
üzenetére
Az ilyenek eszembe juttatjak amikor fiatal koromban raporogtem az ilyenekre, megkerestem whois-ben az abuse emailt, reportoltam, logokkal, volt, hogy telefonaltam is. Missziomnak ereztem, hogy megjavitsam az internetet.
Pont ma neztem az egyik routerem logjat, tele volt az is ilyenekkel, elvette a hasznos logbuffert a valodi uzenetek elol. Ma mar csak kikapcsoltam a loggolast es elmentem teazni. At ugyse jutnak, akkor meg felolem probalkozzanak.
-
user12
őstag
Igen ez a három próbálkozás utáni tiltás jó dolog. Nálunk itthon sima mezei pppoe végpont van dinamikus címmel, mégis mindig van próbálkozás, hol celzottan a nyitott l2tp/ipsec portokra, hol csak úgy random 1xxxx portra.
Pár naponta átnézem a logot és a gazamberek mennek a ban listára (syno log központba átküldi a mikrotik, itt tudom szűrni is + küld értesítést adott kulcsszavak esetén). -
ekkold
Topikgazda
válasz
MasterMark
#26526
üzenetére
Konkrétan mire gondolsz? Az oldal https-el megy és egy jelszót kell megadni. Ez mindössze csak annyit tesz, hogy ha megfelelő a jelszó, akkor az adott port, a megadott IP-ről elérhető lesz. Tehát ez csak bekopogás az ajtón, a VPN csatlakozás és authentikáció csak ezután jön.
A Mikrotik és a NAS (webszerver) ilyenkor csak LAN-on belül kommunikál egymással. -
ekkold
Topikgazda
válasz
ncc1701
#26523
üzenetére
Ha van webszerver (NAS) a hálózatban, akkor olyan megoldást is lehet csinálni, hogy egy webfelületen először kérünk port nyitást, és utána mehet a VPN. Nálam ez így néz ki:

A webszerver php-vel küld egy megfelelő csomagot a mikrotiknek, az pedig felteszi "fehérlistára" az illető IP címét.
Az IP mezőt automatikusan kitölti, de átírható, ha pl. valaki másnak a címélt akarom felvenni, és nem akarom elmagyarázni neki, hogyan/hol lépjen be, vagy ha nem akarok neki jelszót adni.
Ha az IP nincs felvéve, akkora port számára zárva van, és nem tud csatlakozni.
Kicsit több munkával átírható lenne úgy is, hogy név-jelszó párost kelljen megadni itt is.Amúgy a wireguard szerintem sokkal jobb mint az SSTP, és kb minden opendszerre van kliens. Ami hiányossága van, hogy nincs dinamikus IP kiosztás, azaz neked kell konfigot generálni a felhasználók számára, egyedi belső IP címmel, de ez viszonylag egyszerűen megoldható.
-
Lenry
félisten
válasz
ncc1701
#26519
üzenetére
Vannak erre scriptek, hogy pl 3 sikertelen próbálkozás után blacklistre kerüljön a tűzfalban.
Egyébként nem is kell hogy meg legyen nyitva egy-egy port, próbálkozni akkor is fognak. Nálam nincs nyitva se az SSH, se a telnet, se a Winbox portja kifelé, mégis többezer cím került fel néhány nap alatt a blacklistre, amikor létrehoztam egy tűzfalszabályt, hogy ezekre a portokra érkező minden próbálkozás azonnal bannolva legyen
-
ncc1701
veterán
Van a céges routerünkön configolva sstp vpn szerver, de mocskosul próbálkoznak rajta. Bejutni nem tudnak, mert tanusítványos a vpn, de bántsa a szemem. Van pár honeypot az eszközön (80, 22, 3389-es portokra), de ez nem segített számottevően csökkenteni a próbálkozások számát.
Mik a lehetőségeim? Geoip talán, de a főni elég világjárós. Ha meg a kapcsolatok számát korlátozom, akkor meg nem fogg minket sem beengedni. -
dybu
tag
köszönöm mindenkinek a tanácsokat, nemsokára újra nekiugrok
-
dybu
tag
válasz
Tamarel
#26512
üzenetére
route volt, mangle volt, dns is renben volt; ping megy routerről is, pc-ről is. mégsem töltődtek be a weboldalak. bosszantó az hogy van minta is ami működik, lemásoltam ugyanazt (természetesen a saját beállításaimat szem előtt tartva), mégsem indult meg rendesen. Egy különbség van, én telekom simet használok, amit másoltam az yettel, dehát ez nem lehet döntő tényező. Nekiállok újra úgyis mert nem hagy nyugodni, csak gondoltam adok/adtok nekem egy kis handicapet

-
Lenry
félisten
válasz
lionhearted
#26513
üzenetére
az OPNSense, ami tűzfal, tűzfalkodik és intézi a 3 WAN kapcsolat közti váltást.
minden más routeolási feladatot a Mikrotik lát el, de hogy éppen milyen útvonalon lát ki az internetre, azt az OPNSense oldja meg -
-
dybu
tag
Halihó, ha valaki szenvedett már failover WAN-al, és esetleg egy videó/szöveges guide alapján csinálta, kérem ossza meg tudását, linket, videót, tegnap 2x elbuktam a configgal. Átváltott rá, pingelni mindent tudtam de egy weboldal sem akart betölteni... RB4011 és RB912R 7.20.8-on mindkettő.
-
ncc1701
veterán
válasz
Reggie0
#26507
üzenetére
Amúgy elég volt felvenni address-list-be az ovpn poolom címtartományát, és erre szűrni src-dst addressre, intf nem is kellett (nincs is ovpn interfacem, csak bridge van).
Most már le merem írni, csütörtökön bekapott egyik ügyfelünk egy zsaroló vírust, tegnapra lett belőle 10, tegnap egész nap mentésből álltunk vissza. Mikrotik elött egy debian a routerünk 4 hálókártyával, ott a kliensek kapásból nem látták egymást. Most már arra nem emlékszem, h ott is kellett-e iptables tűzfal szabályt faragni rá, vagy ovpn szerver config beállítás volt, mindegy is. Hülye voltam, nem néztem meg, egyértelműnek tűnt, h a kliensek itt sem látják egymást. Meg még egyéb tanulságokat is levontunk, kollegák sokat lazíttattak a biztonságon, mert nekik úgy egyszerűbb volt a support. Na, ennek most itt látványosan vége.
-
Reggie0
félisten
-
ncc1701
veterán
Sziasztok,
Van egy mikrotik openvpn szerveren, hogyan lehetne rávenni, h a kliensek ne lássák egymást?
-
leonel
aktív tag
Sziasztok. Remélem jó helyre írok.
Egy mikrotik WAPG-5HAXD2HAXD
Ap pointra szeretnék rákötni egy mikrotik sxtsq5ax antennát. A lényeg hogy a teraszon lévő ap-ről levenné a jelet wifin az sxtsq5ax majd az internetet ethernet kàbelen továbbítaná egy routerre a fém garázsba. Tudna valaki segíteni részletes leírással mert ma 3 óra alatt sem tudtam működésre bírni és ott tartok hogy kidobom a pi….ba az összes mikrotiket és tp link rendszert veszek.
bp. 17. Ker-ben vagyok. Ha valaki kijönne megcsinálni - kifizetem. Már kihullott a hajam.
Új hozzászólás Aktív témák
Hirdetés
- Legújabb Thinkpad T14 gen6 - Bontatlan + magyar! - Core Ultra 7 255U - 16/32GB - 512GB - Gyártói gar
- 96GB DDR5 ECC RDIMM 5600MHz szerver RAM
- Eladó AMD Ryzen 7 9700X, RTX 3070, 32GB 6000MHz DDR5, 1TB M.2, 850W +80 Gold Gamer PC!
- Dell Latitude 5411,14",FHD,i7-10850H,16GB DDR4,512GB SSD,2GB VGA,WIN11
- Dell Precision 7720,17.3",FHD,i7-7820HQ,16GB DDR4,256GB SSD,P3000 6GB VGA,WIN11
- Panasonic CF-XZ6 AIO all-in-one laptop tablet 2k touch i5-7300u speciális ütésálló rugged
- HP omen 17-w131ng bontva
- 27% - ASUS Prime 850W 80 PLUS Gold ATX 3.1 Táp!
- BESZÁMÍTÁS! MSI B650 R7 8700F 64GB DDR5 512GB SSD RX 7700 XT 12GB LIAN LI LANCOOL 217 FSP 650W
- GYÖNYÖRŰ iPhone 13 Pro 128GB Gold -1 ÉV GARANCIA - Kártyafüggetlen, MS4675, 100% AKKSI
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest






