-
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
-
Lenry
félisten
válasz
yodee_
#16108
üzenetére
1280 a WAN bridge (ezt nem is tudom állítani)
1200-ra vettem le a WG-étannyit még hozzá kell tenni, hogy külön interface-t csináltam végül ennek a kapcsolatnak, tehát most a két WireGuard kapcsolat két külön WG interface-en fut.
(nem tudom, hogy ez befolyásol-e bármit, de gondoltam leírom) -
Audience
aktív tag
válasz
yodee_
#16086
üzenetére
Én csináltam egy bridge-et hozzá raktam egy portot és összekötöttem még egy kábellel a HGW-t és a router-t, a TV-nél lévő Mikrotikre is tettem egy plus bridge-et, két portot hozzá adtam és a két bridge-et EoIP tunel-lel összekötöttem. így ha ott a megfelelő portra csatlakozom látom a HGW-t, a másik porton a set top box lóg.
-
Audience
aktív tag
válasz
yodee_
#16081
üzenetére
Nekem a Cloud szolgáltató miatt is le kellett vennem az MTU-t, Hollandiai adatközpontot használok, ebből ennyi jön ki. Néha felmegy 200Mbps-ig de az a plafon. Ha nagyobb VM-re áttenném a CHR-t lehet, hogy lehetne még faragni de amire használom arra már így is bőven jó.
-
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é> -
#15529
E.Kaufmann
veterán
yodee_
#15528
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ó.
-
-
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.
Új hozzászólás Aktív témák
ekkold- GYÖNYÖRŰ iPhone 12 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3195, 95% Akkumulátor
- KARÁCSONYI AKCIÓK / MICROSOFT WINDOWS 10,11 / OFFICE 16,19,21,24 / VÍRUS,VPN VÉDELEM / SZÁMLA / 0-24
- iPhone 13 Pro 128GB 100% (1év Garancia)
- Pixel 7 pro 128/8
- Dell Latitude 5430 14" Touchscreen i5-1235U 16GB 512GB 1 év garancia
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest