-
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
-
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.
-
Lenry
félisten
válasz
yodee_
#16108
üzenetére
1280 a WAN bridge (ezt nem is tudom állítani)
1200-ra vettem le a WG-étannyit még hozzá kell tenni, hogy külön interface-t csináltam végül ennek a kapcsolatnak, tehát most a két WireGuard kapcsolat két külön WG interface-en fut.
(nem tudom, hogy ez befolyásol-e bármit, de gondoltam leírom) -
Audience
aktív tag
válasz
yodee_
#16086
üzenetére
Én csináltam egy bridge-et hozzá raktam egy portot és összekötöttem még egy kábellel a HGW-t és a router-t, a TV-nél lévő Mikrotikre is tettem egy plus bridge-et, két portot hozzá adtam és a két bridge-et EoIP tunel-lel összekötöttem. így ha ott a megfelelő portra csatlakozom látom a HGW-t, a másik porton a set top box lóg.
-
Audience
aktív tag
válasz
yodee_
#16081
üzenetére
Nekem a Cloud szolgáltató miatt is le kellett vennem az MTU-t, Hollandiai adatközpontot használok, ebből ennyi jön ki. Néha felmegy 200Mbps-ig de az a plafon. Ha nagyobb VM-re áttenném a CHR-t lehet, hogy lehetne még faragni de amire használom arra már így is bőven jó.
-
ekkold
Topikgazda
válasz
yodee_
#15981
üzenetére
Mobilneten a szolgáltatók valamiért szeretik blokkolni a VPN-ek működését. Természetesen letagadják. Ezért jobb olyan VPN-t használni, amelyik nem fix portokat használ, hanem tetszés szerint állítható, ugyanis ezeket emiatt nehéz blokkolni... itt jön a képbe az openvpn mert az ilyen, csak éppen sokkal lassúbb mint a PPTP / L2TP / ipsec (ezek viszont csak adott porton működnek). Viszont a RouterOs7-be bekerült a wireguard, ami szintén bármelyik porton működhet, és gyors
Gyakran előfordult, hogy olyan helyen interneteztem ahonnan sem PPTP-t sem L2TP-t nem tudtam használni, és így nehezebben értem el pl. az otthoni NAS-t. A wireguard-al viszont működik. -
pzoli888
kezdő
-
ekkold
Topikgazda
válasz
yodee_
#15958
üzenetére
Nálam ehhez hasonló bejegyzés erre kell:
- Van több különféle port kifordítva, pl. egy webszerver, ami a router WAN oldaláról elérhető (skori.spacetechnology.net)
- Hogyha egy LAN címről (mondjuk asztali PC) el akarom érni a webszervert, de úgy hogy nem a belső LAN oldali címére hivatkozok, hanem pl. az előbbi domain névre - ami ugye a WAN oldali címre fordul, akkor a PC a routerhez fog fordulni a kéréssel, hiszen nem lokális címet akar elérni. A router viszont "észreveszi", hogy az a cím (is) a saját címe, és ezért az említett NAT szabály alapján, annak ellenére kiszolgálja a kérést, hogy az eredetileg a WAN oldali címre vonatkozott.
Magyarán, a LAN-on belül is kiszolgálja a NAT kéréseket. Sokak szerint ez így nem működhet, és valóban kicsit fura a dolog logikája, de a gyakorlatban viszont mégis működik a dolog. A Te esetedben, ha mégis meg akarnád tartani ezt a szabályt, akkor úgy kellene módosítani, hogy a VPN címekre ne vonatkozhasson ez a szabály, ha viszont nincs ilyesmire szükséged, akkor nyugodtan törölheted. -
ekkold
Topikgazda
válasz
yodee_
#15950
üzenetére
Nekem hAPac^2-n a PPTP VPN volt a leggyorsabb, az tudott talán 100Mbit körül, az L2TP+IPsec már jóval lassúbb volt, IPsec nélkül meg csak kicsit volt lassúbb a PPTP-nél. A wireguard gyorsabb volt mindegyiknél (nem emlékszem pontosan mekkora sebességet tudott, de biztosan többet mint 100Mbit/s). IPIP + Ipsec és az EOIP+IPsec sem volt igazán jobb sebességben a fentieknél - bár ezekkel nem túl sokat kísérleteztem. Szóval azért nem kell csodát várni ettől a kis routertől, szerintem a gyakorlatban az a 100Mbit körüli VPN sebesség reális. Ha nagyobb sebesség kell akkor vagy a PC-n kell futtatni valamilyen VPN-t, vagy jóval erősebb router kell. Gyanítom, hogy pl. a Wireguard PC-n futtatva, simán tudna közel gigabitet, de ezt nincs módom tesztelni.
-
ekkold
Topikgazda
Egyébként semmi extra, CAPsMAN fut, pár tűzfal szabály
Új hozzászólás Aktív témák
ekkold- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen processzort vegyek?
- A fociról könnyedén, egy baráti társaságban
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Amazon Fire TV stick/box
- DUNE médialejátszók topicja
- Okos Otthon / Smart Home
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
- Google Chrome
- Elstartolt az Ulefone vetítőtáblája
- További aktív témák...
- Eladó Nintendo Switch 2 garis+ sok tartozék
- Apple Magic Keyboard (2021) magyar kiosztással (mk2a3d/a)
- Ha szeretnéd olcsón de a lehető legjobb minőségben megúszni a karácsonyi ajándékozást!
- Razer Blade 15 Advanced (2019) Rtx 2080 OLED Touch 4K - újszerű
- Samsung Galaxy Watch 6 Classic 47mm, 1 Év Garanciával
- Nagyakkus! Dell Latitude 5430 i7-1255U 16GB 512GB 14" FHD 1 év garancia
- ZOTAC GAMING RTX 3080 Ti Trinity 12GB GDDR6X videókártya eladó!
- Okosóra felvásárlás!! Samsung Galaxy Watch 6, Samsung Galaxy Watch 7, Samsung Galaxy Watch Ultra
- GYÖNYÖRŰ iPhone 13 Pro 256GB Graphite -1 ÉV GARANCIA - Kártyafüggetlen, MS3356
- HP 24" IPS LED FULL HD monitor 24fh 4HZ37AA
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő