Köszi szépen a segedelmet!
Azóta olvasgattam egy kicsit a témában, és bennem is hasonló kép alakult ki :-)

Sziasztok!

Adva vagyon 2 db hAP AC2 IPSEC tunnel-lel összekötve. Működik is nagyon szépen, viszont a hálózati felderítést hiányolom (ip alapján megtalálja a másik oldalon lévő NAS-t, de a hálózati helyekben nem látszik). Utána olvasva IPSEC tunnelnél erre nincs is lehetőség. Valami trükkel nem lehetne mégis kivitelezni? Olvastam a GRE tunnelről IPSEC alapon, csináltam is a meglévő mellé, fel is épül a kapcsolat, de semmi eredmény. Ötlet?

Lehet pl. eoip-vel összekötni a routereket az ipsec felett, akkor a layer2 szintű kapcsolatot is csinálhatsz. Ezzel viszont más problémák jönnek elő (pl. DHCP szerverek ütközése - mivel a távoli DHCP is látszani fog a hálózatban.)

Igen ezzel nekünk is volt gond. ráadásul össze vissza felvették a kliensek a más-más dhcp címeket. :/

A Bridge-en a DHCP Snooping-et erre találták ki!

Leírás: LINK

Ez nem olyan régen került csak be a RouterOS-be. Akkor ki is próbáltam, mivel nekem is van pár állandó VPN kapcsolatom, de valami akkor sem volt oké, furcsa belassulások voltak, a windows-ok meg gyakran IP cím ütközést írtak ki (de valójában nem volt IP ütközés). Gyakorlatilag nem találtam olyan beállítást, amivel elérhettem volna hogy stabil layer2 kapcsolat legyen, és emellett minden működjön úgy mint előtte. Lehet hogy azóta javítottak a dolgokon, nem tudom, nem volt energiám újra nekifutni a dolognak (meg nem is volt olyan fontos). A távoli médiaszerver elérését úgy oldottam meg, hogy szükség esetén egy külön wifi SSID-n szórom a távoli hálózatot, azaz az eoip innenső vége nem a fő bridge-be van belerakva - de ez sem egy állandóan szükséges dolog volt, inkább csak kísérletezés.
Mindenesetre kiváncsi lennék, ha valakinek sikerült jól működő módon megvalósítania két, szokványos otthoni beálllításokkal működő router (NAT, DHCP stb..) között layer2 kapcsolatot, akkor milyen beállításokat használ...

[ Szerkesztve ]

A látókörömben sok L2TP/IPSEC van, igaz nem otthoni környezet de ebből a szempontból lényegtelen, működnek. Ha nem akarsz DHCP Snooping-ot használni a firewall-on szűrheted a DHCP-t.

EIOP-nél a legegyszerűbb szűrni!

/interface bridge filter add action=drop chain=forward disabled=no mac-protocol=ip ip-protocol=udp dst-port=67-68

A Bridge filter a legjobb erre.

(Én személy szerint egy rendes routol-t VPN-t jobbnak tartok mint egy ilyen megoldást!)

Az L2TP/IPSEC alaphelyzetben csak IP-t visz át, layer2-t nem. Persze be lehet állítani hogy layer2-t is átvigyen, de nem ez az alaphelyzet.

[ Szerkesztve ]

Köszönöm, kipróbálom.

Felmerült egy kérdés ezzel kapcsolatban. Ha VPN-el össze vagyunk kötve, erre ráhúzok egy EOIP-t, akkor nem alakulhat ki hurok amiatt, hogy egyszerre van VPN és Ethernet összeköttetés is a két hálózat között?
Vagy kell ilyenkor további tűzfal vagy routing szabály....?

[ Szerkesztve ]

Nekem ez az EoIP egy katyvasz. Hurok nem lesz belőle, mindkét oldalon használhatod ugyanazokat az IP beállításokat.

Tulajdonképpen a Bridge-hez hozzáad mindkét oldalon egy-egy portot ami úgy viselkedik mintha egy kábellel összekötötted volna.

Hallottátok? Megjelent a RouterOS 7.

...vagy nem

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

Nem downgradelek, ez a 8as amit most raktam fel, ez csuda dolgokat tud.., többek között 2x olyan gyors lett a nat a régi routerekben, ezzel még azok is átviszik a gigabitet amin csak 100-as eth csatlakozók vannak

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

Még nem. Nem is találom. Esetleg van linked?

Szerintem innen töltötte le: LINK

Nem kerestem, azért kértem linket....,,

nem túl fényes az uploadom (és akkor még nagyon finoman fogalmaztam), azt is eléggé elviszi a torrent.

egyelőre annyit csináltam, hogy megjelölöm a torrent csomagjait
chain=postrouting action=mark-packet new-packet-mark=torrent-mark passthrough=yes tcp-flags="" protocol=tcp dst-port=51414 log=no log-prefix=""

és a Queue Tree-ben ez a mark a legalacsonyabb prioritást kapja
name="torrent" parent=global packet-mark=torrent-mark limit-at=0 queue=default-small priority=8 max-limit=0 burst-limit=0 burst-threshold=0 burst-time=0s bucket-size=0.1

tudok-e még bármit tenni ezen kívül?

[ Szerkesztve ]

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

A legtöbb torrent kliens tudja korlátozni a fel/letöltési sebességét, nekem általában ennek a beállítása bőven elegendő szokott lenni ahhoz, hogy ne okozzon problémát.

Portonként konfigolom a mikrotiket, így queues szabályokat is tudom így korlátozni, ha nem akarsz minden portot külön, akkor kiveszed a bridge-ből azt amelyiket nem szeretnéd korlátozni a többi portot korlátozod.

köszi, ennyi azért nekem is megvolt.

nem akarom korlátozni, az egy kőbalta megoldás.
azt akarom, hogy amikor nem kell éppen semmi másra a sávszél, akkor tolja csak, ami a csövön kifér. amikor viszont kell, akkor szoruljon háttérbe a torrentforgalom.

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

Őő, nem az src portot kellene figyelni pláne uploadnál? A downstreamhez amúgy sem érdemes piszkálni.

Le az elipszilonos jével, éljen a "j" !!!

a src portot kissé macerás figyelni, mert az szinte minden kapcsolatnál más.

vagy valamit nagyon félreértelmezek...

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

Ok, de feltöltésnél a dedikált torrent portod a forrás.
Viszont lehetne úgy is, hogy fogod a http(s), dns és még pár fontos protokollt, azok kapnak prioritást, minden más a futottak még, ezzel együtt a torrent is.

Le az elipszilonos jével, éljen a "j" !!!

a forgalom egy része udp-s, a szabályban pedig csak a tcp-seket jelölöd meg.

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

és (#7329) E.Kaufmann

köszi, akkor most felvettem két új szabályt

4 ;;; torrent mark
chain=postrouting action=mark-packet new-packet-mark=torrent-mark passthrough=yes tcp-flags="" protocol=udp src-port=51414
log=no log-prefix=""

5 ;;; torrent mark
chain=postrouting action=mark-packet new-packet-mark=torrent-mark passthrough=yes tcp-flags="" protocol=tcp src-port=51414
log=no log-prefix=""

src portot figyel, udp-n és tcp-n

[ Szerkesztve ]

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

Ez nem erősen erőforrás igényes megoldás így? Ha jól értem, te minden egyes csomagot megnézel és megjelölsz, ha kell. Elvileg az lenne a mikrotik ajánlása, hogy megjelölöd a "connection"-t és utána a csomagokat a connection-mark alapján állítod be. Igaz, hogy több szabályt kell írni, de a futás során kevesebb erőforrást használ.

Arra jó, hogy teszteljen. De valóban a conntrack ajánlott.

Le az elipszilonos jével, éljen a "j" !!!

kipróbáltam
packeteket megjelölve 1-2% közt van a CPU Load
connectiont jelölve 0-1%
feleannyi, de elhanyagolhatónak látom így is a terhelést.

cserébe nem jövök rá, hogy a megjelölt kapcsolatot hogyan tudom a Queue-ban szabályozni? csak packet-markra tudok szabályt létrehozni

plusz nem vagyok benne biztos, hogy a postroutingban van ez a legjobb helyen.
mármint igazából így is működik, érezhetően jobb lett az otthoni elérésem, de ha lehet még fejlődni, az sosem zavar.

[ Szerkesztve ]

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

javasolt irodalom: lartc
mikrotik packet flow: [link]

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

Mivel itt sem kaptam választ a hibámra, tapasztalatom leírom:

RB4011iGS+5HacQ2HnD

5ghz wifi "kifagy", ilyenkor semmi sem látja, disabled/enabled után initializing állapotra vált (manuálisan 5180MHz van beállítva), csak újraindítás tán megy újra x ideig, akár 2-3 nap is, amikor megy nincs hiba.
Felvettem a kapcsolatot a külföldi MikroTik Support-tal:
kérték a rif fájlt, majd netinstall-t. Meg is csináltam mindent, de 2 nap után előjött a hiba, most a válaszukra várok. Szerintem ebből garancia lesz.....

Más nem tapasztalta a hibát?

Köszi

Szia nekem január óta van meg. És tökéletes stabil az egész router.

Ezen jelenségen kívül nekem is. Legrosszabb esetben kicserélik.

Újra megpróbáltam az EOIP összekötést. Felvettem a bridge filterbe a 67-68 portok tiltását az EOIP interfészre. Ennek ellenére előjöttek anomáliák. Az otthoni PC-knek, és a wifi AP-knek fix IP címe van, a többi eszköz DHCP-t használ, ill használok párféle Os-t virtuális gépen. Amikor az EOIP interfészt berakom a bridge-be, onnantól a virtuális gépek nem érik el a hálózatot (IP ütközést vagy más nem definiált hibát érzékelnek).A hiba előjön akkor is ha fix. IP-t adok a virtuális gépnek, és akkor is ha DHCP-t kellene használnia. Ha a mikrotikben kiveszem a bridge-ből az EOIP interfészt akkor megjavul minden. Tehát nekem úgy tűnik, hogy még valamit szűrni kellene, de nem tudom mit. Ötlet esetleg? A két összekötött hálózatban nincsenek egyforma IP-k, az egyik 192.168.x.x, a másik 10.x.x.x címeket használ. A cél elsősorban a távoli médiaszerver kényelmes elérése lett volna, esetleg a további hálózati eszközök tallózhatósága és elérése (de egyik sem fontos feladat, csak olyan jó lenne ha működne...). Jelenleg ha a távoli médiaszervert akarom elérni, akkor egy külön wifi SSID-n elérhetővé teszem, amire mondjuk a tv fel tud csatlakozni, így nincs ütközés a két hálózat között. Amúgy a VPN-en keresztül, IP alapon rendben elérhető a távoli hálózat, tehát csak akkor van anomália ha layer2 kapcsolattal próbálkozom.

[ Szerkesztve ]

Most nézem a 6.44.2.RouterOs changelog-ot. Elég rövid. Jól sejtem, hogy ha nem használok IPv6-ot, akkor nem sok értelme van feltenni (a 6.44.1 helyett)?

[ Szerkesztve ]

gondolom ezt javították

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

Tegnap volt egy régi mikrotik doboz nálam, még valami ezeréves 5.2 volt rajta, netinstall után nem volt kulcs, este 8-kor bedobtam a kérést a supportra, reggel 8-kor már postafiókban volt a válasz az új licence-el...

Én a dhcp problémára a bridge-en dhcp snoop-ot használnék és mindkét oldalon csak azt a portot tenném trusted-re ami egy DHCP-hez tartozik az EoIP adaptert pedig nem. Így elvileg a DHCP-vel nem lesz gond ha mindkét oldalon megcsinálod.

Az MTU-re figyeltél? Ha jól emlékszem 1450 az EoIP tunnel-é.

A többi problémáról jó lenne látni mit mond a LOG.

Sziasztok!
Egy kis segítségre lenne szükségem.
Adott egy mikrotik router board.Visszalehet valahogy azt nézni hogy ha egy mondjuk Tp Link router volt rákötve valamikor,és arról interneteztek telefonon?
A Tp link router már nincs rákötve csak mondjuk egyik nap rácsatlakoztatják aztán interneteznek a Tp linken keresztül aztán amikor nem kell már akkor lehúzzák róla a Tp linket és úgy hagyják ahogy volt azelőtt.

A DHCP-log-ban látod a MAC-et és abból látod mikor csatlakozott fel az eszköz és ki volt a gyártója. Vagy a firewall-t logolod.

Szia!
Onnan nem tűnik el ha leválasztják róla?

A LOG-ból nem. De nem igazán értem, mit szeretnél és miért.

Köszönöm a segítséget.
Igazából a munkahelyen van egy ilyen router aztán így lehetne netezni csak félünk hogy rájönnek,hogy ilyen módszerrel internetezünk.