-
Fototrend
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
-
Reggie0
félisten
válasz
yodee_
#18412
üzenetére
Kerdes az, hogy mennyire hasznalnad ki a WG-t az uj routeren. Nekem CCR1009 van, van boven wg-s halozatom, de meg nem nagyon ugrott a proci terheles 10% kore se. El kell donteni, hogy hanyszor utkoznel bele a korlatba es mennyi penzt er meg neked, hogy ezen alkalmakkor valamivel gyorsabb legyen(no meg mennyivel lenne gyorsabb).
-
-
válasz
yodee_
#18280
üzenetére
"Viszont ha már ennyire szükséges akkor miért nem wireguarD?"
Nem csak VPN kapcsolat létezik. A NAS-t pl. FTPS alapon szoktam elérni. Plusz van a NAS-nak néhány egyéb szolgáltatása is.
Valamint nem csak NAS lehet egy hálózatban, amit kívülről jó lenne elérni.
Erre gondoltam azt, hogy az adott no-ip dyndns névvel rendelkező eszközöknek zöld utat adok.
Nekem egyértelmű volt mit szeretnék, de nektek nyilván nem :-)
Bocsánat! -
#17925
E.Kaufmann
veterán
yodee_
#17921
E.Kaufmann
veterán
válasz
yodee_
#17921
üzenetére
Nekem miki router -vezeték- openWRT AP -wifi- miki repeater simán megy. DHCP csak egy eszközön aktív, L2-es kapcsolat a router LAN lábától végig, IP cím és tartomány ésszel beállítva. L3 esetén vagy kézzel vagy routing protokollal kell az útvonalakat rögzíteni, vagy bizonyos esetben elég újraNAT-olni, L3 esetén ne legyenek ütköző IP tartományok.
-
adika4444
addikt
válasz
yodee_
#17664
üzenetére
Wireguard Warp-pal teszteltem, ott 70 Mbps. Most összekötöttem egy Telekomos hAP ac2-vel, 170--220 Mbps között jön minden, a MTU állítgatásával változik, de ha nő a sebesség, egyre jobban ugrál. Viszont ha a Telekom-os WG-be rakom bele a fenntebbi VPS-en lévő WG-t, akkor nagyon hullámzó a sebesség. Tűzfal átnézve, fölösleges szolgáltatások nem futnak, szóval szerintem ez ilyen. A sebesség nem nőtt, de ismét beleraktam a Telekom VPN-be a netcup-ot, és stabilabbnak sokkal stabilabb, sajnos ez megint fekete pont a DIGI-nek, hogy ennyire rosszak ebbe az irányba.
-
Audience
aktív tag
válasz
yodee_
#17583
üzenetére
- Ha IP-t váltasz nem kell az ARP-vel foglalkoznod.
- Mindenképpen kell IP az Ether 1-nek abból a tartományból amiben a Huawei van.
- Az interface/bridge beállításainál tudod az ARP-t állítani, ha maradsz ennél az IP tartománynál. https://help.mikrotik.com/docs/display/ROS/ARP -
Audience
aktív tag
válasz
yodee_
#17579
üzenetére
Igen, csak ez nem fog működni mert ugyanabban a tartományban van az ONT mint amiben a kliens, de nincsenek L2-ben egy broadcast domain-ben, ahogy már írtam.
Adj az ONT -nak egy 10.13.5.254/32 címet a Mikrotik interface-ének egy 10.13.5.1/24-et és a lenti screenshot-on a dst address legyen a 10.13.5.254 és kész is vagy.
-
Audience
aktív tag
válasz
yodee_
#17577
üzenetére
Kényelmesebb más tartományt használni! Mivel nincsenek így egy L2 Broadcast Domain-ben de ugyanabból a tartományból fog IP-t kapni ARP-vel nem fogja a kliens megtalálni az ONT-ot.
a tűzfal szabály végtelen egyszerű egy src NAT-t adsz hozzá, megadod a destination IP-t és a source IP-t vagy tartományt és az action-t masquerading-re állítod. -
#17403
silver-pda
aktív tag
yodee_
#17402
silver-pda
aktív tag
válasz
yodee_
#17402
üzenetére
PPP Client-nél nem tudom kiválasztani, de lett egy LTE típusú interface a listában.
Sztem ez nem PPP típusú.
A listában is vannak egyes eszközök amik sima LTE, van ami meg PPP. Mondjuk ami nálam van, az nincs felsorolva és nem is stick, hanem MIFI.
Vhogy ki kellene engednem az lte-t a tűzfalon, hogy tesztelhessem. -
yodee_
őstag
válasz
yodee_
#17040
üzenetére
Közben megtaláltam a "hiba" okát. Mivel pxelinux.0-át használok, így boot-oláskor ez a folyamat:
"...
As an example, if the boot file name is
/mybootdir/pxelinux.0,
the UUID is b8945908-d6a6-41a9-611d-74a6ab80b83d
the Ethernet MAC address is 88:99:AA:BB:CC:DD
and the IP address 192.0.2.91,it will try:
/mybootdir/pxelinux.cfg/b8945908-d6a6-41a9-611d-74a6ab80b83d
/mybootdir/pxelinux.cfg/01-88-99-aa-bb-cc-dd
/mybootdir/pxelinux.cfg/C000025B
/mybootdir/pxelinux.cfg/C000025
/mybootdir/pxelinux.cfg/C00002
/mybootdir/pxelinux.cfg/C0000
/mybootdir/pxelinux.cfg/C000
/mybootdir/pxelinux.cfg/C00
/mybootdir/pxelinux.cfg/C0
/mybootdir/pxelinux.cfg/C
/mybootdir/pxelinux.cfg/default... in that order... "
Szóval a logban látható hiba kód amikor UUID, és MAC alapján szeretné lehívni a konfigot. Ha készítek UUID alapú konfig fájlt akkor csak egy darab hiba jön az meg annyi hogy ERROR: CODE 0. Mivel mindent betölt, megtanulok együtt élni vele.
-
Lenry
félisten
válasz
yodee_
#16909
üzenetére
pedig érdemes.
a 13.x.x.x nem helyi hálózati IP címtartomány és ezek szabványok, nem ajánlások és nem véletlenül lettek létrehozva.
ha egy webszolgáltatás, szerver ezen a címen működik azt te most egyáltalán nem tudod elérni.amúgy meg nem akkora truváj.
tűzfalszabályokat, az Addressest, a DHCP-t és a Route-okat kell átírni és kb meg is vagy.ha nagyon biztosra akarsz menni akkor exportálod az egész konfigot, egy másolatban átírogatod az IP-ket és visszatöltöd.
-
bacus
őstag
válasz
yodee_
#16893
üzenetére
Azért vesztél el, mert fogalmad nincs mit jelent a /30.
- allowed address: 13.0.4.0/24; 13.255.255.3/30
IP -> Addresses:
13.255.255.1/30 | 13.255.255.0 | wireguard1
13.255.255.1/30 | 13.255.255.0 | wireguard2Ezt te írtad ! Ekkold már megírta, hogy két if-nek adtál azonos ip címet. Egy hiba, a másik, hogy a /30 -as hálóban 4 ip cím van, amiből az első és az utolsó NEM használható, mert az a network és broadcast address, erre te mit csinálsz? ott van feljebb, hogy 13.255.255.3/30
Ezt persze oda adod a kliensnek is !Egy /30 as hálózatban (most írjuk le neked 3x .ra) 2 db ip cím kommunikál egymással.
A te esetedben a 13.255.255.1 - 13.255.255.2 -vel tud kommunikálni. A 13.255.255.3 az az előbbi broadcast addresse. A következő /30-as háló 13.255.255.4-13.255.255.7, amiben a két ip cím ami kommunikálni tud, az a 13.255.255.5-13.255.255.6-al. Most olvasd újra az előző hsz-em, mert ott csak az utolsó számot írtam ki az ip címekhez..Ne keverd már ide a 14.x.x.x es címeket is..., inkább használd a 8.8.8.x-t
, az legalább elég hamar problémát okozna.
Erre kérdeztem, ha az összes routeren azok a címek amik 13.x.x.x -esek, lecseréled 10.x.x.x-re az akkora fájdalom? Nem értem ezt a ragaszkodást a 13-as számhoz vagy egyszerűen csak mert megteheted?
Vagy pénteken konfigoltad? -
bacus
őstag
válasz
yodee_
#16891
üzenetére
"minden működik szóval miért ne"
Teljesen igazad van. Az autód gumijait leereszted 1 barral, minden működik ugyanúgy, akkor miért ne?!/30 -as hálóban négy cím van, te használod a 0,1,2,3 -t (ugye a 2 középső a hasznos), csak találsz még ilyet 255-ig..., de azért nem egymás után lévő 4 címet kell válassz, hanem sorban... tehát jó a 4,5,6,7 jó a 8,9,10,11 és így tovább.. és nem jó 18,19,20,21
Egyébként mennyire fájna a 13-t 10-re cserélni azokban az ip címekben?
-
ekkold
Topikgazda
válasz
yodee_
#16869
üzenetére
Wireguard kapcsolat: az egyik amit használok fix IP-re csatlakozik, ez szinte soha nem szokott megszakadni. Egy másik egy NAT mögött levő eszköz, ráadásul gyakran elmegy a tápja... Erre kellett netwatch script - 5 percenként pingel, ha megszakadt a kapcsolat, akkor letiltja az interfészt, vár 3 másodpercet, majd visszakapcsolja. Ez megoldotta problémát. Itt van párhuzamosan PPTP kapcsolat is, ami stabil, csak nincs oda irányítva semmilyen adatforgalom, de szükség esetén bármikor használatba vehető.
-
ekkold
Topikgazda
válasz
yodee_
#16869
üzenetére
Am i így elsőre feltűnik, hogy miért adsz azonos címet két különböző interfésznek:???
IP -> Addresses:
13.255.255.1/30 | 13.255.255.0 | wireguard1
13.255.255.1/30 | 13.255.255.0 | wireguard2
Aztán később ez szerepel:
IP -> Addresses
- 13.255.255.2/30 | wireguard1
Egy /30-as tartományban két használható IP lehet, a szerver és a kliens címe (a maradék kettő a broadcast, és a hálózati cím).
Tehát a két interfész nem is lehetne közös tartományban, ugyanolyan IP-je meg pláne nem lehetne. Ha meg egy interfészre menne több kliens akkor nem /30-as címtartomány kellene.
Ezen kívül már páran írták neked, és most én is:
A 13 kezdetű címek nem lokális [LAN] címek, normális hálózatban nem illik ilyet használni még akkor sem, ha egyébklént működik.
Tehát vagy a leírásod hibádzik valahol, és nem fedi a tényleges beállításokat, vagy ha mégis ilyen akkor nem csoda ha nem jól működik. -
amargo
addikt
válasz
yodee_
#16776
üzenetére
Ez egy szolgáltató, azaz valamilyen olyan email címet, aminek a postaládáját eléred. Nekem gmail-es van és gmail-es céges is.
Az előre le írom, ahhoz, hogy verificálni tud majd a kilétedet, ahhoz pl kell egy domain. Nálam pl úgy van megcsinálni, hogy a céges info-s cím nevében küldöm ki innen a leveleket (ehhez persze verification kell). -
amargo
addikt
válasz
yodee_
#16774
üzenetére
Mármint? Céges adatokat kell megadni. Nekem egy account-om még azure-on keresztül van, de van egy private is, amihez végül is szintén céges adatokat adtam meg.
A sendgrid tömeges email küldésre van, nem mondom, hogy ez a legjobb megoldás erre a problémára (van pár maradi ISP (pl.: freemail), akik "blokkolják/spam-nak jelölik meg" azt pedig csak a fizetős csomagban tudod kivédeni), de én évek óta használom erre a célra is.. -
ekkold
Topikgazda
válasz
yodee_
#16747
üzenetére
Némelyik kapcsolat esetében meghagytam a PPTP vagy L2TP kapcsolatot is tartaléknak, a wireguard mellett. Egyszerűen a régi, erre vonatkozó routing szabályokat letiltottam, és felvettem újakat, amelyek már a wireguard kapcsolaton át tolják az adatokat. Így bármikor át tudok kapcsolni a régi VPN megoldás, és a wireguard között oda-vissza. A két router között pedig mindkét kapcsolat él, persze más IP címekkel - így ha az egyik kapcsolat megszakadna, a két router akkor is látja egymást.
-
ekkold
Topikgazda
válasz
yodee_
#16713
üzenetére
Szerintem, a mikrotik nem kezeli külön a fájl és a mappaneveket, vagy valójában nincsenek is mappák, csak a névben vannak per jelek. Az RB5009-en én is egy pendrájvra küldöm a backupot, és onnan megy az email. Az eredmény hasonló mint nálad... annyi eltéréssel, hogy a fájlnév per jelekkel érkezik meg a levelező programba, és a programból már kötőjelekkel lehet menteni a csatolt fájlt. Szerintem nálad is, a levelezést kezelő program cseréli le alulvonás jelre.
Még annyit, hogy azokon a routereken, ahol van /flash almappa, a gyökérkönyvtár valójában RAMdiszk, ebben az esetben nyugdodtan mehet a backup a gyökérkönyvtárba. Az email küldése után törlendő, de ez nem fogja a flash-t "koptatni". Nem emlékszem hirtelen, de mintha a hAPac2 is ilyen lenne.
-
Lenry
félisten
válasz
yodee_
#16713
üzenetére
gondolom teljes elérési úttal küldi el, tehát /disk3/backup/xxx.rsc-ként , de egy fájlnév nem tartalmazhat
/jelet, ezért lesz belőle az, ami.egyszer mintha olvastam volna valami olyasmit, hogy a Mikrotik nem kezel rendesen mappaszerkezeteket, hanem a fájlnévből csinál ilyen pszeudo-elérési utat, tehát /backup/ kezdetű fájlneveket úgy mutatja, mintha egy backup nevű mappában volnának.
de elég homályosan emlékszem erre, szóval lehet, hogy hülyeséget beszélek -
Beniii06
addikt
válasz
yodee_
#16655
üzenetére
A VPN kliensnek kellene egy IP-t adni a 4G router tartományában, pl 192.168.8.3/24 az address listben, a 4G eszköz DHCP tartományán kívül mindenképpen. Tippre Huawei eszközöd van, azok a 8.100-tól kezdik a DHCP címeket osztani általában.
A VPN szerveren pedig szerencsésebb lenne megadni a vpn kapcsolatot átjárónak, az ip cím helyett, bár elvileg ugyanaz a kettő, nekem így stabilan működik.
+ Az ip --> firewallban nézd meg, hogy van-e a NAT résznél létrehozva masquerade szabály, srcnat, a 192.168.8.0/24 re aminek kimenő interfésze a vpn kapcsolat.
-
ekkold
Topikgazda
válasz
yodee_
#16428
üzenetére
Azt hiszem a sebességen kívül (egyébként: igen, valószínűleg több is menne) elég sok további indok le lett itt írva.
Ha a fehérlistára felveszel engedélyező szabályt, akkor minden további drop-olható. Vagy akár egy sima drop szabályba is betehető kivételként a fehérlista. Több megoldás is van.
-
ekkold
Topikgazda
válasz
yodee_
#16416
üzenetére
Miért lenne értelme váltanom wireguard-ra?
- Pl. nem kellene ilyen tűzfal scriptekkel bajlódni, mint amit beraktál.
- Az egész fixportos ipsec-es megoldást ki lehetne hajítani, és akkor nem is lenne mit hackelni...
- Az l2tp/ipsec által használt portokra érkező csomagok forráscíme kapásból mehetne a feketelistára, minden különösebb trükközést mellőzve.
- Van fehérlistád: elegendő a fehérlista számára kinyitni a megfelelő portot. Az alkalmi elérésekhez meg lehetne pl. kopogtatással a fehérlistára felkerülni. (Ez mondjuk most is feleslegessé tenné a scriptes megoldást.) -
ekkold
Topikgazda
válasz
yodee_
#16413
üzenetére
Biztos, hogy érdemes azonnal tiltani? Néha látok olyat a logban, hogy egy barátom hAPac^2 routere csak másodszorra tud valamiért kapcsolódni hozzám - ilyen esetben pedig feketelistára kerülne...
Mondjuk ha majd frissít 7-es routerOs-re, akkor kihajítom az L2TP-t, és amit csak lehet wireguard-ra cserélek. -
Statikus
senior tag
válasz
yodee_
#16374
üzenetére
Én azt nem értem, mi köze a windowsnak egy BIOS által vezérelt hálózati kártyára érkező jel feldolgozásában, a gép elindításában, bootolás előtt? Szerintem semmi... De ha rosszul gondolom, ha a windows bármit is vezérel egy kikapcsolt gép indításában, akkor légyszi osszátok meg velem.
-
Lenry
félisten
válasz
yodee_
#16331
üzenetére
látszik, hogy egyetlen találat sincs arra a szabályra, mert valószínűleg rég kiértékelésre kerülnek azok a kapcsolatok, el se jut odáig a listában.
tedd valahova a lista elejére.a drop szabályokat egyébként is érdemes előre tenni, hogy mielőbb végezzen a router a kiértékeléssel és aztán ne kelljen rájuk erőforrást pazarolni.
Egyébként semmi extra, CAPsMAN fut, pár tűzfal szabály
Új hozzászólás Aktív témák
ekkold- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- AliExpress tapasztalatok
- Forza sorozat (Horizon/Motorsport)
- Elemlámpa, zseblámpa
- Kerékpárosok, bringások ide!
- Vivo X300 - kicsiben jobban megéri
- Jövedelem
- Whisky topik
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- PlayStation 5
- További aktív témák...
- AMD Ryzen 5600X/Radeon RX 6800 16GB/32GB DDR RAM/1TB SSD konfig eladó
- Bomba ár! Dell Latitude E7270 - i5-6GEN I 8GB I 256GB SSD I 12,5" HD I HDMI I CAM I W10 I Gari!
- Bomba ár! Dell Latitude 7490 - i7-8GEN I 16GB I 256SSD I 14" FHD Touch I HDMI I Cam I W11 I Gari!
- AMD 5 3600/GeForce RTX 3070/16GB DDR4 RAM/512GB SSD konfig eladó sok-sok garival
- Bomba ár! HP ProBook 445 G9 - Ryzen 5 5625U I 16GB I 512SSD I HDMI I 14" FHD I Cam I W11 I Gar
- Konzol felvásárlás!! Nintendo Switch
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Xiaomi Redmi 14C 128GB, Kártyafüggetlen, 1 Év Garanciával
- 5G LTE! Microsoft Surface Pro 8 i7-1185G7 16GB 1000GB 1 év garancia
- Keresünk iPhone 16/16e/16 Plus/16 Pro/16 Pro Max
Állásajánlatok
Cég: ATW Internet Kft.
Város: Budapest
Cég: BroadBit Hungary Kft.
Város: Budakeszi