- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Poco X6 Pro - ötös alá
- iPhone topik
- Motorola Edge 40 - jó bőr
- Magyarországon is kapható a Moto G85 5G
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Milyen okostelefont vegyek?
- Samsung Galaxy A54 - türelemjáték
- Ilyen lesz a Fairphone 6
- 45 wattos vezeték nélküli töltés jön az új iPhone-ba
-
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
-
DonJoee
tag
válasz
Reggie0
#18684
üzenetére
Köszi.
Még nem igazán ástam bele magam a VLAN-okba.
Amit már most látok, hogy a routeren azt a portot, amit erre akarok használni, azt ki kell vegyem a brigde-ből, továbbá a Switch-menüben kellene beállítani a portot, hogy ő mostantól mondjuk a VLAN10 része. Ezt a beállítást a többi switchen is meg kell tennem.
Most jelenleg 2 kérdés merült fel bennem (mert nem nagyon értek még hozzá, egyébként 17 lenne):
1. Ahány leírást csak olvastam, láttam, a VLAN-okhoz egy bizonyos ponton IP-tartományt rendelnek a routerben. De itt most nem a router fogja az IP-t osztani, hanem a mesh master AP-ja. Vagy ekkor is be kell állítani a routerben, hogy milyen tartományban fog a mesh dolgozni?
2. A CRS305-ök (amik csak optikai switchek) maradhatnak úgy, ahogy vannak? Nyilván, mert azokon az összes forgalom átmegy, nincs mód csak VLAN-portot beállítani rajtuk (illetve mód van, csak értelme nincs).
Na, mégis csak 3 kérdés lett a végére:
3. Mivel a 305-ökön minden adat átsuhan, ők a VLAN tag-ek alapján tudnának jól dolgozni. Ha a routeren a switch részben állítom be a VLAN-t, akkor mi végzi a tag-elést? Vagy az megy automatikusan?Hmm, kezdek belebonyolódni. Lehet, hogy itt az ideje, hogy valakinek megfogjam a sörét........
(Ekkold: nem Mikrotik AP-k vannak. Egyrészt mesht akartam, másrészt AX-támogatást is (harmadrészt "nemsokpézé").
-
DonJoee
tag
Sziasztok!
Hosszú szoktam lenni, előre is elnézést...
Rég voltam már itt, azóta (a segítségeteket is igénybe véve) összeraktam egy kis hálózatot a cégnél Mikrotik eszközökkel, 10 Gigás optikai gerinccel, háromszorosan bebiztosított internet eléréssel (optika, réz(koax), 4G mobil, failover módban).
Szépen megy minden, de az RB4011 wifis része nem képes mindenhol megfelelő lefedettséget biztosítani. Voltak mindenféle extenderes bohóckodások, de inkább véget vetnék ennek. Ezért egy mesh rendszerben gondolkodom, mégpedig úgy, hogy a régi wifi (a 4011 maga) megmaradna és megfelelően rejtve/jelszavazva mindent elérne (a LAN-t is), de az új rendszernek a lehető legkevesebb rálátást szeretnék biztosítani a belső hálózatra ( = semmit), csak internet elérés legyen.
Várj, most jön a csavar: mindezt úgy, hogy ne kelljen külön vezetékelgetnem, hanem a meglevő infrastruktúrát használják a mesh AP-k és a master AP. (Ethernet backhault szeretnék, mert az stabilabb illetve a mesh eszközök csak 2 rádiósak (2.4 és 5 GHz), ne kelljen sávszélt lekötni a wifiből AP-AP kommunikációra.)Hagyományosan ez úgy működne, hogy a mastert beállítom (WAN, LAN, wifi konfig stb.), utána vezetékkel a master egyik LAN-portját összekötöm az következő AP WAN portjával. Az "öntudatra ébred" és letölti a beállításokat a masterről: ezzel kész a 2 egységből álló mesh. Utána az újonnan belépett AP LAN portjához csatlakoztatom a következő AP WAN portját, letölt, üzemel, kész a 3 AP-ból álló mesh ést így tovább.
A mi esetünkben ugye a "kábelezés" megvan, semmi szükség csak a wifi AP-knak külön kábelezgetni.Szóval: odáig jutottam a gondolatmenetben, hogy a master AP kap a 4011-től failoveres internet elérést (mondjuk a eth9-ről), mint mindenki más, csak ő némi tűzfal szabályzásnak köszönhetően nem fog tudni rálátni a LAN-ra. Ezt még tán én is megoldom.
Viszont a master AP egyik LAN-portját visszavezetném a 4011-be, mondjuk az eth10-be, hogy a többi AP a már meglevő switcheken keresztül kapcsolódjon. (először persze mindet közvetlenül "szagoltatnám meg" a master AP-val, hogy tudja: ethernet backhaul lesz, nem wifis)Ezt az eth10-et kellene úgy leszeparálni a hálózat többi részéről, hogy semmi köze se legyen a többihez, mégis keresztül vándoroljon a master AP visszavezetett jele a már meglevő switcheken.
A meglevő LAN 10.10.x.x tartományban működik, a master mesh wifi AP 192.168.0.x-et osztana a saját DHCP-jén. Ezeket nem kellene összekeverni...A megoldás valószínűleg VLAN lesz, és lehet, hogy az RB4011 switchének hardveres megoldását választanám, ha már van. Bár úgy gondolom, hogy a 4011-ben levő CPU elviselné még a szoftveres VLAN terhét is.
A többi eszköz beállításaiban viszont végképp nem vagyok biztos. Mondjuk egy CSS610-nek vagy CSS326-nak még valahogy meg lehet mondani, hogy pl. a 8-as portján VLAN van, de mit mondok a két CRS305-nek, ami az optikai gerincet viszi és azokban ömlesztve megy minden? Lehet, hogy őket nem is kell piszkálni?
Mellékelnék egy képet a jelenlegi hálózatról. Kék színű vonalakkal és feliratokkal jelöltem a "tervezett" részeket.
Nem baj, ha nem csak ötletek szintjén, hanem "kifejtősen" is tudnátok segíteni.
Köszönöm!
-
DonJoee
tag
-
DonJoee
tag
válasz
Reggie0
#13570
üzenetére
Most ugyan a 4011 a fő mindenes router, de pár héten belül már "csak" az internet felé történő forgalmat irányítja, nem erre lesz dugva az összes switch, hanem egy CRS305-re, ami 10 gigás optikai SFP+ modulokon keresztül megy a többi új switchez.
Talán így nem akkora gond ez a 4011. Mondjuk eddig még semekkora, mert nem tapasztaltam problémát vele. A wifi csak vendég wifi, le is korlátoztam 10/2 Mbit/s-re. Mondjuk lehet, hogy ezen emelek kicsit. -
DonJoee
tag
válasz
Reggie0
#13567
üzenetére
Ezzel a port flappinggal kicsit megijesztettél, de ahogy olvasom, leginkább akkor fordul elő, amikor az RB4011 SFP+ portba dugott RJ45-ös modullal találkozik 1 Gbit/s sebességen (t.i. melegszik szerencsétlen). Az auto negotiation kikapcsolásával "javítható", de így csak fix 1 Gbit/s sebesség lesz. Vagy nem lesz, ha mondjuk egy 100 Mbit/s interfészű nyomtató is csatlakozna a hálóra...
Ahogy olvastam, a rev.2-es RB4011-eket már tákolták valamelyest emiatt (ilyen van nekem is), továbbá optikai modullal ugye kevesebb az áramfelvétel és így a melegedés is, tehát port flapping nincs (még).
Egyébként sima üresjárati módban is úgy tud melegedni szegénykém, hogy komolyan elgondolkodtam egy 10cm x 20 cm-es öntapadós hővezető lap + ugyanekkora alapterületű és kb. 10 cm magas hűtőborda felapplikálásán. Mondjuk nem tudom, hogy egy ekkora vasdarab mennyire vágja agyon a WiFi-képességeket?
-
DonJoee
tag
Igen, megvan a "bűnös":
add action=drop chain=forward src-address-list=BlackListHa ezt kikapcsolom, akkor megy minden szépen.
Vajon mennyire fogja hatástalanítani a feketelistázást, ha kiegészítem mondjuk így?add action=drop chain=forward src-address-list=BlackList connection-nat-state=!dstnatMert ezzel a kiegészítéssel is megy minden. Ja, meg spórolnék egy tűzfal szabályt...
-
DonJoee
tag
Azt hiszem, ez hiányzott még:
/ip firewall add action=accept chain=forward connection-nat-state=dstnatMert most már van incoming data az irodai gépek megfelelő portján.
Érdekes, hogy ezt eddig nem igazán láttam megemlítve sehol. Mármint azokon a helyeken, ahol külön cikkeket és blogpostokat írtak a port forwardról Mikrotik eszközökön... -
DonJoee
tag
A Mikrotik 10.x.x.x-en van.
A szolgáltatói routerek 192.168.1.x, 192.168.2.x, 192.168.3.x, statikus IP-k, DMZ-zve, kívülről publikus IP-t kapnak. Molyolok még, hátha nem vettem észre valamit.A másik problémám (és ahogy nézem, a fél internet ezzel küzd), hogy PPTP esetén kapom a Mikrotiken beállított tartományból az IP-t, de 255.255.255.255 maszkkal és magamon kívül senki mást nem látok a helyi hálón... Windows 7, 10, mindnél ugyanez a gond. Skori szerint jártam el.
Egyesek szerint a Windows önmaga maszkolja le így a kapott IP-t, de akkor mi értelme van az egésznek? -
DonJoee
tag
Bekapcsoltam az egyik NAT-szabályra a logot és ezt hozza:
dstnat: in:ether1-WAN1 out:(unknown 0), src-mac aa:bb:cc:dd:ee:ff, proto TCP (SYN), xx.yy.ww.zz:52200->192.168.x.y:xxxx5, len 52A 192.168-as cím a Mikrotik statikus IP-címe, amit a Telekomos routerben állítottam be és azt DMZ-zem.
Szerk: Nem tudom, az "out"-nak biztos "unknown"-nak kell lennie?
-
-
DonJoee
tag
Most azon gondolkodom, hogy van külön interface-list-em a WAN1, WAN2 és WAN3 portoknak. De csináltam egy közös listát is nekik WAN -néven és így hivatkozok rájuk a port forwarding részben is... Lehet, hogy ezt nem szereti? Meg kell csinálnom az összes szabályt mindhárom WAN-ra külön-külön?
-
DonJoee
tag
Köszi!
Az alap "Skori"-dolgokból építkeztem, meg a vendég wifit leválasztottam a LAN-ról.
De nézd meg te is, kérlek. Azt hiszem, sikerült "open world"-kompatibilissé tennem az exportot (nincs benne érzékeny adat):# apr/08/2021 13:12:00 by RouterOS 6.47.9# model = RB4011iGS+5HacQ2HnD/ip firewall address-listadd address=x.y.z.2-x.y.z.254 list=Guest_WiFiadd address=0.0.0.0/8 list=BlackListadd address=127.0.0.0/8 list=BlackListadd address=224.0.0.0/3 list=BlackListadd address=a.b.0.0/16 list=Localadd address=x.x.0.0/16 list=Localadd address=x.y.z.0/24 list=Localadd address=213.108.134.181 list=BlackListadd address=213.108.134.182 list=BlackListadd address=213.108.134.183 list=BlackList/ip firewall filteradd action=drop chain=input comment="Guest WiFi internet only" dst-address=\x.y.z.1 dst-port=21,22,23,80,443,1723,2000,8291 protocol=tcp \src-address-list=Guest_WiFiadd action=drop chain=forward dst-address-list=Local src-address-list=\Guest_WiFiadd action=drop chain=input comment="DNS from LAN only" dst-address-list=\!Local dst-port=53 protocol=udpadd action=fasttrack-connection chain=forward comment="FastTrack enable" \connection-state=established,related dst-address-list=Localadd action=accept chain=forward connection-state=established,relatedadd action=drop chain=input connection-state=invalidadd action=drop chain=forward connection-state=invalidadd action=accept chain=input connection-state=establishedadd action=accept chain=input in-interface-list=!WAN src-address-list=Localadd action=add-src-to-address-list address-list=BlackList \address-list-timeout=1d10m chain=input comment=\"Blacklisting of port scanners" protocol=tcp psd=21,3s,3,1 tcp-flags=""add action=add-src-to-address-list address-list=BlackList \address-list-timeout=6h chain=input dst-port=20-1023,8000,8080,8291 \protocol=tcp src-address-list=!Localadd action=add-src-to-address-list address-list=BlackList \address-list-timeout=6h chain=input dst-port=\20-122,124-499,501-1023,8000,8080,8291 log-prefix=UDP-block protocol=udp \src-address-list=!Localadd action=drop chain=input log-prefix=Input-BlackList src-address-list=\BlackListadd action=drop chain=forward src-address-list=BlackListadd action=add-src-to-address-list address-list=VPN_login \address-list-timeout=1m30s chain=input comment="VPN login protection" \connection-state=new dst-port=1723 protocol=tcp src-address-list=\!VPN_loggedadd action=add-src-to-address-list address-list=VPN_logged \address-list-timeout=59m chain=input connection-state=new dst-port=1723 \protocol=tcp src-address-list=!VPN_loggedadd action=add-src-to-address-list address-list=BlackList \address-list-timeout=5h59m chain=input connection-state=new dst-port=1723 \protocol=tcp src-address-list=!VPN_logged/ip firewall natadd action=masquerade chain=srcnat out-interface-list=WAN1add action=masquerade chain=srcnat out-interface-list=WAN2add action=masquerade chain=srcnat out-interface-list=WAN3add action=masquerade chain=srcnat comment="VPN internet access" disabled=yes \src-address=x.x.z.0/24add action=dst-nat chain=dstnat comment="New broadcast address for WOW" \
dst-port=abcde in-interface-list=WAN protocol=\udp to-addresses=x.x.w.254 to-ports=9add action=dst-nat comment="Port forwarding for clients" chain=dstnat \
dst-port=xxxx1 in-interface-list=WAN \protocol=tcp to-addresses=x.x.0.201 to-ports=yyyyyadd action=dst-nat chain=dstnat dst-port=xxxx2 in-interface-list=WAN \protocol=tcp to-addresses=x.x.0.202 to-ports=yyyyyadd action=dst-nat chain=dstnat dst-port=xxxx3 in-interface-list=WAN \protocol=tcp to-addresses=x.x.0.203 to-ports=yyyyy......... -
DonJoee
tag
Új "probléma" ütötte fel a fejét (illetve az enyémet)...
Nevezetesen egy egyszerű, mezei port forwarding akasztgatja belém a körmeit... (bár egy Mikrotik eszközön mi egyszerű és mezei? Talán a csomagolása...)
Szóval adott egy kis home-office tool-páros, amit szerény személyem kreált cégünk irodai dolgozóinak, mellyel a számítógépeiket otthonról tudják bekapcsolni, be/kikapcsolt státuszukat ellenőrizni, kikapcsolni (a normál "windowsos" módszer mellett). Az irodai LAN-ra és a gépeikre AnyDesk-kel csatlakoznak.A gépek indítása a szokásos 9-es UDP-porton keresztül megy magic-csomaggal (nyilván az internet felé ez másik port és átfordítom 9-re odabent).
Ez szépen működik is.
Az irodai gépeiken fut egy kis "szerver" progi (ööö, ez nagyképűen hangzott, de végül is az) és figyel mondjuk a 33000-es TCP porton, az otthoni gépeiken meg egy "távirányító", amivel a fent említett funkciókat tudják megvalósítani (egy v. több gép be/ki kapcsolása stb.).Az elhalálozott Merlin fw-s Asus RT-AC87u-n úgy volt, hogy minden gépnek az internet felől nézve volt egy saját portja, mondjuk telephely.sajatceg.hu:50001, 50002, 50003 stb., amiket a router forwardolt a nekik megfelelő LAN-os IP-címek 33000-es portjára.
Tudom, kicsit "pazarlónak" tűnik a módszer, meg ott a VPN meg satöbbi, de eddig ez működött. (Az AnyDesk meg saját VPN kapcsolatokat hoz létre, nem tudom, hogy ezeket belenyomni egy naaagy közös VPN-be sebességileg hogy nézne ki?)Csináltam én egy dst-nat -ot minden gépnek, de mintha csak "félig" menne a dolog.
/ip firewall nat add action=dst-nat chain=dstnat dst-port=50001 in-interface-list=WANprotocol=tcp to-addresses=192.168.10.10 to-ports=33000
(ez minden gépre, más-más dst-port-tal és to-addresses-el)A dolgozóknál levő "távirányító" érzékeli, hogy be van kapcsolva a gép (valami tehát megy kifelé a LAN-ból), de egyéb infó már nem jön vissza, továbbá kikapcsolni sem tudják a gépeket a távirányítóból, csak Windows-ból. Tulajdonképpen nagy gond nincs, csak idegesít, hogy valahol féllábú lett ez a forward.
A neten ahány infó, annyiféleképp magyarázza, hogy is kell ezt csinálni... És gondolom, annyiféleképpen rossz mind.Van jó forwarding-módszer a fenti feladatra?
-
DonJoee
tag
Tényleg: hogy lehet ezeket pontosan beállítani, hogy egymás felé nézzenek? Tegyük fel, hogy fel vannak szerelve a végleges helyükre, de egyiknél sem sikerült eltalálni 6-7 fokon belül a másik pozícióját... Ilyenkor ugye semmilyen jelszint nincs. Én a magam eszétől azt csinálnám, hogy mondjuk egy ilyen iránymérő telefonos appal megjegyeztetném az egyik antenna GPS-pozícióját, aztán a másik antennát a telefonnal együtt fordítanám, amíg irányba nem áll, aztán ugyanezt eljátszanám fordítva is. Utána meg már mehet a jelszint szerinti "jobbra-balra-állj-nem jó-vissza-stb"... Vagy rosszul gondolom? Azt hiszem, a közeljövőben lesz egy hasonló feladatom, csak nem 60 GHz-es antennával és nem 300 méterre hanem valami 5 GHz-essel, ami jobban terjed és 2 km-re, amit viszont már lehet, hogy nem látok szabad szemmel...
-
-
DonJoee
tag
válasz
Reggie0
#13415
üzenetére
Aha!
Lássuk, jól értem-e: szóval, ha mondjuk a "whatismyip.akamai.com" IP-címét, ami 91.83.14.187, beírom egy route Dst.address-mezőjébe és ehhez gateway-ként mondjuk a WAN2-őt adom meg, akkor minden alkalommal, amikor a fenti url-t akarom elérni, ezen a route-on (és így a WAN2-őn) keresztül megy ki a forgalom, mert az általánoshoz (0.0.0.0/0) képest "közelebb" van a cél, "jobb" errefelé route-olni... (gondolom egy alacsony distance-szel még jobban is rásegíthetek a dolgokra)
És ha csinálok 3 route-ot (egyet-egyet minden WAN-port számára, amiket gateway-ként adok meg) és sorban, mindig csak egyet kapcsolok be belőlük, akkor mindig csak azon keresztül megy ki a kérés az IP-cím-jólmegmondó szolgáltatás felé...
Aztán, ha végeztem, disablélom az összes ilyen spéci route-ot és kész is vagyok?Ja és mindig:
:if (([:len [/ip route find where comment="WAN1_chk" and !disabled]] > 0) do... -
DonJoee
tag
Sziasztok!
Egy egyszerű, 20 forintos kérdésem lenne...
Több ISP (és ezzel WAN-port) esetén szeretném megtudni mindegyiknek a publikus IP-címét scriptből, custom DDNS-updater számára.
A modemek teszik a saját dolgukat, ők végzik a PPPoE-kapcsolat felépítését és az eredményt (internetet) egy DMZ-zett statikus LAN-címen adják a MikroTik-nek. Szóval nincs bridge-mód a modemeken és ezzel együtt nincs publikus IP-cím sem az RB WAN-portjain.Több lehetséges módot ajánlgatnak a fórumokban és ezek működőképesek is EGYetlen WAN-port esetén, mert a default route-on keresztül megy ki a kérés (akár /IP Cloud, akár :resolve-os, akár külső "IP-cím megmondó" szolgáltatás esetén). De ha mondjuk a WAN2, WAN3 stb. címét szeretném megtudni, akkor is a default route-on megy ki a kérés, amit nálam még bonyolít egy load balancing is. Szóval hol a WAN1, hol a WAN2, hol pedig a WAN3 címét kapom meg akkor is, ha a WAN2-re vagyok kíváncsi.
A route-olást nem biztos, hogy célszerű bántanom (mondjuk ki-bekapcsolgatni a route-okat) mert ha ezt percenként csinálom sokgépes terhelés esetén, az mind vissza fog folyni a nyakamba (anyázás képében).
Van arra valami direkt mód, hogy egy bizonyos kérést (mondjuk /tool fetch -kérést) egy meghatározott WAN-porton keresztül küldjek ki scriptből?
Vagy erre csinálnom kellene egy tűzfal-szabályt (amelyek számával azért spórolni szeretnék, az RB4011 ereje ellenére is) ?
Mit javasoltok (ha nem is szájbarágósan, de mindenképpen MikroTik-laikusok szintjén)?
Rig: RB4011, ROS 6.47.9
Köszi!
-
DonJoee
tag
válasz
DonJoee
#13180
üzenetére
Nna, úgy néz ki, hogy megtaláltam végre a kanálban a mélyedést...
A MikroTik honlapján levő kompatibilitási táblázat szerint a S+85DLC03D modult szereti az RB4011. (Optikában nem vagyok annyira jártas, józan földművelői ésszel beltérre, néhány helyiség összekötésére nekem elég a max. 300 métert tudó, multi módusú, dual LC-csatlakozós modul, ugye?) -
DonJoee
tag
válasz
Ear001
#13181
üzenetére
A távolságok nem feltétlenül nagyok. Van egy 12 méteres és egy tán 22 méteres szakasz. A többi a szokásos, irodán belüli 3-5 méter.
Az SFP+ modulok tekintetében leginkább az RB4011-gyel való együttműködés lenne a fontos. Ez a router, ha minden igaz, nem szereti a passzív modulokat. Vagy csak a leírásában szereplő S+DA000x kábelek nem mennek? De tán nem mennek a "buta" SFP GPON modulok sem, csak az "aktívak", ami nincs MikroTik-ben. Mindenféle más márkákkal próbálkoznak megnyerni a lutrit.
Ha optikai modulnál nincs ilyesmi gond, akkor az örvendetes lenne. -
DonJoee
tag
Sziasztok!
Adott (már megvan) egy MikroTik RB4011-es router, aminek a gigabites portjai egyelőre el fogják látni a szintén gigabites régi switcheinket, melyekre 17 számítógép és 5 nyomtató csatlakozik (bővítés sosem kizárt).
A régi switchek életük delén már túl vannak (inkább olyan este hat felé járhat náluk), úgyhogy azon gondolkodtam, hogy ha már úgy is újakra cserélném őket, akkor fejlődjünk is és tegyük némiképp jövőállóvá a rendszert.
Így most azon törpölök, hogy egy 10 Gigabites "gerincet" alkotnék a helyi hálózatnak MikroTik switchek, ezekbe csatlakoztatott SFP+ modulok és megfelelő kábelezés segítségével.Valami ilyesmit képzeltem:
[Internet]
| |
ISP1 ISP2
| |
RB4011iGS+RM
|
CRS305-1G-4S+IN
|||
||└ CSS610-8G-2S+IN
||
|└ CSS610-8G-2S+IN
|
└ CRS326-24G-2S+IN
|
└ CSS610-8G-2S+INTehát a routertől a helyi hálózat felé minden switch SFP+ (10G-s) modulokkal csatlakozna egymáshoz.
A kérdéseim, ami miatt itt, a MikroTik-topicban zavargok:
Ahogy látom, az RB4011 nem minden SFP+ modullal kompatibilis, azaz milyen MikroTik-gyártmányú modullal lehetne együttműködésre bírni?
Esetleg valami más gyártmány is szóba jöhet? Bár az SFP nem "szabvány", azaz a különböző gyártók közti kompatibilitás kissé lutri, ahogy értesültem. Valakinek van esetleg ezzel kapcsolatos tapasztalata?Az utolsó kérdés pedig az, hogy a modulok elérhetőségét, kompatibilitását is figyelembe véve optikai vagy réz legyen ez a 10G-s gerinc? Én az optika felé hajlok, ha már...
Köszi a segítséget és bocs a hosszúért!
Új hozzászólás Aktív témák
Hirdetés
ekkold- SSD kibeszélő
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- WoW avagy World of Warcraft -=MMORPG=-
- AMD GPU-k jövője - amit tudni vélünk
- Szünetmentes tápegységek (UPS)
- Kevesebb dolgozó kell az Amazonnak, AI veszi át a rutinfeladatokat
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Futás, futópályák
- Poco X6 Pro - ötös alá
- Mozilla Firefox
- További aktív témák...
- Apple iPhone 15 (újszerű, független , 128 GB, 6 GB RAM, Kék)
- Samsung 55" QE55QN700CTXXH 8K UHD Smart Neo QLED Mini LED TV
- Asus VivoBook S15 S513 OLED (S513EA-L12917) Fekete - Garancia 2026.06.22.
- DDR5 GAMER PC: Új RYZEN 7 8700F/9700X/9800X3D +RTX 4060/5060/4070/5070 +16-64GB DDR5! GAR/SZÁMLA!
- Dell Latitude 7410 Strapabíró Ütésálló Profi Ultrabook 14" -80% i7-10610U 16/512 FHD
- Gamer Laptop, Gamer Monitor és Konzol Felvásárlás Magas Áron, Gyorsan és Egyszerűen!
- ÁRGARANCIA! Épített KomPhone i7 14700KF 32/64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- Apple iPhone SE 2020 64GB, Yettel függő, 1 Év Garanciával
- ÁRCSÖKKENTÉS Lenovo ThinkPad T570, T580, P51s, P52s eredeti Lenovo, belső akkumulátor eladó
- Már csak 12 db 5G ROUTER! - Telenor 5G Indoor WiFi Router (FA7550) + töltő (bolti áruk 100.000Ft)
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest