- Doky586: Adattár lemez előkészítése távlati Windows telepítéshez
- eBay-es kütyük kis pénzért
- sellerbuyer: Milyen laptopot vegyek? Segítek: semmilyet!
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- sellerbuyer: Te tudod, mi mennyit fogyaszt az otthonodban?
- ricsi99: 6. Genes alaplap tündöklése.. kontra MS/Zintel korlátozásai.(Mehetnek a levesbe)
- sh4d0w: Tele a hócipőm
- sziku69: Szólánc.
- gban: Ingyen kellene, de tegnapra
-
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
-
mrots
junior tag
válasz
ekkold
#24968
üzenetére
"Egyébként van értelme két betárcsázásnak? Pl. gondolom az össz sávszél nem lesz nagyobb... vagy? ill. akkor ad két publikus IP-t is?"
Persze, hogy van. Szuloknel ket router lerakva, mindketto onalloan kapcsolodik ugyanabba a bridge modban levo modembe, a LAN oldalukon pedig HSRP/|VRRP. Router hiba eseten a masik viszi tovabb a musort, nem kell odarohanni megnezni, miert nincs internet, tavolrol is megy. Szolgaltatoi hiba esetere pedig ott a 4G tavoli eleres.
-
#24913
mrots
junior tag
E.Kaufmann
#24912
mrots
junior tag
válasz
E.Kaufmann
#24912
üzenetére
Kuldhetne, bar pont a mikrotiknal gazabol, mivel a szoftver es a feature lenyegeben mindegyiken ugyanaz, egy rekesz sor arabol igazabol mar fel lehet epiteni egy labort amin tanulni lehet. Nem lesz kurrens hardver, nem lesz gyors, nem fog tudni gigabiteket mozgatni, de a feature-oket megtanulni beallitani teljesen jo. A kerdes valoszinuleg az, hogy egy certifikalt mikrotik tudassal el tudsz-e legalabb annyira boldogulni egy cisco vilagban, mint egy cisco certifikalt tudassal a mikrotikban? Mert szerintem nem, de lehet masok mas velemenyen vannak.
En az enyemet arra alapozom, hogy a cisco altalaban innovativ volt es most is az, tehat talal ki uj dolgokat, csinal uj szabvanyokat. Ne felejtsuk el, hogy hamarabb volt vlan taggeles ciscoban, mint a szabvany (ISL vs 802.1q), hamarabb volt kulonbozo STP funkcio ciscoban, mint a szabvany (PVST, PVST+), hamarabb volt PoE ciscoban, mint a szabvany (pre-standard vs 802.3af) es meg szamtalan dologra igaz ez. Lehetne folytatni a sort, mint peldual CDP vs LLDP, HSRP vs VRRP, IGRP vs RIP, EIGRP vs OSPF. Nem az a lenyeg, hogy melyik a jobb, hiszen kb egyformak, a lenyeg az, hogy (bar nem ellenoriztem mindegyik keletkezeset) de a cisco kitalalt valamit, ami meg nem volt, aztan az ipar ment utana es nyilt szabvanykent kb ugyanazt ledefinialta, utana pedig mar mas eszkozokben is lehetett hasznalni. Es ez ma is mukodik, peldaul nem lattam meg SGT-t illetve SXP-t mikrotikon, sem pedig DMVPN-t akkor, amikor a cisco mar elerhetove tette azt az eszkozein. A VXLAN is egy jo pelda, ami ugyan egy szabvany ma mar, de annak a kidolgozasat kozosen csinalta az arista, vmware es a cisco. A mikrotikot nem latom a sorban, abba csak belekerult amikor lett ingyenes implementacioja linuxban.
A mikrotikban igazabol eleg nehezen tudnek egy olyan feature-t felhozni, ami korat megelozoen letezett bennuk es ahhoz, hogy azt a dolgot hasznalni tudd, feltetlen mikrotikot kellett venned. A mikrotik szep lassan halad a csorda kozepen es implementalja a ROS-ba azokat a dolgokat amik mar leteznek es szabvanyositva vannak. Amivel nincs kulonosebb gond, de vannak, akik a csorda elejen haladnak es a piacot ez viszi elore, nem pedig az, hogy megyunk a tomeg utan. Emiatt gondolom azt, hogy cisco tudassal sikeresebb vagy a mikrotik vilagban, mint forditva, tehat az iskolakban valoszinuleg jobb otlet ciscot tanitani.
-
#24911
mrots
junior tag
E.Kaufmann
#24910
mrots
junior tag
válasz
E.Kaufmann
#24910
üzenetére
Pusztuljak meg de nem ertem a mondanivalod lenyeget. Minden gyarto eseten, ahol a konfiguralas bonyolultabb, mint next-next-finish, ott van egy tanulasi gorbe. Miert gondoljuk, hogy mikrotik eseten nincs ilyen vagy miert gondoljuk, hogy ha mikrotikon tanul epp valaki akkor az ugyfel turelmesebb, mintha ciscon tanulna?
-
#24909
mrots
junior tag
D-LAN|FuRioN
#24903
mrots
junior tag
válasz
D-LAN|FuRioN
#24903
üzenetére
"ha új vonalú Cisco eszközöket használtál már (nem 50 ezres kategóriában) akkor legszívesebben felgyújtanád kb"
Mondjuk inkabb ugy, hogy az elmult 20 evben olyan cisco eszkozokon dolgoztam egy-egy ugyfelnel amelyek nem, hogy 50ezer felett vannak, de az arukbol kulon-kulon egy kisebb falut is siman megveszel .
"1+ millás controllerrel"
Ezt nem ertem, eleve nagyon pici deployment lehet, ha egyetlen kontroller van csak. Az en otthoni halozatomban van csak egy kontroller. Az arkategoriat sem teljesen ertem, ez akkor valami licensz nelkuli kis vacak lehet. Egy tisztesseges kontroller megfelelo licenszekkel es supporttal listaaron 10-11 millio korul van, nyilvan ebbol meg lejonnek a partneri kedvezmenyek, cserebe viszont en meg nem lattam olyan halozatot, ahol ilyenbol negynel kevesebb lenne."szabványos POE+, POE++(60W) tápokkal nem volt hajlandó elindulni, console-on az arcodba vágja, hogy ismeretlen tápegység, ezért kikapcsolja a rádiókat"
Akkor annyira megsem szabvanyos az, bar nem derul ki, mifele eszkozrol beszeltel.
"szóval home környezetben egy ilyen ap kvázi használhatatlan, egy főfal elválasztás után gyakorlatilag minden frekvencián halott"
Nem tudom milyen konkret tipusrol irtal mert az nem annyira derult ki a sok smiley kozott, de egyreszt 1) szerintem ez nem baj, legalabb nem zavarom a szomszedot es o sem engem, 2) lehet, hogy azt a konkret tipust amit neztel nem home kornyezetbe szantak - traktort sem autopalyara vesz az ember, 3) rakjal fel tobb AP-t, nalam is ketto van mert ugy jott jobban ki ebben a lakasban."létrehozol egy kupac dolgot felépíted utána nem tudsz belenyúlni a közepébe, mert sorban vissza kell menned mindenen. Na ilyen a Cisco"
En is ilyennek lattam, amikor nem ertettem hozza."Ciscot részben a neve részben a lusta régi rendszergazdák viszik előre akik a multis környezetben a 30 év alatt oda szocializálták magukat, hogy 1, nem akarnak érteni hozzá 2, nem is értenek."
Ez is egy velemeny, megha szerintem butasag is.
-
mrots
junior tag
válasz
Reggie0
#24832
üzenetére
Sajnos nem, legutobb peldaul egy 4 honapja mukodo 7/24-ben online wap lte hirtelen ugy dontott, hogy nem latja a modemet, ezaltal a sim kartyat es a tererot sem es ezaltal offline lett. Namost ez tobb ezer km-re van tolem. Mokoltam vele tavolrol egy egesz napot, ujrainditasok, stb, semmi, zero. Ugy tunt kompletten megmukkant. Aztan egy honappal kesobb megint rafekudtem es nem tudom mit csinaltam maskepp (a logok szerint ugyanazokat csinaltam) de az egyik usb reset utan eletre kelt es par perc mulva latta a sim kartyat es a mobilhalozatot is.
Ez nem normalis, ez nem megbizhato. Ami megbizhato, az a cisco routerem, amiben van egy 4G LTE modul, benne sim kartyaval es 2019 ota, hat eve megallas nelkul uzemel, 7/24, nem bootolt el, nem romlott el, nem vesztette el a tererot, nem csinal az semmit, csak amit kell neki: uzemel. Teszi a dolgat. Ez megbizhato.
A 4G LTE modul volt 2019-ben valamivel tobb, mint szazezer forint (csak a modul, a router ara ezen felul van). A wap lte kevesebb, mint egy eve van meg, kb 9 honapja, ezalatt volt egy 1+honapos megmagyarazhatatlan leallasa es a beszerzesi ara az egesznek, tehat router + lte modem kb huszezer forint.
Ez a router egy LTE router. Az LTE kepessegeert vettem es semmi mast nem csinal, mint mobilnetet ad ket vezetekes vegpontnak. Nem hinnem, hogy ez a kepessegeinek a tulhasznalasa lenne.
-
mrots
junior tag
válasz
HUNited
#24828
üzenetére
"Kicsit olyan érzésem van hogy a Mikrotik két szék között van."
Szerintem nincs, mert eleve ket teljesen eltero szegmensre lonek. Egyreszt a termekeiket veszik azok a rutinosabb felhasznalok akik mar kinottek a szappantartok kapacitasat. Sajnos az o helyzetuk nem rozsas mert valoban: jo mikrotik dokumentaciot akkor talalsz, ha irsz magadnak. Rettento sok informacio, wiki, howto van neten... csak a ketharmaduk elavult, vagy konkretan hibas is. Nem veletlenul van a leggyakrabban elkovetett hibakra kulon wiki oldal. Ami pedig nem hibas es nem elavult, az meg olyan 50-50 hasznalhato, vagy kuka. Konkret peldakat, ertelmezest, gyakorlati utmutatot nehezen talalni szerintem.
Ebbe a halmazba tartozonak erzem magam is, mert amugy sem a hardver nem kulonosebben megbizhato, sem a konfiguralasa nem annyira intuitiv, mint egy cisco vagy palo alto de sajnos egy ido utan az embernek el kell engednie otthonra a ciscot. Most ahol lakom, csak VDSL van, ezt rohogve elviszi (igaz, a fogyasztasa a cisco 1941-nek nem keves) de a kovetkezo koltozes utan varhatoan 500 mbit lesz a WAN link - erre ha cisco routert akarok, akkor nagy is lesz, sokat is fogyaszt es hangos is lesz. Lakasba ez mar nem jo. Az ara meg nem is veszes, mert licensz is kaphato ebayen szoval mindig lehet kifogni jo deal-eket. De az a helyzet, hogy valoszinuleg mikrotikra kell migralni, mert keveset fogyaszt, tudasban majdnem ott van, igaz, megbizhatatlan de majd akkor ket mikrotik lesz amik VRRP-znek. Igazabol ha lenne a cisconak olyan eszkoze ami kicsi, kompakt es viszi a fel gigat, soha eszembe nem jutna mikrotik fele fordulni. Eleve rohejes, hogy egy halozati eszkozt a CPU-val meg a rammal marketingelnek. Ez egy router. Az erdekel, hogy mennyi packet/s, bit/s amit ki lehet belole hajtani. Pont teliberakom mekkora cpu van benne, senkit nem erdekel.
A masik halmaz viszont az ISP-k, es most nem nagy neves ISP-kre kell gondolni, hanem kis csoffadtakra, akik viszont nagy tetelben tudjak venni a hardvert es kiszorni az ugyfeleikhez. A nagyok megvesznek negyven raklap szappantarto routert kinabol kilora, ceges logoval brandelve, custom szoftverrel. A kicsik viszont rakjak ki a mikrotiket.
Az elso halmaz valoszinuleg sehol nincs, hogy eltartsa a ceget, de a masodik azt gondolom eleg jovedelmezo lehet. Elvegre vannak olyan VPN cegek is, amelyek lockolt mikrotikot adnak a vpn szolgaltatasukhoz.
-
mrots
junior tag
válasz
gabro0
#24801
üzenetére
"Amikor bekapcsolom a filteringet, akkor elszáll minden forgalom a routeren"
Ha nem vagy biztos benne, hogy a konfiguracio hibatlan (tehat fennall a lehetosege, hogy kizard magad) akkor celszeru az egyik switch portot kihagyni minden bulibol es csak ugy hagyni konfiguracio nelkul. Ha ki is zarod magad, ezen a porton mac cim alapjan winbox-szal vissza tudsz jutni barmikor.
Majd ha elkeszult, amit csinalni akarsz, a vegen majd ezt az egy portot is berakod a tobbi melle a bridge-be, ha mar tudod, hogy a kesz konfig jo.
-
mrots
junior tag
válasz
HUNited
#24802
üzenetére
Nem teljesen ertem mi a problemad. Semmi olyat nem adnak a penzert, amit sajat magad ne tudnal egyedul megtanulni. Kitartassal. Laborral. Ujra es ujra probalkozassal. Internetes keresesekkel, kudarcokkal es vegul sikerrel.
Ha sok a 135k, akkor a fenti ut ingyen van, senki nem tart vissza, hogy onerobol megtanulj barmit, amit meg akarsz tanulni. Ha viszont az kell, hogy valaki mas, aki ezt vegigcsinalta (es ujra meg ujra vegigcsinalja, mert a dolgok valtoznak a verziokkal, az ember meg felejt) az fogja a kezed, segitsen esetleg meg tanitson is teged - nos, akkor azt fizeted meg, hogy neked mindezt a keserves melot nem kell beletenni. Ennek semmi koze a hardverhez, az, hogy vannak emberek akik lustak, nem egy konkret gyartohoz kotodik. Meglepodnel, ha tudnad, az en oktatasaim milyen aron mennek (hint: szorozd meg egy ket szamjegyu szammal).
-
#24775
mrots
junior tag
E.Kaufmann
#24774
mrots
junior tag
válasz
E.Kaufmann
#24774
üzenetére
"Arra pont jó, hogy akárki ne dughassa fel a saját vackát valamint kliensenként külön VLAN-t is ki tudnál osztani."
Egyikhez sem kell 802.1x, e nelkul is meg lehet oldani mindkettot. Mondom ezt ugy, hogy itthon en 802.1x -et hasznalok es nem hiszem, hogy normalis ember uzembiztosan akarna ezt csinalni - kezdjuk ott, hogy kapasbol ket radius szerverre van szukseg ahhoz, hogy ha egy elromlik, meg attol hozza lehessen ferni a halozathoz hibajavitas cimen. -
#24773
mrots
junior tag
E.Kaufmann
#24761
mrots
junior tag
válasz
E.Kaufmann
#24761
üzenetére
"vezetékesen kell hozzá 802.1x talán"
A 802.1x -nek semmi koze a szeparalashoz.Alhalozaton beluli szeparalasnal egy logikai bukfencet kell megoldanod. A szeparalasnal abban gondolkodsz, hogy ket ip cim ne tudjon egymassal beszelni. Ez hibas. Alhalozaton belul nem kell IP cim a kommunikaciohoz, mac cimek alapjan tortenik a beszelgetes (peldaul ezert tudsz ip cim nelkul winboxon hozzaferni egy mikrotikhoz azonos halozatban). A szeparalas tehat nem IP cim szinten kell megtortenjen, hanem MAC cim szinten.
Erre ket megoldas van. Az egyik a private vlan (nem sima vlan) amit szerintem a mikrotik nem tud. A masik a linuxbol ismert ebtables ami az iptables masodik reteg-beli implementacioja. Ez utobbi akar meg mukodhet is mikrotikon.
A tobbit leirtak masok. Az eredeti kerdezonek pedig le kellene ulnie es atgondolnia mit akar, mert szerintem maga sem tudja meg.
-
mrots
junior tag
válasz
nemurea
#24744
üzenetére
"A cAP ac-on 6.x-es RouterOS van, ez kb. a legújabb, amit a stable ágon felajánl. Ott van az upgrade-en a 7.x, érdemes, szükséges frissítenem, vagy most ez így a tuti"
- nezd meg, hogy a szoftver hardverkovetelmenyeinek a doboz megfelel-e (es nem csak ugy, hogy eppen)
- nezd meg, van-e olyan feature a 7.x -ben amire konkretan szukseged van
- nezd meg, a jelenleg hasznalt feature-ok bekonfiguralasa ugyanugy tortenik-e vagy maskeppHa a vason nem fut megbizhatoan a 7, vagy ha amugy nincs is semmi olyan amit biztositani tudna amire szukseged van illetve meg raadasul a szintaxis is megvaltozott es maskepp kell konfiguralni (peldaul BGP 6-ban mashogy van, mint 7-ben) akkor van harom indokod a nem frissitesre. Ha futna, van olyan es ugyanaz vagy nem banod a tanulast, akkor van harom indokod a frissitesre. A ketto kozott pedig egyeni merlegeles, hogy megeri-e.
"Plusz ahogy olvasom, a roaming magára a kliens eszközre van bízva, hogy váltson az erősebb AP-re. Ezzel kapcsolatban javaslat"
az, hogy egy vegpont valt egy masik AP-re, az onmagaban meg nem roamingolas.
-
mrots
junior tag
válasz
ekkold
#24707
üzenetére
A hatar elmosodott mar, kulonosen a multilayer switchek letezesevel, amik lenyegeben routerek. Nincs univerzalis szabaly, de vannak jellemzok.
Jellemzoen a routereknek kevesebb fizikai portja van, a switcheknek tobb, mivel a switchek feladata az, hogy fizikai hozzaferest adjon a halozathoz az eszkozoknek (= bele tudjal dugni sok dolgot) a routernek viszont nem ez a feladata. A router osszekot halozatokat, esetleg kulonbozo mediumokon - peldaul egy ethernet halozatot egy LTE halozattal, hogy kijuss az internetre, vagy egy ethernet halozatot egy DSL halozattal, megint csak, hogy kijuss az internetre, vagy, akar ket vagy tobb ethernet halozatot kot ossze, amelyek kulon-kulon onallo broadcast domainek. Egy eszkozt aminek ket ethernet portja van valoszinuleg nem arra terveztek, hogy 16 ip telefont belekoss, hanem inkabb arra, hogy ket ethernet halozatot osszekosson egymassal, tehat valoszinu inkabb routerkent marketingelik. Vannak 16 portos routerek? Nyilvan, bar kicsit csalas, hiszen egy 16 portos switch modult barmikor tehetsz egy cisco routerbe - ettol az switch lesz? Nem igazan, csak felruhaztad switch kepessegekkel a routert, aminek gyarilag van mondjuk harom portja es kesz.
Jellemzoen a megvalositott feladatok atfedesben vannak, hiszen ugyanazt a feladatot meg lehet valositani hardverbol es szoftverbol is. A kerdes az, hogy mi a fo feladata az eszkoznek? Egy routernek inkabb a forgalomiranyitas, a routing protokollok ismerete, a csomagok szurese (acl), korlatozasa (qos), vpn felepites, ezeket csinalja leggyakrabban, tehat layer 3 es layer 4 feladatokat. Tehat egy routernek azt lehet inkabb nevezni, ami ezeket hardverbol tamogatva csinalja, mert azt jelenti, hogy erre terveztek. Tud emellett switch is lenni? Hogyne tudna, barmikor osszebridge-elek ket ethernet portot egy cisco routeren es maris switchkent viselkedik. Erre terveztek? Nem, csak ezt is tudja, de ettol nem lesz switch.
A switcheket inkabb keretek tovabbitasara terveztek, inkabb layer 2-ben mukodik, tehat olyasmikkel foglalkozik allandoan, hogy mac cimek alapjan donteshozas (snooping, arp inspection), ACL, feszitofa protokollok, vlanok. Ezeket mind hardverbol csinalja, mert erre terveztek tehat ezt tudja a leggyorsabban csinalni. Tud ezen kivul routingot? A multilayer switch hogyne tudna. Sot, mar 20 eve is a 6500-as catalyst switch ezeket is hardverbol csinalta. Annyira, hogy a 6500-as switch es a 7600-as router gyakorlatilag ugyanaz a platform volt. Tud dhcp szerver is lenni, ha kell, tud egy csomo olyan funkciot amit egy router tud. Leginkabb azonban szoftverbol, mert nem erre terveztek, de tudja ezt is.
En igy dontenem el, hogy router-e vagy switch-e. Egy routeren ritkan van PoE port, mert olyan vegpontokat amik ezt igenylik, nem routerbe kotsz kozvetlen, hanem switchbe es a switcheket fogja ossze a router. Ennek ellenere persze nekem is van otthon tartalekban egy 1941-es cisco router amiben van egy 8 portos gigabites switch modul ami PoE-t tud adni. De megint csak arrol van szo, hogy egy routerbe teszek switch modult, tehat ket hardveres eszkozt rakok egybe, hogy ne ketto legyen kulon.
A jozan esz szerint ez az eszkoz egy multilayer switch, tehat szerintem helyesen hivjak switchnek.
-
mrots
junior tag
válasz
HUNited
#24697
üzenetére
"Állítólag a Mikrotik nagyon jó hardver és szoftver."
Nezopont kerdese, vannak akik szerint a wifi eszkozeik nem tul jok - en is hajlok erre. A szoftver olyan tekintetben jo, hogy valoban sok dolgot lehet konfiguralni, de azok amiket leirtal szerintem vagy csak nagyon eros scriptelessel oldhatoak meg, vagy talan meg ugy sem. Szoval a szoftvere jo, de nem biztos, hogy minden jelenleg megoldott funkciot ugy ahogy van egy az egyben meg fogsz tudni oldani egy mikrotikon is, mert a szoftvere nem erre van tervezve. Biztosan van aki lescriptelne minden funkciodat amit leirtal de szerintem pont ezek egy szabadabb OS-en (egy nativ linuxon) konnyebben megoldhatoak, mint RouterOS-ben.Par gondoloat:
- en nem migralnek addig, amig ki nem deritettem, hogy mi okozza a jelenlegi problemakat (az, hogy "eldobja a klienseket" az nem muszaki leiras, nem lehet vele mit kezdeni). Ha nem tudod mi a problema, honnan tudod, hogy egy masik eszkozzel nem lesz ugyanez?- 25 eszkoz az semmi, de meg 50 se sok, attol fuggoen, hogy mit csinalnak. Halozati eszkozoknel a session szam, a kapcsolat per masodperc, a csomag per masodperc es a savszelesseg az ami szamit, nem az, hogy hanyan vannak
- en elkepzelheto, hogy lepesenkent migralnek. Ugy latom jelenleg ket problemad van. az egyik, hogy az asus valamit nem csinal rendesen es emiatt ujra kell inditani. A masik a wifi lefedettseg. En lehet, hogy szetszornek par AP-t a hazban, amik csak AP-k, javitva a lefedettseget, az asust pedig akkor cserelnem, ha kitalaltam, hogy 1) mi az ami a mostaniban nem mukodik es egy uj hardverben mukodni fog, 2) minden funkciot tudom, hogy mikepp fogok megvalositani
- a szuloi felugyelet is sok mindent jelent, nem tudom nalad mi van megvalositva. Nalam a szuloi felugyelet a kovetkezoket jelenti es ezeket mikrotik nem tudja sajat maga mind, kulso szerver kell hozza (szerverek, mert peldaul a radius szerver hibaja eseten is kell tudni internetezni):
* 802.1x van radius szerverrel, ami felhasznalotol fuggoen sorolja az eszkozt a gyerek vagy a felnott VLAN-ba, attol fuggoen ki jelentkezett be az eszkozon
* bizonyos accountok csak bizonyos mac cimeket hasznalo eszkozokrol tudnak bejelentkezni
* a veletlenszeruen generalt mac cimek nem tudnak csatlakozni
* a radius szerver session accountingot csinal, azaz minden heten van egy adott ido, amit online lehet tolteni, valamint egy adott MB mennyiseg, amit forgalmazni lehet, ennek elerese utan az autentikacio sikertelen (hetfon nullazodnak az ertekek)
* van idoablak is, amin kivul az autentikacio sikertelen (peldaul este 9 utan es reggel 8 elott)
* van transzparens proxy, amin blacklist van URLekrol, IP cimekrol amik nem toltodnek be
* van SSL decryption MITM-mel megvalositva, a csaladi eszkozokon a sajat PKI CA-ja trusted
* sajat DNS ami nem gyerekbarat domaineket elterit egy landing page-re- az AX nem elavult szabvany, jelenleg a masodik legfrissebb, sot, ha okos otthon eszkozeid lesznek valoszinuleg egy csomo nem is tudja meg az AC-t sem, hanem legfeljebb az N-et (tehat bar regi, lathato, hogy az N sem elavult meg).
- a chateau biztos jo, de szerintem a legtobb funkciot nem o fogja vegul megvalositani, igy igazabol egy olcsobb is megteszi szerintem
- szerintem a router legyen router es csinalja azt amire terveztek: intezze a halozatot. a szoftveres dolgokat meg csinalja valami, ami amugy is lesz: a home assistant sem fog routerOS-en futni, tehat kulso szerver mindenkepp kell
-
mrots
junior tag
válasz
ekkold
#24678
üzenetére
"Igazából biztonsági kockázatot is jelent a bekapcsolása"
Amugy szerinted miert? Mert szerintem kulonosebb kockazatot nem jelent. Az egesz beallitas arrol szol, hogy TCP RST szegmenseket nem dobunk el, amik a csuszoablakon kivul vannak. Milyen tamadas az, ami megvalosithato azaltal, hogy nem dobod el ezeket?
-
mrots
junior tag
válasz
ekkold
#24669
üzenetére
Ez valoszinuleg nem a jo megkozelites. Az enyem sem biztos, hogy jo. De en inkabb akkor kapcsolnam be, amikor a wireshark szerint olyan szegmensek erkeznek a negyedik retegben (TCP - ISO/OSI transzport reteg) amely szegmensek kivul esnek a csuszoablakon. Ezeket normalis esetben eldobna az eszkoz. Normal esetben ilyen forglamat az ember nem varna, hiszen a TCP handshake soran a csuszoablak merete is egyeztetesre kerul, tehat a kuldo pontosan tudja, hogy a fogadonak mekkora buffer all rendelkezesre es csak annyi adatot kuld, nem tobbet. Tehat normal mukodes soran erre nincs szukseg. Viszont a linux kernelben regota benne van, tehat gondolom annyi tortenik, hogy a mikrotik kivezet a felhasznaloi feluletre egy beallitast ami eddig nem volt lehetseges azon, de maga az OS eddig is tamogatta volna.
Az egyetlen eset ami eszembe jut amikor erre talan szukseg lehet, a TCP challenge ACK. Ekkor a haromutas kezfogas nem az iskolaban tanult modon zajlik le, hanem a TCP SYN-re a cimzett egy SYN nelkuli ACK-t valaszol vissza, raadasul egy olyan sorszammal ami nem passzol a szekvenciaba. Ez normalis, igy mukodik a challenge ACK. Erre harmadik csomagkent egy RST kell, hogy menjen az eredeti kapcsolatot kezdemenyezotol. Ez az RST elkepzelheto, hogy eldobasra kerul, ha a beallitas ki van kapcsolva. Nem ellenoriztem, nem olvastam el az RFC-t, szoval lehet tevedek, de most nekem semmilyen mas legitim ok nem jut eszembe, amiert egy RST-t el kellene fogadjak, nem pedig eldobnom.
Ha tehat a mikrotikom tuzfalkent funkcional egy forras es egy cel kozott, akkor amennyiben a cel challenge ACK-t hasznal, e nelkul a funkcio nelkul sosem fog tudni egy TCP kapcsolat felepulni, szerintem.
-
mrots
junior tag
-
mrots
junior tag
válasz
grabber
#24351
üzenetére
Valoszinuleg o csak a bentrol kezdemenyezett forgalomra gondolt, ahol a visszatero forgalom kezelese trivialis. Nem gondolt a kintrol kezdemenyezett forgalomra, ahol a visszatero forgalom kezelesehez marking vagy egyeb routing szabalyok szuksegesek. Mondjuk ezt meg mindig nem hivnam szkriptelesnek, csak tuzfal szabalynak.
-
#24226
mrots
junior tag
Alteran-IT
#24224
mrots
junior tag
válasz
Alteran-IT
#24224
üzenetére
"Számomra ez még mindig egy modernebb dizájn elem, ami olyan elvárás is lenne egy komolyabb router esetén mint opció"
A csapatom durvan 3500 halozati eszkozt uzemeltet. Nem csak, hogy jogosultsaguk sincs bemenni az adatkozpontok egyikebe sem (nem nyitja a kartyajuk, az enyem sem) de biztosan tudom, hogy van koztuk legalabb 6-7 olyan ember, aki eleteben nem latott meg olyan eszkozt fizikai valojaban (tehat nem foton) amit amugy 8 oraban uzemeltet evek ota. En peldaul eletemben nem fogtam a kezemben palo alto tuzfalat, pedig jo regota uzemeltetek tobb szazat.
El nem tudom kepzelni, kinek kell LCD kijelzo. Dolgoztam sufni bt-nek is regen, a halozati eszkoz ott is el volt zarva valami rackbe, ami egy zart szobaban volt. Oda be nem ment senki. Minek is ment volna?
-
mrots
junior tag
válasz
zelikocc
#24173
üzenetére
"Esetleg arra is várok tippet, hogy a S2S forgalom az IPSec vagy WG legyen?"
Nalam is ugyanilyen felallas van, csak bonyolitva BGP-vel, IPv6 routinggal. En az ipsec mellett tettem le a voksomat, tobb okbol is.
1) azt akarom, hogy platformfuggetlen legyen a megoldas. Mivel nalam is tobb orszagban van leteve halozati eszkoz a csaladban, ahol nem feltetlen tudok azonnal megfordulni, ha gond van, mindenhol van lerakva tartalek eszkoz is. Van, ahol hot backup, tehat HSRP / VRRP billenti a forgalmat at, van ahol cold backup, tehat a fiokban vagy egy tartalek, elore felkonfiguralt eszkoz. Viszont mivel az eszkozpark igy nagy, nem mindenhol van ugyanolyan. Van, ahol cisco router az elsodleges de mikrotik a masodlagos eszkoz, van ahol forditva, van ahol linux miniPC van tartaleknak. Tehat nekem fontos, hogy a VPN-t olyan protokoll implementalja ami platformfuggetlen, amibol igazabol egyetlen egy van: az ipsec.
2) nekem fontos, hogy tobb fajta protokoll fut a VPN-en belul. Fut nyilvan ipv4, de ipv6 is, azert, hogy a kulonbozo lakasok egymast akkor is a VPN felett erjek el, ha IPV6-on cimzik egymast. Ezen tulmenoen fut VXLAN is, szinten ipsec-be agyazva. Raadasul, mivel vannak olyan lakasok ahol dupla eszkoz fut (hotbackup) ezek mindegyike sajat VPN tunnelt epit fel a tobbiekkel, ezek kozott pedig dinamikus routinggal tortenik az utvonalvalasztas. Ezt nekem a legegyszerubben egy ipsec felett futo GRE tunnel tudja megvalositani, amiben a routing protokollok is tudnak kozlekedni.
-
mrots
junior tag
Ismerkedem a vxlannal es elakadtam, erdeklodnek, hogy szerintetek merre tovabb / hol a hiba?
Ket hap ax2, 7.12 es 7.15 kozott van a vxlan. Mindket mikrotik mogott tobb vlan van, de csak az egyik a lenyeges. Az egyik oldalon van egy vlan 6 amit ki akarok terjeszteni a masik mikrotik moge. Direkt vxlan-nal, nem massal, mert a vxlan-t akarom megtanulni.
Egyik oldal, ahol a vlan6 letezik:/interface vxlanadd group=239.0.0.1 interface=vrrp_vlan2 local-address=192.168.25.157 \mac-address=1E:5D:9E:33:F8:3B name=vxlan1 port=4789 vni=1200 vrf=main \vteps-ip-version=ipv4/interface vxlan vtepsadd interface=vxlan1 port=4789 remote-ip=192.168.25.199Ezen az oldalon igazabol ket mikrotik van, akik VRRP-znek de ez most mellekes. Eleinte nem volt group es interface sem megadva, ugyanez volt a helyzet. A kurrens beallitasnal az interface az a kettes vlan-hoz tartozo vrrp interfesz, amiben egyebkent a local address is van.
Ezen az oldalon a vxlan1 interfesz benne van a bridge-ben, 6-os VLAN ID-vel, untagged. Tehat lenyegeben a vlan 6 es a vxlan1 van ossze bridge-elve, mert ezt a vlan-t akarom kiterjeszteni.
Masik oldal, ahol egyetlen gep akar resze lenni a vlan 6-nak:/interface vxlanadd group=239.0.0.1 interface=wifi1 local-address=192.168.25.199 mac-address=\3A:59:7F:97:50:C5 name=vxlan1 port=4789 vni=1200 vrf=main vteps-ip-version=\ipv4/interface vxlan vtepsadd interface=vxlan1 port=4789 remote-ip=192.168.25.157Ezen az oldalon is volt group es interface nelkul, nem valtozott semmi. A wifi1 interfesz az, amin a 192.168.25.199 ip cim van. Ez egy route-olt interfesz es station modban van, tehat o kapcsolodik wifin a halozathoz es erre tudja elerni a tuloldali VTEP-et.
Ezen a mikrotiken a vxlan1 interfesz es az ether2 van osszebridge-elve, semmi vlan, semmi egyeb.
Ugyanitt az FDB:[lab@site2-gw1] > /interface/vxlan/fdb/print0 remote-ip=0.0.0.0 mac-address=3A:59:7F:97:50:C5 interface=vxlan1 (3A mac cim a tuloldali vxlan1 cime)1 remote-ip=192.168.25.157 mac-address=1E:5D:9E:33:F8:3B interface=vxlan1 (1E mac cim a tuloldali mikrotik)2 remote-ip=0.0.0.0 mac-address=1E:5D:9E:33:F8:3B interface=vxlan13 remote-ip=0.0.0.0 mac-address=00:00:5E:00:01:06 interface=vxlan1 (ez momentan nem tudom kinek a mac-je)4 remote-ip=192.168.25.157 mac-address=00:00:5E:00:01:06 interface=vxlan15 remote-ip=0.0.0.0 mac-address=48:A9:8A:35:7B:CC interface=vxlan16 remote-ip=192.168.25.157 mac-address=48:A9:8A:35:7B:CC interface=vxlan1 (48 kezdetu a lokalis mikrotik)
A vxlan mukodik. A vlan 6 forgalmat latom a masik mikrotiken az ether2 -re kotott laptopon futo wiresharkon. Latom a STP forgalmat, latom a konstans VRRP forgalmat tehat layer 2-ben latok mindent a tuloldalrol. De ennyi. Kuldeni semmilyen forgalmat nem tudok, DHCP-n nem kapok IP cimet. Ha beallitok statikusan a laptopon egy IP cimet ami a tuloldali vlan 6-ba tartozik, nem lat semmit, nem tud pingelni senkit.
Kicsit elakadtam, a neten talalhato doksik vacakok. A vxlan nyilvan mukodik, mert a forgalom atjon a masik mikrotikre es latszik az ether2-n. De ennyi. Az sem vilagos nekem, hogy azon az oldalon, ahol nincs vlan6, csak vxlan-on keresztul, kellene mennie a dhcp-nek? Kell ehhez lokalis dhcp szerver? Kellene a lokalis mikrotiknak IP cimmel rendelkeznie ebben (a szamara ismeretlen) vlanban?
Ha adok a mikrotiknak (ahol nincs vlan6) egy cimet abbol a tartomanybol (a .17 a masik oldali mikrotik cime is, tehat ugyanazt osztom ki mindket oldalon a mikrotiknak)[lab@site2-gw1] > /ip/address/printColumns: ADDRESS, NETWORK, INTERFACE# ADDRESS NETWORK INTERFACE[...]8 10.8.31.17/28 10.8.31.16 ether2akkor megjelenik a routing tablaban egy bejegyzes ami igeretesnek tunik:
[lab@site2-gw1] > /ip/route/printFlags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC; H - HW-OFFLOADEDColumns: DST-ADDRESS, GATEWAY, DISTANCE# DST-ADDRESS GATEWAY DISTANCE[...]DAc 10.8.31.16/28 bridge_vxlan 0Ebbol nekem ugy tunik, hogy tudja, hogy a kerdeses tartomany a tuloldalon, a vxlan-on at van. De kuldeni nem kuld semmit es oszinten, kezdem elveszteni a fonalat is. Valamit nyilvan elrontok, de tud valaki segiteni, hogy mit?
-
mrots
junior tag
válasz
Bubukain
#24108
üzenetére
En csinalnek egy packet capture-t. A logbejegyzesek arra utalnak, hogy a vegpont ker IP cimet, de a valaszt mar nem kapja meg, tehat adatkapcsolati retegben lehet a problema, meghozza szimplex kommunikacio. dhcp discover megerkezik a broadcast cimre, a mikrotiked meghallja, probal valaszolni a felado mac cimere, de az mar nem er celba, tehat ujra discover, ujra valaszol, ujra nem er celba. Erdemes volna tudni, hogy kimegy-e a dhcp valasz a vezeteknelkuli iranyba, esetleg a jo vlan-ban van-e, nincs e filterezve.
-
#24074
mrots
junior tag
Alteran-IT
#24023
mrots
junior tag
válasz
Alteran-IT
#24023
üzenetére
Udv a klubban
nekem is nemreg volt egy kirohanasom, mert 20+ vagy nem is tudom mar hany ev cisco tapasztalattal a hatam mogott a mikrotik egy ocskavas. En is azt hittem, hogy a tobbi szerencsetlen szappantartohoz kepest vegre egy doboz aminek kozepkategorias ara van es cserebe a feature-ok benne vannak. Hat, benne, de olyan lutri az egesz. Nemreg az LTE-vel szenvedtem, vegul rendszeres reboot lett a dologbol, ami azert eleg szanalmas, ha ugy nezem. Most ket napja eppen egy ipsec kapcsolat szakadozik nekem is. Egy olyan ipsec kapcsolat ami kb evek ota stabilan megy, nem kellett hozza nyulni, most hirtelen ket napja kezzel ki kell torolnom az active peer-eket es hagyni ujra felepulni.Visszaternek a ciscora, csak az a baj, hogy a savszelesseg amit ki kell szolgalni csak akkora cisco cuccal megy, ami befuti a szobat, az meg nem tesz jot a villanyszamlanak.
-
mrots
junior tag
válasz
laracroft
#23971
üzenetére
Szerintem mindez siman megoldhato es nem jelent kihivast - egy kivetellel: az egy csomag ket celba torteno kozvetiteset. En nem tudok olyan mikrotik beallitasrol vagy modszerrol aminek segitsegevel egy csomagbol kettot csinalnal, mivel altalaban a routerek nem tamogatnak olyan metodust, hogy egy csomagbol ketto legyen.
A multicast egy picit kivetel, ott valoban tortenik csomag duplikalas, de nem feltetlenul az a router vegzi aki az egesz halozat elejen van, hanem a multicast forgalom tovabbitasa soran ugyanazt a csomagot kuldik ki tobb helyre (kb mint a switchek, amikor meg hubok voltak) attol fuggoen, hogy hol van feliratkozo az adott multicast csoportra.
Logikus, hogy a mikrotik az egyik helyre kuldi csak ki a csomagot, hiszen megy vegig fentrol lefele a NAT szabalyokon es ami eloszor passzol azt csinalja, utana nem keres tovabb. Ha jol tudom - de lehet rosszul tudom.
Mivel azt irod, hogy a masodik cim az elso tartaleka csupan, ha semmikeppen nem tudod a forgalmat ket helyre kikuldeni es mas iranybol kozelitenek es felvennem a masodlagos gepen (megfelelo ellenorzesek utan) az elso IP cimet es ugy mukodne tovabb. Mint egy IP alias. Nem a kerdesedre a valasz, de mukodne.
Ha mindenkepp kozpontilag akarod megoldani, akkor valoszinuleg egy reverse proxyra van inkabb szukseged.
-
-
mrots
junior tag
válasz
ekkold
#23925
üzenetére
Minden halozatomban van ilyen, mert mindenhol igenye volt a csaladnak erre.
Szerintem a kerdesnek nem lenyeges resze, hogy a wireguard-e a kapcsolat, ez csak egy technikai reszlet. Altalanossagban a lepesek a kovetkezoek:
1 a helyi halozatban mindekninek ugyanaz a default gw, ami a helyi mikrotik
2 a helyi mikrotikban kell egy PBR a kivalasztott forras IP-re, a next hop a tavoli mikrotik
3 a tavoli mikrotiknak ismernie kell a helyi IP cimeket (tudja, hogy merre kell route-olnia)
4 a tavoli mikrotiknak PATolnia is kell, hiszen alapesetben valoszinuleg csak a sajat helyi halozatara PATolA legkonnyebb a 4. Normalis esetben a MASQ szabaly ugy nez ki, hogy forras IP cim legyen a helyi halozat tartomanya, outbound interfesz legyen az amin a kapcsolat az internet fele kilep, action masquerade. Duplikald meg a szabalyt, a forras IP cim az a /32 lesz, akit kivalasztottal a tuloldalon, minden mas ugyanaz.
A masodik legkonnyebb a 3. Egyszeruen egy /32 route-ot fel kell vegyel a tavoli mikrotikon (aki kilepteti a kapcsolatot) ami a helyi mikrotik fele mutat (ahol a kliens valojaban talalhato). Nyilvan a route a wireguard-ba fog mutatni.
Ha szoros tuzfal szabalyaid vannak, akkor elkepzelheto, hogy modositanod kell ezeken is, hogy a forgalom a ket mikrotik kozott kozlekedni tudjon.
A tobbit pedig kronologiailag. Tehat 1. valoszinuleg adott, DHCP oszt egy gw-t ami a helyi mikrotik LAN interfesze.
Marad a 2. En elsokent felvennek egy uj routing tablat. Routing / Tables, +, adj neki nevet, es legyen FIB is. Ezt a routing tablat fogja hasznalni az az egy vegpontod.
Koveetkezo lepesben ebbe az uj routing tablaba vegyel fel egy darab route bejegyzest: IP / Route, +. a cel a 0.0.0.0/0, a gateway a tavoli mikrotik wireguard cime, a routing table mezonel pedig valaszd ki az uj routing tablat amit letrehoztal.
Ez utan a route tabladban ket default gateway bejegyzes lesz. Az egyik amit eddig is hasznaltal, a main tablaban, a masik amit most vittel fel az uj tablaba, ezt meg nem hasznalja senki.
Az utolso lepes, egy routing szabaly felvetele: Routing / Rules, +. A forras cim legyen az az egy host akinek masfele kell mennie, az action legyen 'lookup only in table', a table pedig legyen az uj tabla amit most hoztal letre.
Ennyi. Ugyelned kell, hogy ha a tuzfal szabalyok tul szigoruak, akkor mindket oldalon at kell engedned a legitim forgalmat ami eddig nem volt, valamint a forras oldalon, ahol a kivetelezett egy darab vegpont van, ha tul laza a PAT szabaly, akkor ellenorizd, hogy erre az egy hostra ne vonatkozzon cimforditas. Mivel a PAT szabaly resze a kimeno interfesz is, ennek a hostnak pedig mar nem ez lesz a kimeno interfesze (hanem a wireguard) elvileg az eddigi PAT szabaly nem fog ra mar vonatkozni, de ellenorizd.
-
mrots
junior tag
válasz
yodee_
#23919
üzenetére
"*) lte - fixed R11e-LTE no traffic flow when modem with older firmware version is used;"
Ezt kiszurtam en is, koszonom, hogy bemasoltad ide. Ugyan nem pontosan passzol, ez R11e-LTE -rol szol, a kerdeses eszkozben R11e-LTE6 van, de egye fene. 7.16-hoz irtak, en 7.11 -en futok jelenleg. Ez egy nagy ugras tavolrol. Ugy latom nem vagyok egyedul akik nem biznak a ROS upgrade-ben. Viszont a bug azt mondja a bug akkor letezik, ha regi firmware verzio volt. Nem specifikalja mi a regi, de a firmware frissitest kisebb rizikonak ereztem, mint a ROS frissitest, tavolrol, ugyhogy most igy fut:
/interface/lte/firmware-upgrade lte1
installed: R11e-LTE6_V038
latest: R11e-LTE6_V038Ez, illetve atmenetileg betettem egy 12 orankenti feltetel nelkuli ujraindulast. Meglatjuk par napig, hogy valtozik-e valami. Ha igy stabil, akkor 24 orankenti ujrainditas, utana meglatom.
-
#23921
mrots
junior tag
lionhearted
#23914
mrots
junior tag
válasz
lionhearted
#23914
üzenetére
"Kritikus" rendszert építettél egy SPoF-re. Ha elpukkan a tápegység, akkor mi van?
Idezojelbe tetted, szoval nem tudom pontosan mit ertesz alatta. A rendszer nem kritikus, csak par kamera aminek a kepe nezheto tavolrol. Mi tortenik ha a kamerak kepe nem nezheto? Igazabol semmi. Ennyit a kritikussagrol. Ha valoban kritikus lett volna, akkor nem egy es nem mikrotik eszkozt teszek oda
" mint írtam voltak rá panaszok, konkrétan az LTE modemre is."
A konkretumok erdekesek lehetnek, de azt nem irtal. Ugy altalanossagban en is olvastam sok panaszt, de nem tartottam oket relevansnak. Lehet, hogy a rossz helyen olvastam?"nem mi írjuk, nem is tudunk adni changelogot"
Talan felreerthetoen fogalmaztam, vagy talan nem ment at amit mondtam. Nem azt vartam, hogy itt valaki irjon change logot, hanem azt, hogy segitsen valaki megtalalni. A release notes-ot megtalalom a ROS-hoz, de a firmware-hez nem. En ahhoz vagyok szokva, hogy a gyarto aminek a termeket hasznalom ha kihoz egy uj szoftvert, megmondja mi valtozik benne. Ezt kerestem es segitseget kertem abban, hogy hol talalom a change logot." RSRP: nem összetévesztendő az RSSI-vel"
Nyilvan en osszekevertem, de koszonom a magyarazatot."a workaround meg már csak ilyen, melós, szenvedős"
nincs ezzel semmi baj, csak nem erre szamitottam, ennyi. -
mrots
junior tag
válasz
Reggie0
#23906
üzenetére
Ezt nem ketlem, hogy a legtobb cucc hatterben kezeli, csak itt eppen nem kezeli. Egy masik eszkoz:
gw#sho logging | i Cellular0/1/0
Feb 17 09:00:37.835: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 09:00:38.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 09:00:42.835: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 09:03:46.178: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 09:03:47.178: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to up
Feb 17 15:30:38.803: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 15:30:39.803: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 15:30:43.803: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 15:31:46.504: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 15:31:47.504: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to up
Feb 17 22:00:38.486: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 22:00:39.486: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 22:00:43.486: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 22:03:46.848: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 22:03:47.848: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to upEzzel peldaul tudok elni. Hat - het orankent egy-harom percre leszakad es visszajon. Mert visszajon. Azt gondoltam tud hasonlot a mikrotik es ezert gondoltam:
[root@oob] > interface/lte/monitor lte1 once without-paging
[...]
session-uptime: 5h38m13s -
#23910
mrots
junior tag
lionhearted
#23903
mrots
junior tag
válasz
lionhearted
#23903
üzenetére
Elhiszem, ha amit irok ezt a latszatot kelti. Hadd vilagitsam meg, miert nem csak vagdalkozas szerintem amit irok:
- hardver hiba: ez kb az utolso utani lehetoseg, amikor mar semmilyen megoldas nem mukodik. ez nagyjabol az a kategoria, hogy fogalmam sincs de akkor mondjuk ra, hogy hw hiba, mert ugysem lehet bebizonyitani, hogy az vagy sem. Mindaddig, amig barmilyen modon lehet szoftveresen elore jutni, ez az opcio nem jatszik, hiszen mielott leraktam az eszkozt oda ahova, ket hetig nyuztam ugy, hogy mellettem volt es semmi baja. Szoval egyelore ez a hardver hiba ez nem tobb, mint egy vaktaban lott tipp.
- firmware hiba: megint csak azt mondom, hogy ket hetig mukodott mellettem. Igen, idonkent leszakadt, ujra csatlakozott - ezt be lehet tudni a mobil terero sajatjanak, ha idonkent megtortenik. Nem hinnem, hogy a mostani helyen lett hirtelen hibas a modem firmware. Az, aki javasolta ezt, nem adott linket changelog -ra, hogy a ket fw verzio kozott mi a kulonbseg, en sem talaltam ilyet sehol. Vaktaban nem upgrade-elek firmware-t, mert mint irtam, az eszkoz 1500 km-re van tolem. Ha nem sikerul, vagy offline meg valami entert kene nyomni, vagy megerositeni valamit, az nem fog menni tavolrol, mivel ha jol tudom a fw frissites OTA. Legalabbis egyet frissitettem, mielott letelepitesre kerult. Szoval mivel a riziko nagy, a benefit meg kicsi (igazabol senki se tudja, mi a kulonbseg a ket verzio kozott, szoval tudomanyos alap nelkuli a javaslat) ezert jelenleg nem opcio. De meg mindig jobb, mint a hw hiba tipp.
- mobil terero: most, hogy tobben is irtak ezt a 103-mat, illetve osszehasonlitottam mas lerakott eszkozzel kezdem atertekelni a dolgot. Eddig azert huztam ki, mint potencialis hibaforras, mert a helyszinen 30-50 mbit kozott ment. Tobb sim kartyaval probaltam, huzamosabb ideig egy T kartya volt benne aminek botranyos terereje volt, at kellett helyezni de meg azzal is stabilan ment par napot. Az eszkozt athelyezni nem tudom, szoval az egyetlen opcio: rakenyszeriteni egy masik mobilszolgaltato halozatara, hatha az jobb. De ez is borderline ugyanaz a riziko, mint a fw frissites: ha nem csatlakozik, vagy az rosszabb, akkor vegleg kizarom magam, tehat kb ez a javaslat is olyan, hogy most eppen nem tudok vele mit kezdeni
- a netwatch mukodese: pontosan ez az amire szuksegem volt, csak valoszinuleg nem tudtam megfogalmazni rendesen. Amikor lattam, hogy instabil, akkor a netwatch tunt kezenfekvo megoldasnak, de mint most mas megvilagitotta, a korlatai miatt nem teljesen alkalmas arra, amire hasznalni akarom. Ez momentan a legjobb utvonal elore, mivel kizarni nem tudom magam tavolrol, viszont a helyzethez alkalmazkodni tud egy jol megirt script es ki tudja hozni a helyzetbol a maximumot.
Nem azzal van bajom, ha fw-t kell frissiteni, vagy hw-t kell cserelni. Azzal van bajom, ha minden tudomanyos alap vagy teny nelkul kellene valamit csinalni ugy, hogy a kovetkezmenyeket a javaslat nem veszi figyelembe.
-
mrots
junior tag
válasz
grabber
#23899
üzenetére
Szia,
ne erts felre, halas vagyok az otletert, illetve a tanacsert. De pontosan azert tettem mikrotik eszkozt az LTE vegere, hogy ne kelljen ilyen barkacsolasokat csinalnom. Mar a napi 1 reboot is feszegeti a hatarokat. Ettol meg a tenda is jobb volt, ami eveken keresztul logottt az LTE-n ujrainditas vagy barmi nelkul es teljesen jol mukodott.
Miert szedtem ki? Mert tavolrol nem menedzselheto, kellett valami ami VPN kepes. Azt gondoltam, hogy egy mikrotik van olyan szinten, mint egy huszezer forintos szappantarto.
-
mrots
junior tag
válasz
dombila
#23897
üzenetére
Koszonom a javaslatot, ha visszajott online akkor igy fogok tenni, bar az az igazsag, hogy mivel egy sima pingelest csinal, igazabol nem esemenyvezerelt. Ezt irod:
"az általa figyelt esemény bekövetkeztekor - pl szakadás - egyszer megpróbálja futtatni a scriptet. Ha az valamiért nem sikeres, akkor nem próbálja többször elindítani"
A script ami jelenleg van, amit bemasoltam korabban, nem esemenyvezerelt. Fixen 5 percenkent indul es pingel egyet. Ha sikeres, akkor nem csinal semmit. Ha sikertelen, akkor csinalja, amit csinalnia kell. Mivel nekem sincs jobb otletem, kovetem a javaslatod, es at fogom irni idozitett scriptre. De igazabol most is az. Szoval nem teljesen latom, hogy miert lesz jobb, mint a mostani.
-
mrots
junior tag
válasz
yodee_
#23892
üzenetére
"Amint látszik a firmware nem a legfrisebb, én azzal kezdenék."
Ezek ilyen vaktaba lovoldozesnek erzem. En nem lattam release notes-ot a ket firmware kozotti kulonbsegrol. Illetve nyilvan LTE modem firmware-t sem fogok tavolrol frissiteni ami utan esetleg valtozik valami a kodban, vagy menet kozben tortenik valami es egyatalan nem lesz elerheto utana.
"Ez külföldön található cucc"
Magyar halozaton log, mint lathato a kimenetbol, pannon vagy hogy hivjak most eppen. A sim kartya nem magyar, azert, mert igy barmelyik szolgaltato halozatat hasznalni tudja. A T-s halozat felejtos, 1-2 mbit/s a maximum, olyan a terero - a mikrotik is sargan / naracssargan jelzi a jelszinteknel, hogy nem oke. Vodat nem probaltam. A T-vel a terero olyan volt, hogy a teraszon ha kint volt, akkor mukodott egyatalan."Sajnos azt én is tapasztaltam, hogy a netwatch egyszer próbálkozik, ha nem sikerül után nincs több próba"
Ezt nem teljesen ertem, mire irod. Az en tapasztalatom, es mint a logokbol latszik, az esetek nagy reszeben elkapja, amikor az LTE leszakad es az interfesz billentessel visszahozza a routert. A problema akkor van, amikor ismeretlen ok miatt ket napig nem fut egyatalan. Hogy ilyenkor miert jon vissza a router egyatalan, nem tudom, de ha visszajott, a netwatch megint ugy tunik megy es elkapja a problemat es megoldja. Szoval fut es teszi a dolgat. Kiveve amikor nem.
A terv az volt, hogy ma este miutan a gyerekek lefekudtek reszelek a scripten egy kicsit, de nyilvan ma estere megint offline lett a mikrotik, szoval most megint varok addig, hogy elerheto legyen. Eddig ketszer tamadt fel tok varatlanul ilyen masfel nap utan. Hatha most is.
-
mrots
junior tag
válasz
Reggie0
#23891
üzenetére
"Azert a -103dbm RSRP eleg gyengusz jel."
Az lehet, de 40-50 mbit megvan rajta, egyreszt, masreszt pedig teljesen jol latszik a logokbol, hogy a netwatch script mukodik. Naponta 1x - 2x leszakad a mikrotik az LTE-rol, a netwatch eszreveszi, billent egyet az interfeszen es visszajon. Nem ez a problemam. A problemam az, amikor a netwatch scriptnek futnia kellene, de nem is fut - a logokbol erre lehet kovetkeztetni. Ez nem a mobilhalozat problemaja.
-
mrots
junior tag
válasz
yodee_
#23886
üzenetére
No kerlek, ma 18 ora utan ismet ugy dontott a mikrotik, hogy online lesz, fel is epult a tunnel azonnal es a nagios is szolt, hogy a vegpont online. Amig offline volt, addig nem csak a vpn nem ment, de a mogotte levo kamerak sem.
Kerdeztel az eszkozrol, most tudok belole informaciot kiszedni:
eloszor:
routerboard: yes
board-name: LtAP
model: RBLtAP-2HnD
revision: r2
firmware-type: mt7621L
factory-firmware: 6.48.6
current-firmware: 7.11
upgrade-firmware: 7.11aztan:
uptime: 1w4d13h47m44s
version: 7.11 (stable)
build-time: Aug/15/2023 06:33:51
factory-software: 6.46.6
free-memory: 68.5MiB
total-memory: 128.0MiB
architecture-name: mmips
board-name: LtAP
platform: MikroTika modemet kerdezted meg azt hiszem:
pin-status: ok
registration-status: roaming
functionality: full
manufacturer: "MikroTik"
model: "R11e-LTE6"
revision: R11e-LTE6_V035
current-operator: Yettel HU
roaming: yes
access-technology: LTE
session-uptime: 2h36m18s
primary-band: B7@20Mhz earfcn: 3350 phy-cellid: 158
cqi: 11
ri: 2
rssi: -72dBm
rsrp: -103dBm
rsrq: -7.5dB
sinr: 8dBA firmware pedig:
installed: R11e-LTE6_V035
latest: R11e-LTE6_V038Szerintem ezek a relevans beallitasok illetve parameterek. A logok pedig lentebb. Eloszor 13-an delutan, amikor legutobb visszajott es be tudtam lepni. Csinaltam gyorsan mentest is, modositottam a netwatch scriptet majd kileptem, ez volt delutan, majd jott egy szakadas. A netwatch kiszurta, LTE interfesz disable, varunk 30 masodpercet, enable, ra 15 masodpercre az interfesz beregisztralt, ra 7 masodpercre a link felkott, ra negy masodpercre mar indult is az ipsec. 10.7.20.13 az ipsec tuloldalan van, ez az amit monitoroz a netwatch. Ime:
02-13 15:56:55 system,info,account user root logged out from 10.7.20.13 via winbox
02-13 16:30:28 interface,info lte1 link down
02-13 16:33:57 netwatch,info event down [ type: simple, host: 10.7.20.13 ]
02-13 16:33:57 script,warning OOB VPN down
02-13 16:33:57 system,info device changed
02-13 16:34:27 system,info device changed
02-13 16:34:43 lte,info lte1: registered roaming
02-13 16:34:50 interface,info lte1 link up
02-13 16:34:52 ipsec,info initiate new phase 1 (Identity Protection): 10.148.24.74[500]<=>XXX.XXX.XXX.24[500]
02-13 16:34:54 ipsec,info ISAKMP-SA established 10.148.24.74[4500]-XXX.XXX.XXX.24[4500] spi:c31b2xxxxxcc3d4a:4312cdxxxxxe23cb
02-13 16:39:07 netwatch,info event up [ type: simple, host: 10.7.20.13 ]Szoval minden ugy mukodik ahogy kellene. A fentihez hasonlo borulas volt 23:04 -kor is, amit negy perc mulva eszrevett a netwatch es raizgult. LTE disable, 30s varakozas, enable, 15 sec mulva lte regisztralt a mobilhalozaton, interfesz fel, ipsec felepites sikeres, netwatch megnyuszik. Majd ugyanez lejatszodik par oraval kesobb, 14-en reggel kettokor is, ahol azonban mar az utolso lepes, az ipsec felepites hibara fut, es onnantol egy darab logbejegyzes sincs ma 18:42-ig, amikor is hirtelen eletre kel. De meg az 5 percenkenti netwatch futas es a log bejegyzes sincs.
02-14 02:09:59 interface,info lte1 link up
02-14 02:10:00 ipsec,info initiate new phase 1 (Identity Protection): 10.151.71.133[500]<=>XXX.XXX.XXX.24[500]
02-14 02:10:55 interface,info lte1 link down
02-14 02:11:00 ipsec,error phase1 negotiation failed due to time up 10.151.71.133[500]<=>XXX.XXX.XXX.24[500] 7a6xxxxxxab9f691:0000000000000000
18:42:15 lte,info lte1: registered roaming
18:42:22 interface,info lte1 link up
18:42:22 ipsec,info initiate new phase 1 (Identity Protection): 10.147.208.178[500]<=>XXX.XXX.XXX.24[500]
18:42:26 ipsec,info ISAKMP-SA established 10.147.208.178[4500]-XXX.XXX.XXX.24[4500] spi:751052xxxxxx351:6b4f1cxxxxxxa9f4
18:44:03 netwatch,info event up [ type: simple, host: 10.7.20.13 ]
18:44:03 script,warning OOB VPN upSzoval nekem most eppen az a gyanus, hogy 02:11 -kor meghalt a net, rendben van, masnap este haromnegyed hetkor visszajott, oke, de a ketto kozott a netwatch-nak sirnia kellett volna, hogy nincs net es probalkozni az interfesz lekapcsolas - varakozas - visszakapcsolassal. Ami nem tortent meg. Amikor viszont visszajott, ugy tunik azonal latta is. Lehet, hogy meg futott az elozo netwatch script es ket peldany nem futhat?
Valoszinuleg egy kondicio nelkuli reboot 24 orankent ezt megoldja, csak... hogy is mondjam... olyan szanalmas ez. Foleg, hogy a parezer forintos tendat eveken keresztul nem kellett rebootolni.
A netwatch script amugy:
/tool netwatch
add disabled=no down-script="log warning \"OOB VPN down\"\r\
\n/interface/lte/disable lte1\r\
\n:delay 30s\r\
\n/ip/ipsec/active-peers/kill-connections\r\
\n/interface/lte/enable lte1" host=10.7.20.13 http-codes="" interval=5m src-address=10.7.20.17 \
test-script="" timeout=10s type=simple up-script="log warning \"OOB VPN up\"" -
-
mrots
junior tag
válasz
yodee_
#23884
üzenetére
Ahogy irtam, egy evolucios folyamat vegen vagyok az asztalra csapas fazisaban. A tegnap esti netwatch script modositas, amibe beletettem egy hosszabb varakozast es interface disable / enable parancsokat, azt hittem eleg lesz. Nyilvan nem, durvan 8-9 ora utan megint offline lett. Tegnap este megszuntettem a loggolast a teszt parancsnal is, mert teleszemetelte a logot es nem lattam a relevans uzeneteket. Ha egyatalan visszajon, akkor a kovetkezo lepes a minden reggel 1kor reboot lesz, akar van lte akar nincs, tokom tele van mar. Azt hittem ez egy megbizhato marka, de szerintem a vege az lesz, hogy odaviszek egy ciscot aztan az menni fog es kesz.
-
mrots
junior tag
válasz
yodee_
#23880
üzenetére
Most eppen offline - reggel 4 ota, szoval ha a kerdesre a valaszt egy /system/routerboard print vagy hasonlo adja meg, akkor ezt most nem tudom megadni. A legutobb 4 napig volt offline es utana egyszer csak visszatert, tegnap este bovitettem a netwatch scriptet arra, hogy lte interfesz disable, delay 30s majd enable. Nyilvanvaloan nem segitett, hiszen ezzel ha reggel 4kor elveszti a halozatot, 4:06 -ra mar ujra online kellene, hogy legyen.
Szoval nem tudom pontosan a valaszt a kerdesre, de raadasul megnezni sem tudom most. Az eszkoz kb 1500 km-re van tolem.
-
mrots
junior tag
válasz
yodee_
#23878
üzenetére
A tenda valami hasznalt szutyok - ez az ami mindig mukodott.
A cisco volt 1921, 1941, 2921 es 3g / 4g HWIC kartyakkal.
A mikrotik ltap lte6 kit.Ugyanolyan simkartya ugyanttol a szolgaltatotol, ugyanazon a halozaton a mikrotikban hetente dobal, semelyik masik eszkozben nem.
-
mrots
junior tag
válasz
yodee_
#23864
üzenetére
En is hasonloval kuzdottem es meg kell mondjam, hogy kicsit csalodtam az MT-ben. Valamikor evekkel ez elott vettem hasznaltan egy ko egyszeru hot primitiv tenda 4g wifi routert, azert, hogy egy idos csaladtaggal lehessen facebook portalon beszelgetni. Az idosek otthonaban nem volt wifi, szoval vittem a portalt es vittem hozza egy 4g routert is, amit csak bedobtam az agy ala egy sim kartyaval. Tobb, mint egy even at folyamatosan ment, soha semmi panasz nem volt ra, havonta egyszer kellett megvennem a prepaid simre a havi korlatlan internetet es ennyi torodest igenyelt. Ja, meg evente egyszer az epulet elott wifin racsatlakoztam (covid alatt nem lehetett bemenni), hogy a szolgaltatoi SMS-t elolvassam az adategyeztetesnel. Se VPN se semmi nem volt, olyan primitiv megodas volt amilyet csak elkepzelni lehet. Soha nem kellett foglalkoznom vele.
Most egy eladas elott allo lakasba vittem par kamerat, meg egy mikrotik lte kitet. Mar legalabb a hatodik script verzional tartok, mert hetente egyszer mindig az van, hogy leszakad a mikrotik a mobilhalozatrol. Pedig nem bonyolult igazabol: ad wifin netet a kameraknak, illetve egy ipsec-et felepit egy VPS-hez, hogy tavolrol ra tudjak nezni ha szukseges az eszkozre. Ugy, hogy elotte ket hetig futtattam probakeppen az eszkozt, kellett egyre durvabbra irni a netwatch scriptet. Mennyi idonkent pingeljen, mi legyen a timeout, mi tortenjen, stb. Eloszor csak kill-eltem az ipsec kapcsolatokat. Aztan jatszottam a timerekkel. Aztan mar az lte interface disable meg enable. Aztan megint a timerekkel jatszani. Aztan a naplozassal, hogy latszodjon mi tortent amikor elerhetetlen volt az eszkoz. Most a nagios eppen megint azt jelzi, hogy leszakadt es valoban, az appban a kamerak is leszakadtak, pedig azokhoz nem kell ipsec. A kovetkezo lepes most mar az lesz, hogy reggel egykor kerdes nelkul el fogom bootolni a routert, mert kezd a tokom tele lenni.
Mindekozben ott volt a filleres tenda eszkoz, amivel eveken at nem kellett semmit foglalkozni, csak ment, illetve ott van a sajat cisco routeremben egy LTE HWIC, amiben szinten sim kartya van, arra az esetre ha a vezetekes netem leszakadna - ezzel sincs durvan 2 eve gond, elotte 3G HWIC kartya volt benne, az is legalabb negy-ot evig ugy futott, hogy talan ketszer kellett tavolrol hozzanyulnom ennyi ido alatt.
Szoval en ugy vagyok vele, hogy LTE-ben a mikrotik szerintem eleg fos, megbizhatatlan es nem szabad onmagaban letelepiteni, csak ha van mellette backup megoldas. Mondjuk egy masodik mikrotik egy masik sim kartyaval, amin keresztul be lehet menni a halozatra, ha az elso megall.
-
mrots
junior tag
válasz
myk_to
#23695
üzenetére
Tok ertheto mit es miert akarsz csinalni, en is csinaltam. Az egyetlen kulonbseg, hogy olcson szereztem hasznalt mikrotik routert ami a labor eszkoz lett es azon tudtam mindent kiprobalni. Nem kellett licensz problemakkal kuzdeni, emulalni wifit, driverekkel vacakolni - csak ott volt es ment. Bonusz elony, hogy legalabb volt egy hidegtartalek eszkoz, ha az eles esetleg bekrepalt volna.
-
#23591
mrots
junior tag
Szpilu__25
#23590
mrots
junior tag
válasz
Szpilu__25
#23590
üzenetére
A mikrotik tuzfala ha ures konfiggal inditottal, akkor alapbol enged barmilyen forgalmat barhonnan barhova. Ha allitottal be tilto szabalyt (mondjuk barmely interfeszrol barmi jon az drop, kiveve amit korabban engelyeztel) akkor nyilvan engedni kell a vpn forgalmat. Route elvileg nem kellene, hiszen altalaban a mikrotik az alapertelmezett atjaro is, tehat a visszairanyu forgalom hozza kerul es o tudja merre kell kuldeni. Bonyolultabb esetben ez nyilvan nincs igy akkor kellhet routing is.
-
mrots
junior tag
válasz
Gyula888
#23588
üzenetére
Megkoszonnem, ha kiprobalnad. Nincs ra szuksegem most, de hasznos lenne tudni. Jelenleg a szuloknel a kabeles (one/voda/upc) modemnek van 4 LAN portja, maga a modem bridge modban van. Ebben van ket router es mindketto DHCP-n teljesen onallo cimet kap, megcsak nem is azonos subnetben vagy tartomanyban.
Ha jol ertettem a T-s helyzetet, akkor van PPPoE passthrough, tehat a kerdes, hogy lehet-e ket pppoe session egymastol fuggetlenul felepitve ugyanazon login adatokkal, ugyanazon modem mogul, ket teljesen kulonbozo router altal.
En most hirtelen rakerestem es egy forumot talaltam csak, ahol valaki pont a pppoe passthrough / bridge modrol kerdez. A valasz szerint:
"Don't forget to delete your pppoe username and password at sagemcom. You can only use 1 pppoe session on 1 device.
Yes In Pppoe passthrough mod You can use your own device as firewall. "A fenti tanacs 2019-es, szoval lehet azota valtoztak a dolgok, de senkinek a kornyezetemben nincs T-s elofizetese, szoval sosem kerultem olyan helyzetbe, hogy kiprobaljam.
-
mrots
junior tag
válasz
Gyula888
#23586
üzenetére
De nem csak 1 pppoe session lehet per elofizetes? Hogy akasztok a dobozra ketto darab eszkozt, amelyek kulon-kulon kapnak publikus ip cimet es kulon-kulon cimezhetoek? Mert most a szuloknel igy van letelepitve, mivel nem jarok gyakran arra. Ket router, amelyek kulon-kulon kapnak IP-t, belul HSRP-znek, es ha az aktiv elromlik, a standby atveszi a szerepet addig amig odaerek megjavitani / kicserelni az elromlottat. A halozatukban pedig zero kieses van mindekozben. Az egyetlen single point of failure jelenleg a szolgaltato illetve a modeme amit biztosit, de mivel van egy harmadik router 4G backuppal, igazabol az sem single point of failure.
Szoval ha csak egy pppoe session lehet, akkor nem tud ket router egymastol fuggetlenul publikus ip-t kapni, mert ahhoz mindkettonek sajat pppoe session-t kell felepitenie.
De sose voltam T elofizeto, szoval lehet rosszul tudom.
-
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.
-
mrots
junior tag
válasz
Zwodkassy
#23111
üzenetére
Nem az a kerdes, hogy melyik orszagban vagy, mivel nem ettol valtoznak a hostnevek. Attol fugg, hogy a telefon, aki a halozatodra csatlakozik eppen, az melyik orszag melyik szolgaltatojanal van, az o nevfeloldasa es cel IP cime annak megfeleloen valtozik. Nem irtad, hogy mifele halozat, ceges campus vagy sajat. De igazabol lenyegtelen is, ket okbol. Az egyik, hogy nekem az itthoni halozatomon is rendszeresen megfordulnak olyan vendegeim, akik valami random orszag halozatan vannak es probalnak vowifizni. Eleg, ha valami reg nem latott iskolai ismeros ugrik fel egy kavera, aki ma mar masik orszagban el, vagy masik orszag sim kartyajat hasznalja. Pl amiota van az eves kotelezo adategyeztetes, van aki riasztoba, beagyazott eszkozbe kulfoldi SIMet tesz, mert azt nem kell evente adategyeztetni (es nem mellesleg barmely mobilhalozatot tudja hasznalni, nem csak egyet).
A masik ok, ami miatt nem kuzdenek a regexp-pel az az, hogy ez csak egy hostnev amit leker a DNSbol es gondolom valami konfigot lehuz onnan, a valos IP cim amivel az ipsec kapcsolat felepul, nem feltetlen lesz ugyanez a cim. Szoval ha nevre akarsz regexpet irni, azzal nem vagy elorebb, mert nem ez az a forgalom, aminek qos prioritast akarsz adni.
-
mrots
junior tag
Csinaltam egy gyors tesztet, bekapcsoltam a vowifit a telefonon. A DNS szerverben latszik is:
26-Oct-2024 00:27:07.611 queries: info: client [...] (epdg.epc.mnc020.mcc234.pub.3gppnetwork.org): query: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org IN A
26-Oct-2024 00:27:07.615 queries: info: client [...] (epdg.epc.mnc020.mcc234.pub.3gppnetwork.org): query: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org IN AAAA
26-Oct-2024 00:27:08.663 queries: info: client [...] (epdg.epc.mnc020.mcc234.pub.3gppnetwork.org): query: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org IN AAAA
26-Oct-2024 00:27:13.791 queries: info: client [...] (epdg.epc.mnc020.mcc234.pub.3gppnetwork.org): query: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org IN AAAAUtana megneztem, mi az IP cim amit a telefon kapott a DNS szervertol, mikor elkezdett beregisztralni:
epdg.epc.mnc020.mcc234.pub.3gppnetwork.org has address 185.153.237.96Inditottam egy hivast, majd megneztem a netflow adatokban, hogy milyen forgalom ment ehhez az IP cimhez. Na, ehhez semmilyen. Ez a konfiguracios IP cim volt, a forgalom a konkret hivasfelepitessel mashova ment, ugyhogy a subnetre szurtem, felteve, hogy a fentihez kozeli (szomszedos) cimekre megy a konkret hang kapcsolat.
mrots@rpi$ nfdump -R . -t 2024/10/26.00:00:00 "dst net 185.153.237.96/28"
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows
2024-10-26 00:27:09.684 0.000 UDP [...]:500 -> 185.153.237.98:500 1 466 1
2024-10-26 00:27:09.756 0.308 UDP [...]:4500 -> 185.153.237.98:4500 4 816 1
2024-10-26 00:27:10.264 6.068 UDP [...]:4500 -> 185.153.237.98:4500 23 8656 1
2024-10-26 00:27:35.684 0.000 UDP [...]:4500 -> 185.153.237.98:4500 1 29 1
Summary: total flows: 4, total bytes: 9967, total packets: 29, avg bps: 3066, avg pps: 1, avg bpp: 343Szoval ezert mondom, hogy szerintem nem IP cim alapjan kene qos-t adni.
-
mrots
junior tag
válasz
Zwodkassy
#23088
üzenetére
A konnyebbik, ha a protokollt fogod meg. A vegpont (telefon) ipsec kapcsolatot epit ki a szolgaltatoval. Ha a qos feltetelenek a protokollt adod meg (esp, talan 50?) akkor ez minden vowifi kapcsolatra igaz lesz, azon az aron, hogy az az ipsec forgalom is prioritast kap, ami nem vowifi miatt lett kiepitve. Mondjuk nem hinnem, hogy tul sok belso vegpont allandoan ipsec-et huzna ki mindenhova a jobb qos parameterek miatt. Csinalhatod layer 4 portszamok alapjan is (UDP 500 peldaul, ami ipsec-hez kell) de ezt konnyebb megkerulni, mintha layer 3 protokoll alapjan priorizalsz.
A masodik lehetoseg, hogy megnezed az IP cimeket, amihez a telefon kapcsolodni fog. Ezeket DNS forgalombol kis kinezheted, a hostnevek valoszinuleg pub.3gppnetwork.org -ra fognak vegzodni, az elejuk pedig mindenfele mcc es mnc kodok lesznek (mcc: mobile country code, mnc: mobile network code). Peldaul egy ilyen vegpont hostneve, amit a telefon keres: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org. Adhatsz jobb qos parametereket tehat a cel IP cim alapjan. Ez tuti nem priorizal mas, nem vowifi kapcsolatokat, tehat jo, viszont ami rossz, hogy ismerned kell, milyen szolgaltatohoz tartoznak azok, akik vowifit akarnak a halozatodon hasznalni. Ertelemszeruen a DNS nevek / IP cimek valtozni fognak szolgaltatonkent es nem is csak egy van beloluk.
En szerintem elindulnek az ipsec priorizalasaval es megneznem, hova vezet.
-
mrots
junior tag
-
mrots
junior tag
Amikor en migraltam mikrotikrol mikrotikra, akkor egy fizikai interfeszt fenn tartottam magamnak a konfiguralasra, ahol IP cim sem volt, MAC cim alapjan csatlakoztam csak. Ezt a fizikai interfeszt kihagytam a bulibol a kezdeti konfiguralaskor, mivel vlanokat, bridge-eket is erintett a konfiguracio, szoval menet kozben tuti elvesztettem volna a kapcsolatot.
Ha nincs felesleges interfeszed amit erre dedikalhatsz, akkor csak hagyd ki azt az egy portot, konfiguralj fel minden mast, es a vegen mikor mar elered az eszkozod uzemszeruen, akkor azt az egy fizikai interfeszt is hozzaadod a bridge-hez, vagy vlan-hoz vagy amihez akarod.
-
mrots
junior tag
Vannak kulonbsegek. Nem tudom teged erint-e. En amikor ax2-rol ax3-ra valtottam (hasonloan 6.49-rol 7.x -re) akkor megkuzdottem peldaul azzal, ahogy a BGP redisztribucional a filterek megvaltoztak, es a 7-es ROS nem hirdette azokat a halozatokat amiket korabban a 6-os igen.
Ezen tulmenoen ugy emlekszem a VPN-nel is valtoztak dolgok, a wifinel is megjelentek a profilok, vagy nem tudom mar minek hivjak oket. Szoval az alap dolgok (ip cim, dhcp pool stb) azok ugyanazok, de jo sok dolog teljesen mas.
nekem is nemreg volt egy kirohanasom, mert 20+ vagy nem is tudom mar hany ev cisco tapasztalattal a hatam mogott a mikrotik egy ocskavas. En is azt hittem, hogy a tobbi szerencsetlen szappantartohoz kepest vegre egy doboz aminek kozepkategorias ara van es cserebe a feature-ok benne vannak. Hat, benne, de olyan lutri az egesz. Nemreg az LTE-vel szenvedtem, vegul rendszeres reboot lett a dologbol, ami azert eleg szanalmas, ha ugy nezem. Most ket napja eppen egy ipsec kapcsolat szakadozik nekem is. Egy olyan ipsec kapcsolat ami kb evek ota stabilan megy, nem kellett hozza nyulni, most hirtelen ket napja kezzel ki kell torolnom az active peer-eket es hagyni ujra felepulni.
Új hozzászólás Aktív témák
- Bomba ár! HP ProBook 470 G5 - i5-8GEN I 8GB I 256SSD I 17,3" FHD I Nvidia I W11 I Cam I Garancia!
- Bomba ár! Lenovo ThinkPad P70 - XEON I 32GB I 256SSD I M5000M 8GB I 15,6" FHD I Cam I W10 I Gari!
- Bomba ár! Lenovo IdeaPad Gaming L340-17IRH i7-9750H I 16GB I 256SSD I GTX1650 I Cam I W11 I Gari!
- Bomba Ár! HP Pavilion X2 - m3-6Y30 I 4GB I 128SSD I 12" WUXGA+ Touch I Cam I W11 I Garancia!
- Bomba ár! HP EliteBook 840 G2 - i3-5GEN I 16GB I 128GB SSD I 14" FHD Touch I Cam I W10 I Garancia!
- BESZÁMÍTÁS! Asus TUF A620M R7 7700 64GB DDR5 500GB SSD RX 6800 XT 16GB ZALMAN I3 NEO Seasonic 750W
- Gamer PC-Számítógép! Csere-Beszámítás! I7 6700 / RTX 3050 / 32GB DDR4 / 512 SSD!
- Bomba ár! Lenovo ThinkPad T560 - i7-6GEN I 16GB I 512GB SSD I 15,6" FHD I Cam I W10 I Garancia!
- Bomba ár! HP Elitebook 840 G1 - i5-4GEN I 8GB I 180GB SSD I 14" HD+ I Cam I W10 I Garancia!
- MSI Sword 16 - Core i7 / RTX 4050 / per key RGB / magyar garancia
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest