Hirdetés
- Gurulunk, WAZE?!
- MaxxDamage: (TongFang) Medion Erazer Beast 16 X1 benchmark
- Luck Dragon: Asszociációs játék. :)
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- GoodSpeed: Márkaváltás sok-sok év után
- bb0t: Ikea PAX gardrób és a pokol logisztikája
- sziku69: Fűzzük össze a szavakat :)
- D@reeo: Send to qBittorrent Firefox kiegészítő (with SavePaths)
- sziku69: Szólánc.
- Viber: ingyen telefonálás a mobilodon
-
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
-
Adott egy RB951-es router, ami egy másik router mögött van (passz a márka és a típus, talán Tp-Link). Az ismeretlen típusú router van közvetlenül a neten, mögötte az RB951, de nem NAT-ol hanem ROUTE-ol. A net megy is szépen, nem is ez a kérdés.
Azt kéne megoldani, hogy az RB951 mögötti gépek úgy lássák, mintha Ntp/Sntp szerver lenne a router. Ha NAT üzemben menne az Miki, akkor ez nem is volna gond, egy egyszerű dst-nat szabállyal ezt meg tudnám oldani.
Például így:
add action=masquerade chain=srcnat out-interface=ether1 src-address=\
192.168.80.0/21
add action=dst-nat chain=dstnat comment="Ntp/Sntp redirect" dst-port=123 \
in-interface=BridgeLocal protocol=udp to-addresses=148.6.0.1 to-ports=123Viszont ez a Miki nem NAT üzemben megy, hanem ROUTER-ként.
És még mielőtt bárki SNTP Server-ként szeretné konfiguráltatni a Mikit, köszi szépen, nem ez a kérdés, és nem ez a feladat. -
-
válasz
Adamo_sx
#1381
üzenetére
"natolt hálóban levő mikrotik router lehetőségei már eléggé korlátozottak"
Ha a Miki az egyetlen router a kis helyi hálózatban, vagy ő a második ugyanitt, ugyanúgy 1db NAT van az útvonalban. Tehát van egy NAT itt is,meg ott is. Ugyan annyi korlát (NAT) van. Vagy valamit még nem számoltam bele?
-
#1379
Zwodkassy
senior tag
nyilasmisi
#1372
válasz
nyilasmisi
#1372
üzenetére
Azért egy 100/50-es net ma már nem mondható nagy kihívásnak, még PPPoE-n kersztül sem :-)
-
Ugye itt már többször is szó volt arról, hogy a kis Miki routerek (pl. Rb951G sorozat) megtérdelnek a PPPoE kapcsolattól (nem túl gyosak ezen a téren :-).
Próbált már valaki olyat (mondjuk Digi környezetben), hogy a Miki-t berakta egy HardwareNAT-os kütyü mögé? Mondjuk egy olcsóbb (bár ez relatív) Tp-Link mögé. És itt részemről nem használnék dupla NAT-ot, mivel a Miki "csak sima" Router üzemben menne az első mögött.
A dupla router-es megoldás műxik a gyakorlatban lepróbáltam: az első router (DrayTek) NAT, a második (MikroTik) Router üzemben fut. De mivel nem Digi Giga területen vagyok, a sebességet nem tudom tesztelni :-( -
válasz
balaaa88
#1261
üzenetére
"Monnyuk tiltsd le a telnetet és az ssh-t. Vagy Adj hozzá egy tűzfalszabályt, hogy ha nem LAN-ból érkezik a csomag, akkor dobja el őket."
Szerintem még csak tűzfal szabály sem szükséges. Minek lassítani/terhelni a routert. Egyszerűen csak megadod, honnan érhető el ezekkel a szolgáltatásokkal a router:
-
válasz
SimLockS
#1137
üzenetére
"Erről jut eszembe egy kérdés: HapLite -nál miért nem megy a Winbox??? Az említett kis papírka szerint mennie kellene...
"HapLite esetében már 3-as sorozatú WinBox-ot kell használni. A ROS 6v33-tól felfelé pedig már a 3-as sorozatú RC kiadások sem jók, csak is a 3.0 :-)
-
"Szerintem ha az eszköz frekit is vált, (vagy más az ssid), stb, akkor nem lesz folyamatos a kapcsolat, azaz a váltásnál újból kap pl dhcp-n ip-t. Ez szerintem még capsmannel is igy van, mert maga az eszköz fogja kezdeményezni ezt, neki az a hálózat NEM ugyanaz. Bár ezt nem próbáltam.
Capsmanban azonos profilt használva, az én eszközeim úgy váltanak a cap-ok között, hogy nem szakad meg a kapcsolat, pl. ping folyamatos, stb. Sőt, nem is látszik több eszköznek sem windows, sem android alól."
Az én tapasztalataim szerint akár Winfows akár Driod alól nézve egy hálózatnak látja a CAPsMAN-os hálózatot (még eltérő freki mellett is). Igaz, ezt CAPsMAN Forwarding üzemmódban néztem. Bár számomra ez logikus is lenne (minden kérdésre akad, egy könnyen érthető, téves válasz :-), hisz ilyenkor a kliensek minden egyes AP-t úgy látnak, mintha az a központi egység lenne, ugyanis minden egyes CAP a CAPsMAN saját virtuális interfésze.
Azért majd egy PING folyamatosságot letesztelek :-) -
"Miért kellene mást? Szerintem pont ez a lényege, hogy nem csak központilag van menedzselve, de teljesen transparensen vált, stb. Egy freki, naná, több ilyet is csináltam, remekül megy.
Régebben (capsman előtt) erre egy wds mesh hálót kellett csinálni, az is működött, de tény, hogy a capsman sokkal megbizhatóbb. A wds mesh is ugyanazon a frekvencián ment."
"Nem akarok veled viszályt jó lovag, de a hídon átmegyek, ha addig élek is" :-)
A WDS esetében egyazon frekit kell (!) mindenkinek használni. Ugye ott egy csatornán (frekin) beszélget minden eszköz, mivel egyszerre töltik be a Kliens és AccesPoint szerepét is. És mivel folyamatosan beszélgetnek/szinkronizálnak egymást között, ennek megfelelően feleződik, harmadolódik, negedelődik a sávszélesség is.
Központi AP menedzsment esetében viszont sok egymástól "független" AP-ról beszélünk. Itt a menedzsment, azaz a konfiguráció a központi, ami nem a "levegőben" történik, hanem kábelen. Azaz egy központi helyről kapja meg mindenki a saját konfigját: freki/csatorna, csatorna szélesség, SSID, titkosítás, autentikáció stb. Ennek megfelelően a forgalmuk is teljesen független lehet egymástól. És most itt mindegy is, hogy Miki, Ubi, Draytek, Cisco vagy miféle (kiféle) megoldásokról beszélgetünk.
Ez a megoldás pont ezért "értékesebb" és jobb egy WDS-nél.
De egyébként ezt te magad is kipróbálhatod a CAPsMAN alatt: AUTO frekit adsz meg minden CAP-nak, és megnézed, milyen csatornát választanak :-) -
-
"3 v. 4 hap lite biztos, hogy jobb lefedettséget ad. Ha pénz nem számit, akkor lehet jobb két darab rb951, de egy bármilyen ház lefedettségére tuti a 4 db hap lite jobb eredményt ad."
Amennyiben ez kivitelezhető, akkor érdemes rajta elgondolkozni.
Bár itt már jönnek a technikai kérdések:
1. az RB951Ui-2HnD és RB951G-2HnD modellek, mint az a nevük is sugalja DualChain-esek (2,5 dBi belső antennákkal), és nagy kimenő teljesítményűek (bár ez utóbbi jelen esetben nem érdekes).
2. 4db AP viszonylag "kis" térben... Csatorna átfedésekkel vigyázni kell! Még akkor is, ha csak 20MHz-t használ az ember (ez a sz***s a 2.4GHz használatával). -
"A wifi roaming menni fog minden kliensen, még win phoneon is. Ha most egy ap majdnem lefedi, akkor 2 v. 3db ap biztosan meg kellene oldja.
Hap lite 5e ft netto, ebböl plusz 2db nem akkora költség"Hát engem személy szerint a HapLite Wifi része nem győzött meg. CAP-ként használtam CAPsMAN alatt. Igaz, az árához képes viszont baromi jó eszköz. Most egy RB951Ui-2HnD egységet használok ugyan erre a célra, de sokkal jobb lefedettséget és sebességet biztosít (szerintem). Persze árban sem ugyanazokról beszélünk :-)
Kérdés, hogy egy hAP / wAP / cAP hogyan teljesítene? -
-
-
-
válasz
SimLockS
#983
üzenetére
Az egyes CAP-k a CAPsMAN virtuális interfészei. Kérdés, erre/ezekre lehet-e QUEUE szabályokat illeszteni? Ezek szerint nem (én még nem próbáltam). Viszont BRIDGE interfészre biztosan lehet. Mivel a CAPsMAN-ben meg kell adnod a CAP-khez egy konfigurációt, amibel szerepelni kell egy BRIDGE interfésznek, így ezekre a BRIDGE-kre is megírhatod a QUEUE szabályaidat. Azaz minden CAP-hez, definiálsz egy BRIDGE-t (elegendő egy konfiguráció, csak a CAP-n átírod/átállítod a BRIDGE-t). Kicsit nyakatekertnek tűnhet,de szerintem nem vészes :-)
-
#934
Zwodkassy
senior tag
vitezlejszlo
#933
válasz
vitezlejszlo
#933
üzenetére
"Próbálgattam ezt a capman témát, és olyan érzésem van, mintha a capmanos hAPlite lassabb elnne, mintha nem capmanos modban hanem nativ AP-kent uzemel. Semmi trukk nincs a konfigban lokalis lanra tolja ki a forgalmat, csak a wifi kozpontositva van managgelve, de ha igy van az AP akkor kb 20Mbitet tudok belole kihozni, ha meg nativan megy akkor 28-at. Lattatok mar ilyen csodat?"
"Local Forwarding" vagy "CAPsMAN Forwarding" üzemben megy a CAP? Mert ugye k***a nem mindegy :-)
-
Na, megnéztem, felelevenítettem, mi is volt a trökkje a dolognak. "HairPin-Nat" alkalmazásakor ugye használunk "Port Forward"-ot is. Ez ugye arra kell, hogy kívülről elérjünk egy belső szolgáltatást:
add action=dst-nat chain=dstnat comment="NAS - Ftp+Ftps" \
dst-address dst-port=2121,55536-55663 in-interface=\
pppoe-adsl-out1 protocol=tcp src-address-list=!Balcklist to-addresses=\
192.168.0.100A "Haipin-Nat" segítségével pedig ugyanúhy érhetjük el belülről a szolgáltatást, mint kívülről:
add action=masquerade chain=srcnat comment="HairPin-Nat - NAS" dst-address=\
192.168.0.100 dst-port=2121,55536-55663 out-interface=bridge-local \
protocol=tcp src-address=192.168.0.0/24Csakhogy valamiért ez így nem működik ... neked sem :-) Megoldás:
add action=dst-nat chain=dstnat comment="NAS - Ftp+Ftps" \
dst-address dst-port=2121,55536-55663 protocol=tcp src-address-list=!Balcklist to-addresses=\
192.168.0.100
A "Port Forward" részből kitöröljük az "in-interface" bejegyzést :-) De,hogy mi ebben a logika?!? -
"Ugyanúgy van nálam, csak nálam nem működik"
Mennyire ugyan így? Csak azért kérdezem, mert a "bridge-local" elnevezésből úgy tűnik, mintha ez egy "Default Config" lenne. Márpedig ebben az esetben valamelyik ethrnet interface (pl ether2-local-master) kapja a belső (Lan) IP-t és nem a Bridge. -
Ezzel a hajtű témával nekem is voltak először gondjaim :-) De most műxik:
add action=masquerade chain=srcnat comment=\
"Hairpin-Nat - Nas
tp,Ftps,Https" dst-address=192.168.81.100 \
dst-port=2121,5001,55536-55663 out-interface=Br-Lan81 protocol=tcp \
src-address=192.168.81.0/24
A "Br-Lan81" egy Bridge Interface. Ezen van az (egyik) belső Ip cím és az (egyik) Dhcp Server (is). -
válasz
Zwodkassy
#902
üzenetére
6 chain=forward action=accept protocol=tcp dst-port=80 log=no
log-prefix="filter"7 chain=forward action=accept protocol=udp dst-port=80 log=no log-prefix=""
8 chain=forward action=accept protocol=tcp dst-port=443 log=no
log-prefix=""9 chain=forward action=accept protocol=udp dst-port=443 log=no
log-prefix=""Ezekre miért is van szükség? Én használok "port-forward"-ot, de ilyen szabályok nélkül, és műxik.
Üdv,
z -
1 chain=dstnat action=dst-nat to-addresses=192.168.88.254 to-ports=80
protocol=tcp in-interface=ether1-gateway dst-port=80 log=no
log-prefix=""2 chain=dstnat action=dst-nat to-addresses=192.168.88.254 to-ports=80
protocol=udp in-interface=ether1-gateway dst-port=80 log=no
log-prefix=""3 chain=dstnat action=dst-nat to-addresses=192.168.88.254 to-ports=443
protocol=tcp in-interface=ether1-gateway dst-port=443 log=no
log-prefix=""4 chain=dstnat action=dst-nat to-addresses=192.168.88.254 to-ports=443
protocol=udp in-interface=ether1-gateway dst-port=443 log=no
log-prefix=""Hát ebből a 4db szabályból szerintem 2db UDP-nek nincs értleme (legalább is ezek tipikus TCP-k).
És a másik kettőt is egy szabályba "sűríteném":1 chain=dstnat action=dst-nat to-addresses=192.168.88.254 to-ports=80,443
protocol=tcp in-interface=ether1-gateway dst-port=80,443 log=no
log-prefix="" -
"Azért az utóbbi időben annyi soho cuccot dobott a piacra mikrotik, tegyük hozzá tudásához mérten nagyon versenyképes áron, hogy én nem tartom elvetemült ötletnek, ha lenne egy duál wifis, duál chaines gigabites soho routere.."
Papíron már létezik: hAP ac a neve
• Our first Gigabit dual concurrent home AP
• 2.4GHz high power 2 chain 802.11n
• 5GHz high power 3 chain 802.11ac
• 5 Gigabit Ethernet & 1 SFP cage
• 720MHz CPU
• 300MHz DDR2
• PoE in
• PoE-out on port 5Ennek az "egyszerűsített" verziója a hAP ac Lite lesz :-)
• Our first dual concurrent home Access Point
• 2.4GHz dual chain 802.11n
• 5GHz single chain 802.11ac
• 5 Fast Ethernets
• 650MHz CPU
• 300MHz DDR2 RAM
• PoE in
• PoE-out on port 5 -
#844
Zwodkassy
senior tag
Petrowiczki
#817
válasz
Petrowiczki
#817
üzenetére
"Másodszor, ha nem képzem magam soha nem lehetek jó a szakmámban! Ezzel az eszközzel illetve társaival még nem volt dolgom. Most belefutottam és szeretek új dolgokat tanulni főleg ha hasznos tudásra teszek szert. A munkahelyemen is alkalmazunk Mikrotik eszközöket, és a tanfolyam kicsit húzós. Ezért próbálom magam illetve a net segítségével megoldani ill megtanulni mit miért hogyan kell.
Szeretném jól és maximálisan használni az adott eszközt mivel nem volt olcsó de amire nekem kell a későbbiekben arra tökéletes."A "tanfolyam kicsit húzós", "az adott eszköz nem volt olcsó". Hát pedig ezek még igen csak Low Budget eszközök. Cak nézzél szét más márkák háza táján!
-
"Senki nem próbálta együtt használni a Queues + Fast path/fasttrack kombót?
Úgy tapasztalom, hogy amint bekapcsolom a fasttrack-et, a queues hasztalanná válik."IPv4 FastTrack handler
IPv4 FastTrack handler is automatically used for marked connections. Use firewall action "fasttrack-connection" to mark connections for fasttrack. Currently only TCP and UDP connections can be actually fasttracked (even though any connection can be marked for fasttrack). IPv4 FastTrack handler supports NAT (SNAT, DNAT or both).
Note that not all packets in a connection can be fasttracked, so it is likely to see some packets going through slow path even though connection is marked for fasttrack. Fasttracked packets bypass firewall, simple queues, queue tree with parent=global, ip traffic-flow, ip accounting, ipsec, hotspot universal client, vrf assignment, so it is up to administrator to make sure fasttrack does not interfere with other configuration;
-
Hát a Miki honlapja szerint alapból 6 dBi az antennája.
http://routerboard.com/RBGrooveA-52HPn
Azaz, ha ezt szerelted rá fel, akkor az Antenna Gain értéknek ezt (kellene) megadni. Persze ha ettől eltérőt használsz, akkor annak megfelelően. Ugyanis ezt figyelembe veszi (kalkulál vele) mind az adás, és mind a vétel esetében. Elnézve a Miki saját fórumát is, ezt az értéket érdemes komolyan venni.
-
/ip firewall nat
add action=dst-nat chain=dstnat comment=ftp20 dst-address=public_ip_cimed dst-port=20 protocol=tcp to-addresses=belso_eszkozod_ip_cime to-ports=20
add action=dst-nat chain=dstnat comment=ftp21 dst-address=public_ip_cimed dst-port=21 protocol=tcp to-addresses=belso_eszkozod_ip_cime to-ports=21Nem kötöszködés képpen írom, de azért érdemes a tűzfal szabályokkal spórolni:
/ip firewall nat
add action=dst-nat chain=dstnat comment=ftp20-21 dst-address=public_ip_cimed dst-port=20-21 protocol=tcp to-addresses=belso_eszkozod_ip_cime to-ports=20-21 -
Sziasztok!
Amikor egy ilyen Miki Dns védelmet csinálok, melyik a jobb praktika?
A bejövő/internetes interface-t megadni?add action=drop chain=input comment=Dns-Tcp dst-port=53 in-interface=\
ether1-gateway protocol=tcp
add action=drop chain=input comment=Dns-Udp dst-port=53 in-interface=\
ether1-gateway protocol=udpVagy csak adott IP cím tartományt engedélyezni?
add action=drop chain=input comment=Dns-Tcp dst-port=53 protocol=tcp \
src-address=!192.168.80.0/22
add action=drop chain=input comment=Dns-Udp dst-port=53 protocol=udp \
src-address=!192.168.80.0/22Számomra ez utóbbi akkor tűnik előnyösebb, ha több WAN (internetes) interface-t használunk,így elegendő csak ez az egy (kettő) szabály.
-
Mikrotik alatt/mögött lévő eszköznek szeretném korlátozni a maximum kapcsolatok számát. Mivel mindkét irányban (bejövő és kimenő) szeretném korlátozni; gondolom így két szabályt kell alkalmaznom. Kersgettem erre pédlákat a neten, és ezt sikerül kisütnöm belőle:
add action=drop chain=forward comment="TCP Connection Limits" \
connection-limit=51,32 disabled=no protocol=tcp src-address=11.22.33.44 \
tcp-flags=syn
add action=drop chain=forward comment="TCP Connection Limits" \
connection-limit=51,32 disabled=no protocol=tcp dst-address=11.22.33.44 \
tcp-flags=syn1. Ez így működhet (még nem tudtam tesztelgetni)?
2. Ahogy elnézem, ez csak TCP-re korlátoz. Ha UDP-re is akrok korlátozni, akkor kell még két ilyen szabály?Előre is köszi!
Z -
Az oldal "IPv4 FastTrack handler" részénél ott a megoldás:
http://wiki.mikrotik.com/wiki/Manual
ast_Path"Fasttracked packets bypass firewall, simple queues, queue tree with parent=global, ip traffic-flow, ip accounting, ipsec, hotspot universal client, vrf assignment, so it is up to administrator to make sure fasttrack does not interfere with other configuration."
Evvan :-)
-
"Gondolom amikor már a content vizsgálat menne, akkor az már rég related, established csomag, igy ignorálódik az a tűzfal szabály."
De a "Related + Established" a
add chain=forward comment="default configuration - Related+Esteblished" \
connection-state=established,relatedszabálytól is igaznak kellene, hogy legyen, mégis csak a
add action=fasttrack-connection chain=forward comment="default configuration" \
connection-state=established,relatedszabály megléte esetén nem működik a szűrés.
"Bár a sorrend szerint nem kellene, de ha aktiv a fasttrack akkor az egy különleges "mangle" jelet kap utána, és gyanítom felborul a sorrend.
A 443-as portba eddig sem láthattál bele, zárd ki ha a 80-as port a dst, akkor nem lehet fasttrack."Ha csak 80-as dst portot használok, akkor is ez a jelenség :-(
Kérdés hogyan működik ez a FastTrack -
#637
Zwodkassy
senior tag
HwAdokVeszek
#553
válasz
HwAdokVeszek
#553
üzenetére
Kipróbáltam ezt a FastTrack funkciót, és úgy néz ki, tényleg segít egy kicsit a routernek (RB951G).
Viszont, hazavágta a tűzfal szabályaim egy részét. Itt is a "Url Content Filter" szabálysoromat:/ip firewall filter
add chain=input comment="default configuration" protocol=icmp
add chain=input comment="default configuration - Related+Esteblished" \
connection-state=established,related
add action=drop chain=input comment="default configuration" in-interface=\
ether1-gateway
add action=jump chain=forward comment="Jump to Url-Block" dst-port=80,443 \
jump-target=Url-Block protocol=tcp
add action=fasttrack-connection chain=forward comment="default configuration" \
connection-state=established,related
add chain=forward comment="default configuration - Related+Esteblished" \
connection-state=established,related
add action=drop chain=forward comment="default configuration" \
connection-state=invalid
add action=drop chain=forward comment="default configuration" \
connection-nat-state=!dstnat connection-state=new in-interface=\
ether1-gateway
add action=drop chain=Url-Block content=adverticum
add action=drop chain=Url-Block content=bing.com
add action=drop chain=Url-Block content=gemius.hu
add action=drop chain=Url-Block content=livejasmin
add action=drop chain=Url-Block content=meetdominatrix
add action=drop chain=Url-Block content=femdomchatcity
add action=drop chain=Url-Block content=888poker
add action=drop chain=Url-Block content=xtrasize.hu
add action=drop chain=Url-Block content=pog.com
add action=drop chain=Url-Block content=saloontube
add action=drop chain=Url-Block content=extremetube.com
add action=drop chain=Url-Block content=nunuba.com
add action=drop chain=Url-Block content=fapsex.com
add action=drop chain=Url-Block content=gigiporn.com
add action=drop chain=Url-Block content=play.glomobi.com
add action=drop chain=Url-Block content=landing.pkr.com
add action=drop chain=Url-Block content=ofbinarysystem.com
add action=drop chain=Url-Block content=bb-dating.com
add action=drop chain=Url-Block content=xlovecam.comAmennyiben aktív a "fasttrack-connection" szabály, akkor nem megy az "Url-Block". Ha kikapcsolom, akkor működik (???)
Igen tudom, lehetne ezt Web-Proxy használatával is csinálni, bár nem vagyok benne biztos, hogy kevesebb erőforrással. -
#556
Zwodkassy
senior tag
HwAdokVeszek
#555
válasz
HwAdokVeszek
#555
üzenetére
Bitte-danke!
Amint időm engedi, én is kiprószálom! -
#554
Zwodkassy
senior tag
HwAdokVeszek
#553
válasz
HwAdokVeszek
#553
üzenetére
Az nem rossz! És bonyolult a beállítása? A MikroTik forumon olvasok róla hideget és meleget is egyaránt.
-
Sziasztok,
tegnap állítottam hadrendbe egy RB951G routert. Minden flottul működik kivéve a thome iptv-t.
T-home net egy Cisco EPC3825 modem/routeren keresztül jön. Ha ebbe dugom direktbe az iptv-t minden jön rendesen. Ha a Mikrobiba, akkor csak a csatorna neveket látom, elektronikus műsorújságot, de magát képanyagot nem. Tudja esetleg valaki, hogy milyen szabályt kellene állítanom a mikrobiban?Ezt még régen találtam valahol, egy fórumon:
Configuration of IPTV
IPTV uses IGMP to subscribe to your provider's TV broadcast. To make this work, we need an IGMP proxy which can forward multicast traffic to your IPTV, and configure firewall to allow such traffic. In this tutorial, I will follow my router's settings, so at some places it is up to you to change the settings described here to your needs. My goal was to make this work with the set top box provided by my ISP, so if you want to watch stream on your computer (with VLC for example) this might or might not work for you. This tutorial will not tell you how to configure anything else in the router, I assume you have a minimal knowledge in RouterOS, and the ability to search online for solutions if needed.
Settings of Mikrotik:
Model - RB2011UiAS-RM (should work with any model capable of running RouterOS)
RouterOS version - 6.18
Ether1 - gateway to internet, gets public IP from ISP via DHCP
Ether2 - your local network, also the place where your IPTV is (set top box or VLC or whatever)First, check if your router has the multicast package installed. You can do this by navigating to Routing in RouterOS menu (either via Webfig or winbox). If you have it already, you should see a submenu called "IGMP Proxy". If you don't have it, you need to download it from mikrotik's website and install it on your router. Be sure to get the correct one for your platform and RouterOS version. The easiest way to install a package is to login to your router with winbox, and drag&drop the package file to the "Files" root folder. After rebooting the router, the package installs automatically.
Click on IGMP Proxy. Then click the "Add New" button:
-Enabled: yes
-Interface: Ether1 (the gateway to internet)
-Treshold: 1
-Alternative subnets: 0.0.0.0/0
-Upstream: yesClick apply, then OK.
Click "Add New" again.
-Enabled: yes
-Interface: Ether2 (your LAN with the IPTV)
-Treshold: 1
-No alternative subnets
-Upstream: noClick apply, then OK.
Click "Settings".
-Quick Leave: yes
-leave everything else as isClick apply, then OK.
Proxy configuration is done. Now we need to check firewall rules to allow IPTV's traffic. I assume you have default firewall configuration, same as on my router (you can see the default firewall config here: http://wiki.mikrotik.com/wiki/Manual
e ... igurations, Firewall, NAT and MAC server section). We are going to extend this.Navigate to IP->Firewall menu. Add new filter rule.
-Chain: input
-Protocol: udp
-action: acceptApply and OK.
Add new filter rule.
-Chain: forward
-Protocol: udp
-action: acceptApply and OK.
Add new filter rule.
-Chain: input
-Protocol: igmp
-action: acceptApply and OK.
This is it. If everything else in your network is configured properly, your IPTV should work now. Any questions, just ask, I try to answer them.
-
Első körben a Wireless Interface-en a "Wireless" oldal jobb alsó részen bekapcsolod az "Advanced Mode"-t.
Itt "Frequency Mode : Regulatiry-Domain", majd alatta "Country : Hungary". Így a kishazánkban megengedett max teljesítménnyel fog csak sugározni a kütyüd. Ezt le is tudod ellenőrizni a "Current Ty Power" fülön.
Ha ez is sok lenne, akkor "Tx Power" fül, "Tx Power Mode" ahol két dolgot tehetsz:
"All Rates Fixed": ilyenkor egy értéket megadsz, ami minde esetben igaz.
vagy
"Manual" : itt viszont minden lehetséges átvitelhez megadsz egy értéket. -
-
Nem szívesen ugatok bele ilyen témába, de a MikroTik routerek nem igazán otthoni Soho cuccok.
Az egy dolog, hogy a cég elkezdett gyártani otthoni hálózatokhoz tervezett és gyártott készülékeket, de ez csak kinézetükben és teljesítményükben ilyenek. A program, pontosabban a rajtuk futó RouterOS ugyanaz, mint minden más termékükben. És ez bizony programozós, tanulós és hozzáértős fajta. Nem egy csilli-villi kinézetű, easy-to-use felület. Pontosan erre vannak az MTCxxx tanfolyamok. Ja, igen! Ezek a tanfolyamok pénzbe kerülnek. De jó magyar szokás szerint, mi semmiért sem szeretünk/akarunk fizetni. Ingyen, vagy annál ólcsóbban kell minden :-))
Persze meg lehet tanulni autodidakta módon is, csak hát az "rengeted" idő.
Részemről olcsóbbnak láttam kifizetni a tanfolyamot, mint eldélutánozgatni, eléjszakázgatni a szabad időmet ezzel (A párommal, családommal közben ki foglalkozik?)
Bocs, ha valakinek a lelkébe gázoltam! -
Hi!
Kihajlok ezen a Ip/Firewall/Filter részen
Már azt hittem sikerült megfejtenem a "limit" működését, de most vhogy csak nem úgy működik, ahogyan én szeretném.
A következőket adtam meg:/ip firewall filter
add action=jump chain=input comment="ICMP feldpolgozas" disabled=yes \
jump-target=icmp-chain protocol=icmpEz a legelső szabály, majd ezt követi jónéhány más szabály, de nem erre vonatkozóa.
Majd a végén a 3db Ping-re vonatkozó szabály.add action=drop chain=icmp-chain comment="Ping-Block Part1" disabled=yes \
protocol=icmp src-address-list=ping_blacklist
add chain=icmp-chain comment="Ping-Block Part2" disabled=yes icmp-options=0 \
limit=10,10 protocol=icmp
add action=add-src-to-address-list address-list=ping_blacklist \
address-list-timeout=5m chain=icmp-chain comment="Ping-Block Part3" \
disabled=yes protocol=icmpA célom az lenne, hogy korlátozzam az egységnyi idő alatt lehetségek ping-ek számát. Jelen beállításban Rate: 10/sec
Burst: 10
Jelenleg az első ping után bekerülök a tiltó listába (ping_blacklist). Állítottam a Rate értékét már 100/sec-re, 1000/sec-re, de ugyan az :-(
Valamit nagyon elkoncentrálok. -
Hali Bacus!
A Tűzfal szabályok kiértékelésének menetét nagyjából ismerem/ismertem. Számomra a "gondot" a "Dst-Limit" működése okozta. Mivel választ nem kaptam a működésére, elkezdtem a dologgal játszani. Jelenleg (idő hiányában) ott tartok, hogy a "Limit" már játszogattam egy kicsit. Amit én félreértettem mind a "Limit" és mind a "Dst-Limit" kapcsán az a konkrét működése. Ugyanis egy 20/1min beállítás esetében, én azt hittem, hogy ez azt jelenti, hogy 20db esemény fér bele percenként, és utána jön a következő szabály. Valójában ez egy sebesség érték. Azaz 20db/perc sebességet figyeli :-)) Sajnos a "Burst" érték kezelését még mindig nem sikerült megfejtenem :-((
Amit hiányolok a három soros tűzfal-szabályban, hogy csak az első sorban definiálja a TCP protokoll mellett a 21-es port számot (bár végül is így is jó lehet):add chain=input protocol=tcp dst-port=21 src-address-list=ftp_blacklist action=drop \
comment="drop ftp brute forcers"
add chain=output action=accept protocol=tcp content="530 Login incorrect" dst-limit=1/1m,9,dst-address/1m
add chain=output action=add-dst-to-address-list protocol=tcp content="530 Login incorrect" \
address-list=ftp_blacklist address-list-timeout=3hAnnyit mindenesetre már csiszoltam a dolgon, hogy én első körben ellenőrzöm a protokollt (TCP) és a hozzá tartozó portot (21), és ha ez teljesül akkor egy külön "Chain" használok a további feldolgozásra (action=jump). Számomra könnyebben érthető és átlátható. Egyébként a te általad leírt több lépcsős feldolgozás sem rossz ötlet :-)
-
Nincs engedélyezve se SSH se FTP.
Problem? Solved.1. Köszi a feltételezés :-)
De mint azt írtam is - bár nem pontosan:
"De a másodikat vagy nem értem, vagy nem működik - legalábbis nem úgy, ahogyan én gondolom:
add chain=output action=accept protocol=tcp content="530 Login incorrect" dst-limit=1/1m,9,dst-address/1m
Ha jól sejtem, ez 10 sikertelen belépés után bekorlátoz 1 percre. Hát én kipróbáltam 20 sikertelen próbát is 1 percen belül, de a 21-ikre simán beengedett :-)"
Ehhez annyi kiegészítés jár, hogy az első feltételt kikapcsoltam (ezt nem ítam az előbb). Tehát beenged, nemhogy 10 sikerertelen bejelentkezés, de 20 után is. Azaz engedélyezve van az FTP.2. Az SSH-val még nem is foglalkoztam, gondoltam egyszerre csak 1 lépést teszek meg :-)
-
Valaki próbáltam már ezt a "Brute force login prevention" módszert?
http://wiki.mikrotik.com/wiki/Bruteforce_login_prevention
/ip firewall filter
add chain=input protocol=tcp dst-port=21 src-address-list=ftp_blacklist action=drop \
comment="drop ftp brute forcers"
add chain=output action=accept protocol=tcp content="530 Login incorrect" dst-limit=1/1m,9,dst-address/1m
add chain=output action=add-dst-to-address-list protocol=tcp content="530 Login incorrect" \
address-list=ftp_blacklist address-list-timeout=3hNekem már az első sokertelen/hibás próbálkozásnál megcsinálja a tiltólistát, és onnantól kezdve nincs belépes :-(
Az első lépést még értem is:
add chain=input protocol=tcp dst-port=21 src-address-list=ftp_blacklist action=drop \
comment="drop ftp brute forcers"De a másodikat vagy nem értem, vagy nem működik - legalábbis nem úgy, ahogyan én gondolom:
add chain=output action=accept protocol=tcp content="530 Login incorrect" dst-limit=1/1m,9,dst-address/1m
Ha jól sejtem, ez 10 sikertelen belépés után bekorlátoz 1 percre. Hát én kipróbáltam 20 sikertelen próbát is 1 percen belül, de a 21-ikre simán beengedett :-)És az utolsó:
add chain=output action=add-dst-to-address-list protocol=tcp content="530 Login incorrect" \
address-list=ftp_blacklist address-list-timeout=3h
A legelső sikertelen próba után betesz az "ftp_blacklist"-be :-(Valamit nagyon benézek vagy nem értek :-(
-
Ha csak tárhelyet támogat az USB-n, akkor miért van a Supported Hardware listában USB ethernet cucc?
http://wiki.mikrotik.com/wiki/Supported_Hardware
És hát USB-3G modemet már én magam is használtam/élesztettem MikroTik-en.Ahogyan elnézem, nem egy embernek sikerült is ezt a funkciót életre kelteni :-)
http://forum.mikrotik.com/viewtopic.php?f=2&t=73502Kis nyomozás után kiderült, hogy az általam próbált átalakítóban Asix AX88179 chipset van, ami még nem működik jel RouterOS sorozatban :-(
Viszont a régebbi Asix AX88172 chipset működőképes :-) -
Valakinek valami tapasztalata van már USB-LAN átalakító és Miktorik RouterBoard/RouterOS között.
Értem ezalatt: bedugok egy ilyen kütyüt az RB USB portjáta, majd felveszem mint Ethernet Interface-t.
Én egy ilyen kütyüt http://www.delock.de/produkte/F_671_USB ... kmale.html
próbaképpen rácsatlakoztattam egy Rb951g-2hnd cuccra, ami a System/Resources/USB részben gyönyörűen fel is ismerte :-)
Na de hogyan tovább?
És igen! Van olyan eset, amikor jól jöhet +1 ethernet port. Nem akarok +1 switch-et még használni, cipelni, helyet és konnektor foglalni vele stb-stb. -
Az eszközök/gépek amiket szinkronizálni kellene NTP/SNTP alapon mennek (köztük Windows-os gépek is :-).
Viszont az, hogy nem Interneten keresztül kéne az időszinkront megoldani, azt nem tartom különleges dolognak. Számos helyen (főleg ipari, gyártás-technoloógiai stb környezetben) nem elfogadott (egyszerűen nem megbízható forrás) az Interneten keresztüli szinkronizálás (talán másodlagos forrásként elfogadható, bár erre nem merném a nyakamat tenni). -
Azt látom, hogy van GPS csomag a MOS-ben. Gondoltam ha van ilyen, akkor támogat is vmilyen GPS eszközt, mondjuk USB-n keresztül. És hogy mire is kellene: Időszinkronizáláshoz. Ugyanis lehet kapni GPS alapú időszinkron cuccokat (GPS Time Server, NTP), de x100ezres kategória, mivel 10 a minusz sokadikon pontosak. De nekem az mp pontosság is bőven elég!
Mielőtt még megkérdeznéd: nincs vagy nem lehet/szabad az interneten keresztül szinkronizálni. -
Úgy látom, hogy te "mangle"-ban csak "mark-packet"-et használod. Kölünböző leírásokban, videókban a "mark-packet" mellet a "mark-connection"-t is használják. Van ennek jelentősége? Őszintén szólva még nem igazán vágom a kettő közötti eltérést :-)
Másik. Úgy nézem, te minden QoS-hez (1,2,7,8) csinálsz In és Out verziót is, mégpedik úgy, hogy egyszer a bejövő forgalomnál nézed "src-port"-ot, majd a kimenő forgalomnál a "dst-port"-ot. Kérdés: amikor pl böngészek, a kifelé menő forgalom "dst-port"-ja tcp:80, de a visszairányú forgalomnál már nem "src-port" tcp:80 lesz, nem igaz?
Bocsi, ha nagy botorságot írtam :-) -
Bocsi, de én (mi) csak két (privát) alhálózat között szeretné(n)k átjárást létrehozni.
Gondoltam(uk) a Mikrotik-ben is ez max 2-3 sor route bejegyzés.
Erre belinkeltél egy több száz oldalas leírást (ami nem baj, csak arcul csapott :-))). Erre írtam az, hogy bonyolult, és inkább választunk más eszközt, pl Tomato vagy Dd-Wrt alapon. Ezeken megoldani egy ilyet nem egy nagy varázslat. -
Hi All!
Egy Draytek Vigor 292x routert szeretnék kibővíteni egy Miktorik-es eszközzel.
A cél nyerni még néhány Gigabit ethernet portot, és 5GHz-s wifit.
Mivel a Draytek-en külön subnet (192.168.11.0/24 és 192.168.12.0/24) és külön VLAN (VID11 és VID12) is az ethernet (LAN) és a Wifi, ezt meg kéne tartani a Mikrotik-en is. Az elképzelés szerint Draytek-en kijelölök egy LAN portot amit berakok mindkét VLAN-ba Tagged-ként, és ezen keresztül összekötöm a Mikrotik-el. Ott ez az (uplink) port szintén mindkét Tagged VLAN tagja, amit belül "szétszedek" az ethernet (LAN) portok részére (VID11) és a Wifi (VID12) felé.
Milyen ezközzel oldható ez meg?
"
"
tp,Ftps,Https" dst-address=192.168.81.100 \
e ... igurations, Firewall, NAT and MAC server section). We are going to extend this.
Új hozzászólás Aktív témák
ekkold- Formula-1
- Kecskemét és környéke adok-veszek-beszélgetek
- Milyen billentyűzetet vegyek?
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- Torrent meghívó kunyeráló
- Kis méret, nagy változás a Motorolánál
- Félszáz terabájtos HDD-k előtt nyitotta ki az ajtót a Seagate
- Sütés, főzés és konyhai praktikák
- exHWSW - Értünk mindenhez IS
- További aktív témák...
- Új és régi konzolok Okosítása és Szoftveres szintű javítása - MÁR 12.52 FW-s PS4-ek IS !
- Samsung Galaxy S10 128GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9700X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- iPhone 13 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS4065, 100% Akkumulátor
- Huawei Watch 5 Titanium 46mm
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi