- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Vivo X200 Pro - a kétszázát!
- Milyen okostelefont vegyek?
- iPhone topik
- Poco X5 Pro - ránézésre jó
- Szinte játékpénzért megvehető a Honor Play 10C
- Google Pixel topik
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Azonnali navigációs kérdések órája
Hirdetés
-
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
-
ekkold
Topikgazda
A hAPac^2-ből volt olyan széra amibe nem 128Mb, hanem 256Mb RAM került. Ezekre felmegy a wave pkg. Nekem is ilyen van, majd valamikor kipróbálom.
Amúgy a sima WPA-t is nagyon nehéz feltörni, a WPA2-t pedig méginkább. Ha hosszú, és nem faék egyszerűségű jelszót használsz, akkor gyakorlatilag esélytelen a feltörése. Persze a pin kódos csatlakozási lehetőséget is érdemes kikapcsolni, mert a WPA/WPA2 is többnyire csak is ezen át törhető fel értelmes idő alatt.
Ezzel arra céloztam, hogy jelenleg szerintem még nem érdemes különösebben a WPA3-ra hajtani. -
ekkold
Topikgazda
Csakhogy pixelhiba estén pontosan leírják (nam csak a gyártó, hanem a forgalmazó illetve a kisker. is), hogy mi számít garanciális hibának és mi nem. SSD /HDD esetén a kiskernél nincs ilyen, és szerintem mikrotiknél sem.
Monitort egyébként nem vennék olyan cégtől aki pixelhiba esetén nem cseréli (merthogy van olyan cég, amelyik pixelhiba estén is kicseréli)...
Magánszemélyként pedig egyszerűen indoklás nélkül elállnék... és vennék másikat.Egyébként vettem már úgy cégnévre monitort, hogy az egyik pixelhibás volt, felhívtam őket, hogy akkor most mi van... Azt mondták ugyan nem garanciális hiba, de ha szeretném akkor kicserélik. Szerettem volna. Kicserélték. Ezért aztán máskor is vásárolok tőlük, mert tudom, hogy korrektek.
-
ekkold
Topikgazda
válasz
momcrew #15462 üzenetére
Csakhogy nekem nem a mikrotiknél van garanciám, hanem egy magyar üzletben. Ha nem 0,0% a bad block, akkor a termék nem 100%-os, amit kaptam. Ha nincs ettől eltérő megadva a garanciális feltételek között, akkor ez hibás termék. Pl. ha vennél egy SSD-t, vagyHDD-t, amin csak 0,1% hibás szektor van, Te sem örülnél neki, még akkor sem ha azt mondanák, hogy ugyan már, ennyi simán belefér.
-
ekkold
Topikgazda
válasz
Reggie0 #15457 üzenetére
Köszönöm, hogy felhívtad a figyelmem erre! Megint tanultam valamit!
Lehet, hogy ez a 7-es routerOS-el jött? Mert a show-sensitive nélkül a wifi jelszavakat sem menti. Ez annyiból ügyes, hogy ha csak meg akarod mutatni a konfigot pl. egy fórumban, akkor lehet jelszavak nélkül is exportálni, de azért jelszavakat tartalmazó mentést is lehet készíteni vele. -
ekkold
Topikgazda
A backup mindent ment, de ugye van, amikor nem mindent akarunk átvinni a másik eszközre. Az export menti a PPP jelszavakat (VPN-t és PPOE-t is), a wifi jelszavakat is, ipsec kulcsot is, logikus lett volna ha a wireguardot is lehetett volna úgy exportálni, hogy abból visszaállítható legyen a kapcsolat. Persze script-el meg lehetne oldani...
-
ekkold
Topikgazda
Szerettem volna átvinni másik routerre a wireguard beállításait, ezért próbáltam export paranccsal kimenteni. Nos az export a private key-t nem menti, így az exportált beállítások alapján, másik eszközön nem reprodukálható ugyanúgy az adott kapcsolat, új private key-t fog generálni ahhoz viszont a régi peer-ek nem tudnak majd csatlakozni, mert a public key is változik emiatt. Vagy "kézzel" kell átmásolni mindegyik private key-t a másik routerre (vagy utólag kézzel beleírni az exportba).
(Csak zárójelben: a windows-os wireguardból pl. minden további nélkül exportálhatók a beállítások.)
-
ekkold
Topikgazda
válasz
Pizzafutar #15446 üzenetére
Nekem pár perce jött meg az 5009, bár még nem volt időm bekapcsolni sem.
-
ekkold
Topikgazda
válasz
szuszinho #15358 üzenetére
Egy AP-ként használt cAPac-ra raktam fel próbaképpen az RC verziót, ezen megy a wireguard, aminek az UDP portját egy hAPac fordítja ki a net felé. Windowsos wireguard klienssel egy ideje rendszeresen használom. Teszi a dolgát, ahogy kell, minden más VPN-nél gyorsabb amiket eddig használtam.
-
ekkold
Topikgazda
Most akkor a 7.1 (Testing), vagy a 7.1rc7 (Development) van közelebb a stabil verzióhoz? Csak én nem értem a dolog logikáját?
-
ekkold
Topikgazda
A közeljövőben tervezem, hogy több VPN kapcsolatomat lecserélem wireguard-ra. Jelenleg L2TP és PPTP VPN-t használok, mikrotik-mikrotik, és windows kliens - mikrotik szerver felállásban.
A wireaguard-al a fentiektől eltérően, a szerver oldalon nem tudom pont-multipont szerű módon kialakítani a kapcsolatokat, hanem sok pont-pont kapcsolat kell, másképp fogalmazva minden egyes kapcsolathoz külön wireguard interfészt kell létrehozni a mikrotikben, és minden egyes interfészhez külön UDP portot kell nyitni. Az intefészeknek ráadásul statikusan kell IP címet adni.
Arra lennék kíváncsi, hogy ki milyen stratégiával osztaná ki a z IP címeket, és az UDP portokat, hogy az egész megoldás hosszú távon is logikus és átlátható maradjon? -
ekkold
Topikgazda
Akkor mégegyszer ideírom, hogy egyértelmű legyen: a Parancssor vs. GUI vitát ne itt folytassuk. Az ezzel kapcsolatos hozzászólások a jövőben figyelmeztetés nélkül törölve lesznek.
-
ekkold
Topikgazda
válasz
Apollyon #14886 üzenetére
Szerintem a WireGuard esetében a jó hosszú kulcspárok parancssorba gépelése eleve csak mazohistáknak való, csak a copy/paste a járható megoldás. A dolog filozófiáját értem, sokszor egyet is értek vele, de ebben az esetben pl. nem. Mint ahogy linuxban is használok grafikus felületet, a video playert sem parancssorból indítom, vagy a képeryő felbontást is grafikus felületen konfigurálom, és használok pl. kétpaneles fájlkezelőt is, egyszerűen azért mert kényelmesebb.
-
ekkold
Topikgazda
válasz
adika4444 #14884 üzenetére
Az lesz, de most még csak kísérleti fázisban van a dolog
A windows kliensen javítottak valamit a napokban. Frissült, és most olyan helyről is működik, ahonnét eddig nem működött.
A linux kliens jó, de valami grafikus felületet nem áratana hozzá. Manapság ennek nem kellene problémának lennie - ha a mikrotiken futó RouterOS esetén (ami tulajdonképpen egy linux) megoldható volt, hogy viszonylag kényelmesen konfigurálható legyen, akkor nem értem, hogy a PC-s linuxokon miért kell parancssorral sz@rakodni. Persze nyilván megoldható azzal is, de a mikrotiken sem véletlenül használjuk szívesebben a winbox-ot, mint a parancssoros konfigurálást (legalábbis a többség - mert nyilván akad kivétel). -
ekkold
Topikgazda
válasz
adika4444 #14878 üzenetére
Adott kulcsot több kliensbe is lehet importálni, de ezek a kliensek (ha az IP-ket különbözőre állítom) működhetnek egyszerre is?
Tehát ha a mikrotikbe egyetlen wireguard interfész, és ehhez egyetlen peer van felvéve, de ennek a titkos kulcsa több PC-n is megvan, akkor ezek vajon kapcsolódhatnak-e egyszerre, vagy minden PC számára külön peer-t kell beállítani? -
ekkold
Topikgazda
válasz
Beniii06 #14850 üzenetére
A leírt felállás szerinti állapotban (gyakorlatilag mindkét oldal NAT mögött) és az internetet megosztva a VPN-en keresztül, kb. 150....180Mbit/s sebességet mértem a speedtest.net -en.
Egy erősebb router valószínűleg ennél többre is képes lehet, főleg ha nincs NAT mögött, de a fő routeremre egyelőre nem mertem feltenni egy rc4-es OS-t. Így is kapásból találtam bug-ot az rc4-ben, ugyanis a cAPac-n azóta nem működik pl. az email küldés (közvetlenül a frissítés előtt még működött).
-
ekkold
Topikgazda
válasz
ekkold #14820 üzenetére
Tulajdonképpen magamnak válaszolok, de esetleg más is érdekelhet: Kipróbáltam a WireGuardot mikrotik szerver - PC kliens (Mac és Win) felállásban. A mikortik szerver egy cAPac volt amire feltettem a RouterOS 7.1rc4-et, ez AP-ként funkcionál itthon, a fő router hAPac2, ami forwardolja a WireGuard UDP portját a net felé. Az így elérhető sebesség lényegesen nagyobb volt, mint bármilyen más, általam eddig kipróbált VPN esetében - tehát úgy tűnik érdemes lesz használni.
-
ekkold
Topikgazda
válasz
E.Kaufmann #14822 üzenetére
Igen, még a frissítés előtt le volt lőve az IPv6, és meg is maradt ez a beállítás (is) a frissítés után. Egy barátom is frissítette a cAPac-t otthon, neki meghalt a cucc... majd holnap megpróbálja netinstallal életre kelteni...
-
ekkold
Topikgazda
Az egyik AP-re feltettem a RouterOS 7.1rc4-et.
Mindjárt meg is van az első hiba: nem megy az email küldés, timeout hibát ír a log-ba. A frissítés előtt lefuttattam a backup-ot emailben elküldő scriptet - akkor még működött. -
ekkold
Topikgazda
Próbálgatom a WireGuard-ot, tud valaki segíteni itt: [link]
Igazából nem tudom eldönteni, hogy mikrotik, windows, wireguard, vagy user errror... -
ekkold
Topikgazda
válasz
allnickused #14785 üzenetére
Melyik módszerrel raktad fel a 7-es RouterOS-t?
Simán felmásoltad és restart (vagy ez rc verzió esetén nem megy?), vagy netinstallt használtál?
Közben még kísérleteztem a virtuális PC-ken, és rájöttem, hogy nem csak peer-to-peer módon, hanem akár kliens-szerver alapon is működik a wireguard, tehát lehet, hogy mégis működne a NAT mögötti win10 és a mikrotik közötti kapcsolat. -
ekkold
Topikgazda
válasz
allnickused #14785 üzenetére
Azthiszem az élesben használt routeremre mégsem rakom fel a 7-es RouterOS-t. A wireguardot kipróbáltam két virtuális PC között, az egyik win7-el, a másik linux-al. Végülis működik, összeáll a kapcsolat, de még van mit fejlődnie a klienseknek. Viszont arra amire nekem kellett volna (NAT mögött levő win10-el kapcsolódni mikrotikhez) nem lesz jó, mert ahhoz ki kellene fordítani a win10 által használt UDP portot - amire viszont nincs lehetőségem.
-
ekkold
Topikgazda
Sziasztok, hAPac^2-re rakott már fel valaki 7-es RouterOs-t? Működik rajta rendben, konfig megmarad ha frissítek?
Wireguard-ot próbálta már valaki beizzítani rajta? Win10-el (NAT mögött) szeretnék csatlakozni a hAPac^2-hez. Ahol most vagyok innen nem működik sem a PPTP (GRE nem megy át a hálón) sem az L2TP VPN (csatlakozik, ping megy de nincs adatforgalom,) . Arra gondoltam, hogy mivel a wireguard elvileg bármilyen porton mehet, azzal nem lenne gond.
Van rá esély, hogy wireguard-al kiváltsam a jelenlegi VPN-t?Esetleg tegyek valamelyik AP-re (caAPac) 7-es RouterOs-t, és a fő routerrel csak továbbítsam a portot?
-
ekkold
Topikgazda
válasz
Mr Dini #14667 üzenetére
Hiába használ valaki azonos IP-t, mint ami a VPN hálózatban van, mivel a routing miatt nem fog eljutni hozzá a válasz csomag.
A WAN interfész felől lehet tiltani a router elérését, ha ez a szabály előrébb van, mint ami IP alapján engedi, akkor a wan felől nem lehet hekkelni ilyen módon.
A feketelistás megoldás simán megvéd a brute-force töréstől, 90mp alatt nem lehet túl sok jelszót kipróbálni... Port kopogtatást sem bonyolult kezelni.
-
ekkold
Topikgazda
válasz
Mr Dini #14664 üzenetére
Igazából a mikrotikben levő összes interfész (a virtuálisak is) elérhetik a router szolgáltatásait (hiszen abban a routerben vannak) kivéve ha tűzfalszabállyal letiltottad.
De konkrétan az adott VPN kliensnek is adhatsz fixen kiosztott IP-t, és arra az 1db IP-re is felvehetsz engedélyt, hogy elérje a winbox portját a routerben.
De ha nagyon erősen akarod védeni (szerintem a VPN hálózatán belül nem kell) akkor valamilyen port kopogtatással is kiegészítheted, hogy csak megfelelő portok koppintása esetén nyissa ki a 8291-es portot a VPN kliens IP címe felé.Mondjuk én szükség esetén inkább a VPN-t védeném még erősebben, mondjuk port kopogtatással. De én IP lista alapú védelmet használok, amin gyorsan és könnyen feketelistára lehet kerülni - sokféle szempont alapján. Pl. aki Telneten, SSH-n próbálja elérni a routert kapásból feketelistára kerül a címe... így a VPN-t már ki sem tudja próbálni. A kopogtatás egy speciális megoldását fehérlistához használom, afféle tartalékként, ha netán saját magam is feketelistára kerülnék valamiért.
A VPN-t azzal is védem, hogy aki a portra csatlakozást követő 90 másodpercen belül nem ad meg helyes jelszót, annak is feketelistára kerül az IP-je, így eleve nem tud egy hekker túl sokat próbálkozni.
-
ekkold
Topikgazda
Igazából find nélkül is működik a törlés:
# várakozás, majd a backup fájlok törlése a router tárolójából
:delay 50
/file remove "$filename.rsc"
/file remove "$filename.backup"Annyi az eltérés, hogy én nem csak backup-ot csinálok, hanem exportot is (van amikor az az előnyösebb), és mailban küldöm. De ez fent van a weblapomon is.
Egyébként a routerek egy része esetében van /flash alkönyvtár, ami valóban a flash-en van tárolva, a gyökérkönyvtár viszont RAMdiszk, ami nem írodik a flash-re (és erre a célra ez a jobb megoldás). -
ekkold
Topikgazda
A random hardware cím opciót is a hajára kenheti bárki, ha mondjuk csak adott MAC addresseket szolgál ki a rendszer (akik fel vannak véve a listába), minden más MAC address-t mondjuk korlátozott jogú vendégként kezel.
De wifin pl. használható wpa2-entrprise tehát, nem csak jelszó, hanem usernév/jelszó páros kell a belépéshez - bár ezzel még nem kísérleteztem. De így bármilyen MAC address vagy IP lehet, akkor is be van azonosítva. Ethernetem meg mondjuk PPPOE, ha nagyon muszáj... -
ekkold
Topikgazda
válasz
adika4444 #14406 üzenetére
Ha MAC address-re veszi fel a tiltást, azt jóval nehezebb megkerülni. Bár emlékeim szerint linux alatt rel. könnyű megváltoztatni a MAC címet. Windows nem tudom, hogy enged-e ilyesmit.
A mikrotik bekonfigurálható úgy is, hogy csak a DHCP klienseket szolgálja ki, azaz ha nem kér DHCP-től IP címet, hanem statikusat állít be, akkor nem áll szóba vele a router, és nem továbbítja az IP csomagjait sem a switch része, LAN-on belül sem (mert nem lesz benne az ARP táblában).
-
ekkold
Topikgazda
válasz
Shkiz0 #14310 üzenetére
A superchannelt nem kellene ajánlgatni, főleg egy kezdőnek nem. Ugyanis az tesztelésre való, és nem veszi figyelembe az adott országban érvényes wifi-re vonatkozó szabályokat ill. törvényeket. Ha történetesen sikerül, pl. egy elhibázott frekibeállítással, zavarnia vele valami olyasmit, amit nem kellene, akkor esetleg az NMHH fog bekopogtatni hozzá...
-
ekkold
Topikgazda
válasz
Statikus #14344 üzenetére
Most akkor sima hAPac-d van? Ha igen, azzal nem fog menni a gigabit, régi tipus, egyszerűen gyenge a proci hozzá, sima egy magos 720MHz-es. Nekem is van két ilyen, AP-nek használom, nem sebességbajnok, de stabil, megbízható.
A hAPac^2 ami már tudja a gigabitet erőből is (bár akkor nagyon pörög a proci) fasttrack-al meg kényelmesen megy alacsony prociterheléssel. Kb ez a minimum mikrotikből ha gigabitet akar valaki. De ebben 4 x 700Mhz proci van.
A következőm, ennél erősebb eszköz az RB4011...
-
ekkold
Topikgazda
válasz
Statikus #14204 üzenetére
Az alapkérdésedre válaszolva:
A windowsok által ismert VPN, és a mikrotik által ismert VPN, közös halmaza a PPTP és az L2TP+ipsec típusú VPN.
Az SSTP-t is ismeri mindkettő, de nehéz közös nevezőre hozni, és lassú is, ezért nem javasolt.
A PPTP-t biztonsági okokból nem szokták javasolni, de amúgy jól működik, realtíve gyors is (én szoktam használni).
Az L2TP+ipsec csak kicsit lassúbb mint a PPTP de jobb titkosítást ill. biztonságot nyújt.
Tehát ezeket érdemes beállítanod a mikrotiken. -
ekkold
Topikgazda
válasz
Statikus #14243 üzenetére
Az, hogy VPN-el tudsz kapcsolódni a routerhez eléggé nyilvánvalóan azt jelenti hogy a routeren fut valamilyen VPN szolgáltatás.
Beraktál egy windows-os képernyőképet, ezen van egy olyan mező, hogy "Virtuális magánhálózat típusa". Itt az automatikus beállításon kívül kiválasztható párféle VPN protokoll, tehát kipróbálhatod melyik beállítással tudsz kapcsolódni, így meglesz a VPN típusa is.A másik lehetőség ha a router menüjében megnézed a PPP/active connections fülön hogy ki és milyen VPN-t használva csatlakozott.
A "quick set" egy lépésben bekapcsolja a dynDNS-t és a VPN-t is (esetleg többféle VPN-t is). A kiírás a menüben egyszerűsítve van az egység sugarú júzerek kedvéért, mert nem akarják megzavarni őket a túl sok infóval. Ennél pontosabb választ azért nem kaptál, mert itt a többség egyszerűen nem használja a quick set menüt, mert nincs rá szükségük, vagy mert ennél jobban kézben akarják tartani a beállításokat.
Csak magánvélemény, de aki nem tud elszakadni a quick set-től, annak nem biztos, hogy mikrotik router való. Sokkal jobban jár egy VPN-re is képes, kicsit komolyabb soho routerrel. Mikrotiket akkor érdemes használni, ha részletekbe menően akarjuk kezelni a beállításokat, ha érteni is akarjuk mi és hogyan történik, vagy ha valamilyen speciális dolgot akarunk, összefoglalva: vagy rendelkezni kell némi szakértelemmel hozzá, vagy hajlandónak kell lenni megtanulni néhány új (akár mikrotik specifikus, akár általános hálózati ismeretekkel kapcsolatos) dolgot. -
ekkold
Topikgazda
válasz
Mr Dini #14164 üzenetére
A mikrotik esetében az openwrt egyirányú utca, tehát a RouterOS-t nem biztos hogy sikerül visszatenni rá. A license kulcsot nem biztos, hogy vissza tudod állítani, és a RouterOS sem nyílt forráskódú.
Egyébkén miért kellene route-olni a rendszert, mit várnál ha sikerülne? Pl. tudsz fordítani linuxos cuccokat erre a procira?
A RouterOS-hez egyébként nem nagyon van törés sem, régebben akartam a PC-s verzióval játszani, de license nélkül eléggé korlátozott, megvenni meg nem akartam. Persze ha valaki nagyon keres, akkor valami 100éves verzió fellelhető, ami működik is (virtuális gépen teszteltem annak idején), de kétes, hogy esetleg rosszindulatú kód is van benne... -
ekkold
Topikgazda
A böngészőből futtatva a speedtest-et (>900Mbps letöltés mellett) fasttrack-et használva, 10% alatt marad a proci terhelés, a hAPac² -n.
-
ekkold
Topikgazda
válasz
Mr Dini #14143 üzenetére
A modernebb soho routerekben is erős hardver van, a Mikrotik-nek a RouterOS az erőssége, ezt viszont nem kellett külön, teljes egészében lefejleszteni a soho kategóriához, csak a hardverspecifikus részeket.
Egy hAPac² hardvere pl. nem (nem sokkal) bonyolultabb némelyik jobb soho kategóriás eszköznél, az "extrák" nagyrészt az oprendszere miatt vannak.
Talán még az is benne van a dologban, hogy ez is egyfajta reklám, a komolyabb/drágább cuccaiknak. Aki megismeri ezeket az eszközöket, az rájön, hogy profi alkalmazásra is jó, és esetleg használni is fogja.
Jelenleg nekem is egy hAPac² üzemel itthon, a megjelenése után nemsokkal sikerült kifogni egy dupla RAM-al szerelt példányt, ami szépen teszi a dolgát, de párszor már elgondolkoztam rajta, hogy esetleg beruházok majd egy RB4011-re (vagy a nemrég itt említett utódjára). -
ekkold
Topikgazda
válasz
Reggie0 #14144 üzenetére
Ennyire azért nem fekete vagy fehér minden.. A fastpath helyett használható fasttrack, ami szintén a procihasználat drasztikus csökkenését okozza, de a fasttrack-ot elegendő csak az estabilished, related csomagokra engedni. Így lehetnek tűzfalszabályok, és működnek is. Továbbá a fasttrack címtartománya is korlátozható, így pl. a vendéghálóra lehet sávszél korlátot is alkalmazni.
-
ekkold
Topikgazda
válasz
kopogo #14005 üzenetére
Igen. Ha nincs IP ütközés akkor nagyon sok helyre is kapcsolódhat egyszerre. Ha vannak azonos IP címek vagy IP tartományok akkor az azonosak közül egyszerre csak az egyik lesz elérhető (bár trükkösebb NAT-olásokkal talán még ez is megoldható - de ezt lehet, hogy jobb elkerülni).
-
ekkold
Topikgazda
válasz
lionhearted #13932 üzenetére
A különbség valóban a MAC cím klónozása, de a kérdésedre válaszolva, idézet a wiki.mikrotik.com-ról:
Mode station-pseudobridge
From the wireless connection point of view, this mode is the same as standard station mode. It has limited support for L2 bridging by means of some services implemented in station:
MAC address translation for IPv4 packets - station maintains IPv4-to-MAC mapping table and replaces source MAC address with its own address when sending frame to AP (in order to be able to use 3 address frame format), and replaces destination MAC address with address from mapping table for frames received from AP. IPv4-to-MAC mappings are built also for VLAN encapsulated frames. single MAC address translation for the rest of protocols - station learns source MAC address from first forwarded non-IPv4 frame and uses it as default for reverse translation - this MAC address is used to replace destination MAC address for frames received from AP if IPv4-to-MAC mapping can not be performed (e.g. - non-IPv4 frame or missing mapping).A NAT-olás nekem címfordítást jelent. Valamit rosszul értelmezek?
-
ekkold
Topikgazda
válasz
Dolgos1 #13923 üzenetére
A wifi esetében station bridge, station pseudobridge, vagy station pseudobridge clone beállítás kell. Az első akkor ha mikrotik van az ellenoldalon, a másik kettő ha nem mikrotik van a másik oldalon. Az utóbbi kettő között ha jól tudom annyi a különbség (kivéve ha tévedek), hogy az egyik esetben MAC címeket is natol, azaz a túloldal nem látja a valós MAC címeket sem, csak a mikrotikét.
Ezután a beállítás után pedig csak annyi kell, hogy létre kell hozni egy bridge-t a mikrotiken (Bridge menü) és ebbe portként beletenni a wifi interfészt, meg azokat az ETH potokat is, amiken keresztül hozzá akarsz férni a wifihez.
A böngésző nem fog automatikusan indulni, az csak közvetlen kapcsolat esetén működik, és csak akkor ha az oprendszer felismeri a szükségességét. Tehát a böngészőt valószínűleg neked kell majd elindítani. -
ekkold
Topikgazda
válasz
Dolgos1 #13919 üzenetére
90%-hogy megoldható (a tényleges authentikációs megoldástól függ), de ha megoldható, akkor is scriptet kell rá írni. A scriptnek le kell töltenie az oldalt egy fájlba, ezt kielemezni majd majd visszaküldeni a megfelelő adatokat. Egyszerű esetben a letöltött fájl nem változik (vagy nem változik sokat), és csak egy form-ot kell visszaküldeni POST-al vagy GET-el. Bonyolultabb esetben (pl. captcha, sütik, http authentikáció, és egyéb nyalánkságok) megnehezíthetik, vagy ellehetetleníthetik a megoldást. Persze ilyenkor még mindíg megnyithatod egy böngészőben az authentikációs oldalt... Ha nem vagy profi mikrotikes, és nem ismered eléggé a weboldalak működését is, akkor borítékolható, hogy gyakorlatilag nem tudsz automatikusan működő megoldást készíteni. Ezen kívül mivel itt kérdezel erről, így a válasz is sejthető. Tehát marad a böngésző megnyitása... Ha a mikrotik NAT-ol, akkor elég egyetlen eszközről belépni, és az időkorlát erejéig várhatóan működni fog. Azonban aki ilyen hotspot-ot készít (és valamennyire ért is hozzá) az mindíg korlátozza az authentikáció érvényességi idejét, a reálisan várható felhasználási idő szerint, még akkor is ha egyébként nyílt wifiről van szó, pl. a fair használat érdekében. Ezen kívül pedig ha mondjuk én kezelnék ilyesmit, és észrevenném, hogy egy adott IP/MAC address folyamatosan lóg a wifin, akkor csinálnék olyan tűzfal szabályt ami ezt felismeri és hosszú időre feketelistára tesz...
-
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.
-
ekkold
Topikgazda
válasz
kriszrap #13753 üzenetére
Nem ismerem a teljes konfigot, így nehéz kitalálni mit is szeretnél.
A két VPN-el összekötött helyen nem lehetnek azonos IP címek, különböző IP tartomány kell.
A routing szabályokat nem tudom hogyan vetted fel, de az /IP Routes menüben elsősorban, az elérni kívánt IP (vagy IP tartomány) és a hozzá tartozó gateway IP címét rendeljük össze.
Csak egy példa:/ip route
add dst-address=10.11.11.0/24 gateway=192.168.91.2 distance=1 -
ekkold
Topikgazda
válasz
kriszrap #13739 üzenetére
Itt a ényeg szerintem:
fatal NO-PROPOSAL-CHOSEN notify messsage, phase1 should be deletedEddig ezt találtam ere (google fordítóval):
Ez az IPSec esetében nagyon gyakori probléma. Nem választott javaslatot okoz, mert a két útválasztó nem ért egyet az IPSec konfigurált beállításaiban.Esetleg a használható titkosítások halmazában nincs közös rész
-
ekkold
Topikgazda
válasz
kriszrap #13735 üzenetére
....Mikrotik egy upc box mögött fut.
Nem tudok rájönni....
Lehet, hogy pont ez a baj. Gondolom L2TP+IPsec van, az pedig nem szereti a NAT-olt hálózatot. Windows-ban ez (esetleg némi registry matatással) megoldható, mikrotik esetében nem tudom. A log-ot nem tudom megnézni, nincs google accountom. -
ekkold
Topikgazda
válasz
silver-pda #13699 üzenetére
Ha a egy külön hálózatot akarsz kialakítani wifivel, saját DHCP címtartománnyal, akkor a DHCP működhet a wifi interfészen is, de ha több interfészen is használni akarod ezt a hálózatot, akkor azoknek kell egy külön bridge, és a DHCP szervernek is ezt a bridge-t kell kell beállítani.
-
ekkold
Topikgazda
A játék kedvéért az előbb mindkét megoldást beállítottam, megnézzük melyik tesz több IP-t a feketelistára!
Ja, és két hétig lesz feketelistán egy IP, és hogy saját magamat semmiképpen se zárjam ki, van kopogtatós fehérlista is -
ekkold
Topikgazda
válasz
Zwodkassy #13687 üzenetére
De van egyszerűbb megoldás is, PPTP esetében, adott idő alatt a 1723-as portra érkező új kapcsolatok száma alapján is feketelistára tehető a próbálkozó, mivel minden új jelszó kipróbálásához új TCP kapcsolatot kell indítani. Ehhez csak tűzfal szabályok kellenek, script-re nincs szükség.
-
ekkold
Topikgazda
válasz
Zwodkassy #13687 üzenetére
A VPN-re kapcsolódni próbálkozók felkerülnek két IP listára, ha ezután 90 másodpercen belül nem lép be a megfelelő usernév/jelszó párossal, akkor feketelistára kerül az IP néhány órányi (vagy tetszés szerinti) időtartamra. Ez a 90 másodperc a gyakorlatban 3...4 jelszó kipróbálására ad lehetőséget. A logban annyi látszik ilyenkor, hogy próbálkozik admin, root, user, teszt felhasználónevekkel és kb. ennyire futotta, ment a feketelistára.
Ehhez kell néhány tűzfal szabály, és egy egyszerű script. A script minden VPN kapcsolat felépülésekor lefut + óránként egyszer. Annyit csinál, hogy ha él az adott IP-hez tartozó VPN kapcsolat, akkor az IP listában másfél órára meghosszabbítja azt az időt amíg a tűzfal nem teszi feketelistára. Mivel óránként is lefut így a lejárat előtt mindíg meghosszabítja az időt. Elég régóta használom ezt a megoldást, és szerintem sokat javít a VPN biztonságosságán. -
ekkold
Topikgazda
válasz
silver-pda #13685 üzenetére
Távoli asztalt kirakni a netre, ahogyan előttem is írták, eléggé veszélyes játék (magyarul: számíthatsz rá, hogy állandóan próbálkoznak majd a hekkeléssel, és esetleg szét is fogják hekkelni).
Még a legkevésbé biztonságosnak tartott PPTP-VPN is sokkal jobb megoldás lenne. Vagy miniumum egy fehérlistás megoldás kellene, hogy ne kapcsolódhasson bárki bárhonnan.
-
ekkold
Topikgazda
válasz
silver-pda #13682 üzenetére
Van olyan eszközöd aminek a címe 192.168.88.254 és a TCP 3389-es porton kommunikál?
-
ekkold
Topikgazda
válasz
silver-pda #13679 üzenetére
Azt szeretnéd ezzel a tűzfal szabállyal elérni, hogy azokat a kapcsolatokat dobja és ne forwardolja amelyekre nincs DST-nat szabály létrehozva?
Lehet, hogy tévedek, de ennek így nem sok értelme van. Amit nem tud hová tovább forwardolni a router, mert nincs rá NAT szabály, az amúgy is el lesz dobva...
Igazából azt kellene eldönteni, hogy a kapcsolat jogos, vagy esetleg káros , és ez alapján dönteni hogy drop legyen-e. Erre vannak módszerek. -
ekkold
Topikgazda
válasz
silver-pda #13667 üzenetére
Sem a Winbox, sem az SSH elérését nem célszerű kintről engedélyezni. Ha valamiért mégis elkerülhetetlen, akkor sem a standard porton, hanem egy másik, véletlenszerűen választott porton (pl. 10000 felett). Ezen kívül ilyenkor érdemes további tűzfal szabályokkal is megtámogatni, pl. hogy adott idő alatt csak 3 próbálkozást engedjen, vagy mondjuk "fehérlistát" létrehozni, és csak a listán szereplők számára engedélyezni a hozzáférést. A fehérlistára dinamikus címeket is fel lehet tenni, illetve az ún. kopogtatásos módszerek is hatékonyak.
De talán még jobb megoldás a VPN használata. Ilyenkor egyáltalán nem kell portokat nyitni kifelé. Ilyenkor elsősorban a VPN-t kell védeni, a fentiekhez hasonlóan, tehát pl.:
- hosszú és bonyolult jelszó használata
- korlátozni a jelszó próbálgatások számát,
- fehérlista használata
- port kopogtatás, vagy csomagméret kopogtatás fehérlistával
- jelszócsere adott időnként
- feketelista a támadó IP címeknek
- stb.... -
ekkold
Topikgazda
válasz
ratkaics #13654 üzenetére
Több különböző LAN IP tartomány használatához, a LAN oldali bridge-nek több IP címet kell adni. Az, hogy melyik tartomány tud netezni, két dologgal szabályzható ill. korlátozható:
- A NAT szabály(ok)ban meg lehet adni, hogy melyik IP tartományra vonatkozzon.
- Tűzfal szabályokkalA VPN alaphelyzetben mindegyik IP tartományt látja, de tűzfal szabályokkal ez is korlátozható.
Mivel minden szabály ki/be kapcsolható egyetlen kattintással, így "hab a tortán" is megoldható.
Nyilván meg kell oldani a DHCP szerver megfelelő beállítását, és azt is hogy melyik eszköz melyik IP tartományba kerüljön (pl. MAC adress alapján). De végülis ez is csak pár kattintás.
Más lehetőség ha csak 1 IP tartomány van, de abból nem minden cím éri el az internetet... Ehhez csak tűzfal szabály(ok) kellenek.
Viszont egy ilyen komplett konfig azért lehet, hogy nem fér el 3..4 sorban itt a fórumban...
-
ekkold
Topikgazda
válasz
totoka2 #13621 üzenetére
Wifi kikapcsolása:
/interface disable wlan1
Wifi bekapcsolása:
/interface enable wlan1
A per jel ne maradjon le az elejéről. Ha az interfész nevét megváltoztattad, akkor a wlan1 vagy wlan2 helyén az aktuális nevét kell beírni (nálam pl. wlan2.4G és wlan5G).
Időzíteni a scheduler-ben tudod ezeket a parancsokat. Kipróbáltam, jól működnek. -
ekkold
Topikgazda
A tűzfalad alap logikai koncepciója hibás. Korlátoztad a kimenő forgalmat 12 portra. Attól, hogy te mondjuk a 43788-as portot használod a torrent klienseden, mások valószínűleg teljesen más portot használnak, de mivel ezek nem szerepelnek a listádon, ezekkel nem tudsz kommunikálni, azaz kb. senki más torrent kliensével sem. Egy munkahelyen még csak-csak megértem (megértem, de nem értek egyet vele), hogy ilyen drasztikusan korlátozzák pl. a dolgozók net elérését, ha pl. a munkájukhoz nincs szükségük rá. Otthon meg szimplán hülyeség (bocs) mert csak saját magadat (és esetleg a családtagokat) szivatod meg vele. Ugyanakkor semmilyen plusz biztonságot nem ad, sőt lényeges dolgokat meg nem védesz (pl. winbox portja, DNS, stb...), amit viszont igencsak kellene...
-
ekkold
Topikgazda
válasz
totoka2 #13616 üzenetére
Az, hogy a DHCP-t be kell-e kapcsolni attól függ, hogy sima AP-ként van konfigurálva, vagy routerként működik úgy, hogy a a wifi külön hálózat lesz.
A QuickSet szoftver verziónként változhat, sokan nem is követik, hogy éppen mit tud, és mit nem. Már erősebb kezdő szinten sem javasolt a QuickSet használata (sőt kimondottan kerülendő).AP-nek konfigurálni csak annyi hogy 1db bridge-t kell létrehozni, és abba betenni az összes interfészt, és be kell állítani a wifi paramétereit. Még IP címet sem feltétlenül kell adni neki, de akár DHCP kliens, akár fix IP is beállítható (akár egyszerre is) a könnyebb kezelhetőség érdekében.
Persze ehhez meg kell ismerni kicsit a Mikrotik ill. a RouterOS beállításának logikáját - kell hozzá némi szakértelem ill. műszaki érzék.
Ha ez nincs meg, ill. ha szándék sincs a tanulásra, akkor egyszerűbb eladni és más típust venni, vagy megbízni valakit, hogy állítsa be neked.
Ha van szándék és kitartás megismerni a RouterOS-t, akkor bizonyára sokan tudnak majd segíteni, de ehhez is el kel jutni egy olyan szintre, hogy legalább kérdezni tudj, és meg tudd érteni a választ amit kapsz. Kezdésnek talán olvasgass itt egy kicsit: [link]
Persze ha érthető volt , hogyan állítsd be AP-nek (bridge+portok +wifi beállítás - QuickSet nékül), akkor hajrá... Ha elakadsz kérdezz! -
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.
-
ekkold
Topikgazda
válasz
ssarosi #13413 üzenetére
Ahogy előttem is írták a windows-al lesz a gond. Nekem Win7 alatt most is működik a PPTP, RouterOS verziótól függetlenül.
Viszont a windows alaphelyzetben automatikusan dönti el, hogy milyen tipusú VPN-re próbál kapcsolódni. Tehát ha beállítasz egy L2TP-t is ugyanolyan jelszóval, akkor jó eséllyel fel tudnak rá kapcsolódni a windows kliensek.
Új hozzászólás Aktív témák
Hirdetés
- Battlefield 6
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Samsung Galaxy A54 - türelemjáték
- Vezeték nélküli fejhallgatók
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Luck Dragon: Asszociációs játék. :)
- 3DMark 11 eredmények
- sziku69: Szólánc.
- Alkoholista nevelde
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- További aktív témák...
- BESZÁMÍTÁS! ASUS H87I-PLUS H87 chipset alaplap garanciával hibátlan működéssel
- Bomba ár! Lenovo ThinkPad T480s - i5-8GEN I 8GB I 256GB I 14" FHD I HDMI I Cam I W11 I Gari!
- HUAWEI MateBook 13 2020 - Kijelző nélkül - I7-10510U - 16GB - 512GB SSD - Win11 - MAGYAR
- Megkímélt állapotban lévő Xiaomi 12T Pro 8/256GB / 12 hó jótállás
- Azonnali készpénzes Sony Playstation 4 Slim / PS4 Pro felvásárlás személyesen/csomagküldéssel
Állásajánlatok
Cég: FOTC
Város: Budapest