- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Samsung Galaxy S24+ - a személyi asszisztens
- Google Pixel topik
- A Galaxy Z Fold7, minden színben és oldalról
- Samsung Galaxy A54 - türelemjáték
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Szerkesztett és makrofotók mobillal
- Külföldi SIM-ek itthon
- iPhone topik
-
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
-
-
Marcelldzso
tag
válasz
Reggie0
#13783
üzenetére
Nem tudom mitől lett ez az állapot, sokáig rendben működött. Szélsőséges időjárási viszonyoknak sincs kitéve, ESD védett kábelezést csináltam hozzá.
Tehát meglátásod szerint a modem lehet a rossz?
Magyarul bontsam szét az elejét, modem ki megfújkod majd vissza?
Nincs lehetőségem cseredarabbal tesztelni. -
#13697
silver-pda
aktív tag
Reggie0
#13696
silver-pda
aktív tag
válasz
Reggie0
#13696
üzenetére
Köszi.
IP Firewall-ra gondoltam virtual interfesz esetén, tehát akkor ez átmegy.L2TP, illetve PPTP esetén kérdéses a pool. Úgy látom csak pool-t kell megadni, a többit intézi a vpn szerver.
Egyik wlan-nak pool: tehát kell egy másik dhcp szerver és pool. Viszont a bridge1-be van az összes ethernet port meg a 2 darab wlan.Akkor onnan ki kellene venni vagy vhogy exclude-olni, hogy ne kapjon az eredeti dhcp-től ip-t. -
-
#13639
E.Kaufmann
veterán
Reggie0
#13638
E.Kaufmann
veterán
válasz
Reggie0
#13638
üzenetére
Nem játszottam vele ilyet, inkább "kettébontottam" (hw diagramnak megfelelően) a Mikrotik-et és hanyagoltam a bondingot. Így azóta is müxik, se CPU terhelés, se hálózati gixerek. Egyik lábon meg még a PoE is jön. Igaz, így nincs olyan szépen elosztva a terhelés, de jobb mint egy darab gigabites uplink.
-
zex
aktív tag
válasz
Reggie0
#13584
üzenetére
Beállítottam a jelszavas védelmet, de mivel a scriptem létrehozza az .rsc és a .backup kiterjesztést is, így ha jól látom csak a .backup-nak tudok jelszavas védelmet adni, az .rsc-nek nem. Ez nem gáz így? Vagy azért nem, mert az .rsc nem tartalmaz alapból jelszavakat, a böbbi meg nem sensitive adat?
-
DonJoee
tag
válasz
Reggie0
#13570
üzenetére
Most ugyan a 4011 a fő mindenes router, de pár héten belül már "csak" az internet felé történő forgalmat irányítja, nem erre lesz dugva az összes switch, hanem egy CRS305-re, ami 10 gigás optikai SFP+ modulokon keresztül megy a többi új switchez.
Talán így nem akkora gond ez a 4011. Mondjuk eddig még semekkora, mert nem tapasztaltam problémát vele. A wifi csak vendég wifi, le is korlátoztam 10/2 Mbit/s-re. Mondjuk lehet, hogy ezen emelek kicsit. -
DonJoee
tag
válasz
Reggie0
#13567
üzenetére
Ezzel a port flappinggal kicsit megijesztettél, de ahogy olvasom, leginkább akkor fordul elő, amikor az RB4011 SFP+ portba dugott RJ45-ös modullal találkozik 1 Gbit/s sebességen (t.i. melegszik szerencsétlen). Az auto negotiation kikapcsolásával "javítható", de így csak fix 1 Gbit/s sebesség lesz. Vagy nem lesz, ha mondjuk egy 100 Mbit/s interfészű nyomtató is csatlakozna a hálóra...
Ahogy olvastam, a rev.2-es RB4011-eket már tákolták valamelyest emiatt (ilyen van nekem is), továbbá optikai modullal ugye kevesebb az áramfelvétel és így a melegedés is, tehát port flapping nincs (még).
Egyébként sima üresjárati módban is úgy tud melegedni szegénykém, hogy komolyan elgondolkodtam egy 10cm x 20 cm-es öntapadós hővezető lap + ugyanekkora alapterületű és kb. 10 cm magas hűtőborda felapplikálásán. Mondjuk nem tudom, hogy egy ekkora vasdarab mennyire vágja agyon a WiFi-képességeket? -
Marcelldzso
tag
válasz
Reggie0
#13563
üzenetére
Megpróbálom jobban összefogalmazni. Mindhárom telephelyen van 3db SQL szerver amit egy gépre telepített kliens szoftverrel nézegetnek különböző telephelyeken utazgatva.
Tehát A_B_C telephelyeken nézegetik A_B_C sql szervereit. (készletprogram)
WAN oldalon 100/100 van LAN oldalon pedig gigabit. Az elvárt az lenne, hogy, a telephelyek között valamelyest gyorsabb legyen az elérés, gondoltam ehhez megpróbálnék értelmes eszközt találni.
l2tp/ipsec site2site kapcsolatokon gondolkozom.RB4011/RB3011 milyen bugjai vannak?
Mi akkor az első értelmes választás egy /24-es hálóhoz gigabiten? -
Reggie0
félisten
válasz
Reggie0
#13536
üzenetére
Na, ma mar nem adok semmi otletet, mert vak vagyok es nem szurja ki a szemem, hogy tcp...
Az alatta levo sort akartam masolni:
add action=add-src-to-address-list address-list=BlackList \address-list-timeout=6h chain=input dst-port=\20-122,124-499,501-1023,8000,8080,8291 log-prefix=UDP-block protocol=udp \src-address-list=!Local -
-
válasz
Reggie0
#13510
üzenetére
Mind a két verziót kipróbáltam.
Ha a "xyz.sn.mynetname.net" alapján akarok csatlakozni:
"Nem lehet csatlakozni a következőhöz: Miki SSTP teszt
A tanúsítvány CN-neve nem felel meg az átadott értéknek."
Itt azért egy kicsit trükköztem. Jelenleg egy default konfigos KapAc2-val kísérletezek, méghozzá LAN oldalról.
Annyi a trükk, hogy a "xyz.sn.mynetname.net" nevet, felvettem a "IP / DNS / Static" részbe, így ezt a 192.168.88.1 IPv4 címre oldja fel a Windows számára :-)
PING esetén ezzel nincs gond, sőt a RouterOS HTTP elérése is műxik így :-) -
válasz
Reggie0
#13454
üzenetére
Sikerülni sikerült már létrehozni kapcsolatot, de csak úgy, ha a cert-ben is az IPv4 címet adtam meg, és a Windows-ban is erre az IPv4 címre szól az SSTP kapcsolat.
Próbáltam az "IP / Cloud" alatt található DDNS névvel is (xyz.my.netname.net), de nem jött össze :-(
Valamit nem jól csinálok? -
vampire17
addikt
válasz
Reggie0
#13495
üzenetére
Mivel en nem allitottam semmit es ma reggelre pedig "varazsutesre" megjavult, igy gyanitom, ok allitottak valamit...
Illetve az egesz varosban panaszkodtak, illetve ok maguk is mondtak, hogy valami el lett qurva az Invitel atvetel alatt es felhasznaloi adatok vesztek el.... Ezert is kaptak uj felh. nev jelszo adatokat sokan.
-
yodee_
őstag
válasz
Reggie0
#13486
üzenetére
Ezt egész pontosan hogyan is?
- 1: hAP ac2 szerver:
PPP -> Profiles -> VPN-profile1 -> protocols -> Use Encryption = no? Most default-on van
IP -> IPsec -> Proposal -> Enc. algorithms -> minden pipa ki? Most aes-128 cbc; aes- 192 cbc; aes-256 cbc aktív
IP -> IPsec -> Profiles -> default -> Encryption algorithm minden pipa ki? Most 3des; aes-256 aktív.- 2 hAP ac2 kliens 1 és 2:
Ugyanúgy az előzőek vagy más?Köszönöm
-
yodee_
őstag
válasz
Reggie0
#13463
üzenetére
Közben utána olvasgattam. Amennyiben a packet méret az MTU, akkor az 1450. 2 kapcsolat van, szinte sosincs egyidejű nagyobb adatforgalom. Samba-n mért sebesség:
- Szerver felől hAP ac2 usb kártyára samba-n: 20-30mbit/s
- hAP ac2 usb kártyáról samba-n szerver mögötti kliensre: 5-10mbit/sA titkosítást nem jöttem rá hol lehet megnézni.
-
Zsolt_16
tag
válasz
Reggie0
#13443
üzenetére
A hiba valószínűleg általad leírtak voltak mert google találatok alapján is ilyenekkel találkoztam. Sajnos ennyire nem vagyok tapasztalt a témában így ezt javítani nem tudtam de egy reset és újra konfigurálással jelenleg nem kapok hibát
Ami jobban aggaszt az, hogy nem tudom eredetileg volt félre konfigurálva a mikrotik vagy valami kiválthatta ezt mert akkor idő kérdése, hogy újra előjön.
-
-
-
DonJoee
tag
válasz
Reggie0
#13415
üzenetére
Aha!
Lássuk, jól értem-e: szóval, ha mondjuk a "whatismyip.akamai.com" IP-címét, ami 91.83.14.187, beírom egy route Dst.address-mezőjébe és ehhez gateway-ként mondjuk a WAN2-őt adom meg, akkor minden alkalommal, amikor a fenti url-t akarom elérni, ezen a route-on (és így a WAN2-őn) keresztül megy ki a forgalom, mert az általánoshoz (0.0.0.0/0) képest "közelebb" van a cél, "jobb" errefelé route-olni... (gondolom egy alacsony distance-szel még jobban is rásegíthetek a dolgokra)
És ha csinálok 3 route-ot (egyet-egyet minden WAN-port számára, amiket gateway-ként adok meg) és sorban, mindig csak egyet kapcsolok be belőlük, akkor mindig csak azon keresztül megy ki a kérés az IP-cím-jólmegmondó szolgáltatás felé...
Aztán, ha végeztem, disablélom az összes ilyen spéci route-ot és kész is vagyok?Ja és mindig:
:if (([:len [/ip route find where comment="WAN1_chk" and !disabled]] > 0) do... -
válasz
Reggie0
#13377
üzenetére
délelőtt, amikor írtam a kommentet, akkor vettem föl a szabályt, azóta ez az 5 cím került rá, és 24 óra után lejár a ban, szóval nem érzem problémásnak a dolgot. célzott támadás esetén lehetne ezt jól kihasználni, de ezek valószínűleg csak botok, amik időnként végigszkennelik a netet.
(mondjuk az érdekelne, hogy a Creation time miért Atlanti nyári idő szerint kerül naplózásra...
) -
bacus
őstag
válasz
Reggie0
#13364
üzenetére
ok, biztosan igazad van, ennek ellenére nem szakad meg a beszélgetés, vagy ha pingelek kifele nincs csomagvesztés, miközben átvált a cap-k között. Gyakorlatban nekem ez nagyon vándorlásnak tűnik. Pár helyen beállítottam, mindenhol elégedettek.
Ami problémás, az inkább a "nem akar váltani" valamiért kérdése, de amikor valaki sétál a telefonjával, akkor szépen látszik, ahogy a cap-k között váltogat. -
#13369
E.Kaufmann
veterán
Reggie0
#13368
E.Kaufmann
veterán
válasz
Reggie0
#13368
üzenetére
Ha a nulla tapasztalat azt jelenti, hogy fingja sincs a WIFI-ről, akkor tényleg, egyébként nulláról könnyebb összelőni egy Unifi hálót Windows-on futó site-tal, mint CAPSMAN-nal bohóckodni. Amikor nézem a különféle leírásokat és össze-vissza ugrálgatnak a winbox-ban, a hajam égnek áll. Persze be lehet egy példakonfigot is lőni, de azt meg nem fogja tovább értés nélkül reszelgetni. Hozzá képest a Unifi készhez áll. De még egy tipli dekóval is lehet jobban jár ő is, meg az ügyfelei is.
Arról ne is beszéljünk, hogy a Mikrotik cuccok esetén régi kernel és régi driverek vannak vagy legalább is annyira újak, amiket még tudott backportolni, míg Unifi, ahogy néztem OpenWRT alapokon frissebb kernellel és driverekkel játszik.
-
-
válasz
Reggie0
#13287
üzenetére
Ha már szóba jött az IPv6! Ki mennyire jártas a témában?
Van itthon néhány Miki-m : egy routernek (Rb3011), kettő AP-nak, és egy switch-nek.
Pár hónapja kísérlet képen, engedélyeztem mindegyiken az IPv6 csomagot, és mindegyiknek adtam egy belső használatú címet (ULA - Unique Local Unicast) : fd00:0:0:81::1/64, fd00:0:0:81::2/64, fd00:0:0:81::3/64 és fd00:0:0:81::4/64.
Eddig nem is volt gond. Viszont innentől kezdve nagyon (szörnyen) lassú az internetes böngészés a Winows-os gépeken. Mint az kiderült számomra, IPv6-on akartak kimenni a netre. Persze ez nem sikerülhetett nekik, mivel ilyet nem állítottam be egyik Miki-n sem. Sebtapasz megoldásként, letiltottam a Windows alatt az IPv6 kapcsolatot :-(
Erre csak ilyen "csúnyácska" megoldás létezik? -
yodee_
őstag
válasz
Reggie0
#13300
üzenetére
Közben jött egy újabb ötlet. Adott 3 darab hAP ac2.
- 1: fő Router, VPN szerverrel
- 2: másodlagos Router, VPN L2TP+IPsec kliens a fő Routerre.
- 3: harmadlagos Router, VPN L2TP+IPsec kliens a fő Routerre.Mindegyik Router szépen látja a többit és vissza. A rá csatlakozott eszközök szintúgy. Viszont, most jön a csavar. Amennyiben a telefonommal becsatlakozok a fő Routerre akkor csak azt érem el. Sem a másodlagos sem a harmadlagos Routert, sem a rájuk csatlakoztatott eszközöket. Ez miért lehet? Beállítás gond, vagy a telefonon nem lehet ezt megoldani?
Köszönöm
-
ncc1701
veterán
-
mcll
senior tag
válasz
Reggie0
#13238
üzenetére
Úgy látom nem jött vissza szerencsére, a /tmp-ben semmi, a Mikrotik router logjában is csak befele próbálkozás van (ami megszokott) mint ilyenek:
10:26:08 firewall,info SSH! forward: in:pppoe-out-DIGI out:bridge1, proto TCP (SYN), 109.104.151.109:48028->192.168.1.250:22, NAT 109.104.151.109:48028->(78.131.19.90:22->192.168.1.25
0:22), len 60
10:26:30 firewall,info SSH! forward: in:pppoe-out-DIGI out:bridge1, proto TCP (SYN), 109.104.151.109:43256->192.168.1.250:22, NAT 109.104.151.109:43256->(78.131.19.90:22->192.168.1.25
0:22), len 60
10:26:53 firewall,info SSH! forward: in:pppoe-out-DIGI out:bridge1, proto TCP (SYN), 109.104.151.109:38546->192.168.1.250:22, NAT 109.104.151.109:38546->(78.131.19.90:22->192.168.1.25
0:22), len 60
Kifele a tegnap esti javítás óta semmi (illetve csak az amikor én kezdeményeztem ssh-t egy másik külső szerverre, de az ok).De ezeket a fail2ban szépen blokkolja 2 hibás próbálkozás után, gyűlnek is a bannolt IP-k rendesen:
Status for the jail: sshd
|- Filter
| |- Currently failed: 0
| |- Total failed: 9
| `- File list: /var/log/auth.log
`- Actions
|- Currently banned: 30
|- Total banned: 30
`- Banned IP list: 113.161.57.148 116.98.161.19 116.98.167.174 171.240.195.126 172.93.129.188 194.165.16.58 203.159.80.114 221.131.165.23 221.131.165.86 221.181.185.140 221.181.185.143 221.181.185.151 221.181.185.19 221.181.185.198 221.181.185.220 221.181.185.223 221.181.185.237 222.187.232.205 222.187.232.213 222.187.239.31 222.90.28.99 36.71.233.203 45.141.84.10 81.161.63.100 81.161.63.103 81.161.63.253 89.3.71.43 221.181.185.135 115.221.13.230 109.104.151.109 -
mcll
senior tag
válasz
Reggie0
#13236
üzenetére
Nahh aszt hiszem megvan... Kis idő után ez lett a tmp-ben:
root@mcllserver-i3:/tmp# ll
összesen 36K
drwxrwxrwt 9 root root 4,0K márc 12 19:54 ./
drwxr-xr-x 25 root root 4,0K márc 12 15:49 ../
drwxrwxrwt 2 root root 4,0K jan 23 20:41 .font-unix/
drwxrwxrwt 2 root root 4,0K jan 23 20:41 .ICE-unix/
drwx------ 2 root root 4,0K febr 25 09:41 .oscam1/
drwxrwxrwt 2 root root 4,0K jan 23 20:41 .Test-unix/
drwxrwxrwt 2 root root 4,0K jan 23 20:41 .X11-unix/
drwxrwxr-x 3 aaa aaa 4,0K márc 12 02:27 .X25-unix/
drwxrwxrwt 2 root root 4,0K jan 23 20:41 .XIM-unix/A top-ban is látható volt egy TSM alkalmazás "aaa" userrel. És akkor jöttem rá hogy ezt a usert pár nappal ezelőtt hoztam létre, ráadásul samba user is lett csinálva, csak én marha elfelejtettem a teszt után leszedni. Mivel a pass is aaa volt, így nem volt könnyű ezzel bejönni.
Persze kissé agresszív volt ez az alkalmazás, ps ezt mutatta:root@mcllserver-i3:/tmp# ps aux | grep tsm
aaa 30442 0.0 0.0 13304 944 ? S 19:51 0:00 timeout 3h ./tsm -t 515 -f 1 -s 12 -S 10 -p 0 -d 1 p ip
aaa 30443 0.0 0.0 14448 3028 ? S 19:51 0:00 /bin/bash ./tsm -t 515 -f 1 -s 12 -S 10 -p 0 -d 1 p ip
aaa 30448 7.9 0.4 6306356 34260 ? Sl 19:51 0:12 /tmp/.X25-unix/.rsync/c/lib/64/tsm --library-path /tmp/.X25-unix/.rsync/c/lib/64/ /usr/sbin/httpd rsync/c/tsm64 -t 515 -f 1 -s 12 -S 10 -p 0 -d 1 p ipAztán a pkill -KILL -u aaa parancsal kilőttem, gyorsan töröltem a usert, meg a /tmp tartalmát. Azóta nem jött vissza szerencsére, tiszta a Mikrotik logja, csak egy próbálkozás volt befelé:
20:03:03 firewall,info SSH! forward: in:pppoe-out-DIGI out:bridge1, proto TCP (SYN), 104.128.228.18
, NAT 104.128.228.187:59961->(78.131.19.90:22->192.168.1.250:22), len 44Remélem így is marad!
Köszönöm a segítséget. -
Reggie0
félisten
válasz
Reggie0
#13223
üzenetére
Esetleg indonesia4-et is kiprobalhatod, ott nagyobb a dfs mentes tartomany:
[admin@MikroTikCCR] /interface wireless info> country-info indonesia4
ranges: 2402-2472/b,g,gn20,gn40(20dBm)
5170-5320/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(20dBm)
5735-5815/a,an20,an40,ac20,ac40,ac80,ac160,ac80+80(20dBm) -
ekkold
Topikgazda
válasz
Reggie0
#13205
üzenetére
Hát nekem a mikrotiken azóta sem megy. A TCP protokoll úgy néz ki átmegy, de a GRE valószínűleg nem. Pedig ha szűri a szolgáltató a 1723-as potot akkor jól jöhet(-,ne ha működne).
Utoljára ezzel próbálkoztam:
Kliens oldali mikrotik:/ip firewall natadd action=dst-nat chain=dstnat dst-address=szerverIP dst-port=1723 protocol=tcp to-addresses=szerverIP to-ports=51723
Szerver oldali mikrotik:/ip firewall natadd action=redirect chain=dstnat dst-port=51723 in-interface=ether1 protocol=tcp to-ports=1723
A TCP kapcsolat összeáll, és utána nem történik semmi. -
-
-
Beniii06
addikt
válasz
Reggie0
#13199
üzenetére
Nem az erő a lényeg, hanem látszik és kész. Csak az nem veszi észre, aki nem akarja.
Laptopnál is márkánként eltérő mit engednek meg garancián belül, pl. ha van direkt szerviznyílás az alján hdd/ssd vagy ramhoz és azon keresztül cseréled/bővíted az még belefér egyes márkáknál, másiknál már az sem, főleg amelyiknek egyben van az alja és nincs nyílás sem rajta.
-
ekkold
Topikgazda
válasz
Reggie0
#13122
üzenetére
Kipróbáltam így:
/ip firewall natadd action=dst-nat chain=dstnat dst-address=szerverIP dst-port=1723 protocol=tcp to-addresses=szerverIP to-ports=51723
Az eredmény pedig:
A logban annyi látszik hogy a TCP kapcsolat összeállt, aztán semmi....Tehát a GRE protokoll nem megy át... erre valami ötlet?
(próbáltam a GRE protokollra is egy dst-nat szabályt felvenni ugyanúgy mint fent, csak IP-vel, portok nélkül - semmi változás) -
Beniii06
addikt
válasz
Reggie0
#13155
üzenetére
"amugy is mar csak 100.x.x.x-es cimeket szokas osztogatni, "
Kivéve telefonálsz egyet az ügyfélszolgálatra és rögtön kapsz publikus ip-t. Egyébként nehéz kívülről elérni a belső hálózatodat, akkor már nem mindegy, persze igénye válogatja, de ha már fizetsz egy szolgáltatásért, miért is elégednél meg kevesebbel?
Szeretem használni, mire kellene jobban odafigyelni?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
Hirdetés
ekkold- Bambu Lab 3D nyomtatók
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Autós topik
- Diablo IV
- AMD vs. INTEL vs. NVIDIA
- Nehéz helyzetben az SMIC, régebbi chipet használ az új Huawei laptop
- Tőzsde és gazdaság
- Ingatlanos topic!
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- sziku69: Fűzzük össze a szavakat :)
- További aktív témák...
- Új MSI KATANA 17 Gamer Tervező Laptop 17,3" -35% i7-13620H 10Mag 16/1TB RTX 4060 8GB FHD 144Hz
- Apple Iphone 13 128gb csillagfény színű OLCSÓN . Csere/beszámítás
- OnePlus Pad 2 + OnePlus Pad 2 billentyűzet + Extrák
- AKCIÓ!!! GAMER PC: Új i5-14400F +RTX 4060/5060/4070/5070 +Új 16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ!
- HP EliteBook 855 G8, 15,6" FHD, Ryzen5 PRO 5650U CPU, 16GB DDR4, 256GB SSD, WIN 11, ( olvasd végig )
- DOKKOLÓ BAZÁR! Lenovo, HP, DELL és egyéb más dokkolók (TELJES SZETTEK)
- Napi 700 ft tól elvihető RÉSZLETRE BANKMENTES HP 840 G11 Ultra 5
- BESZÁMÍTÁS! Microsoft XBOX One S 1TB lemezes játékkonzol garanciával hibátlan működéssel
- AKCIÓ! Apple Macbook Pro 16" 2019 i9 9980HK 64GB 500GB Radeon Pro 5500M hibátlan működéssel
- Csere-Beszámítás! Sapphire Pure RX 7900XT 20GB Videokártya! Bemutató darab!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest