- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Keretmentesít a Galaxy S25 FE
- Apple Watch Ultra - első nekifutás
- Honor 200 - kétszázért pont jó lenne
- Kiborult a Nothing Phone (3) pletykakosara
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- Magisk
- iPhone topik
- Android alkalmazások - szoftver kibeszélő topik
- Okosóra és okoskiegészítő topik
-
Mobilarena
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
-
#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. -
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
Hirdetés
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Sony MILC fényképezőgépcsalád
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Keretmentesít a Galaxy S25 FE
- Apple Watch Ultra - első nekifutás
- Melyik tápegységet vegyem?
- Debrecen és környéke adok-veszek-beszélgetek
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Fejhallgató erősítő és DAC topik
- Xbox Series X|S
- További aktív témák...
- Lenovo Legion 5 Pro Gamer Laptop 2év garanciával (i7 13700HX, RTX 4060)
- IPhone 11 Pro max 64GB megkímélt új emelt kapacitású akku!
- Apple Pencil Pro bontatlan 1 év Apple jótállás
- Nitro ANV15-51 15.6" FHD IPS i5-13420H RTX 4060 32GB 512GB NVMe magyar vbill gar
- Apple watch Series 9 41mm cellular hibátlan 2026.02. 24. Apple jótállás
- AKCIÓ! Apple MacBook Pro 13 2022 M2 8GB 256GB SSD garanciával hibátlan működéssel
- Bomba ár! Dell Latitude 3590 - i5-8GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Garancia!
- Akció! Újra Gamer EGEREK! Glorious , Endgamer XM1R , Nibio
- Akciós Windows 10 pro + Office 2019 professional plus csomag AZONNALI SZÁLLÍTÁS
- Samsung Flip 2.0 PRO 65" WM65R + Connectivity tray + Gurulós állvány
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest