Hirdetés
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- GoodSpeed: Márkaváltás sok-sok év után
- LordAthis: Mission: Imposible? - Együtt 1333 és 1600 MHz, ECC/Non-ECC
- Gurulunk, WAZE?!
- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Samus: Atomic Heart - Egy kis nyafogás
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
-
LOGOUT
Mikrotik routerekkel foglalkozó téma. Mikrotik router típusok, hardverek, router beállítások, programozás (scriptek írása), frissítés, és minden Mikrotik routerrel kapcsolatos beszélgetés helye.
Új hozzászólás Aktív témák
-
ekkold
Topikgazda
válasz
yodee_
#15981
üzenetére
Mobilneten a szolgáltatók valamiért szeretik blokkolni a VPN-ek működését. Természetesen letagadják. Ezért jobb olyan VPN-t használni, amelyik nem fix portokat használ, hanem tetszés szerint állítható, ugyanis ezeket emiatt nehéz blokkolni... itt jön a képbe az openvpn mert az ilyen, csak éppen sokkal lassúbb mint a PPTP / L2TP / ipsec (ezek viszont csak adott porton működnek). Viszont a RouterOs7-be bekerült a wireguard, ami szintén bármelyik porton működhet, és gyors
Gyakran előfordult, hogy olyan helyen interneteztem ahonnan sem PPTP-t sem L2TP-t nem tudtam használni, és így nehezebben értem el pl. az otthoni NAS-t. A wireguard-al viszont működik. -
pzoli888
kezdő
-
ekkold
Topikgazda
válasz
yodee_
#15958
üzenetére
Nálam ehhez hasonló bejegyzés erre kell:
- Van több különféle port kifordítva, pl. egy webszerver, ami a router WAN oldaláról elérhető (skori.spacetechnology.net)
- Hogyha egy LAN címről (mondjuk asztali PC) el akarom érni a webszervert, de úgy hogy nem a belső LAN oldali címére hivatkozok, hanem pl. az előbbi domain névre - ami ugye a WAN oldali címre fordul, akkor a PC a routerhez fog fordulni a kéréssel, hiszen nem lokális címet akar elérni. A router viszont "észreveszi", hogy az a cím (is) a saját címe, és ezért az említett NAT szabály alapján, annak ellenére kiszolgálja a kérést, hogy az eredetileg a WAN oldali címre vonatkozott.
Magyarán, a LAN-on belül is kiszolgálja a NAT kéréseket. Sokak szerint ez így nem működhet, és valóban kicsit fura a dolog logikája, de a gyakorlatban viszont mégis működik a dolog. A Te esetedben, ha mégis meg akarnád tartani ezt a szabályt, akkor úgy kellene módosítani, hogy a VPN címekre ne vonatkozhasson ez a szabály, ha viszont nincs ilyesmire szükséged, akkor nyugodtan törölheted. -
ekkold
Topikgazda
válasz
yodee_
#15950
üzenetére
Nekem hAPac^2-n a PPTP VPN volt a leggyorsabb, az tudott talán 100Mbit körül, az L2TP+IPsec már jóval lassúbb volt, IPsec nélkül meg csak kicsit volt lassúbb a PPTP-nél. A wireguard gyorsabb volt mindegyiknél (nem emlékszem pontosan mekkora sebességet tudott, de biztosan többet mint 100Mbit/s). IPIP + Ipsec és az EOIP+IPsec sem volt igazán jobb sebességben a fentieknél - bár ezekkel nem túl sokat kísérleteztem. Szóval azért nem kell csodát várni ettől a kis routertől, szerintem a gyakorlatban az a 100Mbit körüli VPN sebesség reális. Ha nagyobb sebesség kell akkor vagy a PC-n kell futtatni valamilyen VPN-t, vagy jóval erősebb router kell. Gyanítom, hogy pl. a Wireguard PC-n futtatva, simán tudna közel gigabitet, de ezt nincs módom tesztelni.
-
ekkold
Topikgazda
-
ekkold
Topikgazda
válasz
yodee_
#15892
üzenetére
A közpotni routerbe vegyél fel olyan szabályt ami:
- forward action=log, a forráscím ez egyik másodlagos eszköz, a célcím a másik másodlagos eszköz. A szabályt vidd előre a sorban a drop szabályok elé.
Ebből látszani fog eljut-e a csomag a központi routerbe aminek továbbítania kellene..
-ugyanilyen szabályt vegyél fel fordított irányra is.
Ebből látszani fog eljut-e a válasz csomag a központi routerbe aminek továbbítania kellene..
Ha a szabályokat leszűkíted pl. ICMP protokollra akkor már csak pingelni kell, és nézni, hogy mit logol.A két másodlagos eszközbe pedig hasonló szabályt vehetsz fel ami nem forward, hanem input.
Ezután egy ping szépen lekövethető, hogy hol akad el. -
pzoli888
kezdő
-
ekkold
Topikgazda
válasz
yodee_
#15834
üzenetére
Azért javasoltam, mert nekem csinált olyat a 7.1, hogy hiába vettem fel a routing szabályt, az nem működött. Újraindítás után viszont magától megjavult. A 7.1.1-nél nem tapasztaltam ilyet.
Amúgy meg naplózni kellene, hogy meddig jutnak el a csomagok, akár naplózó tűzfalszabályokat felvenni erre a célra. Csak kiderül, hogy hol akad el.
-
pzoli888
kezdő
válasz
yodee_
#15815
üzenetére
lehet mind a három router tűzfal szabályaiban, ahol az action =drop és a chain= forward vagy input szerepel ott be kellene kapcsolni a log-ot (akár log prefix is legyen: külön prefix input-ra és külön prefix forward szabályra), és megint traceroute-olni a rossz irányt, majd ezek után megnézni, hogy vmilyik router logjában látsz-e vmit, és ha látsz vmilyen logot ezekkel kapcsolatban, akkor tűzfal gond lesz a hiba.
-
ekkold
Topikgazda
válasz
yodee_
#15794
üzenetére
Igen ilyesmi kellene. Gyakorlatilag 4db különböző IP tartománynak kell lennie:
- Fő router
- 1. külső router
- 2. külső router
- VPN címtartománya
(ha wireguard-al oldanád meg akkor 5db IP tartomány kellene, mert a wireguard interfészek tapasztalatom szerint nem működnek jól, ha közös IP tartományban vannak)
- Mindhárom routeren két static routing-ot kell felvenni, (a másik két eszköz felé).
- A VPN címtartományára elvileg létrejön dinamikus routing szabály (de ha nem, vagy ha nem megfelelően akkor az is kell)- A 13.0.0.0/24 IP tartományok szerintem sem célszerűek belső IP céljára.
-
-
pzoli888
kezdő
válasz
yodee_
#15791
üzenetére
a két külső router ip/routes részében fel kell venni a másik külső routernél található hálózatot és beállítani a l2tp interface-t a gatewaynek.
1. külső router:
ip route add dst-address=<a 2. külső router hálózata. pl. 192.168.12.0/24> gateway=<lt2p interface neve a főrouter felé>
2. külső router
ip route add dst-address=<az 1. külső router hálózata. pl. 192.168.33.0/24> gateway=<lt2p interface neve a főrouter felé> -
E.Kaufmann
veterán
válasz
yodee_
#15528
üzenetére
Úgy, hogy IPv6 esetén a szolgáltatók nem csak a routerek adnak egy IPv6 címet, hanem jobb esetben akár egy /56-os vagy /48-as tartományt (ezek továbboszthatóak több /64-es netmaszku) alhálóra, de legrosszabb esetben is kapsz egy /64-est, ami egy alhálót lefed, bár elvileg mintha ez is továbbosztható lenne, de egyes címkiosztó metódusokat ellehetetleníti és nagy macera, ha lehetséges a dolog.
Ha portforward nem is kell, de azért tűzfalat még nyitni kellhet. Valamint ami nekem egy szimpi opció, már ha a router tudja (igazából én is csak olvastam róla) a Network Prefix Translation, mikor csak a hálózat cím részt cserélik, az àllomás azonosítója (gondolom az általunk kiosztott alhálózat azonosítóval együtt) megmarad, így nem kell portszámokat jegyzetelnie a routerek belülről kezdeményezett kapcsolat áll sem, valamint a multiWAN-t is megkönnyíti. -
adika4444
addikt
válasz
yodee_
#15525
üzenetére
Perpill szerintem konkrét szükség nincs rá, én azért szeretem, mert sokszor eltérő - jellemzően kevésbé terhelt - routing útvonalakat használ, mint az IPv4.
Meg amúgy is. Ha már van, és elérhető, ki akarom használni
Megoldódott amúgy, valamiért automatikusan az add-default-route ellenére kézzel kellett felvenni a route-t, azóta teljesen jó.
-
Lenry
félisten
-
ekkold
Topikgazda
válasz
yodee_
#13823
üzenetére
Ha csinálsz külön profilt a PPPOE kapcsolathoz, ott is meg lehet adni scriptet, amit lefuttat, a kapcsolat felépülésekor, illetve a kapcsolat bontásakor egy másikat. Ide lehet betenni pl.
:delay 30
/system script run dyndnsupdate.rsc
Igazából ilyenkor az időzített futtatásra sincs feltétlenül szükség.Amúgy a freedns-t nagyon régóta használom, a mikrotik frissíti az IP-t, és eddig teljesen megbízható, nem kellett adott időnként bejelntkezni sem az oldalra. Ezen kívül a mikrotik IP cloud-ja is jól működik. Amíg van ingyen ilyesmi addig miért fizetnék érte.
Pl. a https://skori.spacetechnology.net/ címemre simán tudtam a szerverre ingyenes (let's encrypt) https tanusítványt is kérni, így a böngészők is biztonságosnak ítélik az oldalt, a dinamikus IP cím ellenére. -
ekkold
Topikgazda
válasz
yodee_
#13817
üzenetére
PPPOE esetén be kell tenni az OnUp scriptbe, így akkor fut le amikor felépül a PPPOE kapcsolat. Sima DHCP-s kapcsolat esetén, a DHCP kliensnél lehet hasonlóképpen scriptet betenni. A script elejébe érdemes betenni egy kis delay-t, hogy várjon amíg a kapcsolat használható lesz.
-
Lenry
félisten
válasz
yodee_
#13812
üzenetére
az intervalt leveszed 00:00:00-ra
de ekkor csak újrainduláskor fog lefutni. ha azt is szeretnéd, hogy óránként lefusson, akkor vegyél fel egy második schedule-t, ami meg óránként frissít, annak a Start Time-ja ne Startup legyen, hanem valami tetszőleges időpont
vagy használd a Mikrotik saját dyndns szolgáltatását: IP -> Cloud
-
bacus
őstag
válasz
yodee_
#13597
üzenetére
tools - netwatch
hozzáadod a figyelni kívánt ip címet, amikor él akkor up statuszban lesz, ebből következik, hogy a a down fülre megy a script
ez addig fog renew-t csinálni, amíg nem elérhető a figyelt ip, a timeout ne legyen kicsi, legyen idő helyreállni a kapcsolatnak, azaz 5-10 mp alá ne menj.
-
ekkold
Topikgazda
válasz
yodee_
#13591
üzenetére
Nem biztos, hogy elegendő a script neve.
Ha a scriptek között van tárolva akkor pl.:
/system script run dyndnsscript.rsc
vagy ha a fájl tárolóban van a script akkor pl.:
import file-name=flash/dyndnsscript.rscHa több DHCP kliens is be van állítva az eszközön akkor a nulla helyén az adott interfészre vonatkozó DHCP kliens listában elfoglalt helyének a sorszáma kell.
/ip dhcp-client renew 0Persze az is kérdés, hogy a renew egyáltalán megoldja-e a problémát. De ha kipróbálod akkor kiderül.... Elképzelhető olyan megoldás is, hogy mondjuk minden éjfélkor letiltod az ETH1 interfészt mondjuk 10 másodpercre, majd újra engedélyezed.
-
Reggie0
félisten
-
Beniii06
addikt
válasz
yodee_
#13388
üzenetére
Nem hinném, akkor már ami hiba maradt hogy a kliens aminek a portot nyitod dhcp-n kap ip-t és nem statikusan/ a dst nat szabály nincs teljesen kitöltve vagy lehet bug is a huaweien. Nekem B525-el így működött mikrotikkel, azon nincs bridge mód, de az általam leírt módokon működött a port nyitás.
-
Beniii06
addikt
válasz
yodee_
#13383
üzenetére
A huaweien "net" van beírva APN-nek? Ha nem akkor írd át + Dinamikus helyett statikus ip-vel csatlakozzon a mikrotik a huaweire és a huawein arra az ip-re kapcsold be a DMZ-t + ha van a firewall részen tűzfal típus választási lehetőség akkor próbáld ki a másikkal is(core és dynamic van ha jól emlékszem)
+ a hap ac2-n a képen látható dst-nat szabályoknál nézd meg, hogy az action fülön is kitöltötted a dstnat port és ip mezőket helyesen.
-
Reggie0
félisten
válasz
yodee_
#13305
üzenetére
Sajnos kicsit csokevenyes az ovpn szerver a mikrotikben, es igy a kliensnek nem tud extra routing szabalyokat lekuldeni. Igy harom megoldas van:
0. beallitod manualisan a kliensben a routing tablat
1. beallitod a kliens konfigban, hogy a vpn szervert rakja be default route-nak, de ekkor a kliens osszes netes forgaloma atmegy az ovpn szerver fele
2. olyan netmaskkal osztod ki az ovpn kliensnek az ipcimet, amibe a halozatodon levo tobbi cim is beleesik, azaz a te esetedben 255.255.0.0-val es akkor elmeletem szerint a router at fogja routeolni, de ezt ki kell probalni, nem vagyok biztos benne, lehet meg 1-2 dolgot be kell allitani hozza.Mellesleg: 13.x.x.x cimeket ne hasznaljal, mert az az interneten letezo cimtartomany, LAN-ra az 10.0.0.0/8, 172.16.0.0/12 es 192.168.0.0/16 van. A 13.0.0.0/12 konkretan a xerox-hoz tartozik.
-
amargo
addikt
-
ekkold
Topikgazda
válasz
yodee_
#12032
üzenetére
Lenry válaszát kiegészíteném azzal, hogy az rsc fájlt mindenképpen érdemes megnyitni, és szerkeszteni ha más eszközre akarod átvinni. Ugyanis a MAC addresseket is átmásolja, és így a régi, és az új eszköz ütközhet, ha azonos hálózatba kerülnek. Tehát a script MAC addresseket beállító részeit érdemes kiszedni, vagy átírni.
-
Lenry
félisten
válasz
yodee_
#12032
üzenetére
nagyon dióhéjban:
belépsz a régi routerbe, nyitsz egy termináltexport file=konfig.rsc
ezt aztán letöltöd a gépedre, belépsz az új routerbe, oda feltöltöd, terminálimport file=konfig.rscaz rsc fájl egyszerű szöveges scriptfájl ami azokat a terminál parancsokat tartalmazza, amiket sorrendben lefuttatva, be lehet konfigolni a routert az aktuálissal megegyező állapotba, szóval még az újba való feltöltés előtt megnyithatod akár egy sima jegyzettömbbel is, és ha valamit másképp szeretnél az újban, akkor itt át tudod írni.
fontos, hogy a routerbe való belépéshez szükséges usernevet és jelszót nem tartalmazza, így azt kézzel kell majd beállítani, minden más jelszót (WiFi, VPN, stb) viszont igen, úgyhogy ne nagyon oszd meg senkivel
-
Adamo_sx
aktív tag
válasz
yodee_
#11506
üzenetére
Hát, passz, nem tudom, hogy ez elég-e (lehet, hogy igen). Még annyi ötletem van, hogy mindkét oldalon megnézném konkrétan menet közben, hogy biztosan nem az eszközök a szűk keresztmetszet. A routeren is, meg a gépen is (gondolom a task managerben látszik, ha elfogy a teljesítmény).
-
Adamo_sx
aktív tag
válasz
yodee_
#11500
üzenetére
Nézz egy terhelést a routeren, miközben másolsz a titkosított VPN-en. Ha az magas, akkor nem támogatott titkosítást választottál az IPsec-hez. Ha ezek rendben vannak, akkor - szerintem - nem a routerednél lesz a hiba.
-
vargalex
félisten
Ha visszaköveted az ottani beszélgetést, akkor nagyjából olyanból indult ki a kolléga tesztelgetése, hogy sok router a 300 Mbps-es torrent seed mellett már nem tudja a gigabit letöltést produkálni, vagy csak nagyon magas load mellett. Nekem ez nem szempont, de ott többek számára valamiért ez a legfontosabb.
Arra nem válaszoltál, hogy van valahol szintén gigabites kapcsolaton egy szervered amivel iperf3-al tudsz mérni? A le/feltöltést úgy írtad, hogy az iperf3 client módja (természetesen -R kapcsoló nélkül) a sender (azaz a feltöltő)? -
vargalex
félisten
A Milyen routert topicban masszív torrentezős tapasztalatra lennének kíváncsiak.

Egyébként van valahol egy szintén legalább gigabites net mögött csücsülő szervered? -
#42556672
törölt tag
Ez egy jó kérdés! A Wifi sebessége és az AP-Router sebessége az két dolog. Az én konfigomban megvan az általam igényelt sebesség. Az AP-k wifi-s összekötésének sávszélességet érintő negatív hatásai nálam nincsenek.
De őszinte leszek! Én csak akkor mérek ha valami nem tetszik, egyáltalán nem érdekel a sebesség elméleti maximuma amíg nem akad a video, tudok VoIP-t használni, a biztonsági kamerák képe rendben van és ezeket akár egyszerre is használhatom. File transfer-t ha nagy a mennyiség csak LAN-on csinálok. Így, hogy őszinte legyek fogalmam sincs, hogy mennyit tudnék belőle kicsiholni. Nem piszkálom naponta, egy éve beállítottam és azóta használom.
-
#42556672
törölt tag
Tudsz! Ráadásul 1 SSID lehet mindkét sávra. A load balance segítségével megoldhatod, hogy ha sokan vagytok és 2 AP is jó térerővel látszik egyenlően ossza el a klienseket egymás között. Nagyon sokat tud! Érdemes utánaolvasni!
Ha nem is kell AC akkor is CAP AC-t vagy HAP AC^2-t javaslok a körülményektől függően.
-
ekkold
Topikgazda
Rendben, de akkor kezdjük a nulláról.
Tehát tölts le egy winbox-ot - ha eddig még nem tetted.
- A PC-nek adj fix ip-t, hogy induláskor ne kelljen DHCP-re várakozni, pl. IP: 192.168.5.12 MASK: 255.255.255.0 GW: 192.168.5.1
- Ellenőrizd, hogy a PCről eléred-e a mikrotiket winbox-al MAC adress alapon.
- Utána winbox-ból SYSTEM / Reset Configuration, No default config bejelölve, és hadd szóljon.
- Ha ujraindult nem lesz IP címe, csak winbox-al éred el MAC alapon.
- Állíts be egy jelszót az eléréshez, és csatlakozz ujra. (system/password)
- Létrehozol egy bridge-t (Bridge menü + gomb)
- Beleteszed a bridge-be (Bridge menü - Port) az EHT2, ETH3,ETH4 és ETH5 portokat (tehát amik a LAN portok lesznek - amúgy vedd észre, csak a konfigon múlik melyik lesz LAN és melyik lesz a WAN port!)
- IP menü: adsz egy IP címet a bridge -nek 192.168.5.1/24 (ha esetleg nem tudod a /24 a netmask-ot adja meg - nem windows oprendszerek alaltt)Ha megvan - folytassuk innen.
-
ekkold
Topikgazda
Ha a konfigot törlöd, ne használj default konfigot, az az egység sugarú userek kedvéért van. Ami kell neked WAN oldal: PPPOE beállítása, LAN oldal: LAN portokat bridge-be tenni, bridge IP beállítása, DHCP szerver beállítása, NAT-olás beállítása. Ezután már lesz internet. Persze még némi tűzfal konfig sem árt.
Utána jöhet a többi pl. wifi beállítás, port-forward, VPN, stb....Ha pedig bizonyos oldalak nem jönnek be: akkor olvass bele ebbe
Új hozzászólás Aktív témák
- WoW avagy World of Warcraft -=MMORPG=-
- Xiaomi 15 Ultra - kamera, telefon
- Hálózati / IP kamera
- AMD vs. INTEL vs. NVIDIA
- Autós topik
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Azonnali fáradt gőzös kérdések órája
- Konteó topic
- Samsung Galaxy A56 - megbízható középszerűség
- További aktív témák...
- Segway Ninebot KickScooter D18E
- Apple Watch Ultra 3 2025 - rendelhető!
- BESZÁMÍTÁS! MSI Thin A15 B7VE Gamer notebook - R5 7535HS 16GB DDR5 512GB SSD RTX 4050 6GB WIN11
- BESZÁMÍTÁS! MSI Bravo 15 C7VF Gamer notebook - R7 7735HS 24GB DDR5 2TB SSD RTX 4060 8GB WIN11
- iPhone 14 128GB karcmentes, magánszemélytől
- Xiaomi Mi 10T Pro 256GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 12 64GB Black-1 ÉV GARANCIA - Kártyafüggetlen, MS3653,100% Akkumulátor
- 2025.11.22 - Frissített Lenovo Gamer árlista (RTX 5090 / 4090 / 5080 / 4080 / 5070Ti / 4070 / 5060)
- Motorola Edge 40 / 8/256 GB / Kártyafüggetlen / 12Hó Garancia
- ÁRGARANCIA!Épített KomPhone Ryzen 5 9600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi

ekkold
