- iPhone topik
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Fotók, videók mobillal
- Xiaomi 15 - kicsi telefon nagy energiával
- Karaktere biztos lesz az első Nothing fejhallgatónak
- Android alkalmazások - szoftver kibeszélő topik
- Honor 400 Pro - gép a képben
- Apple iPhone 16 Pro - rutinvizsga
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Samsung Galaxy S24 FE - később
-
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
-
mrots
junior tag
válasz
Protezis
#23576
üzenetére
"Olyan előírást, amire én számítanék, miszerint 100.x.x.x IP-ről jövő, public IP-re menő csomagnál is SRCNAT "
Azert, mert ez sehol nem eloiras. Te magad is bemasoltad, mit mond az RFC. Es azt is irtad, hogy teljesul. Azert latsz 100 kezdetu cimeket, mert ezek a csomagok nem hagytak el a szolgaltato halozatat, tehat nem kotelesek cimforditani.
A mikrotik arul eszkozoket ISP-nek, ilyen kontextusban teljesen valid, hogy a dokumentacio azt javasolja, hogy a 100 kezdetu cimek blokkolva legyenek. Mert az ISP nem lathat ilyen forrascimrol bejovo forgalmat a halozat hataran, hiszen az a masik ISP akitol erkezne, RFC szerint cimforditani koteles, hiszen a csomag elhagyja a halozatat.
Szoval a javaslat lehet helyes - attol fugg, kinek szol.
-
ekkold
Topikgazda
válasz
Protezis
#23576
üzenetére
Szerintem kár ezen pörögni. Ez van, így van megoldva. Magánvélemény, de szerintem ez a megoldás jó kompromisszum.
Ha a NAT-olt címről kommunikálna valaki felém, akkor kimehetne egy közös publikus IP-n, amin keresztül eléri a publikus címem, csak akkor feleslegesen foglal portot (v. portokat) az éppen használt közös publikus IP-n, és feleslegesen használja a NAT-otlást. Értem, hogy szerinted ez így nem jó, de a CGNAT (ami egy nem túl jó, inkább kényszerű dolog) miatt még mindíg ez a kevésbé rossz megoldás.
És persze megteheted, hogy blokkolod a saját eszközödön ezt a tartományt. Ezért jó, hogy mikrotiket használunk, mert pár kattintással megoldható a dolog. Pl. én nem fogom tiltani, mert kihasználom, és szerintem ügyes, hogy apóséknál is út tudok elindítani ill. megnézni egy filmet, mesét, stb.. az otthoni NAS-ról, mintha az otthoni PC előtt ülnék.
Igazából az lenne a normális ha nem lenne szükség CGNAT-ra, de mégis ez van. Ugyanakkor nem értem, hogy számodra miért jelent problémát? Vagy inkább, szerinted miért és miben lenne neked jobb, ha "rendes külső IP"-n kommunikálna feléd a többi (egyébként natolt) digi ügyfél. -
#23580
lionhearted
őstag
Protezis
#23579
válasz
Protezis
#23579
üzenetére
Ez nem ajánlás, ez példa leírás. Tényszerű, hogy nem global cím. Ha ez valami otthoni SOHO ajánlás lenne, ez lenne a SOHO default konfig, de ugye nem az. Nem jó mindenhova.
Bárki mondhatja, hogy így szabványos? Mert akkor mondom, be is másoltad. Persze a következő mondat is segíthet a szabványból, vagy a Mikrotik oldaláról:
Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. In RouterOS this can be easily done with firewall filters on edge routers
Az ISP a saját hálózaton nyugodtan forwardolhat ilyen csomagokat, a te publikus IP-d pedig attól, hogy másik subnet, még az ISP hálózata, amiből nem lép ki. Úgy értelmeztem a kommentedet, hogy ezt a részt az RFC-ből te is így olvastad, ez "teljesül". Amit te kívántál a srnattal, olyan meg sehol sincs leírva, "nem teljesül".
A két hipotézis alapján nekem olybá tűnt, hogy nincs problémád a Digi RFC6598 implementációjával. Nincs még egy routere az ISPnek a CGN Router után, hogy a globális, de saját címeket itt külön routeolja.
-
#23578
lionhearted
őstag
Protezis
#23576
válasz
Protezis
#23576
üzenetére
CGNAT nem olyan belső IP, mint a privát IP tartományok... A szolgáltó hálózatán ugyanúgy használható tartomány, ahogy a te publikusod, csak az ezen kívül is. Semelyik cím fordítás nincs "ingyen", feleslegesen terhelné a saját eszközeit egy srcnat, miközben semmi sem indokolja. Leszámítva, hogy neked nem tetszik hogy a többiekkel vagy összezárva.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
ekkold
Topikgazda
válasz
Protezis
#23569
üzenetére
Apóséknál NAT-olt IP van, nálam public IP. Amikor csatlakoznak hozzám (van egy filmnézős weboldal az otthoni NAS-on), annak ellenére, hogy nem vagyok NAT mögött, 100 kezdetű (100.x.x.x) bejövő IP címről jön a kommunikáció. Azaz bár publikus IP-m van a 100 kezdetű belső IP-kkel közvetlenül is lehet kommunikálni, azaz ki lehet kerülni egy dupla NAT-olást.
Szerintem ez összességében nem egy rossz dolog. Sajnos az IPv4 címek mennyisége korlátozott, ezért NAT-olnak, de aki kéri - az kap publikus címet. Tehát végülis elfogadható módon van megoldva a probléma. A tipikus belső címeket (10.x.x.x 172.16.x.x 192.168.x.x) talán tényleg érdemes tiltani - bár szerintem elegendő csak azt, amelyik címtípust használod LAN oldalon. a 100 kezdetű IP-ket meg nem tiltom, mert minek, miért ne kommunikálhatnák más digis felhasználókkal, akkor is ha történetesen ők NAT mögött vannak. Torrentezéskor pl. még hasznos is, mert a net felé ugyan passzív módban vannak, de felém akkor tud(na) aktívan is seedelni.A régen alkalmazott "nagy közös switch" biztonsági szempontból nem túl jó, de
- ennek tudatában is meg lehet védeni a belső hálót,
- vagy akár kihasználható lehetőségként kell kezelni, ha történetesen pont a szomszéddal akarsz kommunikálni - viszonylag jó sebességgel. -
-
ekkold
Topikgazda
válasz
Protezis
#23438
üzenetére
Nálam teljesen stabil az SMB, scriptek is írnak a beledugott pendrájvra, sftp-vel is írok rá távolról, és SMB-vel is elérem probléma nélkül. Akár nagy fájlok írása olvasása is megy stabilan. Nincsenek holtdidők, vagy hosszú megakadások sem.
Nekem jelenleg 7.11.2 van az RB5009-en, de akkor ezek szerint még marad is ez egy darabig. -
válasz
Protezis
#23245
üzenetére
Mikor töröljem ki a default configot?
már a resetnél van ilyen opció, ekkor létre sem jön (ahogy a kolléga fentebb mutatta is). aztán vagy úgy mész tovább, ahogy ugyanott mutatta, hogy az addigra már módosított scriptet importálja is rögtön (run after reset), ekkor az egyetlen manuális dolgod az a user / password létrehozása és kész is vagy.
a B opció, hogy resetelsz, no default config, ekkor nem kapsz semmilyen IP-t, kézzel felveszed a gépednek a jövőbeli tartománynak megfelelőt, MAC addressel rácsatlakozol a routerre, importálod az eddigre már módosított konfigot, user / password -> profit.
azért ez nem akkora truváj
-
-
#23241
lionhearted
őstag
Protezis
#23240
-
-
válasz
Protezis
#23237
üzenetére
te nem akarod érteni, amit írok:
RouterOS-ből hiányzik egy normális text alapú backup
az export / import a textalapú backup. egészen pontosan ugyanazt csinálja, mint a backup / restore, csak scriptbe ment, nem binárisba.
attól félsz, hogy kizárod magad (aminek amúgy szubminimális az esélye, és ha igen, akkor is mi van, resetelsz még egyet), de arra már nem vagy hajlandó, hogy végignézd, hogy mit fog csinálni az import script, hogy tuti ne zárd ki magad
most akkor biztosra akarsz menni vagy sem?Wireguard config belemegy? Elég nyugtalanító, hogy valamit csak úgy kihagy.
semmit nem fog "csak úgy" kihagyni. a show-sensitive kapcsolóval bele fog rakni minden jelszavazott vackot is. -
válasz
Protezis
#23233
üzenetére
Soronként, vagy akárhogy részletekben betöltve nagyon könnyen kizárhatom magam.
ez a lényege a soronként betöltésnek, hogy tudod mi fog történni.De ettől függetlenül az import tudtommal nem feltétlenül írja felül a meglévő configot.
ha valami logikai ütközés van, akkor megáll. ugyanúgy, ahogy a bináris restore is.
de továbbra is: ezért ütöd be soronként, hogy előre lássad mi történik.Nekem olyan egyszerű megoldás kéne, hogy backup text formátumban, átírom benne a címeket, aztán restore.
mert szerinted az export / import mégis mi, ha nem pontosan ez? -
stopperos
senior tag
válasz
Protezis
#23231
üzenetére
Rosszul tudod, elég a sima export és a show-sensitive. Abból vissza lehet tölteni üres eszközre. Egyedül a userek nem lesznek benne (illetve nekem a digis pppoe sem került bele). Tehát:
/export terse show-sensitive file=rb5009.rsc
Ezt letöltöd, Notepad++ segítségével megcsinálod a cseréket. Majd az eszközre visszamásolod. Csinálsz egy Reset configuration-t ezekkel a beállításokkal és a Run After Reset-et beállítod a visszatöltött szkriptre.
Volt hogy 20 eszközt kellett felkonfigurálnom hasonlóan. Az elsőt kézzel beállítottam, lementettem, utána a maradék 19-et Python3+Jinja template segítségével legeneráltam az első alapján, és mehettek fel az eszközökre.
-
válasz
Protezis
#23231
üzenetére
Az exportban meg vagy benne van a default config, ami visszatöltésnél problémát okozhat, vagy nincs benne
az exportban az van benne, ami éppen benne van a routered konfigjában. semmi más.
de ha attól félsz, hogy elakad valahol az import, akkor csináld azt, hogy néhány soronként illeszted be a terminálba, úgy pontosabban nyomon tudod követni, hogy mikor mi történik. -
Audience
aktív tag
válasz
Protezis
#23100
üzenetére
Én kábel végére dugót tettem.
A sarokba kerültek a plafonon.
Ahol a plafonon nem volt elhelyezhető ott a falsarokba került.
POE-s minden, 230V-ot egyikhez sem vittemHa nagyon szépre akarod csinálni akkor felteszel egy rendes 65-ös szerelvénydobozt, abba érkezteted a kábelt és egy minőségi szerelvényt felszerelsz majd patch kábellel abba dugod az AP-t.
-
#22172
lionhearted
őstag
Protezis
#22171
-
#22121
lionhearted
őstag
Protezis
#22120
-
Protezis
őstag
válasz
Protezis
#22119
üzenetére
Épp ezt olvasgatom: https://help.mikrotik.com/docs/display/ROS/Layer2+misconfiguration#Layer2misconfiguration-BridgedVLAN
Nálam ez így néz ki:
/interface bridge vlan
add bridge=bridge comment=Management tagged=bridge vlan-ids=10
add bridge=bridge comment=Home tagged=bridge,ether5,ether6 untagged=ether3,ether4,sfp-sfpplus1 vlan-ids=20
add bridge=bridge comment=DMZ tagged=bridge untagged=ether1,ether2 vlan-ids=30
add bridge=bridge comment=IoT tagged=bridge,ether5,ether6 vlan-ids=40
add bridge=bridge comment=Guest tagged=bridge,ether5,ether6 vlan-ids=50
/interface vlan
add interface=bridge name=vlan10-management vlan-id=10
add interface=bridge name=vlan20-home vlan-id=20
add interface=bridge name=vlan30-dmz vlan-id=30
add interface=bridge name=vlan40-iot vlan-id=40
add interface=bridge name=vlan50-guest vlan-id=50Jó egy így? Az
/interface vlanalattiakat ki kellene törölnöm? De azokat interface listekben használom, amiket meg firewall filter rule-okban használom. -
#22118
lionhearted
őstag
Protezis
#22115
válasz
Protezis
#22115
üzenetére
Nem érted félre. Bár a fastpath nem switch chipen belüli dolog, de mivel semmilyen ágra nem használhatnál IP szűrést, nyilván egy routert nem lehet úgy üzemeltetni. A Fasttrack is fastpath-ot használ a háttérben, csak kell hozzá a connection tracking. FT mellett is pörgeti a CPU-t rendesen a ROS, senkinek se 0-5% mellett dolgozik.
Nehezen bírta az agyam elengedni, hogy ne lenne képes nagyobb sebességre, ha már ott a 9GBps hivatalos teszt és a 10G link a CPUhoz. Jómagam otthon a CRS326-tal (igen, L3HW) végzem el a piszkos munkát. Ezek szerint okkal kerül ugyanannyiba, mint egy RB5009.
Így nagyjából teljesen mindegy mit teszek utána...Most olvastam el a linket is, amit küldtél utoljára. 1 streamre nézted te is?
A hivatalos teszt egyébként frissült kiadás óta, nagyobb értékek vannak rajta, lehet érdemes FW-t is frissíteni. -
#22111
lionhearted
őstag
Protezis
#22108
válasz
Protezis
#22108
üzenetére
Egy dolgot nem értek. Ha van bridge vlan filtering, akkor miért tettél rá IP filtert? Nagyobb belső forgalmat nem kellene a fasttrackre bízni, mert véges számú kapcsolatot tud kezelni.
Frissítve van?
Ha jól láttam (és remélem nincs belőle új rev), akkor egy switch-en vannak a portok, így switch ACL-lel (kb. stateless firewall) tudod tiltani az egyes irányokat. Leírás.U.i: > L3 HW Offloadot sajnos nem tud ez a router, szóval a CPU-n mindenképp átmegy az inter-VLAN routing.
Ez esetben a kommentem vége nem játszik.
Viszont ha nincs IP filter rá téve, akkor fastpath lesz, nem fasttrack. -
![;]](http://cdn.rios.hu/dl/s/v1.gif)
A fórumra direkt módosítottam a helyi IP címem, de a printscreen lebuktatott. 
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Honor 200 Pro 512GB, Kártyafüggetlen, 1 Év Garanciával
- Lenovo Thinkpad L14 Gen 4 -14"FHD IPS - i5-1335U - 8GB - 256GB - Win11 - 2 év garancia - MAGYAR
- Apple iPhone 14 PRO - 128GB - Deep Purple - 85% akkumulátor
- GOPRO Hero 11 BLACK akciókamera - különlegesség!!! Labs fw 01.20.70
- DJI Mavic 3 Pro RC - drón szett új állapotban - 2 akkuval
- Honor X6b 128GB Kártyafüggetlen 1Év Garanciával
- Bomba ár! HP ProBook 430 G3 - i5-6GEN I 8GB I 256SSD I HDMI I 13,3" HD I Cam I W10 I Garancia!
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- Új Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 3 Év Garanciával
- Bomba ár! Dell Latitude E5570 Touch - i5-6300U I 8GB I 256SSD I 15,6" FHD I HDMI I CAM I W10 I Gari
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest