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.

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?

Ha jól látom akkor ezek jók :

Honor Magic 6 Pro | Lenovo Thinkpad X280 | Lenovo Thinkcentre M800

És a másik oldalon mi csinálja a titkosítást? Az az oldal elég erős hozzá?

Nem egészen értem, már 24 órája megy, most nem áll le. Annyit változtattam, hogy hozzáadtam a DHCP/Networknél is a DNS szervert. De akkor is idegesít miért állt

A másik oldalon egy T-Home optikai modem +Router kombo van, a gépen van VPN kapcsolat beállítva Windows 10 alatt. 3. Generációs i5 a proci, 8GB rammal Ssdvel.

Honor Magic 6 Pro | Lenovo Thinkpad X280 | Lenovo Thinkcentre M800

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).

Akkor annyi változott, hogy eddig a kliensek a routeről kértek DNS feloldást és a router kérte a PiHole-tól, most pedig a kliensek megkapják a PiHole címét és közvetlenül ahhoz fordulnak a DNS kéréssel?

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?

[Change MSS] [link]

Ezeket ismerem valamiért az értékek meg a beállítások nem nem tudom úgy összelegózni, hogy működjön.

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?

[ Szerkesztve ]

Vidd vissza, hiszen garis...

Az lesz. Gondoltam leadom en, es ha javithatatlan akkor "benyujtom a szamlat" az Alzanak. De ahogy latom, nincs is helyben szerviz, igy lesz egy korom a Robert Karoly korutra

Az mitől lehet, hogy DAC kábellel 15 perc után szakad a kapcsolat? A naplóba csak annyi kerül, hogy sfp-sfpplusxx link down. Viszont ugyanez a kapcsolat modullal optikai kábellel stabil.

Lehet, hogy valamelyik modul hibás.
Kapcsold be debugot és több mindet fog naplózni.

Link down után mi történik? Magától helyrejön vagy valamit csinálni kell (pl kihúzni-bedugni, vagy interface reset, stb), hogy újra felálljon

[ Szerkesztve ]

Rendszergazda vagyok....ha röhögni lát, mentsen

Dac kábel esetén nincs modul. Csak akkor áll helyre a kapcsolat, ha tiltom, majd engedélyezem a portot a routerben. Még a csatlakoztatott gép újraindítása sem hozza rendbe a linket.

DAC esetén is ott van két modul a két végén, csak nem tudod kihúzni belőle a kábelt. (egynél többször )
A tiltás/engedélyezés egyenlő ki/be kapcsolással, ami sok problémát megold ideiglenesen.

user12, jerry311:
Köszönöm a tippeket.
Az az érzésem, hogy a mikinek nem tetszik túlzottan a mellanox kábel. Kérdéses az, hogy ha veszek egy S+DA0001 kábelt, ahhoz meg a mellanox kártya mit szólna.
Nincs valakinek véletlen egy felesleges SFP-10G-SR modulja?

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

[ Szerkesztve ]

Én úgy gondolom, hogy nem a kontakttal lesz a baj, inkább maga a modul nem kompatibilis vagy hibás. (már csak azért is mert azt mondod, hogy optikával jól megy)
Ha van lehetőséged, próbáld ki másik sfp portban vagy ha van, teljesen más eszközpárral.

Rendszergazda vagyok....ha röhögni lát, mentsen

Átdugtam a DAC kábelt a 10-es portba. Egy órája stabil, eddig nem ment ennyit egyszerre. Az optikai, amiről próbáltam, az a 12-esben van. Sajna egyelőre úgy néz ki, hogy a 11-es port lesz a hibás a routeren.... de még tesztelem.

Lehet csak túl közel vannak egymáshoz és elmelegszenek.
Cisco-nak is volt ilyen hardver bugja.

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.

Nem baj az.
Egy ideig nem lesz szűk keresztmetszet

Rendszergazda vagyok....ha röhögni lát, mentsen

hmm. meglepődtem, az s+rj10 engedélyezve van a ccr2004-hez...

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

É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.

[ Szerkesztve ]

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

Hairpin Nat.

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=""

[ Szerkesztve ]

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 counters
      chain=forward action=passthrough 
 1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 
 2    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix="" 
 3    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 
 4    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN 
 5    ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec 
 6    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 
 7    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection connection-state=established,related 
 8    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 
 9 X  ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 
10    ;;; defconf:  drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN 

Pár órája itt ülök, hogy kibogozzak mindent, de a Rules-ban nem látok semmi olyat, ami miatt ne mehetne át az UDP. Felvettem külön Firewall szabályként is kifejezetten az adott UDP portot, de meg se nyikkan, még csomagot se számol hozzá mikor pingelem.

Találtam egy régről felvett UDP forwardot a routerben, érdekes ezen keresztül tudom pingelni a gépet, az újakról nem. A win tűzfal kilőve. Belefulladtam

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-27050

Egyesek 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!

Igaz mobil telefonon nézem, de ebben nem találom az UDP-s szabályodat.
Szerintem ezt nem feltétlenül az Ip/Firewall/Filters részben kéne definiálni, hanem az Ip/Firewall/NAT részben.

[ Szerkesztve ]

"Felvettem külön Firewall szabályként is kifejezetten az adott UDP portot, de meg se nyikkan, még csomagot se számol hozzá mikor pingelem"
Hát a PING az ICMP protokoll, tehát arra nem is fog számolni

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.

[ Szerkesztve ]

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-d

fix.ip-d: a belső hálózatos ip-d amit statikusra állítottál.

[ Szerkesztve ]

(De, az vagy)

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.

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.

(De, az vagy)

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

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, hogy
respond 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án
phase1 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-je

a 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?

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

"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.

Próbáltam is Bridge-re rakni és lehallt a teljes hálózat.

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

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.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Én is azt érzem, hogy a wan2-ről érkező csomagot a def route miatt a wan1-en küldi vissza..

Kössünk egyezséget, megegyezős egyezséget... https://www.paypal.me/engiman/30

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.

Kössünk egyezséget, megegyezős egyezséget... https://www.paypal.me/engiman/30

ami egyébként általában nem probléma.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis