- Samsung Galaxy Watch7 - kötelező kör
- Samsung Galaxy A34 - plus size modell
- Nem várt platformon a OnePlus Nord 5
- Samsung Galaxy XCover7 Pro - burokban született One UI
- One mobilszolgáltatások
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Android alkalmazások - szoftver kibeszélő topik
- Android szakmai topik
- iPhone topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
-
Mobilarena
Mikrotik routerekkel foglalkozó téma. Mikrotik router típusok, hardverek, router beállítások, programozás (scriptek írása), frissítés, és minden Mikrotik routerrel kapcsolatos beszélgetés helye.
Új hozzászólás Aktív témák
-
bacus
őstag
válasz
Beniii06
#11595
üzenetére
"Mivel másik hálózatban vannak,így nem fogják egymást látni, kivéve ha olyan route vagy mangle szabályt adsz hozzá."
Ez nem biztos. Ha ezt azon a routeren csinálod ami az alapértelmezett átjáró is, akkor minden féle szabály nélkül átlát az egyik a másikba. Az, hogy nem megy a windowsos hálózatfelderítés, az nem jelenti azt, hogy nem lát át.
A masq. szabályt NEM mindegy hogy veszed fel, ha megadod hogy az out interface az a wan1 (bármi legyen is az, pppoe vagy fizikai interface), akkor a létrehozott hálózatok mindegyike egy szabály alatt működik, egymás felé pedig nem fognak maszkolni.
-
#11598
Zwodkassy
senior tag
E.Kaufmann
#11597
válasz
E.Kaufmann
#11597
üzenetére
Sajnos most nem találom a forrást, leírást (és mobilon nincs is idegem megkeresni), így csak fejből írom :
1. GPS
2. NTP/SNTP - itt először a dinamikusan (pl DHCP-n) kapott címeket használja, aztán a kézzel megadottakat.
3. IP Cloud
Persze script alapon "minden" lehetséges
-
#11597
E.Kaufmann
veterán
E.Kaufmann
veterán
Valaki nem tudja, hogy a különböző időszinkron források között (IP Cloud, GPS és SNTP) van valami prioritás a RouterOS-ben, vagy ha mindhárom be van lőve, vagy egymást csapkodják fölül?
Jó lenne az, hogy amíg nincs rendses GPS vétel addig a cloud-ról vagy SNTP-ről szinkronizáljon, de utána már csak GPS-ről. Ezt hogy lehetne akár scripttel megoldani? -
Beniii06
addikt
"elbeszélünk szerintem egymás mellett."
Szerintem is.
""tudjanak netezni. pont."
Ehhez kell az említett nat szabály, mivel külön hálózatban vannak a vpn címek. Amikor teljesen üres konfigot állítasz be, az első lépések között van ennek a masquerade szabálynak a létrehozása, más különben pont ugyanez történik, hogy a route-olás nem működik nat szabály nélkül. Ennél egyszerűbben nem lehet leírni. Mivel készítetted el a mostani konfigodat, quick set-el? Úgy már világos lenne, miért beszélünk el egymás mellett. Minden konfigolt eszközben, amelyiknél ki szeretnél "nézni" a netre ott a szabály. Nálam is.
"én nem akarom, hogy az eth5-re kapcsolódók elérjenek bármit ami a belső hálón"
Mivel másik hálózatban vannak,így nem fogják egymást látni, kivéve ha olyan route vagy mangle szabályt adsz hozzá. A probléma szerintem az, hogy nem ip alapon látod az egészed, hanem interface-nként.
-
-
Laca0
addikt
válasz
user12
#11588
üzenetére
Köszönöm! Itt sohase találtam volna meg magamtól...
Amióta letiltottam a router eszközben a wifit, azóta a cpu sem szállt el és nem volt eldobás.
Azt is megfigyeltem, hogy sokáig nem volt baj a rendszerrel, amíg minden kliens a külső ap-hoz csatlakozott. Amint egyik telefon a router wifijére csatlakozott, 1-2 percen belül elszállt a rendszer. -
nálunk akkor dobálta el a capsman a cap-okat és a klienseket, amikor maradt a hálózatban olyan eszköz, amiben nem volt bekapcsolva a spanning tree, meg amikor maradt a hálózatban ilyan Ubiquiti eszköz, ami csúnyán összeakadt a Mikrotik féle capsmannal, de mindkét esetben loopot érzékelt a Mikrotik és azután dobta el a cap-ot.
-
-
Laca0
addikt
válasz
user12
#11579
üzenetére
Az a probléma megoldódott, de sajnos azóta is eldobálja az interfész kapcsolatot. Már most cap50-nél jár. Ilyen szekvencia látszik a logban:
oct/24 22:42:22 caps,error removing stale connection [48:8F:5A:00:xx:xx/11/fe56,Run,CAP-488F5A00xxxx] because of ident conflict with [48:8F:5A:00:xx:xx/11/2b3a,Join,CAP-488F5A00xxxx]
oct/24 22:42:22 caps,info 28:16:7F:E9:xx:xx@cap8 disconnected, interface disabled
oct/24 22:42:22 caps,info 80:35:C1:5F:xx:xx@cap8 disconnected, interface disabled
oct/24 22:42:22 caps,info C8:93:46:75:xx:xx@cap8 disconnected, interface disabled
oct/24 22:42:22 caps,info [48:8F:5A:00:xx:xx/11/2b3a,Join,CAP-488F5A00xxxx] joined, provides radio(s): 48:8F:5A:00:xx:xx
oct/24 22:42:23 caps,info cap9: selected channel 2442/20-Ce/gn(20dBm) (fixed)
oct/24 22:42:32 caps,info C8:93:46:75:xx:xx@cap9 connected, signal strength -66
oct/24 22:42:45 caps,info C8:93:46:75:xx:xx@cap9 reassociating
oct/24 22:42:45 caps,info C8:93:46:75:xx:xx@cap9 connected, signal strength -67
oct/24 22:42:49 caps,info C8:93:46:75:xx:xx@cap9 reassociating
oct/24 22:42:51 caps,info C8:93:46:75:xx:xx@cap9 connected, signal strength -67
oct/24 22:43:00 caps,info 28:16:7F:E9:xx:xx@cap9 connected, signal strength -69
oct/24 22:43:00 caps,info C8:93:46:75:xx:xx@cap9 disconnected, 4-way handshake timeout
oct/24 22:43:01 caps,info C8:93:46:75:xx:xx@cap9 connected, signal strength -66
oct/24 22:43:02 interface,info cap9 detect LAN
oct/24 22:43:05 dhcp,info dhcp_lan deassigned 192.168.2.57 from C8:93:46:75:xx:xx
oct/24 22:43:05 dhcp,info dhcp_lan assigned 192.168.2.57 to C8:93:46:75:xx:xx
oct/24 22:43:07 dhcp,info dhcp_lan deassigned 192.168.2.52 from 28:16:7F:E9:xx:xx
oct/24 22:43:07 dhcp,info dhcp_lan assigned 192.168.2.52 to 28:16:7F:E9:xx:xx
oct/24 22:43:22 caps,info 80:35:C1:5F:xx:xx@cap9 connected, signal strength -47
oct/24 22:43:27 caps,info 80:35:C1:5F:xx:xx@cap9 disconnected, received deauth: unspecified (1)
oct/24 22:43:27 caps,info 80:35:C1:5F:xx:xx@cap9 connected, signal strength -49
oct/24 22:43:28 dhcp,info dhcp_lan deassigned 192.168.2.51 from 80:35:C1:5F:xx:xx
oct/24 22:43:28 dhcp,info dhcp_lan assigned 192.168.2.51 to 80:35:C1:5F:xx:xx
oct/24 22:46:24 caps,error removing stale connection [48:8F:5A:00:xx:xx/11/2b3a,Run,CAP-488F5A00xxxx] because of ident conflict with [48:8F:5A:00:xx:xx/11/f25a,Join,CAP-488F5A00xxxx] -
Beniii06
addikt
Ha külön hálózatba raktad a kiosztott vpn címeket(ha nem, akkor így nem érnék el a többi eszközt pl.), akkor azoknak(annak a hálózatnak) is kell srcnat szabály.(masquerade) Ez megvolt?
A filter rule-t hanyagold szerintem, előbb próbáld meg más tartományt kiosztani a helyitől eltérő hálózatban és arra nat szabályt létrehozni.
-
egyszer volt, hol nem volt, volt egyszer egy router, melynek az eth1 portjába jött a WAN, az eth5, meg egy bridge része volt (fölöslegesen, mert senki más nem volt a bridge-ben)...
br0-on van egy DHCP szerver, meg egy alhálózat, és azt szeretném, ha a router semelyik másik interfészét, virtuális interfészét, VPN kapcsolatát, akármilyét nem érnék el azok az eszközök, amik eth5-re kapcsolódnak, de persze globális internet azért legyen.én kis naiv azt gondoltam, hogy ha azt mondom a tűzfalban a filter szabályok közt, hogy
add action=drop chain=forward in-interface=br0 out-interface=!eth1-Digi
akkor az majd pont ezt fogja csinálni, de valójában azt eredményezte, hogy a netet se érte el semmi abból az irányból.most ahogy ezt írom, jutott eszembe, hogy lehet, hogy nem eth1-et, hanem a pppoe kapcsolatot kellett volna megadni.
vagy nem? -
-
m0ski
aktív tag
Sziasztok!
Nem biztos, hogy Mikrotik probléma, de mivel minden eszköz Mikrotik, itt próbálnék először a problémára megoldást találni.
CRS328-24P-4S+ hajt meg 4 darab cAP AC-t és egy RB951G-2HnD-t, amiket egyébként egy RB4011 fog össze CAPsMAN-ben.
A konfig alapvetően jól működik, viszont van egy fura jelenség:Az AP-k időnként eltűnnek Winbox-ban az eszközlistáról, ilyenkor egy CRS328-on indított Power cycle szokott segíteni. Beállítottam, a power cycle ping-et 2 perces timeout-tal, és jelenleg a fő eszközök 28 napos uptime-al mennek, az AP-k viszont 1-2 nappal.
Power cycle után megy minden rendben.
Mi okozhatja a problémát? Gyenge kábelezés (CAT5e), eszköz probléma?
Előre is köszönöm a segítséget!
-
Laca0
addikt
Sziasztok!
Van egy hap lite routerem és egy cAp 2nd AP-m. Capman-t szeretném használni velük. A hap a manager, beállítottam rajta a saját wifi interfészét is használatra. Ez eddig működik. A cAp-on a wireless interface alatt beállítottam, meg is jelent az interface (cap2) a manager-ben.
De valamiért nem akart működni. Mivel régebbi ros volt rajta (gyári), frissítettem. De ez már újabb lett, mint a hap, ezért a hap-ot is frissítettem (6.47.6).
Viszont azóta nem akar hozzákapcsolódni a manager-hez a cAp. Már 3x reseteltem és kezdtem előröl a beállítását, de nem jelenik meg a cap interface listában és nem is látom a részleteket megjelenni a cap-on.
Van valami ötletetek? -
b10up
tag
válasz
Formaster
#11563
üzenetére
Biztos nincs ezen valami pppoe pass-trough opció, amit lehet használni? Azt még megértem, ha az eszközt nem lehet lecserélni, de ez még megérhet egy kört, hátha.
IPTV és telefon általában külön vlan-on szokott menni a nettől függetlenül, nem hiszem ,hogy az érinti, inkább -ha tényleg ez a baj- akkor a webes felületen lévő DMZ rosszul vezérli a tűzfalat és csak tcp portokra vonatkozik a nyitás, udp pedig elfelejtődött.
Ez utóbbit mondjuk ki tudod próbálni úgy, hogy simán kinyitogatod az udp portokat még a DMZ mellé. -
#11564
noorbertt
őstag
E.Kaufmann
#11438
noorbertt
őstag
válasz
E.Kaufmann
#11438
üzenetére
Szia,
Mikrotik rendszerén belül milyen beállításokat érdemes csinálni hogy ne keljen nagyon foglalkozni vele? Pl auto update?
-
jerry311
nagyúr
válasz
hun005a
#11560
üzenetére
Oké, ha kinyitod akkor azt bárki elérheti. Ha nem a default porton van, akkor legfeljebb egy kicsit később.
Csinálsz egy dst-nat-ot, amin a General fülön a dst port 49345, az Action fülön a To Ports meg 8001.
Kell még egy tűzfal szabály, ami beengedi a külső IP-re és 49345-ös portra érkező kapcsolatokat.
Röviden és tömören ennyi. -
b10up
tag
válasz
Formaster
#11554
üzenetére
Nekem ez gyanús.
Meg kéne nézni, hogy az UDP csomagok eljutnak-e a Mikrotik WAN-jáig, mert láttam olyan bugos szolgáltatói modemroutert, hogy meglehetősen hiányosan működtek hasonló funkciók, pedig látszólag minden oké volt.
Bővebb típust lehet esetleg tudni a szolgáltatói dobozról? -
Formaster
addikt
válasz
Beniii06
#11553
üzenetére
Külföld és ez a box nem tud bridge módot, illetve sajátot sem engednek felkonfigolni. Marad a DMZ, de ez az egyetlen alkalmazás ahol gondot okoz, ennél is csak az UDP nem megy át, a TCP portok rendben vannak. Számtalan más eszköz van fent, NAS, Pi, stb, amiknél minden jól megy. Ettől függetlenül szerintem mégis a Mikrotikben lesz a megoldás.
-
Formaster
addikt
Jó lenne valakit bevonni, akár fizetnék is érte, szerintem a Filters-t is át kéne nézni és ezzel itt valami tuti nincs rendben. A DMZ nem kiiktatható a szolgabox miatt, de ez mennyire számít dupla NAT-nak? Minden portot átad a Mikrotiknek.
Zwodkassy: Nagyon nem akart helyreállni, csak winboxon keresztül tudtam elérni a routert, semmi más nem kommunikált a hálózaton.
-
-
bacus
őstag
válasz
Formaster
#11545
üzenetére
A fizikai interface-nek adott ip, ami része egy bridgenek, szóval ez tuti potenciális probléma, még akkor is, ha látszólag működik. Ez a dmz meg dupla nat nem kiirtható?
Mutasd meg valakinek a konfigot, pl: engedd be a routered-be olvasási joggal aztán hadd nézelődjön, mert lehet átmész ugyanazokon a hibás beállításokon.
-
bambano
titán
ha a router a vpn szerver: a router általában arról az ip-ről fog válaszolni, ahova a kapcsolódás történt. ezért azt kell megoldanod, hogy minden csomag aszerint kapjon next-hop-ot, hogy milyen forrás ip-je van.
mondjuk kérdés, hogy a két wan a vpn szerver routerben végződik-e, vagy van két szolgáltatói router és amögé tettél mikrotik vpn szervert.
-
jerry311
nagyúr
A routing makacs dolog, nem olyan egyszerű a dual WAN, hogy csak bedugunk 2 kábelt.
Bejön az egyiken a kapcsolat, de a route tábla miatt nem azon válaszol.
Ez segíthet: https://mum.mikrotik.com/presentations/PH18/presentation_5105_1516322800.pdf -
válasz
Formaster
#11542
üzenetére
"A 88.1 a belső hálózatom címe, de hogy ez miért lett anno ether2 kérlek ne kérdezzétek
"
Régen ez volt a RouterOS default config-ban. Ha jól tudom, manapság bár a (local) bridge interface kapja az IPv4 címet. Hivatalosan "slave" interface-nek nem is adhatsz IP címet. -
van egy Mikrotik routerem, amire L2TP/IPSec-kel kapcsolódnak a kollégák.
lett egy második WAN, és jó lenne, ha azon keresztül is lehetne kapcsolódni.
ha megpróbálom, annyi látszik a logban, hogyrespond new phase 1 (Identity Protection): 192.168.1.2[500]*<=>1.2.3.4[500]**the packet is retransmitted by kapcsolódniPróbálóEszközIPje[500].
ez még néhányszor, aztánphase1 negotiation failed due to time up 192.168.1.2[500]<=>1.2.3.4.[500] randombetűkÉsSzámokHexában* a router IP-je, amit a szolgáltatói eszköztől kap
** a kapcsolódni próbáló eszköz IP-jea szolgáltatói eszközben DMZ-be raktam a Mikrotiket, szóval elvileg nem az fogja meg, és ha mégis, akkor a próbálkozás se látszódna a Mikrotik logban. ugyanemiatt nem gyanakodok arra se, hogy a szolgáltató (Digi) blokkolna valamit.
a Mikrotikben meg nem találok olyan specifikus beállítást, opciót, tűzfalszabályt, ami alapján az egyik WAN-on faszául működik minden, a másikon meg csak a fenti szerencsétlenkedés valósulna meg.ötlet, hogy egyáltalán mit nézzek meg merre?
-
#11542
Formaster
addikt
allnickused
#11541
Formaster
addikt
válasz
allnickused
#11541
üzenetére
Letiltottam minden tűzfal szabályt, kivéve a portforward accepteket, mert van a hálózaton eszköz, ami folyamatosan elérhető kell legyen. Nem segített. Sajnos az elérhetőség miatt nem tudok resetelni.
Még ezt találtam ami problémás lehet:
Az ether2 -re az említett PC csatlakozik. Fogalmam sincs miért sikerült anno így, de működik minden a hálózaton és a múltkor átraktam Bridge-re, azzal elszállt minden kommunikáció. Az sfp Interface értelem szerűen a bejövő WAN, ami az ISP boxon az 1.123-as címet kapja, erre irányul minden DMZ-ben. A 88.1 a belső hálózatom címe, de hogy ez miért lett anno ether2 kérlek ne kérdezzétek
-
allnickused
tag
válasz
Formaster
#11540
üzenetére
UPnP-nél azért adja hozzá, mert automatikusan létrehozza a szabályt és ilyenkor ignorálja a kézit. Ezért látod duplikáltan. Próbáld meg, hogy letiltod manuálisan az összes tűzfalszabályt és ha ekkor sem mennek át a csomagok, akkor csinálsz egy konfigmentést, kireseteled és az üres defconffal megpróbálod. Ha így sem megy, akkor lehet azzal az egy játékkal van a gond.
-
#11540
Formaster
addikt
allnickused
#11539
Formaster
addikt
válasz
allnickused
#11539
üzenetére
Valóban, már jojózik a szemem. A ps4 portok mások, mint PC-n, nálam az UDP miatt nem Open a NAT. Hiába van forwardolva, a 3074-eset UPnP-n ismét hozzáadja, de hiába adja hozzá, csomag nem megy át rajta. Ezért gondolom, hogy valami Filter részen akad el, de miért csak ez a game. Vagy valahol a dupla NAT-olással akad el, már ha DMZ-nél lehet dupla NAT-nak nevezni.
-
allnickused
tag
válasz
Formaster
#11538
üzenetére
Ha jobban megnézed nem ugyanaz a 3. Prerouting, forward, postrouting.
Egyébként nekem ezekkel a szabályokkal mennek a forwardok, ps4-en open nat működik. Ha gondolod írd át a portokat és próbáld ki, hátha...
/ip firewall nat add action=dst-nat chain=dstnat dst-port=80,443,1935,3074,3478-3480 in-interface=ether1 protocol=tcp to-addresses=fix.ip-d
/ip firewall nat add action=dst-nat chain=dstnat dst-port=80,443,1935,3074,3478-3479,6000,9306-9308 in-interface=ether1 protocol=udp to-addresses=fix.ip-dfix.ip-d: a belső hálózatos ip-d amit statikusra állítottál.
-
Formaster
addikt
válasz
Zwodkassy
#11536
üzenetére
NAT részben természetesen definiáltam és ha a PING nem is kellene számoljon, de az adott program indításakor igen. Ha UPnP-t bekapcsolom, akkor is hozzáadja NAT-ot, de csomagok nem mennek, ezért gondolom, hogy a Filter-nél akad el. Az utolsó hsz-nél ahogy írtam, hozzá is adtam a Rule-t a Filters-hez, kifejezetten erre szabva, mégsem Forwardolja UPD-n a portot.
szerk:
Ezt a két fület nem értem, leginkább azt nem miért szerepel a Mangle alatt 3x ugyanaz a dummy.
-
Formaster
addikt
válasz
Formaster
#11534
üzenetére
Nem akarom tele spammelni a topikot, de azóta sem oldódott meg a NAT problémám. Kicsit kifejtem, hátha valakinek van bármi elképzelése.
Szóval a problémám egy game NAT type-ja, hiába forwardolom a portokat, a NAT Moderate marad, minden imám ellenére sem lesz Open. Kicsit beleolvasva a témába, több mikrotik topik is hemzseg a hibától, de bármelyik megoldást keresem, problem unsolved.
Szóval, adott egy szolga box, DMZ irányít minden portkérést a Mikrotikre. Mikrotikben NAT-oltam a portokat a statikus IP-re, a TCP-sek működnek is, de UDP az süket, csomagok sincsenek.
UPnP-t engedélyeztem, ilyenkor a szükséges UDP portot hozzáadja, ezt a WAN-os interface-re kapcsoltam, próbáltam Internal/External beállítással is, semmi. External-nál az ISP Box által osztott mikrotik IP-t írja Dst. Addressnek, to Address pedig a PC címe.
Gondoltam Firewall Filter probléma lesz, másnál meg is oldotta a problémát, így hozzáadtam az alábbi sort, de hiába.
/ip firewall filter add chain=forward action=accept connection-nat-state=dstnat protocol=udp dst-address=ip.of.your.PC dst-port=3074,27014-27050Egyesek szerint dupla NAT-olással sehogy sem lesz Open NAT-om, mások szerint DMZ-vel ennek mennie kellene. A többi portnál sem okoz ez gondot. Port ütközés nincsen. Ami furcsa, hogy ha én nyitottam manuálisan egy NAT-ot a PC-re, akkor ha UPnP rakom, miért csinál egy ugyan olyan ismét.
Szerintem továbbra is a Firewall Filterben rejtőzik a problémám gyökere, de nem tudok rájönni, mi hiányzik, vagy tiltja le, miközben a TCP gond nélkül átmegy. Ha valaki ellátna pár tanáccsal, nagyon hálás lennék!
-
Formaster
addikt
-
Formaster
addikt
Nekem is elkelne egy kis port kiigazítás. Sehogy nem tudom az UDP-t működésre bírni, szerintem a Rules-t kissé összekutyultam
0 D ;;; special dummy rule to show fasttrack counterschain=forward action=passthrough1 ;;; defconf: accept established,related,untrackedchain=input action=accept connection-state=established,related,untracked2 ;;; defconf: drop invalidchain=input action=drop connection-state=invalid log=no log-prefix=""3 ;;; defconf: accept ICMPchain=input action=accept protocol=icmp4 ;;; defconf: drop all not coming from LANchain=input action=drop in-interface-list=!LAN5 ;;; defconf: accept in ipsec policychain=forward action=accept ipsec-policy=in,ipsec6 ;;; defconf: accept out ipsec policychain=forward action=accept ipsec-policy=out,ipsec7 ;;; defconf: fasttrackchain=forward action=fasttrack-connection connection-state=established,related8 ;;; defconf: accept established,related, untrackedchain=forward action=accept connection-state=established,related,untracked9 X ;;; defconf: drop invalidchain=forward action=drop connection-state=invalid log=no log-prefix=""10 ;;; defconf: drop all from WAN not DSTNATedchain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN -
e90lci
senior tag
válasz
hramon94
#11530
üzenetére
Példa:
0 ;;; Hairpin Nat
chain=srcnat action=masquerade src-address=192.168.1.0/24
dst-address=192.168.1.10 log=no log-prefix=""1 ;;; Hairpin nat nas
chain=dstnat action=dst-nat to-addresses=192.168.1.10 to-ports=5001 protocol=tcp
dst-address-type=local dst-port=50001 log=no log-prefix="" -
hramon94
tag
Sziasztok! Port Forwardingban szeretnék segítséget kérni. IP kamerát szeretnék távolról elérni. Ez működik is első próbálkozásra. Ha beírom a WAN_IP:8000 címet akkor mobilnetről tökéletesen elérem viszont ha hazaérek és csatlakozom a saját hálózatra akkor csak a kamera belső ip-jén(192.168.88.10:8000) tudom elérni a belső hálózatról megnyitott WAN_IP:8000 egyszerűen nem működik. Kérlek segítsetek a beállításban.
Jelenlegi beállítások:/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat dst-address-type=local dst-port=8000 \
protocol=tcp to-addresses=192.168.88.10 to-ports=8000 -
mrzed
senior tag
Érdekesen alakul ez a dac kábel dolog... Első körben a kábelre tippeltem, mint a szakadás oka. Többször ki-be dugdostam a 11-es portba, minden esetben szakadás volt a vége. A 10-esbe hibátlanul futott egész nap, ekkor már gigás rezes modul került a helyére, ami szintén hiba nélkül ment. Már ott tartottam, hogy valamiért a 10Gb -es kapcsolat nem tetszik a szóban forgó portnak. Kezdtem agyalni, hogy a csudába tudom ezt majd gariztatni. Támadt egy ötletem, és optikai modult tettem oda... ezzel is hibátlanul megy már több órája. Elég kacifántos ez így... még szerencse, hogy a 14 portot össze tudom úgy forgatni, hogy ne legyen fennakadás.
bambano:
A választásnál az egyik alapvető szempont volt, hogy tudjon kezelni 10Gb -es rj45-öt. Egyelőre kettő ilyen van benne, egész jól szerepelnek, lényegesen nagyobb melegedésre számítottam. 65 foknál nem igen megy feljebb, csak az miatt be se indulnak a ventilátorok. Viszont érdekes, hogy ugyanennyi a hőfok 1Gb és 2,5Gb kapcsolatnál is, huzamosabb terhelés mellett sem melegszik ettől jobban. -
mrzed
senior tag
válasz
jerry311
#11525
üzenetére
Nem tudom, mi lehet a nyűgje. A két mellette lévő nem ment egyszerre. Most a 10-esben van a DAC kábel, mellette a 9-esben egy s+rj10 fűti, még sincs baja. A hibásnak vélt 11-esbe most áttettem egy gigás rezes modult, ap-t dugtam bele, úgyhogy még log sem kell, ha megáll, úgy is lesz visítás.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
-
-
mrzed
senior tag
Izopropil alkohollal megtisztogattam a DAC kábel érintkezőit, és visszaraktam, előtte bekapcsoltam a debug-ot. Viszont nem lettem tőle okosabb.
Itt volt egy pillanatnyi szakadás, de azonnal visszacsatlakozott:
Nem sokra rá ismét megszakadt, csatlakozás azóta sem történt:
Nem tudom, hogy Nektek többet mondanak-e ezek a bejegyzések.
Megyek, muszáj visszatennem optikára a NAS-t.szerk:
A NAS logjában sem látszik több:
Oct 16 09:17:31 OMVNAS kernel: [60145.037519] mlx4_en: enp1s0: Link Down
Oct 16 09:17:31 OMVNAS systemd-networkd[312]: enp1s0: Lost carrier
Oct 16 09:17:32 OMVNAS systemd-networkd[312]: enp1s0: Gained carrier
Oct 16 09:17:32 OMVNAS kernel: [60145.776558] mlx4_en: enp1s0: Link Up
Oct 16 09:24:25 OMVNAS kernel: [60559.279133] mlx4_en: enp1s0: Link Down
Oct 16 09:24:25 OMVNAS systemd-networkd[312]: enp1s0: Lost carrier -
mrzed
senior tag
-
-
powerwade
senior tag
Sziasztok, van valakinek tapasztalta szervizzel kapcsolatban? Tortent ugyanis, hogy az alig 3 honapos cAP - RBcAPGi-5acD2nD fogta magat es elnemult. Hiaba kap POE-n tapot, nem gyulladnak ki a LEDek, total halott. Probaltam masik kabellel, masik POE eszkozrol tapolni, de semmi. "Sajnos" (
) Alzan vasaroltam valami akcioban... Van itthon ezeknek az eszkozoknek szervize? -
ZPKing
tag
válasz
Adamo_sx
#11508
üzenetére
Nekem is sebesség problémám van L2TP/IPsec-en belül továbbra is.
VPN server L2TP/Ipsec Mikrotik 4011.
Annyit tudunk mostmár ha egy másik mikrotik routerrel csinálunk btestet VPN-en keresztül
100/100 a vpn szerver 1000/300 as digi net kliens között ott nagyjából megvan a sebesség 80-90 Mbit mind a két irány.
Probléma akkor jön ha a routeren lógó SMB szerverről akarok másolni VPN-en keresztül egy kliens windowsra ugyan ezen a rendszeren keresztül akkor csak 20-25Mbit között van a letöltési sebesség. Csináltunk windows kliensről jperf tesztet úgy hogy az SMB serveren (ubuntu 12.04) a jperf server.
Itt is arra jutottunk mint a másolásnál. 20-30Mbit között.
Sajnos érthetetlen a dolog.
Annyi infó hogy szerintünk az MTU érték lehet a probléma. SMB serveren elvileg 1500 az MTU 100/100as Internet ami Ethernet SHD Telekom béreltvonali internet az is 1500.
Az L2TP meg csak 1400MTU értéken fut. Kliens oldalon a digi net ha minden igaz akkor 1498 a másik kliens esetén 1500MTU.
Arra gondolunk hogy a csomag mért miatt darabolásra elmegy a sebesség.
Valakinek ötlet esetleg? -
Adamo_sx
aktív tag
válasz
yodee_
#11506
üzenetére
Hát, passz, nem tudom, hogy ez elég-e (lehet, hogy igen). Még annyi ötletem van, hogy mindkét oldalon megnézném konkrétan menet közben, hogy biztosan nem az eszközök a szűk keresztmetszet. A routeren is, meg a gépen is (gondolom a task managerben látszik, ha elfogy a teljesítmény).
-
#11502
takikacska
csendes tag
takikacska
csendes tag
Sziasztok.
Jelenleg Van egy Mikrotik routerem Telekom optikai hálózaton, a Telekomos router bridge(passthrough) módban van, a mikrotik építi fel a pppoe kapcsolatot.
A vonalon van IPTV és telefon előfizetés is, a telefon és az IPTV box-ok a Telekom routerre van csatlakoztatva.A telefon vonalon kb 5 másodpercenként egy kattanás hallatszik a vonalban, az IPTV adás csatorna váltás után 5 másodperccel kimerevedik egy kis időre(kb 20s), az IPTV hiba nem mindig de ha igen akkor ha sokiíg kapcsolgatok a csatornák között akkor megszűnik a hiba.
A Telekomos szerelő lehúzta a router a hálózatról akkor megszűnik a hiba. Járt már valaki így?
Milyen tűzfal szabályt kellene felvennem a mikrotikbe? -
Adamo_sx
aktív tag
válasz
yodee_
#11500
üzenetére
Nézz egy terhelést a routeren, miközben másolsz a titkosított VPN-en. Ha az magas, akkor nem támogatott titkosítást választottál az IPsec-hez. Ha ezek rendben vannak, akkor - szerintem - nem a routerednél lesz a hiba.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
CCR2004
)
Új hozzászólás Aktív témák
Hirdetés
ekkold
- HP Probook 640 G2 (14FHD/i3-G6/8GB/256SSD/Magyar/Win11) - Szép!
- AMD Ryzen 5 5500 - Új, 3 év garancia - Eladó!
- Kamerarendszerek telepítése //// Gyengeáramú hálózatok kiépítése //// Informatikai segítségnyújtás
- Hibátlan Apple iPhone 15 Pro - Kártyafüggetlen - 128GB Fekete Titán (87% Akku)
- Apple iPhone 14 Pro, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! HP Elitebook 850 G8 - i5-11GEN I 16GB I 256GB SSD I 15,6" FULLHD I Cam I W11 I Gari!
- Dell és HP szerver HDD caddy keretek, adapterek. Több száz darab készleten, szállítás akár másnapra
- Asus TUF A15 FA507NU - 15.6"FHD IPS 144Hz - Ryzen 7 7735HS - 8GB - 512GB - RTX 4050 -2.5 év gari
- Csere-beszámítás! Számítógép PC Játékra! I3 14100F / RTX 3060 12GB / 32GB DDR4 / 500GB SSD
- VÉGKIÁRUSÍTÁS - REFURBISHED - Lenovo ThinkPad 40AC Thunderbolt 3 docking station
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged