- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- Magga: PLEX: multimédia az egész lakásban
- sziku69: Fűzzük össze a szavakat :)
- sellerbuyer: Te tudod, mi mennyit fogyaszt az otthonodban?
- GoodSpeed: iPadOS 26 A Liquid Glass varázsa
- Doky586: Adattár lemez előkészítése távlati Windows telepítéshez
- sellerbuyer: Milyen laptopot vegyek? Segítek: semmilyet!
- eBay-es kütyük kis pénzért
- Brogyi: CTEK akkumulátor töltő és másolatai
-
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
-
Lehet, hogy nem tetszik a DrayTek TrueDmz megoldása, de működik. Nekem volt is Draytek Vigor routerem, használtam is (2910, 2110, 2130, 2912, 2920, 2925), és bizony tudja ami le van írva. Azt, hogy hogyan csinálja nem tudom (nem is törtem magam, hogy megtudjam). A 21xx sorozat az elég home kategória, de a 29xx sorozat már "fasza" (nekem). Persze ez mindenkinél mást jelent. Egy tény, hogy stabilan végezték, és végzik mai napig a dolgukat.
Az árain persze el lehet dillemázni. Egy tény: a max uptime az a két áramszünet közötti időszak :-)Ui: a tápegység ezeknél is gyenge pont. 5-6 év után lehet őket cserélni.
-
-
Hát igen! Ha egy Ethernet interfész egy Bridge-hez tartozik, akkor úgy tudom, hogy a Bridge-hez kell konfigurálni az IP címet. Én legalábbis, így csinálom évek óta. De javítsatok ki, ha tévedek!
És természetesen ha még DHCP szervert használunk, akkor tersmészetesen azt is a Bridge-re konfiguráljuk. DHCP Server csak érvényes IP címmel rendelkező interfészen lehet!!! -
#3017
Zwodkassy
senior tag
nyilasmisi
#3015
válasz
nyilasmisi
#3015
üzenetére
"Ezzel mit kezdjek?"
Itt találsz megoldást arra, hogyan működjön a Windows és a RouterOS IPv6 szépen. Azaz kapjál DNS címeket. -
#3007
Zwodkassy
senior tag
nyilasmisi
#3006
válasz
nyilasmisi
#3006
üzenetére
IPv6 / Addresses / +
Eredmény : 2a01:36d:3001:513e::81/64
-
-
Azt látom, hogy nálam Digi FTTH területen, bridge üzemmódba állított ONT után a saját MikroTik routerem a Digi honlapján megfelelő/hasonló IPv6 címeket vesz fel.
Digi honlapján: IPv6 tartományok
kliens - 2a01:36c::/32
delegated - 2a01:36d::/32Nálam a MikroTik routeren:
pppoe-out (Wan) interészen : 2a01:36c:3001:513e::xy/64
Lan oldali bridge interfészen : 2a01:36d:3001:513e::xy/64
és természetesen minden iterfészen van Local cím is: fe80::xxxx:xxxx:xxxx:xxxx/64 -
"Gépen (win7, centos7) úgy tűnik megy rendesen. Nekem csak androiddal nem jó. (A tableten nexus 7 2013, már 6os droid van, ott is nagy a lag, ha bekapcsolom az ipv6-t)"
Talán ez lehet a megoldás?
Bosszantó IPv6-hiba keseríti meg a telekomosok életét
http://www.hwsw.hu/hirek/56684/telekom-ipv6-ip-android-wifi.html
-
#2977
Zwodkassy
senior tag
Bile Demon
#2963
válasz
Bile Demon
#2963
üzenetére
Ha "mindent" akarsz látni, akkor "ipconfig -all" vagy "ipconfig /all"
-
válasz
kammler
#2974
üzenetére
3.sor: DSU - Dynamic, Static, Unreachable
4.sor: DAC - Dynamic, Active, Connected
Ráadásul a 3-on a Distance=1, a 4-en pedig Distance=0. Ha két azonos feltételeknek megfelelő route bejegyzésed van, mindig a kisebb értékű a nyerő (kisebb költség, rövidebb útvonal). Ilyenkor a másik kékre vált. -
"Működik egyáltalán valakinél hibátlanul az ipv6?"
Az IPv6 teszt szépen lefut a Windows7 gépemen, de cask akkor, ha IPv4 is engedélyezve van :-)))
Ugyanis van Local és Global IPv6 címe a Win7-nek, és van Gateway is (ez a MikroTik LAN oldali Bridge interface címe), de DNS címek nincsenek :-)) -
#2971
Zwodkassy
senior tag
nyilasmisi
#2957
válasz
nyilasmisi
#2957
üzenetére
Úgy néz ki, csiszolgatják az IPv6-ot a srácok:
RouterOD 6.37.4
*) winbox - show errors on IPv6 addresses;RouterOD 6.38.0
*) webfig - show ipv6 addresses correctly;
*) winbox - show proper ipv6 connection timeout;
*) ipv6 - added "no-dad" setting to ipv6 addresses;
*) ipv6 - fixed "accept-router-advertisements" behaviour;
*) ipv6 - moved empty IPv6 pool error message to error topic;RouterOD 6.38.1
*) winbox - show dynamic IPv6 pools properly;
*) winbox - show errors on IPv6 addresses; -
#2962
Zwodkassy
senior tag
Bile Demon
#2960
válasz
Bile Demon
#2960
üzenetére
Ha a routerből tudsz pingelni IPv6-os címeket (pl Google : •2001:4860:4860::8888 és •2001:4860:4860::8844), akkor ez pipa.
Ezután nézd meg a Windows IP aktuális IPv6 konfigját: IPv6 cím, Gateway.
Ha nincs Gateway, akkor nem fog menni a ping sem... Mint az közismert, Mr Teufel :-) -
#2959
Zwodkassy
senior tag
nyilasmisi
#2957
válasz
nyilasmisi
#2957
üzenetére
"Nekem valamiért ilyen hülye ip-t ad aminek ráadásul hiányzik az eleje. Láttál már ilyet?:"
Melyikre gondolsz? Az első sorban lévő "Disabled"-re?
-
A "gond" viszont az, hogy a MikroTik ROS a DNS szerver címeket hírdetés formájában teszi közzé. Azaz nem DHCPv6 szerveren keresztül. Viszont a WIndows DHCPv6-on keresztül várná a DNS címeket is.
IPv6 címed lesz, de DNS nem. Ezeket manuális kell beírnod, ha csakis és kizárólag IPv6-on keresztül akarsz kommunikálni az internet felé.
Amennyiben IPv4 + IPv6 is megy a Windows-od alatt, semi dolgod, szépen fog működni minden (legalább is ezt fogod látni:-) -
#2955
Zwodkassy
senior tag
Bile Demon
#2953
válasz
Bile Demon
#2953
üzenetére
"Amiről sejtem, hogy gond lehet: a LAN interfésznek nem állítottam be IPv6 címet, csak egy link local címe van. (Jó az úgy, vagy mit állítsak be?)"
Hát igen. Ahogy az IPv4 esetében, úgy az IPv6-nál is, a DHCP szervernek rendelkeznie kell (!) érvényes IP címmel. Ezt kihagytam a hozzászólásomból.
Én a LAN oldlai Bridge interfészemnek a következőt adtam meg:
- Address : ::81/64 - azért 81, mert az IPv4 címének a vége is ez :-)
- From Pool : a Wan oldali DhcpClient által létrehozott
- Interface : értelemszerű
- EUI64 (*) : én nem használom
- Advertise : pipaEUI64 (*) : IPv6 cím generálása az adott interface MAC Address felhasználásával
-
válasz
bambano
#2948
üzenetére
"mert az okosok úgy gondolták, hogy a helyi hálózaton úgy osztanak ipv6-os ip címet, hogy az ethernet kártya mac címéből, ami 48 bit, fix módszerrel csinálnak 64 bitet, az lesz a v6-os cím egyik fele. a másik felét kapod a szolgáltatótól"
De ez csak SLAAC (StateLess Address AutoConfiguration) esetében igaz, ha jól tudom?
-
#2947
Zwodkassy
senior tag
Bile Demon
#2946
válasz
Bile Demon
#2946
üzenetére
"És mi lett a megoldás?"
Egy Hap Ac Lite-ból kimásoltam a Default Config-ot :-)
"IPv6"
Nekem Digi van, cask erről tudok nyilatkozni:
- Wan iterfész: ezen DhcpClientv6, Address és Prefix pipa (igénylés), megadtam egy Pool-t, és a PoolPrefixLength=64 (a Diginél 64 bit). UsePeerDns és AddDefault Route pipa.
- Lan oldal: itt a Bridge interfészre definiáltam egy Dhcp-Server-v6-t, ahol is a előzőleg megadott IpV6Pool-t használom, adom meg. A gond akkor van, ha ez nem jön neked létre. Azaz nem kapsz ilyet a Telekom-tól. Bár ha jól látom, te a Cisco Epc3925 után vagy kötve. Szerintem mivel ő kapja meg "kívülről" a "public" IPv6 címet és prefixet, így te már nem lehet tovább "adni". Még nekem sem minden világos az IPv6 technikában.
Ugyanis nekem van több MikroTik-em otthol? switch és AP. Ezek sem kapnak már a "fő" MikroTik router után prefix-et (vagy címet ?, most nem is tudom :-).
És valami olyat is olvasgattam a neten, hogy /64-es prefix 1db subnet. /63-as 2db subnet, /62-es 4db subnet lehetséges. Még nem egészen vágom miért :-( -
#2945
Zwodkassy
senior tag
Bile Demon
#2936
válasz
Bile Demon
#2936
üzenetére
Sajnos ezzel detto ugyanígy jártam én is :-(
Annyi eltéréssel, hogy én 6.37.3-at tettem rá vissza, de azzal is ugyanolyan fos volt :-( -
Küzdök a Digi féle IPv6 beállításokkal. A kimeno interace-en kapok címet, ezzel nincs is gond, csak a belső hálózat felé van némi problem. Két alhálózatom van, ami két külön bridge-hez csatlakozik. A gondom az, hogy egyszerre csak az egyik bridge interfészen lehet IPv6 címem, így csak azon működik a Dhcp.Server is :-(
/ipv6 dhcp-client
add add-default-route=yes interface=pppoe-out-digi pool-name=Ipv6-pool-digi \
request=address,prefix/ipv6 address
add from-pool=Ipv6-pool-digi interface=Br-Lan82-Guest
add from-pool=Ipv6-pool-digi interface=Br-Lan81/ipv6 dhcp-server
add address-pool=Ipv6-pool-digi interface=Br-Lan81 lease-time=1d name=\
Dhcp-v6-Srv-Lan81
add address-pool=Ipv6-pool-digi interface=Br-Lan82-Guest lease-time=1d name=\
Dhcp-v6-Srv-Lan82/ipv6 nd
set [ find default=yes ] advertise-dns=yes disabled=yes \
managed-address-configuration=yes
add advertise-dns=yes hop-limit=64 interface=Br-Lan82-Guest
add advertise-dns=yes hop-limit=64 interface=Br-Lan81
add interface=pppoe-out-digiA tűzfal részt be sem másolom, mert akár van, akár nincs, a helyzet ugyan az.
-
"Egy csatornán egyszerre egy pofázik, a manager ezt vezérli"
Hát ezt "CAPsMAN Forwarding" üzemmód esetében még el is tudom képzelni, de "Local Forwarding"-nál már nem.
Sajna az a tapasztalatom a "CAPsMAN Forwarding" üzemmel, hogy lassabb az átvitel, mint "Local Forwarding" esetében. Bár ez lehet csak olyan AP esetében igaz, aminek 100-as portja van. -
Közös csatornán nem zavarják egymást? A tesztekből nekem nem ez jött le. 3db aP CAPsMAN-nal vezérelve, plussz 3db kliens, 1xAP - 1xkliens párosításba. Elindítottam mindhárom gépen egy másolást.
- közös/azonos csatornán/frekin: 1-4 MB/s
- 1-7-13csatornákon: 8-11 MB/s.
Akkor ez most hogy is van? -
Roaming? Igen, ez mostanság egy nagy divat-követelmény :-) De otthoni környezetben hányan használnak Roaming-ot? De úgy tényleg, kritikus követelményeknek megfelelően? Mondjuk VoIP telefonálgatás az átlag otthonokban?
Egyébként én vettem a fáradságot, és rászántam az időt és az energiát anno a CAPsMAN tesztelgetésére. Viszonylag nagy irodatér, 3db AP, CAPsMAN-on keresztül hajtva. Külön csatornán/frekin (1-7-13) mindegyik. Laptopon PING elindít (Windows 7 + Intel Wifi), és sétálgat az irodában. Egy db nem maradt ki a váltások alatt. Persze mobil telefonnál (Android) már nem ilyen sima a váltás: ott kimarad 1-2 ping. Bár tudtommal az 5-ös Androidban is csak "Roamingocska" lehetőségé van implementálva.
Persze ez a közös csatorna/freki használata egy háztartásban sem feltétlenül veszélyes, főleg ha cask 1-2 kliens eszközt használunk, és ott is minimális az egyidejűség
Megjegyzés: ahhoz hogy közös csatornát/frekit használjunk, nem szükséges CAPsMAN. -
-
-
"Voda?
Nekem ha internet.vodafone.net-et állítom be akkor rendszerint natolt ip-t kapok. Ha standardnet.vodafone.net-et akkor kapok külsőt (és mindig mindenhol ugyanazt..
)"Mint azt az általam is írt IP címből (tartományból) is láthatod - 192.168.9.0/24 - ez belső hálózati cím, nem pedig a Voda tömörített címtartománya. Mint kiderült, ez a Vodafonos Zte K4607-Z eszköz modem + router egyben :-( Az eszköz menűjét mégignézve nem találtam benne sem
- Bridge
- Port Forward
- DMZ
lehetőségeket.
Sőt, még cask az APN beállításokra vonatkozó részt sem találtam :-(( -
Kinek van tapasztalata LTE Usb eszközökkel?
Kaptam/kaptunk a cégnél Vodafonos Zte K4607-Z eszközt.
Amikor bedugom egy Miki-s eszközbe, az fel is ismeri mint LTE eszközt/interfészt.
Ha teszek rá Dhcp-Client-t, akkor kapok is IP címet, és alapvetően működik is a dolog: megfelelő beállítások mellett lehet rajta keresztül pl: netezni. Ok.
A gondom mindösszesen annyi, hogy nem publikus címet kapok az eszköztől, hanem egy NAT-olt, belső címet: 192.168.9.0/24 :-(
Lehet ezen valahogyan változtatni? -
-
"Fő" router (első hálózat) <-> MikroTik <-> saját hálózat, saját számítógép(ek)
Az első hálózat mondjuk: 192.168.1.0/24
A saját hálózat: 192.168.201.0/24
Az első router NAT-ol a net felé, és static route szabályok vannak felvéve benne a Miki mögött lévő hálózathoz. Azaz gyönyörűen lehet netezni a Miki mögül.
Hogy miért ez a felállás? Gondolom így nem kell(ett) duplán NAT-olni. -
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.
)"
"
"
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
- Lenovo Thinkpad T490 Core i5 8365U 16GB RAM 256GB NVME SSD Magyar Bill Gar
- IPhone 16 Pro 128GB One 2027.07.11. Apple jótállás
- HIBÁTLAN iPhone 15 Pro 256GB Natural Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3507
- Eladó M1 MacBook Pro 13"-14"-16" Keresek
- HIBÁTLAN iPhone 15 Pro 256GB Blue Titanium -1 ÉV GARANCIA - Kártyafüggetlen, MS3506, 92% Akkumulátor
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- HIBÁTLAN iPhone 13 Mini 128GB Green -1 ÉV GARANCIA -Kártyafüggetlen, MS3305
- REFURBISHED és ÚJ - Lenovo ThinkPad Ultra Docking Station (40AJ)
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RX 9060XT 16GB GAMER PC termékbeszámítással
- LicencAruhaz.hu OLCSÓ, LEGÁLIS SZOFTVEREK AZONNAL - Windows - Office - Win Server - ÖRÖK GARANCIÁVAL
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest