-
Fototrend
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
-
Reggie0
félisten
válasz
Zwodkassy
#13966
üzenetére
Ott siman bridge-vel, mert nincsen switch chip. De az procibol csinal mindent, csak birja a procija.
Bridge vlan tablat lehet kitolteni, hogy feleslegesen ne kuldje ki azokra a bridge portokra, ahol nem szukseges. Letre kell hozni egy virtualis vlan interfeszt -ugy, hogy a brigere a master interfesz - az adott vlan szammala, es arra a vlan interfeszre pedig a router vlanon beluli ip cimet felhuzni.
Nagyjabol ezt kell csinalni neked is a 4011-en, csak a swithcportok kozotti vlan forgalmat nem fogod tudni korlatozni, mert azt azon a routeren a switch-ben kene allitani, csak eppen nem tamogatja. Ha meg bridge-bol csinalod a switchelest es filterezest, akkor a procit terheli.
-
-
Reggie0
félisten
válasz
Zwodkassy
#13961
üzenetére
Milyen router? Bridge vlan-nal sem leszel nagyon kisegitve, mert a bridge is prociban fut, szoval ha a procinak foglalkoznia kell a vlanban levo forgalommal(pl. van ipcime a vlanban, vagy routingol), akkor ugyis be kell mennie a prociba.
switch rule-val tudnal filterelni vlan-ra es ip/mac cimre a vlanon belul, de ahhoz a megfelelo switch IC kell.
(Bridge vlan lenyege, hogy javit a teljesitmenyen es le lehet filterelni, hogy milyen portokra milyen vlan tagged packeket engedhet ki, igy a vlan tagged packetek nem mennek el a halozaton minden iranyban)
-
-
válasz
Zwodkassy
#13905
üzenetére
Ezzel nem vagyok előrébb pont az 1db SFP miatt. Mert bár magába az eszközbe SFP-n eljut a 2G de kifelé már nem tudok csak max 1G-t kitolni, szóval ott vagyok ahol a part szakad
2db SFP port esetén már ahogy írtam korábban tök okés lenne, mert akkor a maradék SFP portból elvinném egy 5 portos 2.5G-s switch-be, és a 3db eszközt csak átdugnám a CSS326-ból. -
daninet
veterán
válasz
Zwodkassy
#13829
üzenetére
ez egy jó hír. Van okos switch-em, egy Unifi USW 24, (bár nem tudom mennyire eretnek dolog ebben a topikban ezt a márkát emlegetni
) megnézem van-e hasnoló funkciója.
Aláírattak velem egy nyilatkozatot, hogy az általam telepített eszközök nem az ő felelősségük A többi az ő bajuk ha így oldják meg a korlátozást 
-
Reggie0
félisten
-
Reggie0
félisten
válasz
Zwodkassy
#13789
üzenetére
Milyen switchek konkretan? A queue miatt kerdezem csak, mert a procit terheli, szoval nem biztos, hogy procival birni fogja, illetve a max savszel annyi lesz, mint amennyivel a proci be van kotve a switchbe, viszont a switch portokra is lehet rule-okat rakni chiptol fuggoen. Nekem CRS3xx van, ott van allithato egress/ingress amit a switch IC intez.
-
ekkold
Topikgazda
válasz
Zwodkassy
#13687
üzenetére
De van egyszerűbb megoldás is, PPTP esetében, adott idő alatt a 1723-as portra érkező új kapcsolatok száma alapján is feketelistára tehető a próbálkozó, mivel minden új jelszó kipróbálásához új TCP kapcsolatot kell indítani. Ehhez csak tűzfal szabályok kellenek, script-re nincs szükség.
-
ekkold
Topikgazda
válasz
Zwodkassy
#13687
üzenetére
A VPN-re kapcsolódni próbálkozók felkerülnek két IP listára, ha ezután 90 másodpercen belül nem lép be a megfelelő usernév/jelszó párossal, akkor feketelistára kerül az IP néhány órányi (vagy tetszés szerinti) időtartamra. Ez a 90 másodperc a gyakorlatban 3...4 jelszó kipróbálására ad lehetőséget. A logban annyi látszik ilyenkor, hogy próbálkozik admin, root, user, teszt felhasználónevekkel és kb. ennyire futotta, ment a feketelistára.
Ehhez kell néhány tűzfal szabály, és egy egyszerű script. A script minden VPN kapcsolat felépülésekor lefut + óránként egyszer. Annyit csinál, hogy ha él az adott IP-hez tartozó VPN kapcsolat, akkor az IP listában másfél órára meghosszabbítja azt az időt amíg a tűzfal nem teszi feketelistára. Mivel óránként is lefut így a lejárat előtt mindíg meghosszabítja az időt. Elég régóta használom ezt a megoldást, és szerintem sokat javít a VPN biztonságosságán. -
Necc
addikt
válasz
Zwodkassy
#13663
üzenetére
Ugy erted hogy pl ETH1-en jon be a net, de ETH1-rol megy egy PPPoE kapcsolat, es ekkor alkalmazunk-e tuzfal szabalyt ETH1-re?
Alapbol nem.
PPPoE kapcsolat is interface-nek szamit, igy arra kell csak tuzfal szabaly. ETH1-re alkalmazott tuzfalszabalyok nem vonatkoznak PPPoE forgalomra.
Termeszetesen mehet ETH1-en egyeb forggalom, ami miatt lehet tuzfal szabalyokat alkalmazni ra, de azok ugyszinten nem kell(ene) hogy erintsek a PPPoE forgalmat.
(Nem allitom 100%-ra mert mikrotik specifikus tapasztalatom ezzel kapcsolatban nincs.) -
-
válasz
Zwodkassy
#13526
üzenetére
És Lenry-nek is
Szóval én qtam el, nem kicsit :-)
Az addig szép, és jó volt, hogy két féle cert-et is legyártottam a Miki-ben: egyet IPv4, és egyet xyz.sn.mynetname.net alapján, és ezeket természetesen a Windows-ba is importáltam, telepítettem. Csakhogy ilyenkor a Miki-ben is, a SSTP Server beállítási alatt is cserélni kell a cert-et, a kapcsolódásnak megfelelően :-) :-) :-)
Köszönet a segítségért! -
Reggie0
félisten
válasz
Zwodkassy
#13513
üzenetére
Az a lenyeg, hogy a kliensnel es a certnel is ugyan azt kell hasznalni. Ha IP, akkor IP, ha host, akkor host.
Ha az IP valtozik idonkent, akkor mindenkeppen host-ot erdemes hasznlani, mert kulonben allandoan cserelheted a certet amikor valtozas van. Esetleg probalhatsz wildcard-os certet csinalni. Kiprobaldhatod, hogy ha egy darab * -ot teszel a CN-be arra hogy reagal, valoszinuleg akkor menni fog barhogyan. (Nem ismerem SSTP-t, hogy mit hajlando elfogadni, SSL eseten a * a wildcard karakter)
-
-
-
ekkold
Topikgazda
válasz
Zwodkassy
#13405
üzenetére
Ha az IP Services részben korlátozod a winbox elérést, az önmagában nem a portot zárja le, csak visszautasítja a kapcsolatot, ha az nem megfelelő IP tartományból jön. Ilyenkor van log bejegyzés. Ha a tűzfalban is letiltod a portot akkor a port nem elérhető, és nem lesz log bejegyzés.
-
Lenry
félisten
válasz
Zwodkassy
#13374
üzenetére
mivel kívülről elérhető volt a WinBox port
nem tudom hogyan írhatnám le, ahogy az előző alkalommal nem sikerült megértetni, de NEM. ELÉRHETŐ. KINTRŐL.
ettől függetlenül a router naplója szól, hogy valaki megpróbálta, mert ez a napló dolga.valaki rendszeresen bekopog. engem ez zavar. nem jött be, nem is tud, mert zárva van az ajtó. de én azt szeretném hogy az első kopogás után ki legyen baszva az utcából is. ennyi.
nem hiszem el, hogy ezt külön magyaráznom kell... -
#13342
E.Kaufmann
veterán
Zwodkassy
#13341
E.Kaufmann
veterán
válasz
Zwodkassy
#13341
üzenetére
Nekem be kellett a Windows kliensen, mert a kapcsolat felépülése után minden forgalom a VPN felé csörgött nélküle.
Cert: kellett egy fő cert, amivel egy az SSTP-hez létrehozott cert-el írtam alá, majd a fő cert-et kellett telepíteni a kliensen, mert a Win10 nem fogadta el az önaláírtat -
#13338
E.Kaufmann
veterán
Zwodkassy
#13336
-
-
#13323
E.Kaufmann
veterán
Zwodkassy
#13321
E.Kaufmann
veterán
válasz
Zwodkassy
#13321
üzenetére
Na jó, én is listáztam egy RB3011-en de nem éreztem túl jó megoldásnak, egyrészt azért nagyobb flash-re se szívesen írogatok a routeren napi/heti szinten, másrészt nagyobb listák feldolgozása sem túl CPU barát, még ha lehet is optimalizálni a dolgokat, és csak az új kapcsolat kiépítésekor csekkoljuk, akkor is zabálja a CPU-t.
Most annyiban érzem jogosnak a nagyobb flash-t, hogy a ROS7-hez van wave2-es Wifi csomag, gondolma az AC Wave2 és esetleg majd a WPA3 miatt, és sokan panaszkodnak, hogy a kissebb flash és memóriájú eszközökön nem haználható a csomag, de remélem, majd csak összegyúrják a dolgokat. Régen is volt külön Wireless-fp majd Wireless-repeater csomag, aztán szépen eltűntek/beleolvadtak az alap FW-be. -
ekkold
Topikgazda
válasz
Zwodkassy
#13221
üzenetére
Kipróbáltam. Nem. A skip-dfs-channels csak kihagyja a tipikusan DFS csatornákat, a hosszú detektálási idő miatt, de a többi frekvencián is van radar keresés, mielőtt elindulna az AP, csak rövidebb ideig tart (nálam kb. 10 másodperc).
Egyébként nem tudom mi lehet itt a környéken, de 5GHz-en akárhová állítom, majdnem minden frekvencián radart detektál, és nem indul el az AP. Emiatt kevés az olyan frekvencia, amit tudok használni. Pedig nem kültéri eszköz, simán a szobában van. -
Reggie0
félisten
válasz
Zwodkassy
#13204
üzenetére
Iptables vagy socat. PPTP eseten az elobbi a celszeru, mert kulonben a GRE csomagok ipjenek valtoztatasaval kell vacakolni es akkor a vegen ugyan ott vagyunk, hogy kell egy DNAT az OUTPUT tablaban.
Szerver oldalon is lehet socat-el megoldani, akar inetd-be is fel lehet venni.
-
ekkold
Topikgazda
válasz
Zwodkassy
#13105
üzenetére
Az IPIP jó, de van egy olyan hátránya, hogy mindkét oldalon publikus IP cím kell hozzá. PPTP esetén viszont csak a szerver oldalra kell publikus IP, a kliens lehet akár NAT mögött is.
Ezen kívül a mikrotik nem is olyan régen még nem kezelt domain nevet az IPIP kapcsolatoknál, azaz csak IP címeket lehetett megadni, ami dinamikus IP esetén annyit jelentett, hogy szkriptet kellett írni rá, hogy működjön. Nem tudom melyik verziótól kezdve fogad el domain nevet is, de nem túl régóta... (és az EOIP esetében hasonlóképpen) -
ekkold
Topikgazda
válasz
Zwodkassy
#13098
üzenetére
A feketelistás megoldásnak van egy olyan előnye, hogy azok az IP-k amelyek felkerülnek rá, nem csak egy adott portról lesznek kitiltva, hanem minden portról és szolgáltatásról. Tehát azokat a portokat sem fogják elérni a későbbiekben, amelyek egyébként mások számára nyitva vannak.
-
válasz
Zwodkassy
#13094
üzenetére
Egyébként meg törje fel. Mire megy vele? Kap egy IPv4 címet, ami a belső hálózaton kívüli, és aminek segítségével csak a router-el tud beszélgetni, és azzal is csak erősen korlátozottan. Ahhoz, hogy tovább jusson, tudnia kell a további lépés(eke)t : mondjuk port-knock. Persze tucatnyi más is lehet ez.
-
betyarr
veterán
válasz
Zwodkassy
#13079
üzenetére
nem akarok belevau,csak próbálok/próbáltam gondolkodni.amíg a megfelelő portokhoz nem tettem be a tűzfal szabályt,addig nekem is tépték a winbox portját.ergo hiába csak belülről érhető el,attól még automatikusan próbálkozhatnak rajta,max nem sikerül.ha már van hozzá FW rule és küldi a feketelistára,onnan már a logban sem jelenik meg.nekem legalábbis így történt.
de javíts(atok) ki,ha ez nem így van.lehet én gondolkodom rosszul
-
bacus
őstag
válasz
Zwodkassy
#12740
üzenetére
Én ezt nem olvastam, akkor nem csak bátor vagyok, de műveletlen is.
Mivel lehet downgradelni is, ezért én még mindig nem látom a stable verzió használatának mellőzését, főleg egy picit elhalasztva. A mostani frissítés is egy hónappal később volt, mint a megjelenés. (egyébként nincs tele a net a problémámmal, lehet tényleg csak a 3011-es típust érinti, nem is tud róla mikrotik, ahol nincs PPPOE szintén nem tudnak róla)
Nálam két dolog ami problémát jelent:
1. ha olyan hiba kerülne bele, amivel feltörhetik a routert a net felől (elsősorban), mert belülről velem nem fordult elő, 1x találkoztam vele
2. ha elveszítem a kapcsolatot a routerrel, pl kinyírja a wan kapcsolatot egy frissítés, mert az ügyfeleim szanaszét vannak az országban, a legtöbbel még soha nem találkoztam személyesen, nem akarnék leutazni a világ végére egy ilyen hiba miatt. -
-
-
#12467
Core2duo6600
veterán
Zwodkassy
#12463
Core2duo6600
veterán
-
Laca0
addikt
válasz
Zwodkassy
#12328
üzenetére
" CAPsMAn Forwarding : minden forgalom a CAPsMAN-n megy át, tehát ős is "dolgozik" vele. "
A CAPsMAN a router volt, kábellel rákötve a 2 CAP. Minden 2 CAP közötti forgalom átmegy amúgy is a router-en, nem?
Nem értem igazából a "local forwarding"-ot, igazából azt, hogy milyen, amelyik nem "local"?
Először azt hittem, hogy az AP-ra csatlakoztatott eszközök közötti direkt átvitelt jelentheti, de van külön "client-to-client" beállítás is... -
Laca0
addikt
válasz
Zwodkassy
#12321
üzenetére
Mert már tudtad, hogy mit lehet tőle várni és mit nem! Volt tapasztalatod!
Egyébként nem értem, hogy ez a funkció miért annyira erőforrás-igényes? Végülis csak kapcsolatot tart az AP-kkal, küldi nekik a működési paramétereket, ők meg küldik az adatokat a csatlakozott kliensekről. Kvázi statisztikai infóáramlás.
) megnézem van-e hasnoló funkciója.
Ja és 30ezerrel drágább is termesztésen 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
ekkold- Luck Dragon: Asszociációs játék. :)
- Világ Ninjái és Kódfejtői, egyesüljetek!
- sziku69: Fűzzük össze a szavakat :)
- BestBuy topik
- Battlefield 6
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Újjászületés: szombattól új szerverkörnyezetben a PROHARDVER! lapcsalád
- iPad topik
- Ubuntu Linux
- AMD Navi Radeon™ RX 9xxx sorozat
- További aktív témák...
- ASUS VZ24EHE 1080p / 75Hz / 60cm (23,8") IPS /1ms válaszidő / Gamer funkciók / FreeSync
- MSI MECH 2X RX 6600 XT - eladó!
- Újszerű Topping D10s - USB DAC 32bit 384KHz DSD256
- PCLab Pro P-689 Ryzen 7 9700x / 32GB DDR5 / RTX 5070 - halk, prémium 1440p/4K gamer PC
- 2019 MacBook Pro 16" i9 Radeon Pro 5500M 4gb 32gb RAM 1TB SSD eladó!
- Bomba ár! HP EliteBook 745 G6 - Ryzen PRO 5 I 8GB I 256GB SSD I HDMI I 14" FHD I Cam I W10 I Gari!
- 137 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4080 - 4 ÉV GARANCIA!
- HP Probook i5-7th, 8/128 Notebook
- ÁRGARANCIA! Épített KomPhone Ultra 7 265KF 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
- HIBÁTLAN iPhone 13 256GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3770, 91% Akkumulátor
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Promenade Publishing House Kft.
Város: Budapest