- Yettel topik
- Netfone
- További kavarás a Pixel 10-ek körül
- Mobil flották
- Akciófigyelő: Jelentősen olcsóbban nyit az Ulefone új mindenese
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Motorola Edge 40 neo - színre és formára
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Samsung Galaxy A52s 5G - jó S-tehetség
- Android szakmai topik
-
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
-
ekkold
Topikgazda
válasz
laracroft
#23992
üzenetére
Tehát, ha jól értem adott egy publikus IP, amin egy mikrtotik router van. A router mögött két szerver, az egyik üzemel, a másik tartalék. A router megnyitja az 5000-es portot, és továbbítja az adatokat az egyik szerver felé. Ha az adott szerver nem működik, akkor a router a másik szerver felé továbbítja az adatokat.
Ez gyakorlatilag megoldható úgy, hogy egy szkript módosítani tudja az ehhez tartozó port forward (destination NAT) szabályt. Azt kell megoldani, hogy a szkript tudomást szerezzen a szerver működéséről. Pl. pingeli a szervert, és ha nem elérhető, akkor átvált a tartalék szerverre. Vagy lehet, hogy ennél ügyesebb módszer is adódhat, amivel ellenőrizheti, hogy a szerver működik-e (pl. lekér a szervertől egy weboldalt, ha sikeres, akkor üzemel a szerver).
A két szerver szerintem dolgozhat független adatbázisba, csak naplózni kell, hogy mikor melyik szerver üzemelt. A lekérdezéseknek pedig tudnia kell mindkét adatbázisból lekérdezni. És/vagy meg kell oldani, hogy a két adatbázis időnként össze legyen fésülve... -
ekkold
Topikgazda
válasz
laracroft
#23989
üzenetére
A TCP csomagok nem fognak tudni egyszerre két helyre eljutni - legalábbis ezt a mikrotikkel nem tudod megoldani szerintem. Tehát máshol/máshogyan kell "belenyúlni" a dolgokba.
- Pl. a távoli berendezések nem módosíthatók úgy, hogy két helyre is elküldjék az adatokat?
- Vagy a protokollnak kellene másképp működnie pl. nem a távoli eszköz küldi az adatot, hanem a szerver kérdezi le. Így akárhány szerver lehet aki adatot gyűjt.
- Esetleg az eszközök küldhetnek broadcast csomagokat, akkor mindkét szerverhez eljuthat.
- Vagy a broadcast csomag csak jelzi, hogy "itt az idő most ébren van az eszköz lehet lekérdezni"... és mindkét szerver lekérdezi az adatokat...
- Esetleg mindkét szerver működhet eszközként is, és egymásnak is elküldik a kapott adatokat.
Esetleg ha egyik sem megy, akkor lehetne egy központi gyűjtő szerver szerűség, ami csak cache-el, és két helyre továbbítja az adatokat: erre viszont egyedi célszoftver kell(het). Persze továbbra sem tudjuk miről is van szó, így csak találgatni lehet.Ha nem feltétel, hogy egyszerre működjenek, akkor a két szerver IP címét pl. fel lehet cserélni, vagy ami még egyszerűbb, domén nevet kell hozzá rendelni, a domén név pedig mindíg az éppen működő szerverre mutat. A mikrotik támogat statikus domén név bejegyzéseket, de akár az ARP táblában is manipulálható a MAC - IP összerendelés...
-
mrots
junior tag
válasz
laracroft
#23971
üzenetére
Szerintem mindez siman megoldhato es nem jelent kihivast - egy kivetellel: az egy csomag ket celba torteno kozvetiteset. En nem tudok olyan mikrotik beallitasrol vagy modszerrol aminek segitsegevel egy csomagbol kettot csinalnal, mivel altalaban a routerek nem tamogatnak olyan metodust, hogy egy csomagbol ketto legyen.
A multicast egy picit kivetel, ott valoban tortenik csomag duplikalas, de nem feltetlenul az a router vegzi aki az egesz halozat elejen van, hanem a multicast forgalom tovabbitasa soran ugyanazt a csomagot kuldik ki tobb helyre (kb mint a switchek, amikor meg hubok voltak) attol fuggoen, hogy hol van feliratkozo az adott multicast csoportra.
Logikus, hogy a mikrotik az egyik helyre kuldi csak ki a csomagot, hiszen megy vegig fentrol lefele a NAT szabalyokon es ami eloszor passzol azt csinalja, utana nem keres tovabb. Ha jol tudom - de lehet rosszul tudom.
Mivel azt irod, hogy a masodik cim az elso tartaleka csupan, ha semmikeppen nem tudod a forgalmat ket helyre kikuldeni es mas iranybol kozelitenek es felvennem a masodlagos gepen (megfelelo ellenorzesek utan) az elso IP cimet es ugy mukodne tovabb. Mint egy IP alias. Nem a kerdesedre a valasz, de mukodne.
Ha mindenkepp kozpontilag akarod megoldani, akkor valoszinuleg egy reverse proxyra van inkabb szukseged.
-
#23977
D-LAN|FuRioN
aktív tag
laracroft
#23973
D-LAN|FuRioN
aktív tag
válasz
laracroft
#23973
üzenetére
Ilyesmit nem így szoktak megoldani. Nem router segítségével. Amit írtál megoldás erre nem jó szerintem. Nem írtad, hogy ezt az 5000-es portot pontosan mire használod, milyen szolgáltatás van mögötte. Mit szeretnél megvalósítani magas rendelkezésreállást terhelés elosztással vagy folyamatos adat replikát? Amit írtál nekem az jön le, hogy a 2. gép csak backup. Szóval ha gép 1 kiesik akkor nem érdekes, hogy megáll az a bizonyos szolgáltatás, a lényeg, hogy legyen replikád róla. Vagy a cél az, hogy ha gép1 kiesik akkor gép2 vegye át a feladatait úgy, hogy szinkronban tűpontos másolata az elsőnek? Mindenre van megoldás, de egyiket sem router szinten szokás megvalósítani. Főleg ha csak abba gondolunk bele, hogy ha UDP-t tükröznél ott nincs hibatűrésed, TCP esetén meg ha csak "hallgatózól" nincs garancia arra, hogy pont az az adat pont olyan formában érkezik oda a gép2-re mint ami a gép1-re, hiszen nincs tcp retransmission. Lehet HA megoldást is csinálni ebben az esetben viszont a gép1-gép2 között szokás egy a routeres hálózattól független fizikai kapcsolatot létesíteni, ez általában nem 1gbit/s-es adatkapcsolat. Ebben az esetben is a pfw gép1-re megy, az adatok tükröződnek a saját kapcsolaton gép2-re, ha ez a kapcsolat kiesik akkor pedig gép2 átveszi gép1 szerepét. Ezek nem két perces megoldások egyébként. AI nem fogja neked megoldani.
Viszont szerintem ezen a vonalon olvasgass: Linux, DRBD, Heartbeat, High Availability Cluster. Itt első körben ami érdekes lesz majd neked a Linux alapon DRBD cluster. -
stopperos
senior tag
válasz
laracroft
#23971
üzenetére
1) Ilyet haproxy-val oldottunk meg máskor. Egy közös IP-n osztoztak, és aktív-passzív állapotban voltak. Amikor az aktív eltűnt, akkor a passzív átvette az IP címet és az lett az aktív.
2) Mikrotik-en is hasonlót kell megcsinálni, csak visszafelé. De ez bonyolult és sok munka (8-10 óra). Az AI nem fogja tudni megoldani. Ez is aktív-passzív megoldás.
TCP miatt nem megy a mirror (ahogy írták is mások). UDP esetén egyszerűbb a helyzet. -
ekkold
Topikgazda
válasz
laracroft
#23973
üzenetére
TCP esetén alacsony szinten mindenképpen megy válasz is, mert nyugtázni kell a csomagokat, nyugta meg csak egy helyről jöhet.
Lehet, hogy létezik valamilyen megoldás, de ezt szerintem semmilyen router nem tudja alapból megoldani, mert ehhez tárolni kell a csomagokat, a saját nevében nyugtáznia kell, majd elküldeni mindkét kliens felé, és mindkettőtől megvárni a nyugtát.
Az UDP azért egyszerűbb mert ott nincs nyugtázás, a küldő elküldi a csomagot, a címzett meg általában megkapja (néha meg nem). Természetesen felette lehet olyan réteg ami megoldja a hibamentes adatátvitelt (pl. csomagismétléssel) UDP esetében eleve lehet olyan egy adatcsomag, hogy nem csak egyetlen címzettnek szól.
-
ekkold
Topikgazda
válasz
laracroft
#23971
üzenetére
Ehhez elvileg boradcast vagy multicast kell, azaz UDP csomagok esetén elvileg megoldható. TCP esetén pont-pontkapcsolat épül fel, ezért szerintem TCP-n nem működne ilyesmi. A cél eszközök mit kezdenek ezekkel a csomagokkal, pl. valamilyen választ fognak küldeni?
Pontosan ilyet még nem kellett csinálnom, így kész megoldásom sincs erre, de ha pontosabban megírnád, hogy mi a célod, akkor talán jobb tippeket lehetne adni. -
#20264
lionhearted
őstag
laracroft
#20261
válasz
laracroft
#20261
üzenetére
Ebben a videóban nincs DHCP-re vonatkozó beállítás, az IP kamerát pedig gondolom nem tudtad statikus IP-re felkonfigurálni. Úgy sejtem ezért nincsen rajta kapcsolat.
Amit én ajánlok, mert jó eséllyel egyetlen hálózatról beszélünk, hogy a wlan1 legyen station pseudobridge módban, az ethernet port és a wlan1 pedig egy közös bridgeben.
Szerencsére erre a beállításra van quickset, CPE a neve. Bridge módot kell választani hozzá. -
bacus
őstag
válasz
laracroft
#10290
üzenetére
Igy kell érteni, ahogy írták.
A lényeg egész röviden. Ha azonos subnetből jön a kérés, akkor az AP tudja hova kell küldeni a csomagot. Amikor kívülről NAT-olva akarod elérni, akkor a bejövő csomagban benne van a forrás IP, a te AP-d a választ a gateway felé fogja elküldeni. Ha ez jól van beállítva (azaz az a mikrotik router), akkor az már tudja a többit, de ha nem, akkor a csomag elveszik.
A forrás IP NATolása azt jelenti, hogy a mikrotik NATolja a bejövő csomagban az IP-t, igy az AP azt hiszi, hogy helyi csomag, amire tud válaszolni.
A legegyszerűbb, ha nem rakod ki az AP felületét a nagyvilágnak, erre alkalmas bármelyik VPN.Azt írod, hogy mögötte kamera lesz. Ennek az eléréséhez, amennyiben az AP nem NAT-ol, azaz CSAK AP üzemmódban van, nem router üzemmódban (és ez most valószínűleg így van, ha letiltott dhcp mellett is van a wifi kliensen net), akkor NEM kell, hogy elérd az AP management felületét, azaz nem feltétel pl az AP helyes GW beállítása, a kliensek ugyanis DHCP.n megkapják a mikrotiktól a beállításokat, pl a gateway címet is. (ami nem az AP lesz)
A rengeteg port forward helyett, ami több eszköz esetén még ütközést is mutat és ilyenkor kell trükközni, hogy az egyik kamera a 8080.on lesz a másik 8081-en, és így tovább, szóval itt is egyszerübb a VPN alkalmazása. Ennek is nyilván megvan a hátránya, pl mobilos alkalmazásnál először fel kell építeni a vpn kapcsolatot, mielőtt látod a kamerák képét. Ennek elkerülésére is van megoldás, a felhős kamerákkal vagy egy belső NVR szerverrel, stb.
-
-
-
-
Szpilu__25
tag
válasz
laracroft
#6892
üzenetére
én így csináltam és megy DIGIvel, belső hálón, dyndnsel.
3 szabályt csináltam, nekem két port kell (8383-as és az 554)emiatt 3.
1 ;;; Hairpin Nat NVR
chain=srcnat action=masquerade src-address=192.168.1.0/24 dst-address=!192.168.1.1 log=no log-prefix=""2 ;;; Hairpin Nat NVR:554
chain=dstnat action=dst-nat to-addresses=192.168.1.19 to-ports=554 protocol=tcp dst-address=192.168.1.1 dst-address-type=local dst-port=554 log=no log-prefix=""3 ;;; Hairpin Nat NVR:8383
chain=dstnat action=dst-nat to-addresses=192.168.1.19 to-ports=8383 protocol=tcp dst-address=192.168.1.1 dst-address-type=local dst-port=8383 log=no log-prefix="" -
ekkold
Topikgazda
válasz
laracroft
#6894
üzenetére
A 192.168.5.0/24 tartományt persze írd át a saját LAN címtartományodra.
A 192.168.5.1 címet pedig vagy a routered LAN címére (ha a NAT olást is beállítod) vagy közvetlenül az elérni kívánt eszköz LAN címére (akkor megy NATolás nélkül is)Az internetet hogyan éred el? PPPOE kapcsolat van, avagy sima dinamikus IP (tehát DHCP kliensként)?
PPPOE kapcsolat esetén lehet TCP csomagméret probléma is az SQL elnemérés probléma oka. -
ekkold
Topikgazda
válasz
laracroft
#6889
üzenetére
2 megoldás van, amelyek külön is hatékonyak, de akár egyszerre is használhatók:
- Kell egy statikus DNS bejegyzés a mikrotikbe, ami a dyndns nevet a belső IP-hez rendeli, így otthon a belső háló IP címén éred el, de ugyanúgy a dyndns név alapján.
/ip dns static
add address=192.168.5.1 name=teneved.dyndns.org- Kell egy NAT szabály ahol forrás és a célcím is a helyi hálózaté: a mikrotik a külső IP címre hivatkozás esetén felismeri, hogy a helyi hálóból is elérhető ugyanaz a cél, valahogy így:
/ip firewall nat
add action=masquerade chain=srcnat dst-address=192.168.0.0/16 src-address=192.168.5.0/24 -
#4474
Core2duo6600
veterán
laracroft
#4472
Core2duo6600
veterán
válasz
laracroft
#4472
üzenetére
Nem tudom, hogy nálatok milyen van, nálunk a cégnél olyan van, hogy beállítom a fix ip címet átjárót dns hálózati maszkot, és utána megy, nem néz se mac adresszt sem semmit.
Tehát úgy kellene beállítani, hogy megadod az ip címet a wan oldali interface nek, legyen mondjuk az egyes port.
figyelve arra, hogy a hálózati maszkot is meg kell adni.
ehhez kalkulátort tudsz leszedni a telóra.
szinte biztos, hogy nem a szokásos /24 van.Utána már csak a szokásos nat, dns , ill alap tűzfalszabály kell, amit a linkelt cikk közül az első tartalmaz.
Viszont szerintem ezen a vonalon olvasgass: Linux, DRBD, Heartbeat, High Availability Cluster. Itt első körben ami érdekes lesz majd neked a Linux alapon DRBD cluster.
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Apple Watch SE2 / 44mm / Midnight / Black Sport / Cellular (99%)
- Iphone 13 Pro Max 128 GB /// 86% Akku // Számlával és Garaniával
- Iphone 12 Pro Max 128 GB /// 88% Akku // Számlával és Garanciával
- Xiaomi Redmi 9A 32GB Kártyafüggetlen 1Év Garanciával
- Apple iPhone 12 Pro Max 128GB Kártyafüggetlen 1Év Garanciával
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy J6 2018 32GB, Kártyafüggetlen, 1 Év Garanciával
- ViewSonic VG700b monitor 17" 1280 1024 DSUB, DVI, beépített hangszórókkal
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 4060 Ti 8GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest