Új hozzászólás Aktív témák

• #9227 hzcs senior tag bacus #9224

  Új Válasz 2019-12-05 15:04:46 #9227

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  válasz bacus #9224 üzenetére

  Rendben, ha odakerülök, csinálok

• #9220 hzcs senior tag Alteran-IT #9210

  Új Válasz 2019-12-04 19:07:33 #9220

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  válasz Alteran-IT #9210 üzenetére

  Így van, egy port, publikus ip cím, dhcp-n, és nem fix. Fasttracket nem állítottam be, és úgy sem megy, ha a tűzfalszabály teljesen üres, csak a NAT-nál a masquerade. A fasttracket kipróbálom, köszi a tippet!

• #9219 hzcs senior tag bacus #9209

  Új Válasz 2019-12-04 19:03:36 #9219

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  válasz bacus #9209 üzenetére

  A márkáját fejből nem tudom, egy koax és 1 utp csati van rajta, ez megy a mikrotikbe, mert nem csak a riasztónak kell net, hanem több mindennek. A szolgáltató Vidanet, és dhcp kliensként van beállítva a WAN, ami ip-t kap, az a publikus ip is (ugyanaz, mint amit pl. az ipcim.com mutat).
  A kábelmodemnek csak 1 utp-je van.
  Ha direktben dugom rá, akkor csak annyit, hogy dhcp-n kapja az ip-t, a mikrotik mögött a biztonság kedvéért a dhcp lease-ben is fixálva van, és fixen van megadva a riasztóban is (ha dhcp-n kapja, akkor sem működik, csak egyszer).

• #9207 hzcs senior tag Alteran-IT #9206

  Új Válasz 2019-12-03 19:11:25 #9207

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  válasz Alteran-IT #9206 üzenetére

  Elvileg nem, publikus IP-t ad, be tudok jelentkezni ip cím alapján a routerbe távolról. Vannak ezen keresztül egyéb tűzfalszabályok, amik a VLAN-ok közötti forgalmat szabályozzák, de annak nincs köze hozzá. Kipróbáltam úgy is, hogy a riasztó ip-je legyen a forward lánc első sorában (hogy ki tudjon menni bármilyen porton), de nem oldotta meg. Ma nem tudtam kipróbálni másik routerrel, de ha rájövök mi okozza, megírom. Addig bármilyen tippet szívesen fogadok

• #9201 hzcs senior tag vargalex #9200

  Új Válasz 2019-12-03 11:26:45 #9201

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  válasz vargalex #9200 üzenetére

  És utána a routeren keresztül miért csak dns kérés van, kapcsolódási kísárlet pedig nincs? Ha router nélkül kapcsolódik, akkor van. Ezért nem értem.

• #9199 hzcs senior tag vargalex #9198

  Új Válasz 2019-12-03 10:54:37 #9199

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  válasz vargalex #9198 üzenetére

  Igen, így működik (első). Nincs közvetlen kapcsolat a kliens és a riasztó között akkor sem, ha be lehet jelentkezni rá. A routerben nincs tiltva semmi, mégsem megy, csak 1x. Ha direktben van rákötve a kábelmodemre, akkor jó.

• #9197 hzcs senior tag dmc #9196

  Új Válasz 2019-12-03 09:56:06 #9197

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  válasz dmc #9196 üzenetére

  Megtörtént, de nincs forgalom a befelé nyitott portokon, és ugyanúgy csak 1 alkalommal lehet csatlakozni.

• #9195 hzcs senior tag bacus #9193

  Új Válasz 2019-12-03 08:59:02 #9195

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  válasz bacus #9193 üzenetére

  Köszönöm, hogy próbáltok segíteni. Ami felmerült kérdés, arra próbálok válaszolni:
  - Az establishedből Time wait tudom, hogy az a normális működés, viszont az established nem az én készülékem és a riasztó között van, hanem a riasztó és a cloud között. Vagyis ha zárom a kapcsolatot, akkor a cloud és közöttem záródik, a cloud és a riasztó között nem kellene.
  - Ha letiltom a routeren a portot, attól nem kap a riasztó új IP-t, van közöttük egy 24 portos nem menedzselhető, "buta" switch. A port letiltást nem veszi észre a riasztó.
  - UPNP alapból nem aktív, de kipróbáltam azzal is, nem nyit portot. A riasztó leírásában az van, hogy engedélyezni kell a 443, 25000, 25010 TCP portot kifelé, de minden port engedélyezve van. Cloud felé kommunikál, vagyis csak 1 (a 3 IP közül valamelyik) aktív kapcsolat van. Persze csak az első be és kilépésig. Ha belépek a riasztóba netről, akkor is csak az az egy kapcsolat van, ami előtte volt.
  - Port forward nem kell.
  - Ha segítség, akkor van 2 packet capture fájlom, az egyik az, amikor rossz jelszóval próbálok többször belépni, és a kapcsolat mindig aktív marad, a másik pedig tartalmazza a belépést-kilépést, és utána azt, hogy nem kommunikál többé.

  Snorbi: Jelenlegi felállás szerint a router és a 8.8.8.8 van beállítva dns-nek a riasztóban, a routerben a 8.8.8.8, 8.8.4.4, valamint a 2 kapott szolgáltatói. Ha a riasztóban csak a 8.8.8.8 van beállítva, akkor is ugyanúgy működik (egy kapcsolat erejéig).

  Ma kipróbálom úgy, hogy teszek be egy alap tplinket a mikrotik helyére, utána egy switchet port mirroringgel, hogy lássam, hol akadhat el a folyamat. De ha van ötletetek, akkor azt távolról ki tudom próbálni napközben.
  Köszönöm!

• #9192 hzcs senior tag

  Új Válasz 2019-12-02 22:03:56 #9192

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  Sziasztok!

  Számomra igen nagy problémával írok nektek, végső elkeseredésemben, mert már napok óta keresem rá a megoldást.

  Vagy egy Pyronix PCX46APP riasztóközpont, amit felhőn keresztül lehetne bizergálni. Ugyanazon a bridgen van, mint minden más, internet nincs szűrve, minden mehet kifelé, se qos, se portforward, se semmi. Mindenhol van net, tökéletesen működik, kivéve persze a riasztón.

  A probléma: a riasztóközpontnak kommunikálnia kell a felhővel, amit a panel.pyronixcloud.com címen ér el. Ezt ha megnézem a dns cacheben, azt látom, hogy ez egy CNAME, ami mutat egy hosszú.amazonaws.com címre, ami A rekord, és 3 ip cím szerepel. Ezek közül az egyikre felcsatlakozik, és ha a Firewall-Connectionsnél nézem, akkor látom, hogy a központ hozzácsatlakozik, és az állapota established, 24 óra limittel. Ha csatlakozni akarok a telefonon a felhős appon keresztül, de rossz jelszóval, akkor is marad established, és újraindul a 24 órás limit. Viszont ha jó jelszóval lépek be, és utána kilépek, akkor az established megváltozik time_wait-re, és 10 másodperc után a kapcsolat eltűnik, és nem is éled fel. Természetesen ekkor már hozzá sem tudok csatlakozni a router újraindításáig, utána 1x ismét megy, de csak 1x. Forgalom ezután csak a központ és a router között halad, hogy lekéri a panel.pyronixcloud.com ip címét, de ennyi és semmi más.
  Ha pár percig letiltom a routeren a portot, majd engedélyezem, akkor általában ismét megy.

  Ha direktben kötöm a netre a riasztót, akkor megy. A telepítő állítása szerint raktak már ilyet mikrotikre, ott működik, de az ember nem árulja el a megoldást (nem a riasztós, hanem aki a routert állította).

  Mi a fene lehet a probléma, amit nem vettem észre?

  Köszönöm!

• #3286 hzcs senior tag

  Új Válasz 2017-03-03 17:53:05 #3286

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  hzcs

  senior tag

  Sziasztok!

  Lenne egy nagy problémám, és nem találok rá megoldást.
  Capsmannel van megoldva a wifis hálózat a cégnél, és egy dologra nem jövök rá. Jelenleg 3 ssid van, 1 rejtett és 2 látható. A rejtetten és az egyik láthatón a hitelesítés EAP passthrough-val megy, vagyis a kliens ha csatlakozni akar, beírja a felhasználónevét és jelszavát, és az AD szerver hitelesíti. Ez megvan. A harmadik a vendég hálózat, ott sima wpa2 psk jelszó van.
  A gondom a következő: a telefonok (amik a látható SSID-t EAP-pal) használják, sokszor eldobják a kapcsolatot, főleg ha séta van pl a folyosón. Nem roamingol. A laptopok (rejtett SSID) roamingolnak, de egy pillanatra megszakad ott is a net, de visszalépnek (1-2 ping marad csak ki). A vendég telefonok a harmadik vendégwifis hálózaton rendesen roamingolnak. Vagyis a hiba az a radius szerver hitelesítési mechanizmusában (esetleg idejében) keresendő, de nem jövök rá, hogy hol kell a hibát keressem. Az EAP-os mobiloknál az is probléma, hogy nem mindig a legerősebbre csatlakoznak, pl ott van a teló és az AP a helyiségben, de a 2 helyiséggel arrébb lévő, jóval gyengébb erősségűre csatlakozik. Amikor sétálok a telefonnal és laptoppal, akkor látom a connect listnél, hogy amikor roamingolni próbál, fellép egyszerre 2-3 ap-ra is, de dőlt betűs, vagyis nincs kapcsolat. Az AD szerver logjában természetesen az van, hogy grant full access, vagyis ad neki teljes jogot a hálózathasználatra.

  Az OS a legújabb 6.38.3, de a 6.38.1-gyel is csinálta (akkor csináltam a rendszert).
  Kérdésem még, mert többféle variációt olvastam, hogy a roamingnál azonos csatornán kell-e lenniük az eszközöknek, vagy nem? Eddig eltolva 1-6-11-1-6-11... volt, de átrakva azonosra sem javult a helyzet.

  Találkozott már valaki ilyennel, vagy használ AD-s EAP-os hitelesítést?

  Köszi!

Új hozzászólás Aktív témák