- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Gurulunk, WAZE?!
- sziku69: Szólánc.
- hcl: Kelj fel komám, ne aludjál
- bambano: Bambanő háza tája
-
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
-
-
#24336
Tamarel
senior tag
E.Kaufmann
#24333
Tamarel
senior tag
válasz
E.Kaufmann
#24333
üzenetére
Szóval nem otthoni.
Proton vpn plus, egyhavi előfizetés 10€ és tesztelhetsz 10 gigás szerverekkel.Annyi, hogy vpn-nél a pingelés tud anomáliákat okozni. Pl 1.1.1.1 válaszol x napig, aztán elnémul és nem válaszol semmit semmire.
-
#24332
Tamarel
senior tag
E.Kaufmann
#24331
Tamarel
senior tag
válasz
E.Kaufmann
#24331
üzenetére
Weboldalon belépve láthatod melyik szerver mennyire van terhelve (%). Minél alacsonyabbat válassz.
Hogy ne legyen off: route tábla és ip routes különböző distance értékekkel a legegyszerűbb beállítás.
Ha a cél pl %pppoe1, akkor ha lent van az interface, akkor alapból ki kellene essen a lehetséges route-ok közül, így a forgalom menne a következőre.
Persze lehet ping teszt (ha a gateway válaszol), rekurzív feloldás (= két szabály és bármilyen ip-t pingelsz a next hop helyett) vagy script, ami az ip route bejegyzést kapcsolhatja (enabled/disabled). -
#24330
Tamarel
senior tag
E.Kaufmann
#24328
Tamarel
senior tag
válasz
E.Kaufmann
#24328
üzenetére
Sebesség feltételt nem írtál.
Be tudod állítani és tudod tesztelni is. -
#24326
Tamarel
senior tag
E.Kaufmann
#24323
Tamarel
senior tag
válasz
E.Kaufmann
#24323
üzenetére
Protonvpn, minden szerverre csinálhatsz külön wireguard-ot.
-
Tamarel
senior tag
válasz
ekkold
#24205
üzenetére
Fast Path miatt 800+. Van 17 filter, 8 nat és 6 mangle szabály.
A wireguard szimmetrikus, nincs szerver.
Az alacsonyabb feltöltés oka a Telekom, mert a budapesti proton szervereket Ausztrián keresztül érem el (bix helyett). Ez az oka a késletetésnek is.
Régen Németországon fordult, 50ms késleltéssel. Még régebben a diginél voltak a szerverek meg én is, akkor 0ms volt.Nagyjából hiába nyitogatok hibajegyeket. Digi nem is válaszol, Telekomnál egyszer sem sikerült hozzáértővel beszélni, Protonnál sok adatot küldve 2-3. nekifutásra talán változik valami. Hónapok alatt.
A családban lévő másik ax3 eddig digin lógott (napi 5+ megszakadással és akár 1.5 óra kieséssel), most került át telekomra.
Magyarul végre van 1Gb/1Gb mind a két oldalon, tudok majd tesztelni. -
Tamarel
senior tag
válasz
Bubukain
#24092
üzenetére
Mi a szoftververzió?
Ax-hez wpa3 kell, a beállításaiddal kellene menjen, n-en…
Ha nem akarsz wpa3-at, akkor tedd n-re.
Valamint ha régi eszközökről van szó, akkor management protection-t kapcsold ki (ami amúgy kötelező a wpa3-hoz).Jobb, ha a csatornát kézzel választod ki. Pl ne menjen 13-asra, ha van olyan kliensed, ami nem csatlakozik arra.
Úgy általában 7.x verzión próbálj minél kevesebb dolgot beállítani, hogy hadd oldja meg a driver.
-
Tamarel
senior tag
válasz
user12
#24008
üzenetére
Szintén telekom - digi (mindkettő ftth).
Vagy a telekom eszköz (bug) vagy az ip címhez köthetően valami szűrő (a restart-nál új ip-t kap).Alteran-IT
Ez nem mikrotik, digi - digi között nem volt, telekom - digi között mindig volt. Azóta volt legalább 3 új főverzió és teljesen mindegy mit próbáltam. -
-
Tamarel
senior tag
A packet sniffert még soha nem használtam, így arról nem tudok nyilatkozni.
A beállításokban vannak zavarok, a tűzfal szabály elnevezések is mutatják a bizonytalanságod.
Kezdésnek: ipv6 kikerüli a proton wireguard vpn-t. A nasról mindenképp le kell szedned az ipv6-ot, ha úgy egyébként vpn-en belül szeretnéd tartani a forgalmát.
Ha a routeren van ipv6, akkor a dns-edben is lesz, aztán az ftp vagy megoldja majd vagy nem.Vlan, guest, routing: kell némi (szabad)idő a kibogozásához.
-
Tamarel
senior tag
válasz
ekkold
#23929
üzenetére
Ezekkel a szabályokkal csinálok ilyesmit, vpn-en kívül tartani meghatározott forgalmat.
Az első mangle a kimenő forgalom megjelölése, a második a bejövő irányból felépülő eset.
Minden szabály elől legyen./ip firewall filter
add action=accept chain=forward comment="no-vpn no fasttrack" connection-mark=no-vpn connection-state=established,related/ip firewall mangle
add action=mark-connection chain=prerouting dst-address-list=no-vpn in-interface-list=LAN new-connection-mark=no-vpn
add action=mark-connection chain=prerouting dst-port=5510 in-interface-list=WAN new-connection-mark=no-vpn protocol=tcp
add action=mark-routing chain=prerouting connection-mark=no-vpn new-routing-mark=no-vpn passthrough=no protocol=tcp/routing rule
add action=lookup-only-in-table comment=no-vpn disabled=no routing-mark=no-vpn table=main -
#23636
Tamarel
senior tag
lionhearted
#23624
Tamarel
senior tag
válasz
lionhearted
#23624
üzenetére
Feltettem 17én, igazából nincs vele semmi.
Minden funkció működik, naplóban egy új dolog volt csak (egy syn flood warning egyszer, indítás után - új riasztás).
A dns adlist jobb, flash helyett memóriába tölti le a fájl és 35%-kal kevesebb helyet foglal a dns cache-ben. -
-
Tamarel
senior tag
válasz
poli27
#23529
üzenetére
Csak az elméleti részben, mert ipv4-only vpn miatt teljesen kikapcsoltam (vpn bypass lenne).
Szóval az ipv6 tervezése szerint end-to-end, így nem kell szervert beállítanod. A telekom adja a tartományt és a dhcpv6 szervert is, ha egyáltalán szükséges (automatikus címzés is lehetséges).
Ezzel jár, hogy kívülről látszik az összes eszközöd, közvetlenül címezhetőek is, illetve nagyon kell az ipv6 tűzfal.
Valamint ha éppen a lan-on belüli kommunikációdnál is azt a címet használja (mármint ipv6 és nem a link local) és megbillen a net / más tartományt kapsz = eltűnik az ip, akkor a belső forgalom is megszakad.Paranoid hozzáállás esetén fórumokon körbenézve találhatsz egy reserved tartományt, amit használhatsz belül, dhcpv6 szerverrel és nat-olhatod.
-
#23378
Tamarel
senior tag
Alteran-IT
#23377
Tamarel
senior tag
válasz
Alteran-IT
#23377
üzenetére
Cisco WLC cserénél ugyanúgy ki kell tenni a régi AP-kat, mert egyszerűen nem kompatibilis.
Az AP gyártásakor beleégett tanúsítvány (MIC) pedig 7 évig jó, utána nem lesz biztonságos a kommunikáció. Nálunk ilyenkor rövid úton kikerül a hálózatból. -
#23301
Tamarel
senior tag
Alteran-IT
#23300
Tamarel
senior tag
válasz
Alteran-IT
#23300
üzenetére
Van switch a két eszköz között?
-
#23280
Tamarel
senior tag
skylinelaca
#23275
Tamarel
senior tag
válasz
skylinelaca
#23275
üzenetére
TTL-t átírod? [link]
-
#23177
Tamarel
senior tag
lionhearted
#23173
Tamarel
senior tag
válasz
lionhearted
#23173
üzenetére
Amikor próbálkoztam, akkor elég nehéznek tűnt megoldani, hogy a saját LAN semmit ne lásson belőle.
Aztán inkább húztam külön kábelt neki.
Végül a bekötésnél mondták, hogy az új iptv kliens már működne wifin is, de nekik szigorúan tilos úgy telepíteni. -
#23172
Tamarel
senior tag
lionhearted
#23171
Tamarel
senior tag
válasz
lionhearted
#23171
üzenetére
Teljesen sikerült elkülöníteni?
-
Tamarel
senior tag
válasz
Tamarel
#23042
üzenetére
v3, reboot utáni üres értéket is kezeli
:if ((:put [/interface/wireguard/peers/get ([find name=xyz]) last-handshake] > 3m) or (:put [/interface/wireguard/peers/get ([find name=xyz]) last-handshake] = [])) do={ip route disable ([find comment=xyz disabled=no])} else={ip route enable ([find comment=xyz disabled=yes])} -
-
#23003
Tamarel
senior tag
silver-pda
#23001
Tamarel
senior tag
válasz
silver-pda
#23001
üzenetére
Van masquerade szabály a guest és az internet között?
-
#22998
Tamarel
senior tag
E.Kaufmann
#22997
Tamarel
senior tag
válasz
E.Kaufmann
#22997
üzenetére
Szóval naponta kapcsolgatni.
A tarpit engedi felépülni a kapcsolatot, csak forgalmat nem enged.
Mondjuk a reject-et érthetné. -
Tamarel
senior tag
Érdekesség:
wireguard check gateway helyett helyi scriptNéhány eszközt csak wireguard szerveren keresztül engedek ki az internetre, de az ip / routes check gateway nem volt elég megbízható.
Háttér: Volt 2 wireguard, az elsődleges (distance = 1) csak aktív forgalmazási lehetőség eseten kellene aktív route-al rendelkezzen, a második mindig aktív.
Probléma:
- a wireguard interfész mindig aktív, így a route is
- a peer ip-je nem válaszol ping-re
- rekurzív next hop és 1.1.1.1 check gateway nem stabil, többször indokolatlanul kiesik vagy aktív állapotban ragad
(nem kell azonnal átalljon, de ne ragadjon be kézi javításig)Megoldás:
Észrevettem, hogy a mikrotik maximum 2 perces handshake időt próbál tartani (persistent keepalive = 25 mp…), így ha eléri a 2 percet, akkor pár másodpercen belül kommunikál. Ha tud.Ez a script percenként fut, ha a handshake 3 percnél régebbi, akkor kikapcsolja a route-ot. Ha nem, akkor vissza. Mindkét esetben állapotot ellenőriz előtte, így tiszta és hasznos a napló.
:if (:put [/interface/wireguard/peers/get 4 last-handshake] < 3m) do={:if (:put [/ip/route/get 4 disabled] = true) do={:put [/ip/route/enable 4]}} else={:if (:put [/ip/route/get 4 disabled] = false) do={:put [/ip/route/disable 4]}}
Nyilván jobb lenne, ha a wireguard peer magától tudna inaktívba menni (opcionális beállításként).
-
#22994
Tamarel
senior tag
E.Kaufmann
#22993
Tamarel
senior tag
válasz
E.Kaufmann
#22993
üzenetére
Tarpit.
Amúgy nem világos, hogy mi a nat-od funkciója és miért veszed ki. -
Tamarel
senior tag
Attól is függ mennyi ilyen eszköz van.
A tuti a layer 2 elkülönítés, vagyis külön subnet és bridge. Az elérést meg tűzfalon tudod finom hangolni (pl csak estabilished és related jöhet be).
Gyakorlatilag vendég hálózat.Amúgy én nem különítem el, csak az internetről tiltok le mindent…
-
Tamarel
senior tag
válasz
[sultan]
#22986
üzenetére
Valószínűleg engedélyezned kell a wpa-t és tiltani a management protection-t. Ha igen, akkor legalább a tkip-t ne kapcsold be.
Amúgy tudsz minkét sávon modern eszközöket használni (ax, wpa3), ha a 2.4Ghz-re felveszel egy másodlagos ssid-t, ami a régi eszközöknek dedikált (n, wpa/wpa2).
Így nyerhetsz egy kis hatótávot a telefonoknak (a 2.4Ghz messzebb terjed), de megmarad a fejlett energiagazdálkodás is (alvó mód). -
Tamarel
senior tag
BtH-t soha nem használtam.
Sima wireguard esetén akkor vannak Handshake for peer did not complete after 5 seconds, retrying (try 2) üzenetek a naplóban, ha a responder kapcsoló nincs bekapcsolva a mobil eszköz felé lévő peer beállításai között.
Vagyis fel szeretné építeni a kapcsolatot, de a mobil lehet épp alszik, hálózatot váltott és így más az ip-je, épp túlzsúfolt cellában van és nem kap forgalmat vagy bármi hasonló. -
Tamarel
senior tag
válasz
hun005a
#22804
üzenetére
A legjobban akkor jársz, ha az iptv külön kábelt kap a telekom modemből (teljesen kikerüli a sajátodat).
Az iptv először unicast, majd 5 másodperc múlva multicastra vált. Egy második kábel a mikrotik és a modem között is jó megoldás lehet, ha vlan van a saját hálózatodon és így csak az iptv-nek dobod át azt a plusz portot.
-
#22652
Tamarel
senior tag
lionhearted
#22650
Tamarel
senior tag
válasz
lionhearted
#22650
üzenetére
Igaz, a bss coloring inkább szoftver, mint hardver limit.
Megtaláltam: [link]
-
Tamarel
senior tag
válasz
LaCeeN
#22647
üzenetére
Nem probléma, rádiónként 25 felett érdemes gondolkodni a dolgon.
Ha van sok eszköz, akkor egyszerre 8-nak tud kevés adatot küldeni és 2 tud fel/le maximális sebességgel menni. Csak ax-es klienseknél, természetesen.A mérések szerint ha már az eszközök 30%-a ax-es, akkor az egész hálózat állapota javul (több idő jut a többire).
-
Tamarel
senior tag
válasz
LaCeeN
#22633
üzenetére
A config és a log szerint a wifi2 a 2.4Ghz és csak azt használod, ráadásul van -80 dB alatti kliens is.
Kezdetnek szoftvert kellene frissíts, 7.14.3 -> 7.15.3. A wifi driver miatt.
Utána az elhelyezést nézd meg:
- lehetőleg a lefedni kívánt terület közepénél legyen
- inkább magasan, mint alacsonyan (plafon, fal, szekrénytető)
- függőleges, párhuzamos antennákkalA beállítás szempontjából a mikrotik wifi ax-nek, jó, ha minél kevesebbet állítasz és a többit a meghajtóra bízod. Ez stimmel.
- Viszont ha wpa2 van, akkor illene kitiltani a tkip-t.
- 2.4Ghz is mehet ax-re, mert a régi kliensek a management protection frame-től zavarodnak meg (wpa3-hoz kötelező), nem az ax-től (-> 5Ghz mehetne csak wpa3-ra). -
#22569
Tamarel
senior tag
privatposta
#22567
Tamarel
senior tag
válasz
privatposta
#22567
üzenetére
Address is van? (router címe a guest subnetben)
-
#22565
Tamarel
senior tag
privatposta
#22564
Tamarel
senior tag
válasz
privatposta
#22564
üzenetére
Bridge-ből vedd ki azt a wifit, mivel igényli a beállítást, csinálj neki egy másikat.
A blokk pedig forward tűzfal szabály, guest -> lan irányra (de leginkább oda-vissza).Bandwidth control: 2.4Ghz-t a guest-nek.
-
#22455
Tamarel
senior tag
lionhearted
#22454
Tamarel
senior tag
válasz
lionhearted
#22454
üzenetére
Kezdésnek kapcsold ki a telekom netvédelmét. Nem csak szűrőlistás dns szervereket jelent, hanem ip blokkolást is (talán portokat is).
-
Tamarel
senior tag
Most dobtam össze, remélem nincs benne hiba.
/routing table
add disabled=no fib name=proton
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=%proton-interface routing-table=proton suppress-hw-offload=noForrás ip alapján:
/routing rule
add action=lookup-only-in-table disabled=no src-address=192.168.0.2/32 table=protonForrás ip + cél port alapján:
/ip firewall mangle
add action=mark-connection chain=prerouting protocol=tcp dst-port=22 src-address=192.168.0.2 new-connection-mark=proton passthrough=yes
add action=mark-routing chain=prerouting connection-mark=proton new-routing-mark=proton passthrough=no protocol=tcp
/routing rule
add action=lookup-only-in-table disabled=no routing-mark=proton table=proton+ ha van fasttrack, akkor első szabálynak:
/ip firewall filter
add action=accept chain=forward connection-mark=proton connection-state=established,related -
-
-
Tamarel
senior tag
Megváltozott az rss url…
A 7.14.3 jónak néz ki (a queue).
What's new in 7.14.3 (2024-Apr-17 15:47):
*) bgp - correctly synchronize input.accept-nlri address list;
*) bridge - use default "edge=auto" for dynamically bridged interfaces (PPP, VPLS, WDS);
*) disk - improved system stability;
*) fetch - fixed slow throughput due to "raw" logging which occurred even when not listening to the topic (introduced in v7.13);
*) queue - improved system stability (introduced in v7.6);
*) wifi-qcom - added configuration.distance setting to enable operation over multi-kilometer distances (CLI only); -
#21966
Tamarel
senior tag
lionhearted
#21916
Tamarel
senior tag
válasz
lionhearted
#21916
üzenetére
Köszi az ötletet, már jól működik.
-
Tamarel
senior tag
-
#21927
Tamarel
senior tag
lionhearted
#21924
Tamarel
senior tag
válasz
lionhearted
#21924
üzenetére
A nas ddns ip-je mutatja merre ment ki.
A mangle-vel pont, hogy a main-be szeretném tenni, a forrás ip-re vonatkozó másik szabály előtt. -
#21923
Tamarel
senior tag
lionhearted
#21922
Tamarel
senior tag
válasz
lionhearted
#21922
üzenetére
De, csak az adott kliensnek nem a main az alapértelmezett kijárata.
Hétvégén átnézem a forgalmi irányokat, mert kezd bonyolult lenni. -
#21921
Tamarel
senior tag
lionhearted
#21916
Tamarel
senior tag
válasz
lionhearted
#21916
üzenetére
Van fast track, igen…
Ha működik egy weboldal, akkor rendesen lehet csinálni rajta bármit, percekig.
kress:
- elég felvenni a dns-t, magától hozzáadja az ip címeket
- nem tudom milyen gyakran frissít,
- már gyanakodtam rá, mert bár ugyanaz marad az ip, néha akkor is máshogy viselkedik egy rámentés után -
Tamarel
senior tag
Sziasztok.
Policy routing-al kapcsolatban van kérdésem: vajon miért nem stabil?
Synology NAS heartbeat és ddns forgalmát szeretném elterelni vele, de hosszabb-rövidebb ideig működik nem-működik, magától (percektől órákig megy vagy éppen nem).
Az eredmény szempontjából mindegy, hogy packet vagy connection mark mentén megy a logika.
Ha teszek mellé weboldalt, az működik (new connection)./routing table
add disabled=no fib name=no-vpn/ip firewall address-list
add address=account.synology.com list=no-vpn
add address=ddns.synology.com list=no-vpn
add address=checkip.synology.com list=no-vpn
add address=checkip.dyndns.org list=no-vpn
add address=checkipv6.synology.com list=no-vpn/ip firewall mangle
add action=mark-packet chain=prerouting dst-address-list=no-vpn in-interface-list=LAN new-packet-mark=no-vpn passthrough=yes
add action=mark-routing chain=prerouting in-interface-list=LAN new-routing-mark=no-vpn packet-mark=no-vpn passthrough=no/routing rule
add action=lookup-only-in-table comment=no-vpn disabled=no routing-mark=no-vpn table=no-vpn
(ez az első szabály)/ip route
add comment=no-vpn disabled=no distance=1 dst-address=0.0.0.0/0 gateway=x.x.x.x@main pref-src="" routing-table=no-vpn suppress-hw-offload=no
Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy XCover7 Pro - burokban született One UI
- Honda topik
- iPhone-t használók OFF topikja
- Star Trek
- Renault, Dacia topik
- Okos Otthon / Smart Home
- Suzuki topik
- Synology NAS
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Azonnali notebookos kérdések órája
- További aktív témák...
- Telefon felvásárlás!! Samsung Galaxy A20e/Samsung Galaxy A40/Samsung Galaxy A04s/Samsung Galaxy A03s
- BESZÁMÍTÁS! 1TB Western Digital SN850X NVMe SSD meghajtó garanciával hibátlan működéssel
- Lenovo Thinkpad T14 üzleti i5-10310u 10th gen. 8-32Gb RAM 256GB-1TB SSD gar.
- Használt Intel procik - Core 2 - Dual Core
- LG 27GR95UM - 27" MiniLED - UHD 4K - 160Hz 1ms - NVIDIA G-Sync - FreeSync Premium PRO - HDR 1000
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest