Hirdetés
- sh4d0w: Kalózkodás. Kalózkodás?
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- bambano: A sor végén
- Brogyi: CTEK akkumulátor töltő és másolatai
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Mr Dini: Mindent a StreamSharkról!
- Magga: PLEX: multimédia az egész lakásban
- Lalikiraly: Astra kalandok @ Harmadik rész
-
LOGOUT
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
ekkold
#17350
üzenetére
+1 a wireguard. En most osszehuztam a laptopot es a mobiltelot kozos lokalis haloba wireguarddal, majd felpattintottam a KDEConnect-et es most a laptopon megjon minden ertesites, latom a hivast, meg tudom osztani a vagolapot, stb. az eszkozok kozott fuggetlenul attol, hogy hol milyen neten vannak, kb. ugy mint iphone-macbook-nal is meg van oldva.
-
Reggie0
félisten
-
Reggie0
félisten
válasz
Audience
#17340
üzenetére
Tul van ertekelve a problema. Alig van par radar az orszagban, ha nem a kornyeken vagy hegyteton elsz, akkor eselyed sincs zavarni. Viszont pont a surun lakott teruleteken lesz problema a DFS-el, mert megy a harc a frekikert a juzerek kozott. Audiencen pl. egy darab 160MHz-es csatorna erheto el es mind DFS/CAC-en van, tehat maskeppen hasznalhatatlan a termek arra, amire valo.
-
-
Reggie0
félisten
válasz
taki01
#17306
üzenetére
Azert mas a teljesitmeny, mert mas a frekvencia. Ez a magyar szabalyozas:
5ghz: 5180 MHz 20/40/80mhz 23 dBm indoor
5200 MHz 20/40/80mhz 23 dBm indoor
5220 MHz 20/40/80mhz 23 dBm indoor
5240 MHz 20/40/80mhz 23 dBm indoor
5260 MHz 20/40/80mhz 23 dBm DFS (CAC 1 min) indoor
5280 MHz 20/40/80mhz 23 dBm DFS (CAC 1 min) indoor
5300 MHz 20/40/80mhz 23 dBm DFS (CAC 1 min) indoor
5320 MHz 20/40/80mhz 23 dBm DFS (CAC 1 min) indoor
5500 MHz 20/40/80/160mhz 30 dBm DFS (CAC 1 min)
5520 MHz 20/40/80/160mhz 30 dBm DFS (CAC 1 min)
5540 MHz 20/40/80/160mhz 30 dBm DFS (CAC 1 min)
5560 MHz 20/40/80/160mhz 30 dBm DFS (CAC 1 min)
5580 MHz 20/40/80/160mhz 30 dBm DFS (CAC 1 min)
5600 MHz 20/40/80/160mhz 30 dBm DFS (CAC 10 min)
5620 MHz 20/40/80/160mhz 30 dBm DFS (CAC 10 min)
5640 MHz 20/40/80/160mhz 30 dBm DFS (CAC 10 min)
5660 MHz 20/40mhz 30 dBm DFS (CAC 1 min)
5680 MHz 20/40mhz 30 dBm DFS (CAC 1 min)
5700 MHz 20mhz 30 dBm DFS (CAC 1 min)Szerk:
TEVEDTEM! Most latom, hogy mind a ketto 100 alatti csatorna. Akkor egyformanak kene lennie, bar lehet hogy a masik routerben meg mas tablazat van. -
-
Reggie0
félisten
válasz
FeriPapa2
#17249
üzenetére
Ki kene deriteni, hogy ez vezetett zavar vagy sugarzott. Peldaul akkor is eldobja-e router, ha szunetmentesrol vagy akkumulatorrol van taplalva es kikapcsolod mellett a TV-t. Ha igy nem, akkor nagyon nagy valoszinuseggel az elektromos halozaton jelentkezo zaj jut at a mikrotik tapjan es az okozza.
-
Reggie0
félisten
válasz
Shkiz0
#17214
üzenetére
A 7.x.x verzioknal az a tapasztalatom, hogy ha barmilyen extra csomag van fent, abbol baj lehet frissitesnel. Ezert en mindig ugy frissitettem, hogy lementettem a configot, utana leszedtem minden extra csomagot, utana config reset es ekkor indult a frissitest, majd ugyan ez visszafele.
Szerintem valamit nagyon elszurtak, amikor attertek az egycsomagos alaprendszerre es mindig elfelejtik, hogy azert leteznek hasznalatban levo extra csomagok is. Nem tudom naluk milyen a CI/CD, de fogadnek, hogy az autotesztekbol kiszedtek.
-
#17198
Reggie0
félisten
Marcelldzso
#17197
Reggie0
félisten
válasz
Marcelldzso
#17197
üzenetére
Erdemes inkabb a forras oldalt elrakni, mert sok egyeb abra es magyarazat van ott: https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS
-
Reggie0
félisten
válasz
Zwodkassy
#17194
üzenetére
Ahogy Audience is mutaja, vagy ahogy irtam ettol a szabalytol: /routing rule add src-address=<wan2ipcime> action=lookup-only-in-table table=<wan2routingtabla>
Ez forrascim alapjan hatarozza meg, hogy melyik tablaban kell keresnie a dest ip-hez tartozo routingokat.
Linux alatt ezt source-routing-nak hivjak. [link]
-
#17193
Reggie0
félisten
Marcelldzso
#17185
Reggie0
félisten
válasz
Marcelldzso
#17185
üzenetére
Nincs mit igazan. Amugy a mangle-t is lehet hasznalni, csak ilyenkor nem a forward chainbe kell rakni a connection markot, hanem az input chainbe, mivel a mikrotik belso(proci) interfesze fele megy a forgalom es forwardot sosem lat(nem interfeszek kozott iranyitja).
Azaz az alabbi abran nem az I pontbol L-be megyunk, hanem a J-be, onnan a LOCAL-IN-be. Es I es J kozott az INPUT van, amit kaptal eddig configot, pedig a FORWARD-ba rakta a szabalyt. Ezert nem mukodott.
-
#17182
Reggie0
félisten
Marcelldzso
#17181
Reggie0
félisten
válasz
Marcelldzso
#17181
üzenetére
Hat. Lehet, hogy akkor nem artana, ha a teljes felepiteset es celjat elmondanad a halozatod ezen reszenek, mert meg azt is talalgatnunk kell, hogy mit is szeretnel valojaban.
Ha kintrol szeretnel csatlakozni es onnan szeretnel kintre valaszolni, akkor mangle sem szukseges, mivel mas IP cimed van a wan2 interfeszen, igy egy egyszeru policy based routing kell arra az ipcimre, amire bejott a csomag. Tehat a fib tablan kivul torolsz mindent amit eddig csinaltal, beleertve a tuzfalszabalyokat es csak ennyi kell:
/routing rule add src-address=<wan2ipcime> action=lookup-only-in-table table=<wan2routingtabla>
/ip route add dst-address=0.0.0.0/0 routing-table=<wan2routingtabla> gateway=<wan2interfesz> suppress-hw-offload=no -
#17180
Reggie0
félisten
Marcelldzso
#17179
Reggie0
félisten
válasz
Marcelldzso
#17179
üzenetére
Mivel a kapcsolatot bentrol kezdemenyezzuk kifele ezert a benti interfeszen kell markolni a csomagokat, hogy tudjuk merre kell tovabbkuldeni. Amit te csinaltal az pedig a wan interfeszen markolja a csomagot, aminek max akkor van ertelme, ha kintrol be lehet csatlakozni es mondjuk portforwardolsz. De alapbol nem ez kell neked.
Szoval inkabb igy:
/ip firewall mangleadd action=mark-connection chain=forward in-interface=wg new-connection-mark=connWAN2 passthrough=yesadd action=mark-routing chain=prerouting connection-mark=connWAN2 in-interface=wg new-routing-mark=wgtable passthrough=yesA tobbi sor az rendben van.
-
Reggie0
félisten
válasz
Ablakos
#17171
üzenetére
Attol fugg milyen router, lehet meg lehet oldani a hw offloading elvesztese nelkul is layer 2 acl segitsegevel.
Az a baj, hogy ha a bridgeben tuzfalazol, akkor elkuld mindent a procinak es elveszted a switch chip adta sebessegelonyt.
Ha meg kulon bridget hozol letre, akkor arra a ket kulon portra veszted el a sebesseget, mert azokat atkuldi a procinak. Illetve az a forgalom is a procin megy at, ami a bridge1 es a masik ket port kozott zajlik. -
Reggie0
félisten
válasz
Audience
#17160
üzenetére
A leiras nem azt irja, amit te mondasz. Ha megnezed, akkor pl. egy lokalis halozatnal csak az interfesz neve van ott a routingban. Ez azt jelenti, hogy az adott halozathoz azon az interfeszen kell kimenni a csomagnak, ehhez a MAC cimet lookupolnia kell. Ha IP cim (is) van megadva az azt jelenti, hogy nem kell MAC cimet lookupolni, hanem a default gw-nek megadott ipcimu gep MAC addressere kell kuldeni. Ezert van az, hogy a csak interfesz neves route-nak 0 lesz a distance, mig az IP cimesnek mar 1, mert ott egy masik host-on keresztul tortenik a kommunikacio.
Persze lehet, hogy peldaul PPPoE-nel van olyan okos a rendszer, hogy rajon az egy pont-pont tunnel igy logikusan csak a tuloldal MAC cime van es emiatt nem fogja izgatni, hogy az if neve vagy cime van megadva, de erre mondtam, hogy ki kell probalni.
Viszont ha ez mukodik akkor Marcelldzsonak csak a scriptes reszet oldja meg, a tobbire meg szukseg lesz. A packet flow/routing decision ugy megy, hogy eloszor a celcimhez keres routing szabalyokat lehetoleg minel rovidebb eredo distancevel. Ha versenges van, akkor mukodestol fuggoen sorrendben vagy esetlegesen round robin rendszerben kivalasztja egyiket. Majd miutan megvan, hogy a default gw milyen cim lesz annak megfeleloen valaszt interfeszt. Tehat a logika forditott, mint ebben az esetben varnak, nekunk elobb kene interfeszt valasztani es az interfesz szerint routingot.
-
#17155
Reggie0
félisten
Marcelldzso
#17153
Reggie0
félisten
válasz
Marcelldzso
#17153
üzenetére
Sajnos ez nem lesz egyszeru menet, ha nem statikus routingot hasznalsz, hanem DHCP vagy PPPOE kapcsolatot a WAN2 porton, azaz a default gateway cimet valamilyen kapcsolat felepitese kozben kapod meg. Ekkor muszaj lesz scriptet hasznalnod es scriptbol felhuznod/frissitened egy masodik routing tablat - mivel ezekkel a protokolokkal csak a main routing tablaban allitja be a default gw-t - , aminek a default gw-jet beallitod a wan2 gw cimere, majd policy based routingot adsz meg a wan2 connectionokra, amiket a mangle tabla prerouting chainjeben kell connection markingolni mikor beesnek a wan2 interfeszen.
-
-
Reggie0
félisten
válasz
seqwel
#17080
üzenetére
Nem lehet tudni, sehol sem lattam megemlitve. A forumon csak talalgatnak a felhasznalok, hivatalosat nem lattam rola. A tamogatas eddig csak ARM, MIPSBE es TILE architekturakon volt, de a docker csak az elobbi kettot tamogatja hivatalosan, igy TILE architekturara letoltheto vagy minta cointainer sem letezik. Tehat attol is fugg, hogy lesz-e valaha az eszkozodon, hogy milyet veszel.
-
#17036
Reggie0
félisten
E.Kaufmann
#17033
Reggie0
félisten
válasz
E.Kaufmann
#17033
üzenetére
Nem tudok rola, hogy terveznek.
-
-
Reggie0
félisten
válasz
gidacska
#17000
üzenetére
Elvileg kompatibilis, de a PoE uzemmodokat nem talaltam meg online, igy lehet, hogy a PoE switch es a PoE eszkozok kozott cross-link-nek kell a csatlakozokat krimpelni, hogy megkapjak a tapot.
Ha falra szereled fel a cap AC-t, akkor szamolj azzal, hogy a fal fele nem fog sugarozni erdemben.
-
Reggie0
félisten
válasz
Audience
#16978
üzenetére
Igen, igy van. Akar nincs kivezetve a trafo, akar ki van, a kozeppontokat ellenallasokon(75 Ohm) keresztul levalaszto kondira kotik (Bob Smith Termination a neve, szoktak BST-nek is hivni). A trukk ott van, hogy sporolnak a kondival es a kozeppontokrol lejovo ellenallasok masik felet kozositik es igy csak egy darab kondival mennek tovabb a fold fele. Ezzel az a problema, hogy ha PoE tapot kapnak, akkor az egy 150 ohmos ellenallast kepezt a tapra ket kozepmegcsapolas kozott, ami persze nem birja azt a teljesitmenyt elfuteni, ami kialakul rajta(pl. 50V poenel az 16.6W lenne, mig negyed-tizenhatod wattosak az ellenallasok). Jobb oldali bekarikazott resz: (jobb oldali bekarikazott megy a kabelre)
Ahol nincsen kivezetve, ott maga a trafo tartalmazza a Bob Smith lezarast(jobb oldal megy a kabelre):
Erre az a normalis megoldas, hogy ellenallasonkent egy-egy kondit terveznek, igy nem tud egyenaram folyni, de a vezeteket nagyfrekvencias szempontbol lezarja.Ezen az abran pedig lathatod, hogy hogyan oldjak meg a problemat: mindegyik 75Ohmos ellenallassal sorbakotnek egy 10-47nF-os kondenzatort, hogy egyenaram ne tudjon folyni az ellenallasokon. Ez mar egy PoE kompatibilis kapcsolas, ha nem is hasznalja a PoE-t nem fog elfustolni, ha akar passziv vagy aktiv PoE-s kabelre dugjak: (a jobb oldal megy a kabelre)
-
Reggie0
félisten
válasz
gidacska
#16973
üzenetére
Passziv felado vagy bekapcsolasra kenyszeritett kimenetu switch tonkrevaghat eszkozoket. Igazabol az eszkozoktol is fugg, mert van ami ugy van tervezve, hogy nem zavarja egyaltalan a poe feszultseg. (Vicc vagy nem, igazabol ez a turokepesseg 4 darab extra filleres kondenzatort jelent a gyarto oldalarol a nem POE-s eszkozoknel).
-
#16936
Reggie0
félisten
Marcelldzso
#16932
Reggie0
félisten
válasz
Marcelldzso
#16932
üzenetére
Amint kiderul ide fogom irni.
-
#16931
Reggie0
félisten
Marcelldzso
#16930
Reggie0
félisten
válasz
Marcelldzso
#16930
üzenetére
Akkor igen. Esxi nem tudjuk mennyire viszi, egyik ismerosom rendelt belole, hogy letesztelje, de elmeletileg jonak kene lennie.
-
#16928
Reggie0
félisten
Marcelldzso
#16927
Reggie0
félisten
válasz
Marcelldzso
#16927
üzenetére
Mi lenne jo neked?
-
Reggie0
félisten
válasz
Zwodkassy
#16896
üzenetére
forras es cel ip valamint interfesz vagy routing-mark alapjan eltero routing tablakat tudsz hozzarendelni illetve filterelni.
Peldaul nekem ugy van fix ip cimem, hogy egy vps-re van egy tunnelem. Onnan forwardolom at a bejovo csomagokat a tunelen keresztul a routernek. Igy a visszafele iranyu kommunikacional, amikor a tunnel lokalis ipcimerol megy kifele a valasz, akkor egy masik routing tablara van szukseg, kulonben a normal wan-os uplinken akarja kikuldeni a csomagot.
Egy peldaval bemutatva: interneten egy gep 1.1.1.1 cimrol csomagot kuld a vps ipcimere(legyen 2.2.2.2). Innen tuzfalbol atforwardolom a tunnel routeremen levo vegpontjara(legyen ez a tunnel lokalis fele, 3.3.3.4 cim). Ekkor a forward utan(dst nat volt ugye tehat az ip csomagnal 1.1.1.1->2.2.2.2 cimebol 1.1.1.1->3.3.3.4 lesz). Ekkor a 3.3.3.4 valaszolni akar es azt latja, hogy 1.1.1.1-re kell kuldeni a valasz. A normal routing tabla alapjan a default route a wan interfesz fele kuldene. Ezert kell egy olyan szabaly, hogy 3.3.3.4 forras eseten egy alternativ routing tablat hasznaljon, ahol a default gateway 3.3.3.3 ami a vps-en levo tunnel vegpont ipcime. Igy a vps-re jut vissza a csomat, az latja, hogy forwardolva volt es visszanatolja, igy a 3.3.3.4->1.1.1.1 csomagbol 2.2.2.2->1.1.1.1 csomag lesz, mintha a vps-es gep valaszolna.
-
-
Reggie0
félisten
válasz
ekkold
#16894
üzenetére
Nezd ugy, hogy 2x25gbites halokartya helybol, aminek elegge olcso. Egy egyszeru 10gbites NIC is 100 dolcsirol indul boltban, ez meg 2x25 mindossze 200 dolcsiert.
Amugy arra jo, hogy ocska oprendszerrel is lehet jol tuzfalazni. Peldaul nyugodtan rakhatsz a gepre windowst, vagy az oprendszer tudta nelkul tudsz tunnelezni/vpnezni, ha megtorik a gepet a network meg vedett maradhat, stb., stb.. Vagy szinten oprendszer nelkul lehet failoverezni, load balancingolni a kartyaval. Eleg sok szituacio van amikor elonyos lehet egy ilyen felallas.
De ha azt nezzuk felaron kapsz egy CCR2xxx-es routert. Legtobb embernek csak az kell, hogy NAT-olja a WAN-t, majd filterezzen. Egy sokportos switch SFP+-os uplinkkel mehet bele ebbe es akkor nem kell azon fajjon a feje, hogy csak 16 portot kap maximum a CCR2004-ek melle.
-
Reggie0
félisten
válasz
ekkold
#16102
üzenetére
Szerintem te egy lassu CCR-en mertel, nem az 1.2GHz-esenl, mert ezen 800Mbit felett megy a wireguard meg natolva is nat nelkul pedig megvan a 900mbit is.(LAN-on tesztelve, smb fajl masolassal).
Az a nagy kulonbseg, hogy a ccr-ben networkinges a proci, azaz az osszes port prociba van bekotve es sok feladatot hardverbol helybol megold, emiatt gyorsabb tud lenni. Peldaul akarhany bridged lehet, mindegyik ugyan olyan gyors lesz, igy tetszoleges groupokba tudod a switch portokat osszehozni, mig a tobbi switch chipesen csak egyhez lesz hw offload. Igy ezt RB5009-en csak egy bridge-vel es layer2-es filteringgel tudod megoldani, de az elegge szukos, mert csak 256 elemet lehet a filter tablajaba rakni, ez a switch chip limitacioja.
Vagy peldaul a queue-kat is kb. ketszer gyorsabban kezeli. -
-
Reggie0
félisten
Azok sajat honeypotokat hasznalnak, a juzerekre nem alapoznak.
"ha bizonyítékra van szükség, a kulcsot berakod a drop loggolós szabályhoz prefixként utána a log bejegyzéseket meg egy script felszedné és beküldené mondjuk valami HW egyedi azonosítóval összekötve"
Ezt konnyu hamisitani, hiszen maguk az eszkozok nem alairt logot adnak. No meg logot krealni sem bonyolult dolog, eleg csak transzparensen beekelodni a router ele egy masik routerrel es mar barmilyen ipcimrol lehet injektalni csomagokat. -
Reggie0
félisten
válasz
starchild
#16590
üzenetére
Teny, hogy mas kategoria
Szerintem nincs azzal gond, ha rezes portok karara megy. Viszont a jelenlegi switch chip csak 2db 10g portot tud, a procihoz meno 10g porton felul, igy nagyobb atalakitast igenyelne. Vagy a pcie buszt kene bealdozni egy nic-re.
De a 2.5 gigas portot nyugodtan cserelhetnek 10-esre.
Új hozzászólás Aktív témák
- Óvodások homokozója
- Pánikban a világ a Radeon RX 5000 és 6000 sorozat támogatása miatt
- sh4d0w: Kalózkodás. Kalózkodás?
- Xiaomi 15 - kicsi telefon nagy energiával
- Elektromos autók - motorok
- Gitáros topic
- ASUS routerek
- Miskolc és környéke adok-veszek-beszélgetek
- 5.1, 7.1 és gamer fejhallgatók
- Mikrotik routerek
- További aktív témák...
- Corsair Vengeance DDR5 16 GB / 5200MHz / 2x8
- Dell Latitude 5420 Újszerű állapotban, i5 FHD IPS LCD,16GB,magyar világítós billentyűzet
- Dell Latitude 5420 Új, Fóliás állapotú,i5 FHD IPS LCD,16GB,magyar világítós billentyűzet
- DELL P2714H "27 colos kalibrált IPS panellal rendelkező monitorom eladó tökéletes állapotban!
- MSI GTX 1070 Ti GAMING 8G stabil, működésileg megbízható állapotban eladó!
- Microsoft Surface Laptop 3 13.5" fekete i5-1035G7 16GB 512GB 1 év garancia
- HIBÁTLAN iPhone 13 mini 256GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3441, 92% Akkumulátor
- LG 27UP850K-W - 27" IPS LED - 3840x2160 4K - DisplayHDR 400 - USB Type-C - AMD FreeSync
- Apple iPhone 12 Mini 64GB, Kártyafüggetlen, 1 Év Garanciával
- HIBÁTLAN iPhone 13 Pro 128GB Alpine Green -1 ÉV GARANCIA - Kártyafüggetlen, MS2978
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest