-
Fototrend
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
-
kammler
senior tag
válasz
ekkold
#25635
üzenetére
chain=forward action=fasttrack-connection
nekem van ilyen, de disabledre van állítva tűzfalban
yettel 5g amúgy 1 gigabit sebesség le, rb5009-en 32% proci terhelés, meg 110 mbit sebesség androidon. 1412 MTU volt, most átírtam. Mondjuk úgy rémlik előtte is volt ennyi. Igazából nekem ok, csak mondom ránézek
-
ekkold
Topikgazda
válasz
yodee_
#25631
üzenetére
További beálítási tanácsok:
1, WireGuard interfész MTU csökkentése
RouterOS terminálban:/interface wireguard set [find name=wg0] mtu=12802, TCP MSS clamping – kötelező mobilnál
Ez RACs után is működik:/ip firewall mangle add chain=forward action=change-mss new-mss=clamp-to-pmtu \ protocol=tcp tcp-flags=syn out-interface=wg0 comment="WG MSS clamp"3. FastTrack kizárás WG-re
Ha FastTrack aktív, az hazavágja a WG forgalmat.
Ellenőrzés:/ip firewall filter print where action~"fasttrack"
Ha ilyet látsz:chain=forward action=fasttrack-connection
Akkor tegyél elé egy exclude szabályt:/ip firewall filter add chain=forward action=accept in-interface=wg0 comment="Accept WG traffic"
vagy FastTrack módosítása interface alapra.4. UDP timeout növelés
Mobilnál kapcsolateldobás ellen:/ip firewall connection tracking set udp-timeout=30s udp-stream-timeout=3m
Android WireGuard kliens – ajánlott beállítások
Android WG app-ban (wg0.conf-ban):
1. MTU megadása
Add hozzá az [Interface] részhez:
MTU = 1280
Ha tesztelni akarsz:
MTU = 1320
2. PersistentKeepalive kötelező mobilnál
A [Peer] részhez:
PersistentKeepalive = 25
Ez:
életben tartja a NAT-ot
csökkenti az LTE random megakadást -
ekkold
Topikgazda
válasz
yodee_
#25631
üzenetére
Megkérzdeztem a chatGPT-től, azt mondja 1350 vagy kisebb MTU kellhet, mert a mobilhálózat alacsonyabb MTU-val működik.
Mobilhálózati MTU kisebb
LTE/5G-n jellemző:
TechnológiaTipikus MTUEthernet1500PPPoE1492LTE / 5G maghálózat1428–1460WireGuard overhead-60 byte
Ez azt jelenti, hogy a valódi átmenő MTU gyakran 1350 körülire esik le.
Ha nincs jól beállítva:
fragmentáció történik
vagy a csomagokat a hálózat eldobja
TCP újraküld → brutális lassulás
Ez tipikusan:
CIFS/SMB esetén nagyon érzékeny
DLNA (HTTP stream) is megakad
iperf kevésbé érzékeny rá, mert más blokkmérettel dolgozik
2. Mobil szolgáltatók forgalomkezelése
Yettel és Telekom LTE core hálózaton gyakran van:
DPI (Deep Packet Inspection)
TCP flow kontroll
nagy latency + jitter
A SMB nagyon nem tolerálja a zajos kapcsolatot, míg az iperf mesterségesen “szép” forgalmat generál.
3. WireGuard tipikus MTU csapda
Ha WireGuard alapértelmezett MTU-val megy (1420 vagy 1500), akkor LTE/5G irányban:
✅ Handshake OK
❌ Normál alkalmazás szív
Ez 100%-ban passzol a tüneteidhez.
-
#25632
Reggie0
félisten
lionhearted
#25630
Reggie0
félisten
válasz
lionhearted
#25630
üzenetére
Nem mondtam h kell hanem kiproblatja mint faek, legegyszerubb, legbiztosabb modositaskent. Abbol kiderul, hogy tenyleg ez-e a gond.
Amugy meg lehetne packet tracelni is a talalgatas es probalkozas helyett.
-
#25631
yodee_
őstag
lionhearted
#25628
yodee_
őstag
válasz
lionhearted
#25628
üzenetére
Köszönöm, utána olvasok a dolgoknak.
-
#25630
lionhearted
őstag
Reggie0
#25629
-
Reggie0
félisten
válasz
yodee_
#25616
üzenetére
De, de nagyjabol par szazalek az elteres, annyit be lehet vallalni. Igazabol kezdetnek probald ki, hogy megoldja-e a problemat. Ha nem, akkor tudod, hogy masfele kell keresni, nem a nas MTU okozza a problemat, sot lehet nem is a packetmerethez van koze, hanem valami teljesen mas dolog okozza a lassulast. Ha igen, akkor meg raersz gondolkodni, hogy mit lehetne meg optimalizalni a halozatodon.
-
#25628
lionhearted
őstag
yodee_
#25627
válasz
yodee_
#25627
üzenetére
Gyakorlatilag bármit, ami illeszkedik a workflowba, és távoli (internet távoli) elérésre terveztek.
Anélkül, hogy vitát nyitnék arról, hogy a publikus felhőszolgáltatókat ide behoznám, maradhatunk self-hosted vonalon is: NextCloud (Webdav, natív kliens, HTTPS), OwnCloud Scale (igen, újraírták), S3 kompatibilis megoldások (nem akarom a minio döntéseit sem idehozni, szóval általánosítok kicsit), Resilio Sync (közös tárterületről syncel), Syncthing (hasonló), Seafile.. a lényeg, hogy megtaláld azt a folyamatot, ami kényelmes és hatékony a továbbiakban. És persze próbáltam a free vonalon is mozogni, mert vannak bőven fizetős verziók is.
Egyébként érdekes fejlemény az SMB over QUIC, de még bőven a sütőben van, annyira friss.
DLNA-t pedig a mediaserverek váltják: Kodi, Jellfyfin csak a legismertebbek (és opensource kitétellel).
-
#25627
yodee_
őstag
lionhearted
#25626
yodee_
őstag
válasz
lionhearted
#25626
üzenetére
Meghallgatok tanácsot szívesen. Alapvetően egy konkrét mappa van amit minden kliens elér, dolgozik benne. Ezt samba-n kívül mivel tudnám kivitelezni? A dlna nem létfontosságú, csak ha már van rá lehetőség használnám.
-
#25626
lionhearted
őstag
yodee_
#25620
-
yodee_
őstag
válasz
ekkold
#25623
üzenetére
Tamarel: Nem csináltam semmit, telefonon kedvencekben el van mentve a média szerver és amikor aktív a wg kapcsolat akkor elérem. Csak a mobil kliens felől lassú a samba, optika mögül rendben van.
ekkold: Amikor próbálkoztam MTU csökkentéssel akkor igen, minkét oldalon csökkentettem. Egy ilyen ollóztam össze:
chain=forward action=change-mss new-mss=1380 passthrough=no tcp-flags=synprotocol=tcp out-interface=wireguard14 tcp-mss=1381-65535 log=nolog-prefix="" -
ekkold
Topikgazda
válasz
yodee_
#25620
üzenetére
A wireguard MTU-t mindkét oldalon egyformán lecsökkentetted? Tehát a mikrotik szerver oldalon is, és a mobilos kliens wg konfigjában is?
Próbáltál esetleg a mikrotikben, a wg intefész felé csomagméretet csökkenteni?
Valahogy így:
/ip firewall mangle
add action=change-mss chain=forward comment="1350 VPN csomagmeret 10.0.8.0" \
dst-address=10.0.8.0/8 new-mss=1350 passthrough=yes protocol=tcp \
src-address=192.168.23.0/24 tcp-flags=syn tcp-mss=!0-1350 -
#25620
yodee_
őstag
lionhearted
#25619
yodee_
őstag
válasz
lionhearted
#25619
üzenetére
Oké akkor megpróbálom pontosabban vázolni. Tehát. A WG szerver a saját x86 alapú L4-es MikroTik eszközöm, egy Telekom-os 2000/1000 optikai internettel, PPPOE kapcsolaton, publikus IP-vel. Ezen a szerveren lóg az ubuntu alapó szerver, ami tartalmazza a korábban felsorolt szolgáltatásokat (minidlna, ftp, samba, web. A kliensek a következőek:
- 1. Mikrotik hAP ac2 + Telekom optika 1000/1000 PPPOE kapcsolaton, az ac2-n lógó eszközök az ac2 maximális sebességével érik el azu ubuntu szolgáltatásait.
- 2. Mikrotik Chateau LTE18 + Yettel Otthonnet LTE frekvencián. A rajta lógó eszközök iperf-el a hálózat maximális tempóját mutatják (100-150 mbps) viszont a minidlna stream megakad, samba másolás nagyon maximum 600KB/s tempóval megy.
- 3. BananaPi BPI-R3 mini + Telekom MultiSIM LTE frekvencián. A rajta lógó eszközök iperf-el a hálózat maximális tempóját mutatják (50-80 mbps) viszont a minidlna stream megakad, samba másolás nagyon maximum 600KB/s tempóval megy.
- 4. Honor Magic 6 Pro + Yettel SIM 5G/LTE frekvencián android klienssel iperf-el a hálózat maximális tempóját mutatják (50-80 mbps) viszont a minidlna stream megakad, samba másolás nagyon maximum 600KB/s tempóval megy.
-
#25619
lionhearted
őstag
yodee_
#25618
válasz
yodee_
#25618
üzenetére
Látod, még mindig nem ismerem a releváns útvonalat. Biztos ki kéne találnom, meg ismernem a korábbi 2 évből, hogy mi van nálad.
Próbálkozom WG optimalizálással, de elfogytak az öteleteim. A saját kapcsolaton T-Home optika 2000/1000. A kérdéses interface mögött mobilinternetes mikrotik/openwrt eszköz van.
Ezt írtad. Ebben melyik a "szerver"? A telekom eszköze, csak nem... a mobilnetes Tik egyszerre vezetékes T-s Tik? Vagy ezek a külsős eszközök, de mi a központ? Hogyan van beállítva? Mit mivel hasonlítasz? Az a 1/1 mögötti ac2 szintúgy egy külsős eszköz ugyanerre a központra, csak az gyors?
Miért csoda, hogy a mobilnet nem gigabites?
Megannyi kérdés. -
#25618
yodee_
őstag
lionhearted
#25617
yodee_
őstag
válasz
lionhearted
#25617
üzenetére
Van egy szerverem ubuntuval. Ezen fut minidlna, ftp, samba, web szereverek. Ezeket érném el távolról. És csak a mobil oldalon vannak problémák.
-
#25617
lionhearted
őstag
yodee_
#25616
-
yodee_
őstag
-
ekkold
Topikgazda
válasz
yodee_
#25608
üzenetére
Ami a leírásodból látszik, hogy az egyik esetben mikrotik-mikrotik, a másik esetben mikrotik-openwrt közötti kapcsolat van. Utóbbi esetben esetleg valamilyen kompatibilitás gond?
Másmilyen VPN-el (pl. l2tp) ki tudod próbálni, akkor is alacsony a sebesség? UDP portot is probáltad lecserélni? -
yodee_
őstag
Sziasztok!
Próbálkozom WG optimalizálással, de elfogytak az öteleteim. A saját kapcsolaton T-Home optika 2000/1000. A kérdéses interface mögött mobilinternetes mikrotik/openwrt eszköz van. Az eszközök között iperf3-al a lefedettségtől függően megvan a megfelelő sebesség (10-50mbps), viszont SMB, FTP, miniDLNA streaming esetén használhatatlanul lassú a kapcsolat. Próbálkoztam a WG interface-ek MTU-jának csökkentésével de nincs hatása a sebességre. Mit tudok még kipróbálni? A másik interface esetén, ahol szintén optika van (T-Home 1000/1000, MikroTik hAP ac2) WG-n keresztül 250-300 mbit/s sebesség van minden extra beállítás nélkül. Ha valakinek van ötlete szívesen fogadom
Nagyon köszönöm.
-
#25607
lionhearted
őstag
aujjobba
#25606
válasz
aujjobba
#25606
üzenetére
Ez így van, Debian alapú, nftablesre épült tűzfal megoldásokkal. De változtattak a kiadási megoldásán legalább is a community vonalon. És nem is találtam még aktívabb magyar közösséget rá, redditen azért vannak rá threadek.
Ez az az OS, amivel a korábban emlegetett fórumtársunk ~ 7/7 feletti eredményt ért el PPPoE felett, speedtest-clivel... Talán egy TCP szálon értve, ha az a default.De talán pont a Linux alap megközelítés miatt hasonló a tűzfal a Mikrotikesre.
-
ekkold
Topikgazda
-Attól is függ milyen protokollal megy a másolás. Lehet, hogy valamelyik eszköz cache-el, vagy tömörít az adatátvitelben... A wg nem szokásos szerver-kliens kapcsolat, egyenrangú a két oldal, ebbe csak az szól bele, ha pl. az egyik oldal NAT-olt interneten lóg... Ja meg persze a köztes hálózaton is múlik, hogy mennyi fér át a gyakorlatban.
A hap ac3 valószínűleg nem tud ekkora sebességet wg-al, tehát biztos van "valami trükk" a dologban. -
Lenry
félisten
érdekes adalék itt a fenti témához.
épp két gépem közt másolok.
A gép -> hap ac3 -> wireguard -> CCR1009 -> B gép útvonalon.B gépen belépve:
rsync -avP Agépről ideparanccsal
a sebesség olyan 150-200 Mbit volt, a hap ac3 60-70%-on pörgöttmost ugyanazt másolom, csak A gép irányából tolva:
rsync -avP innen Bgépreparanccsal, és 800-900 Mbit, hap ac3 20%-on -
#25603
lionhearted
őstag
Reggie0
#25600
válasz
Reggie0
#25600
üzenetére
Akkor nem az encryption teszi, ettől még nem gyors. A NIC se tud segíteni, mert nem érti a PPP fejlécet, szóval azokon sincs offload.
@mrots: nem igazán vagyok oda a kötekedésért. Mikrotiken tudtommal nincs openvpnben ChaCha, aes van és blowfish (és tiktosítatlan, de azt továbbra sem tekintem titkosításnak).
Akár mikrotik felületen kb 3 kattintás egy wireguard peer, aztán ott a generált QR kód, telefon pittyent, készen vagy. Melyik ipsec tud ilyet? Melyik ipsec használható úgy, hogy a vonal egyik fele cgnatolt, mindenféle ISP szűrésen átesett, instabil hálózaton van?
-
mrots
tag
válasz
user12
#25589
üzenetére
A tunnel gyors felepulese igazabol mas technologiaval is elerheto. Igen, ertem, hogy most masodperc nagysagu, vagy annal kisebb idorol beszelunk, tehat a kerdes pusztan elmeleti. OpenVPN nincs keznel, ipsec van. Lebontottam a tunnelt, hogy nullarol induljon, majd elinditottam a linux oldalon, vegul elkezdtem pingelni a cisco oldalrol:
En ebben nem vettem eszre kesleltetest.
cgw#ping 8.8.8.8 source gigabitEthernet 0/1.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.8.30.33
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 msMegegyszer: nem akarok senkit semmirol meggyozni, mindenki azt hasznal amit akar, megerteni szeretnem a technikai erveket. Nekem jelenleg sem az openvpn, sem a wireguard nem opcio, mert halozati eszkozok az ipsecet tamogatjak es kesz, ez az "ipari" szabvany. De ez nem jelenti, hogy ne akarnam megerteni a szakmai erveket egyik, vagy masik vpn megoldas korul. Ki tudja, talan egyszer meg lesz cisco vagy palo alto eszkoz amiben opcio lesz a wireguard.
-
#25601
mrots
tag
lionhearted
#25586
mrots
tag
válasz
lionhearted
#25586
üzenetére
Erdekes, hogy nem valaszthato a titkositast / autentikacio algoritmusa, de gondolom a lenyeg az egyszeruseg volt - ezzel sem kell bibelodni. OpenVPN-t nem hasznalok mar egy ideje de gondolom az allitasod, hogy 'barmelyik' -nel gyorsabb az valoszinuleg nem igaz, hiszen lehet gyenge titkositast valasztani, vagy akar titkositas nelkul is lehet kuldeni, ami nyilvan gyorsabba teszi az adatatvitelt. De nem is ez a lenyeg, hanem az, hogy - amennyiben jol ertelmezem a wikipediat - a wireguard a felepult tunnelben ChaCha20 stream ciphert hasznal. Elvileg ebben van a truvaj, hogy gyors es biztonsagos is. Nade egy sima strongswan is tudja ezt hasznalni:
root@vm-test:/usr/src/strongswan-6.0.3# ./configure --help | grep -i chacha
--enable-chapoly enables the ChaCha20/Poly1305 AEAD plugin.A kerdes ezek utan - es ez nem okoskodas, oszinten nem tudom a valaszt - az, hogy egy chacha20-szal forditott strongswan, ami ipsec, mitol rosszabb, mint egy wireguard, ha a felepitett tunnel feletti atvitelt nezem?
-
#25600
Reggie0
félisten
lionhearted
#25598
Reggie0
félisten
válasz
lionhearted
#25598
üzenetére
Hat nekem a J4025 kis szerverem 21gbyte/s-t tud triple des algoval egy szalon, ami a legkemenyebb a pppoe algoi kozul. Szoval nem hinnem, hogy egy nagyobb intel procin ennek gondot kene okoznia.
de latszik mennyit szamit a fejlodes, pl. a xeon 2697 v4 proci egy szalon csak 9.7 gbyte-ot tud.
a laptopomban az amd 8840u pedig 16gbyte/s.nasban a 4590S 29gbyte/s.
rpi 3: 8.6 gbyte/s
STM32MP157C (600MHz Arm A7): 1gbyte/s
-
#25598
lionhearted
őstag
ekkold
#25596
válasz
ekkold
#25596
üzenetére
Csak?! Vegyük a legdurvább Netgate 8300-at, Intel Xeon D-1733NT : Single thread 2198... akár egy i3-7100 tudja azt... és ahogy látod, fele a Ryzennek... de tegyük fel nincs jól lehűtve, és csak a 80%-ot tudja, akkor is elég durva... az Netgate 8300 28Gbps firewallra van beígérve, 14Gbps IPsec mellett. Számok alapján az azért nem kevés.
A probléma az, hogy nincs megírva egy rendes HW offload. Lásd a Telekom által biztosított Qualcomm alapú eszköz képes megoldani a feladatot.
Mivel én is csak átadom az infót, semmire sem esküszöm... a tapasztalat azt mutatja, hogy a többszálas speedtest mikrotiken is szétosztja a forgalmat a CPU magok között. De egyetlen TCP streamnek nem elég a kraft.
-
#25597
ekkold
Topikgazda
Krisztianby
#25595
ekkold
Topikgazda
válasz
Krisztianby
#25595
üzenetére
512Mb RAM-al, meg kétmagos procival nem tudom mekkora lesz a kontérnerben futó app teljesítménye... Persze lehet, hogy elég amire kell. A Pi-hole lényegében egy DNS szerver, ami szűr bizonyos címeket. De ilyen adlist-et a mikrotik önmagában is támogat egy ideje, próbáltam, és egész jól működik. Itt érhető el:
ip/dns/adlist/
Csak egy megfelelő szűrő-listát kell hozzáadni. Gondolom a Pi-hole többet tud, meg sokféle szűrője van, de a viber reklámjait pl. el tudtam tüntetni ezzel is.
viber-ad.txt:
0.0.0.0 ads.viber.com
0.0.0.0 ads.aws.viber.com
0.0.0.0 ads-d.viber.com
0.0.0.0 s-bid.rmp.rakuten.com
0.0.0.0 ad.adverticum.net
0.0.0.0 rmp.rakuten.com
0.0.0.0 ams1-mobile.adnxs.com
0.0.0.0 api.mixpanel.com
0.0.0.0 fra1-ib.adnxs.com
0.0.0.0 mediation.adnxs.com
0.0.0.0 s-imp.rmp.rakuten.com
0.0.0.0 s-bid.rmp.rakuten.com
0.0.0.0 api.taboola.com
0.0.0.0 video.primis.tech
0.0.0.0 ads.stickyadstv.com
0.0.0.0 primis.tech
0.0.0.0 live-eu-am.primis.tech
0.0.0.0 live-us-ny.primis.tech
0.0.0.0 live.primis-amp.tech
0.0.0.0 live.primis.tech
0.0.0.0 primis-amp.tech
0.0.0.0 primis-d.openx.net
0.0.0.0 primisttd-d.openx.net
0.0.0.0 rtb.primis.tech
Ezt felvettem mikrotik adlist-be.
De felvehető sokkal szélesebb körű szűrés is pl:
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
Fel lehet venni kapásból a fenti linket is a mikrotik szűrőjébe, nem muszáj letölteni a fájlt (de egyébként letöltve is lehet használni).Otthon használok NAS-t is, annak több erőforrása van, mint a routernek, ha konténert (vagy akár virtuális gépet) akarnék használni, akkor inkább arra tenném.
-
#25596
ekkold
Topikgazda
lionhearted
#25594
ekkold
Topikgazda
válasz
lionhearted
#25594
üzenetére
Az említett Ryzen proci 16 magos, és 32 szálas. CPU mark: 55601 pont. Viszont az egy magos teljesítményére csak 4301 pontot kap. Tehát ha a feladat nem tud több szálon futni, akkor az elérhető maximális teljesítménynek, még a tizedét sem éri el.
A PPPOE ezek szerint ilyen? Intel procin is ilyen?
Ennek vajon a PPPOE működéséből fakadó oka van, esetleg a linux kernel verzió korlátoz, vagy csak a szoftver nincs jól megírva? -
#25595
Krisztianby
tag
Krisztianby
tag
Sziasztok nézegettem a hivatalos oldalt és megláttam ezt a "gyöngyszemet" : Mikrotik hAP ax S. Jelenleg egy hAP ax lite használok, viszont már csak érdekesség ként is beruháznák az ax S-re az USB támogatás végett így lehetne egy konténeres Pi-holém
.Néztem a Ethernet test resultokat és nagy különbséget nem látok eredmények között. Yt szekció alatt leírták tök fasza route lenne ha nem ez a processzor került volna bele.
Aki jobban rálát szerinte a AX S procija (EN7562CT) mennyire lehet erősebb/gyengébb a IPQ-5010 tol. Nyilván a AX S mindenben jobb mint a AX lite viszont kíváncsi vagyok porcira.
Árukeresőn a AX S még nincs is fent amikor néztem és yt- tesztek sincsenek
-
#25594
lionhearted
őstag
ekkold
#25587
válasz
ekkold
#25587
üzenetére
Kraft egyszálon pedig akadt a srácnál: Ryzen9 9955HX (turbo 5.4Ghz!!!), passmark singlethread szerint az általam nézett kategória dupláját tudja.
Kézreállás most már közel mindegy, lehessen IaC eszközzel kezelni, és akkor ronda mindegyik.
Uhh, azt hogy milyen hardvert szándékozom használni... az egy olyan hosszú történet, hogy nem fér bele a fórumba.
![;]](//cdn.rios.hu/dl/s/v1.gif)
És még most sincs leütve. Röviden: Intelt. 
Meg virtualizálás, de a NIC megy direktbe. 
-
válasz
ekkold
#25581
üzenetére
"ha már kiadják x86-ra is az oprendszert, akkor x86 alapú hardvert miért nem árulnak hozzá?"
Ezen is csak megy a spórolás, vagy nem is tudom.
A 16 MB Flash méretnek mi értelme volt? De anno kötötték az ebet a karóhoz (Normis-val az élen), hogy 16 MB mindenre is elég. Ja, látjuk.
De igen. Egy dedikált, mini MikroTik féle PC-re lehet és is szívesen váltanék.
Lenne bőven memória és háttértár is, processzor teljesítményről nem is beszélve! -
user12
őstag
Nekem az tetszik benne, hogy baromi gyorsan felépül a tunnel, routing. Rákattintok a konfig nevére és már ott is a hálôzati meghajtó, winbox eléri az eszközt, stb. Nekem annyi bajom van vele, hogy a win kliens néha nem indul el, ilyenkor kell egy restart a gepnek, parancsikonnal se indul el. De ennyi baj legyen
-
ekkold
Topikgazda
A wireguard az egyik legmodernebb VPN megoldás. A kódja, ha jól emlékszem tizedakkora, mint az openvpn kódja, és eddig még nem találtak benne biztonsági problémát, pedig a rövidebb kódot könnyebb ellenőrizni. Az erőforrásigénye is kicsi, még egy régi mikrotik eszközön, (pl. RB951) is megy olyan 50Mbit/s-al, ezen egyedül talán a PPTP gyorsabb egy lepkefinggal (de az ma már nem ajánlott), minden egyéb lassúbb rajta.
-
#25587
ekkold
Topikgazda
lionhearted
#25583
ekkold
Topikgazda
válasz
lionhearted
#25583
üzenetére
1, nézegettem már kíváncsiságból más x86-on futó routereket is, de valahogyan egyik sem állt kézre úgy, mint a RouterOs. Szükség esetén megoldható nagyon olcsón is
, bár az talán jelent némi kockázatot, de az eddigi tapasztalatok alapján, otthonra esetleg bevállalható lehet.
2, Nem tudom hány embernek van ilyen netje, de szerintem némi túlerővel (a hardver tekintetében) ez megoldható probléma.
Te milyen hardvert szándékozol a RouterOs alatt használni? -
#25586
lionhearted
őstag
mrots
#25584
-
mrots
tag
válasz
ekkold
#25572
üzenetére
sosem hasznaltam wireguardot, csak ipsec meg openvpn, ugyhogy nem tudom, nem lehet-e a titkositast valasztani wireguardnal? vannak olyan titkositasok, amik cpu intenzivebbek es vannak olyanok, amik kevesbe. Ha fontosabb a sebesseg, mint a titkossag (azaz mondjuk kisebb kulcs, vagy egyszerubb algoritmus is eleg) akkor altalaban egy vpn eseten ezzel lehet jatszani. hogy konkretan a wireguard ezt engedi-e azt nem tudom, ha nem, akkor megoldas lehet elmozdulni egy olyan vpn technologia fele, ahol az algoritmus konfiguralhato.
-
#25583
lionhearted
őstag
ekkold
#25581
válasz
ekkold
#25581
üzenetére
Épp egy ilyenen dolgozom, pont a felsorolt okok miatt. Bár én nem rendelek ilyen kínai vackokat, ki tudja mi van benne. Viszont van két elgondolkodtató pont:
1. fizetős és zárt routerOS szemben a népszerű FOSS firewall OSekkel (ha már van előtte egy CRS igazából a tűzfal a kérdéses főleg)
2. Telekom topikban írták, nem tudja PPPoE-n kihajtani a 8/8Gbps netet, főleg felfelé van gond (egyszálas az encryption gondolom) 2.5Gbps körül. Nem mintha lenne ilyen netem, csak a tudat, ha már megépítem, fizetem a P10 licencet, és nem fogja kiadni. Legalábbis egyelőre.
-
Reggie0
félisten
-
ekkold
Topikgazda
válasz
Reggie0
#25579
üzenetére
Azt én sem értem, hogy ha már kiadják x86-ra is az oprendszert, akkor x86 alapú hardvert miért nm árulnak hozzá? Még egy régebbi x86 PC procival felszerelt router is erősebb mint ezek az ARM-os routerek. Távolkeletről lehet rendelni ilyen több portos mini PC-ket N100 és hasonló procival, de ezekkel kevés a tapasztalat. Szerintem többen szívesen vennének ilyesmit, ha lenne megbízható, Mikrotik névvel elérhető, x86 alapú routerboard is a kínálatban.
Itthon az RB5009-et egyelőre nem szándékozom lecserélni, de ha egyszer lesz következő routerem, akkor lehet, hogy az már x86 alapú lesz. Virtuális gépen futó, x86 alapú routert használok időnként, és eddig egész jók a tapasztalatok vele. -
Reggie0
félisten
-
ekkold
Topikgazda
De a windows-t valószínűleg nagyságrendekkel erősebb processzoron futtatod. Ugyanolyan hardveren a RouterOs-nek is könnyedén, akár számottevő terhelés nélkül menne...
Ha van rá lehetőséged, akkor egy próbát megérhet az is, hogy a wireguardot külön hardverre teszed, (vagy akár egy virtuális gépre), hogy a routernek csak forwardolnia kelljen a csomagokat...
-
ekkold
Topikgazda
Igen, bár a 650Mbit azért már nem rossz. Valószínűleg akkor menne gigabittel ha nem lenne semmi más dolga a routernek (PPPOE, NAT, Tűzfal, Portforward és egyebek).
"Szintetikus tesztekkel" lehet, hogy jobb eredmények jönnének ki amúgy.
Azért majd próbáld ki azt az RB5009-et, ha lesz lehetőséged, mert elvileg jóval erősebb procija van mint mint az ax3-anak. Bár érdekes, hogy nekem régen a sima hAPac² is tudott 200....300Mbit/s-ot wireguard-al - tehát kicsit olyan mintha nem lenne egyenesen arányos a proci teljesítményével. -
ekkold
Topikgazda
válasz
Reggie0
#25569
üzenetére
Sajnos nem mentettem képernyőképet amikor teszteltem a wireguard sebességét, de emlékeim szerint olyan 650Mbit/s körülit mértem CCR1009-el, és RB5009-el is kb annyit.
J1900 Celeronos miniPC-n, RouterOs x86 verzióval viszont, kicsivel 700Mbit/s felett - valós körülmények között - tehát internet elérés VPN-en keresztül, kb. 150km-ről, speedtest.net-en tesztelve.
Ugyanez 4.gen i7 procis miniPC-vel (ez sem mai darab, de a celeronnál sokkal erősebb), már simán tudta volna távolról is a gigabitet. A korlát a köztes hálózat volt. 700....800Mbit/s wg sebességhez mindössze 17....20% proci terhelés tartozott, és mind a 8 szálat használta a RouterOs. -
Reggie0
félisten
válasz
stopperos
#25570
üzenetére
A logika az vilagos, de a profiler szerint a wireguard 25%-ot eszik meg, szoval az tobb mint 2 szal, hiaba van csak 2 kliens.
Ha csak 1 klienssel megyek a routerre es natolok, akkor 19%-ig megy a wg a profiler szerint.
De en ugy emlekszem, hogy 7.8-nal volt ez meg tobb szal is es nagyobb savszel.
-
stopperos
senior tag
válasz
Reggie0
#25568
üzenetére
Ha 1 bandwidth tesztet ráengedsz 1 wireguard kapcsolatra, akkor az 1 szálon fog menni.
Ha több kliensről több kliens felé indítod a tesztet, akkor az több szálon megy ugyanaz a wireguard kapcsolat. (7.12-nél néztük, akkor még így volt)
Ez akkor a probléma ha két szerver kommunikál egymással 1-1 mikrotik router mögött wireguarddal összekötve.
SzerK: (Mi home office kiszolgálására használjuk, ezért ott nem ütközünk problémába. Több szálon megy minden.) -
stopperos
senior tag
A problémád az, hogy a wireguard 1 cpu szálat használ Mikrotik-en. (Nézd meg a cpu terhelést).
RB5009-en 500/500 Mbit/s, de CCR-eken is hasonlót mértünk 2 éve.Azóta nem foglalkoztam vele, hogy mi van ha 2-3 wireguard interfész van. (Illetve ha 2-3 bandwidth teszt megy párhuzamosan). A wireguard felépítése alapján nem kellene 1 cpu-n futnia, de nem lehet tudni, hogy milyen a RouterOS megvalósítása. Főleg, hogy valahol 5.6 Linux kernelnél megálltak.
-
ekkold
Topikgazda
Biztosan valamit rosszul csináltam, de nekem, valós körülmények között, sem az RB5009 sem a CCR1009 nem tudta wireguarddal elérni a a gigabites sebességet (szerintem kb. egyforma erős a két típus, de a ccr 9 magos, ennél az egy magos teljesítmény kisebb).
Nekem csak PC alapú routerrel sikerült elérni wg-vel a gigabites sebességet.
Úgy teszteltem hogy a router csatlakozott PPPOE-vel, és NAT-olt is a wg mellett, tehát nem kizárólag a wg terhelte a routert. -
Sziasztok,
Az létezik, hogy egy hap ax3 nem tud full sebességet leadni Wireguardon keresztül?
Van egy állandó kapcsolatom egy rackforest-es szerveren. Feltöltés / letöltés kicsit karcsú, le 600Mbit/s fel 2-300Mbit. Ugyan ez a config Windows-os wg kliensel full speed, tehát 900Mbit/s fel és le is. Gigabites Telekom van egyébként otthon.
Amit látok, hogy pl egy speedtest a cpu-t 60-70%-ban leterheli de mást nem. -
user12
őstag
válasz
Ablakos
#25559
üzenetére
A leírás azt írja, hogy csak passzív poe a támogatott
https://help.mikrotik.com/docs/spaces/UM/pages/14221549/Groove-seriesRádughatod nyugodtan az at-s tápfeladót, nem fog füstölni. Valszeg nem is fog elindulni az eszköz, mivel a Groove nem támogatja az at szabványt, így nem is tud egyeztetni a tápfeladóval a feszültségről. Mindaddig csak minimális 1-2 V lesz a kábelen, ami nem tesz benne kárt (és más eszközben sem)
Vagy nézel egy fix 12-24V-os passzív poe tápot vagy veszel egy ilyet a meglévő at-s tápfeladóhoz
https://mikrotik.com/product/rbgpoe_con_hp -
válasz
aujjobba
#25538
üzenetére
"A "D" azt gondolom a DFS csatornat jelenti jelen esetben, a #136-os az pont az."
Hát úgy néz ki, neked lesz igazad:current-channels=5180/a/I,5180/n/I,5180/n/Ce/I,5180/ac/I,5180/ac/Ce/I,5180/ac/Ceee/I,
5200/a/I,5200/n/I,5200/n/eC/I,5200/ac/I,5200/ac/eC/I,5200/ac/eCee/I,5220/a/I,
5220/n/I,5220/n/Ce/I,5220/ac/I,5220/ac/Ce/I,5220/ac/eeCe/I,5240/a/I,5240/n/I,
5240/n/eC/I,5240/ac/I,5240/ac/eC/I,5240/ac/eeeC/I,5320/ac/eeeC/DIcurrent-channels=2412/g,2412/n,2412/n/Ce,2417/g,2417/n,2417/n/Ce,2422/g,2422/n,
2422/n/Ce,2427/g,2427/n,2427/n/Ce,2432/g,2432/n,2432/n/Ce,2432/n/eC,2437/g,
2437/n,2437/n/Ce,2437/n/eC,2442/g,2442/n,2442/n/Ce,2442/n/eC,2447/g,2447/n,
2447/n/Ce,2447/n/eC,2452/g,2452/n,2452/n/Ce,2452/n/eC,2457/g,2457/n,2457/n/eC,
2462/g,2462/n,2462/n/eC,2467/g,2467/n,2467/n/eC,2472/g,2472/n,2472/n/eCEzek szerint ez is változott a "wireless" és a "wifi" csomag között :-)
-
#25556
kammler
senior tag
E.Kaufmann
#25555
kammler
senior tag
válasz
E.Kaufmann
#25555
üzenetére
Hát, úgy voltam vele, hogy a HP mini PC-be nem volt gyárilag wifi, vettem bele. Ha meg már veszek hát vettem egy intel be202-öt. Az se volt drága, sőt, gyanúsan olcsó volt. De működik bluetooth, meg minden. Igaz WIFI7-en nem tudom próbálni.
-
stopperos
senior tag
Itthon én wAP ac-t és hAP ac-t használok wifihez. (mindkettő triple chain-es)
Guest hálózatnak és IoT-nek van egy 2.4 GHz-en sugárzott SSID, visszavett adóteljesítményekkel. Minden más SSID (2-3) 5 GHz-en van, triple chain, 80MHz. Amióta ezekre átálltam, nincs panasz itthon a hálózatra.
Ha új telepítést csinálunk, akkor az csak ax-es eszköz. (10 évre kell tervezni, és hogy ott lehessen úgy hagyni, hogy nem lesz vele gond) -
#25553
user12
őstag
E.Kaufmann
#25550
user12
őstag
válasz
E.Kaufmann
#25550
üzenetére
Még 6e eszköze sincs, vagy ezt skipelik és egyből a 7-be ugranak
Annak meg úgy lesz értelme ha legalább 10G-s interface lesz az AP-n
Nekünk egyelőre nem releváns, a legfullosabb wifi eszközünk is ax/80Mhz-t tud -
#25551
kammler
senior tag
E.Kaufmann
#25550
kammler
senior tag
válasz
E.Kaufmann
#25550
üzenetére
Nem érint amúgy. Egyrészt mala drága lesz, másrészt újak még nekem amúgy is, nem mostanság cserélem az AX3-akat
-
#25550
E.Kaufmann
veterán
kammler
#25549
E.Kaufmann
veterán
válasz
kammler
#25549
üzenetére
Na ja, mire lesz már Wifi8-as eszköze másnak, késznek kell lenniük nekik is a Wifi7-el
Mondjuk Fitkó Félix (Felix Fietkau) se rég tette még be az MLO konfig lehetőségeket az OpenWRT-be (de amúgy a kedvenc author-om, mert a nekem fontosabb fejlesztéseket tőle láttam az OpenWRT changelog alatt).
-
-
Apollyon
Korrektor
válasz
user12
#25545
üzenetére
Szerintem is olvasható, de ez inkább mobilra van optimalizálva, és kevésbé desktopra.
Konkrétan a főoldalon a kurzorral oldal irányba swipeolva lehet lapozni a routerek között.
Azonkívül sok a nagy, üres hely, kilométer távolságok a feliratok között.
A betűtípus klassz, de ez is inkább mobilos site lett... -
#25545
user12
őstag
Dr.FantastiK
#25542
user12
őstag
válasz
Dr.FantastiK
#25542
üzenetére
Nekem is. Külön piros pont, hogy a mobilos optimalizálás is jó lett.
-
user12
őstag
válasz
Zwodkassy
#25531
üzenetére
Én külföldi oldalakon olvastam róla. Állítólag nem rossz, de a cpu és az architektura miatt lehúzzák. vártam nagyon a 3x3-as wifi miatt, de rájöttem, hogy fölösleges, mert úgyis csak 1G lesz az uplink. Így inkább veszek majd egy hAP AX-et, annak amúgyis jobb cpu-ja van.
-
#25543
Reggie0
félisten
Dr.FantastiK
#25542
Reggie0
félisten
válasz
Dr.FantastiK
#25542
üzenetére
Jo ocska lett, a reginek sokkal kezelhetobb volt a filtere. Most nem is lehet szurni sfp portra se. Az az erzesem, hogy az egyre debilebb juzereknek egyre debilebb honlapokat keszitenek...
Meg szerencse, hogy a product matrixot nem csesztek szet, mar csak az hasznalhato ertelmesen: [link] De cserebe kb. sehol sincs linkelve az oldalukon
-
#25542
Dr.FantastiK
őstag
Dr.FantastiK
őstag
Nekem tetszik az uj weboldal, de BITANG NAGYOK azok a KOCKAK !!
.. es odairhattak volna hogy mibol hany van a cuccon,
Peldaul : 2 x M.2
-
Apollyon
Korrektor
Lol ez a videó
Back to Home VPN by MikroTik -
válasz
aujjobba
#25535
üzenetére
"De varjunk, a laptop pl. elvben 40Mhz szeles csatornan van"
Az, hogy egy Access Point 40 , 80 esetleg 160 MHz széles csatornát használ, az nem azt jelenti, hogy a kliens is így csatlakozik. Ez kliens függő. Ha az csak 20 MHz-t tud, akkor csak annyit használ.
Ez igaz a "/D : Dual" , "/T : Triple" esetében is! -
-
-
#25530
Zwodkassy
senior tag
E.Kaufmann
#25529
válasz
E.Kaufmann
#25529
üzenetére
Hát ez az új Weboldal ... hmmm
Nem túl átlátható és felhasználó barát
Miért kellett így elbonyolítani?
Úgy látom a csilli-villi fontosabb lett, mint az átláthatóság agy a tartalom. -
#25529
E.Kaufmann
veterán
E.Kaufmann
veterán
Új weboldal. Azt nem mondanám, hogy tetszik is, pláne, hogy eddig a download-nál volt egy tábla, most meg választhatok a listákból...
-
aujjobba
addikt
válasz
Tamarel
#25527
üzenetére
Igen, full automata.
name="cap-wifi2" mac-address=<> arp-timeout=auto
radio-mac=<> configuration=WIFI-config
configuration.mode=ap .ssid=<> .country=Hungary
.hide-ssid=no .installation=indoor
security.authentication-types=wpa2-psk
.multi-passphrase-group=WIFI-passphrase .ft=yes .ft-over-ds=yes -
-
aujjobba
addikt
Van egy L009-em, ami ra van kotve egy switch-re.
A switchen log a NAS, egy hAPax2, es egy cAPax is.
A NAS-on iperf3 szerver, a kliens a telefonomon ami vagy a hAP-ra vagy a cAP-ra csatlakozik.
Namost amikor frissen ujra vannak inditva az eszkozok, az iperf 600-700 Mbps sebesseget mer.
Aztan egyszer tortenik valami, es onnantol atlag 300 lesz ez, egyik kesobbi meressel sem lesz megint 600-700.
Tehat ez mind wifi-n merve.Mindekozben az appletv-rol merve, ami a hAP-ra van kotve kabelen, 950Mbps korul kapok.
Gondolom a wifi korul tortenhet valami, de nem jovok ra mitol lassul be par nap utan.
Van esetleg valami otlet?A hAP es a cAP cpu-ja se terhelodik nagyon, az L009-et nyilvan nem is erinti a forgalom, a NAS kiadja magabol a 950-et vezeteken nezve, szoval passz.
-
#25524
yodee_
őstag
lionhearted
#25523
yodee_
őstag
válasz
lionhearted
#25523
üzenetére
Értem. Köszönöm akkor ezt hanyagolom.
-
#25523
lionhearted
őstag
yodee_
#25522
-
#25522
yodee_
őstag
lionhearted
#25521
yodee_
őstag
válasz
lionhearted
#25521
üzenetére
Itt nem sebesség probléma van, hanem egyeltalán nem is csatlakozik. A kliens.
-
#25521
lionhearted
őstag
yodee_
#25520
-
#25519
yodee_
őstag
lionhearted
#25518
yodee_
őstag
válasz
lionhearted
#25518
üzenetére
A Router x86 alapú (4 mag/8 szál, 16GB DDR3) erőforrás ott is van bőven. A gond az hogy ha nem a Router a szerver akkor nem tudok 4 klienssel csatlakozni és leterhelni a 10G portot.
-
#25518
lionhearted
őstag
yodee_
#25517
-
#25517
yodee_
őstag
lionhearted
#25516
yodee_
őstag
válasz
lionhearted
#25516
üzenetére
auth-ot nem állítottam, tűzfal csak a windows-os van. Érdekes, de ha a PC a szerver a router a kliens akkor működik. Csak fordítva nem.
-
#25516
lionhearted
őstag
yodee_
#25515
-
yodee_
őstag
válasz
Shkiz0
#25514
üzenetére
Úgy néz ki vaklárma volt, kábel csere után oké a dolog. Viszont ahhoz hogy a nagyobb tempót ki tudjam sajtolni, működésre kellene bírnom a windows-os btest.exe-t. Csak én vagy láma és nem sikerül, vagy nem megoldható hogy a router a szerver és két pc-ről kliensként csatlakozok rá?
-
yodee_
őstag
válasz
Shkiz0
#25488
üzenetére
Megérkezett a switch. Sajnos első nekifutásra nem igazán hozza amit vártam tőle. Rj45 10gbps-en csatlakozik a mikoritk x86-hoz, link sebesség megfelelő. Viszont ha két külön 2,5gb-es porton indítok tesztet akkor még az összesített érték sem éri el a gigabit forgalmat. Kell valami extra beállítás?
-
#25511
user12
őstag
Dr.FantastiK
#25510
user12
őstag
válasz
Dr.FantastiK
#25510
üzenetére
Örülök, hogy meg vagy vele elégedve, sok sikert és kitartast a felfedezéshez és a tanuláshoz
-
#25510
Dr.FantastiK
őstag
Dr.FantastiK
őstag
Nem gondoltam volna hogy van olyan software amire meg en is azt mondom hogy na erre erdemes volt kifizetni a penzt erte !!
a Hardvare mar csak bonusz hozza
Dobbenetes az a kellemes erzes amikor azt latom ezzel foglalkozva volt/van komolyan ! ..nemugy mint a rengeteg buta ASUS DLink tpLink .. -
#25509
user12
őstag
Dr.FantastiK
#25497
user12
őstag
válasz
Dr.FantastiK
#25497
üzenetére
A settings>log menüben tudod megnézni, állítani. alapértelmezésben a memóriába (RAM) logol.
-
#25507
myk_to
csendes tag
lionhearted
#25504
myk_to
csendes tag
válasz
lionhearted
#25504
üzenetére
Most vettem észre a hozzászólásodat. A költség nem lényeges, mert tényleg nagyon ritkán fordul elő, inkább az automatizmus, és a kényelem. Ahogy 25506-ban írtam találtam egy repeater itthon, azzal remekül megcsinálható (a kapcsolódást már teszteltem!) Ha nem vagyok itthon akkor az USB-mobil rákapcsolódást nehezen lehetne megvalósítani (a feleségemnek). ha én vagyok itthon akkor meg a mobilt beáldozni kellene... Szóval én előnyösebbnak tartom a "repeateres tartalék" megoldást.
Neked is köszönöm, hogy törődtél a problémámmal. -
myk_to
csendes tag
Köszönöm válaszodat: Te pontosan megértetted a problémámat. Az ötleted tetszik. Kerestem és találtam itthon egy TP-Link repeatert, mely az általad leírt ötlet megvalósítására alkalmas lesz. Vagyis a jelenlegi pppoe- WAN (ether1-n) mellett beáldozom (az egyébként nem használt) ether2-t. Ide csatlakoztatom a repeaterból kijövő "rescue-net"-et. Az állandóan használt WAN meghibásodása esetén átkapcsolok a "rescue-net"-re mivel nem a AX3 wifijét használom, így az a LANom része lehet függetlenül a WAN forrásától. Időnként ellenörzöm, hogy a "rescue-net" él-e még.
A fentiek beállítását a Routeremen, (előbb-utóbb ) meg tudom csinálni.
Köszönöm mégegyszer! (itt mondok köszönetet E.Kaufmann fórumtársnak is!) -
#25504
lionhearted
őstag
myk_to
#25492
válasz
myk_to
#25492
üzenetére
Nem szoktam teljesen eltérő megoldásokat javasolni, hiszen többnyire fix elképzeléshez keresnek lehetőséget... de van USB rajta, telefon bedug, Ethernet Tethering bekapcs, ott a backup net. Nagyjából annyi kell, hogy felveszed a WAN interface listára (ha úgy írtad meg a tűzfalat, hogy listára vonatkozzon), és innentől egy mozdulatra van. Persze, drágább mint a szomszéd wifijét használni.
-
#25503
mrots
tag
E.Kaufmann
#25502
mrots
tag
válasz
E.Kaufmann
#25502
üzenetére
1. mivel alkalmazkodnia kell a szomszedjahoz, nem lehet kotott a frekvencia
2. erre vonatkozott a kerdese, szerintem a scripteles kevesbe racionalis megoldas valamire, ami eddig 10 ev alatt ketszer fordult elo
3. ezt irtam, hogy szerintem a jo megoldas -
#25501
mrots
tag
E.Kaufmann
#25498
mrots
tag
válasz
E.Kaufmann
#25498
üzenetére
"Ok, folyamatosan fent lesz a szomszéd wifin"
Na de az illeto pont azt irta, hogy normal uzemben mindket wifit hasznalja es nem akarja bealdozni tartalekolasra.
PMTUD és MSS a sztenderd eljárás.
.![;]](http://cdn.rios.hu/dl/s/v1.gif)
És még most sincs leütve. Röviden: Intelt. 
Meg virtualizálás, de a NIC megy direktbe. 
Új hozzászólás Aktív témák
- Asus rog ally X + 2db dock + 512GB micro sd
- Intel Core i5 3470 confidential Ivy bridge Quad Core
- DELL Latitude E7440 Ultrabook i5/8 GB RAM/128 GB SSD/Full HD érintőképernyő
- Gamer PC-Számítógép! Csere-Beszámítás! R7 2700X / 16GB DDR4 / GTX 1080Ti 11GB / 256SSD + 2TB HDD
- Apple iPhone 15 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! GIGABYTE B650M R5 7600 32GB DDR5 1TB SSD RX 9070 16GB NZXT H700 Cooler Master 750W
- BESZÁMÍTÁS! ASUS H510M i7 11700 16GB DDR4 500GB SSD RTX 3060 Ti OC 8GB Zalman Z1 PLUS ADATA 600W
- Xbox One S 512 GB + kontroller 6 hó garancia, számlával!
- OnePlus 12 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- Gamer PC-Számítógép! Csere-Beszámítás! I5 12400F / RTX 3070 8GB / 32GB DDR4 / 1TB SSD
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest