Hálózatok egyéb

Céges hálózat 3 db telephelyel

Sziasztok!

Van egy megoldandó problémám, amivel még nem találkoztam és ebben kérdném ki a véleményeteket.

Jelenleg OneDriveot használunk, hogy mindenki elérje az adatokat amik 90% ban Office Dokumentumok, és scannelt dokumentumok. Az első telephephelyen 6 db számítógép van, a második és harmadik telephelyen 3,3 db gép van jelenleg. Szeretnénk, hogy minden dokumentum elérhető legyen a telephelyek között is, de egyik helyen se stabil az internet és szeretnénk ha esetleg megszakad az internet elérhetőség akkor is tudjanak tovább dolgozni. 

Szükség van arra is, hogy azok az alkalmazottak is elérjék az adatokat, akik kint vannak terepen, ez telephelyenként 3 eszköz maximum 1 időben. 

Tárhely igény nem egetverő jelenleg van a fő telephelyen 100 GB adatunk a másik két telephelyen összesen 120 Gb.

A következő megvalósításra gondoltam:

Minden telephelyre 1 db Synology DS2020+ NAS-t vagy Dell Mini szerver T40t vásárolnánk 2db 2TB Ironwolf (ST2000VN004) merevlemezzel. Ezen kívül egy db Google Workspace vagy One Drive fiókot használnánk, ahova minden telephelyről a nasok feltöltenék az adatokat. így azok is elérnék az adatokat, akik nem tartózkodnak a telephelyen. 

A Dell T40 et ZFS Mirroral használnánk, a NAS-t pedig RAID1 el.

Amiben nem vagyok biztos, hogy működne-e megfelelően a Google Drive/ One Drive 1 fiókkal több eszközről egyidőben.

A másik amire gondoltunk hogy a Google Workspace/ OneDrive helyett egy egy 300 GB tárhelyel rendelkező VPS-t bérelnénk, és azon futtatnánk privát felhőszolgáltatást, de ez jóval költségesebb lenne.

Válaszaitokat előre is köszönöm!

Kié az optikai vezeték?

Egy (számomra) érdekes kérdésem lenne. Van a panelben egy meglévő, de nem használt FTTH optika a telekomtól. Ez benn van a lakásban (ezért ftth). Namármost, ha a digi szeretne ftth-t telepíteni a meglévő FTTB helyére, használhatja-e a telekom vezetékét? Vagy az a telekom tulajdona? Vagy behúzza párhuzamosan a lakásig a saját optikáját és azon belül mondjuk egy patch-csel rácsatlakozik a lakáson belüli telekom optikához? Ami a lakáson belül van az már az enyém, vagy az is a telekomé?

WiFi kültéri kamera

Sziasztok!

Kamerarendszert szeretnék telepíteni a ház körül.

Beltérben van mozgásérzékelős riasztó, biztonsági céghez bekötve, kivonuló-szolgálattal.
Kutya van, de betörőt max halálba tudja nyalogatni. 

A ház kétszintes, éjszakára a földszintet riasztom.

A célom az, hogy észlelni tudjam ha éjszaka valaki az udvaron ólálkodik (előfordult mostanában) és létszámtól függően a megfelelő fegyvernemet felvonultatni :D

Gondolom arcfelismerés meg ilyenek feleslegesek, ugyis maszkban jön.

Tápellátás biztosított, a falon lévő külső kötődobozokból. PoE-t sajnos nem tudok behúzni, nagyon macerás lenne.
6-8 kamerával tudnám lefedni, erre méretezett NVR-t is szeretnék.

Van létjogosultsága a WiFi-s kamerarendszernek?

Gondolom ha látszik az antenna akkor egy 50 dolláros wifi jammerrel ezek gond nélkül kiüthetők, meg ha nem dóm kamera akkor egy hosszú kampóval le tudja tépni bárki.

saját domain + lakossági net + rendesen működő email küldés

Adott egy lakossági internet, változó publikus IPv4 címmel, saját domainnel, NoIP-vel. A DNS-ben CNAME-ek vannak megadva, ilyesmik:

  • CNAME mail.domainem.hu --> envagyok.no-ip.org
  • CNAME ftp.domainem.hu --> envagyok.no-ip.org

Mivel dinamikus az IP-cím, ezért nem tudok felvenni állandó A-rekordot:

  • A domainen.hu --> 1.2.3.4

Csak ilyesmiket:

Emiatt a www.domainem.hu alól működik a weboldalam, a domainem.hu alól viszont nem. Igen, kéne fix IP cím, de a szolgáltatómmal ez nem oldható meg lakossági internet mellé.

Van MX rekord is, jól működik a fogadás (MX envagyok.no-ip.org). Küldésre a szolgáltató smarthostját használom. Változóan a gmailes címzettek hol megkapják a leveleimet, hol Spambe kerülnek; az utóbbi időben viszont egyáltalán nem kapják meg, már a freemail is kiszűr, meguntam. Eddig az volt a gmailnél, hogy akivel sokat leveleztem, meg aki írt a "gyanús" címemre már többször, az szépen megkapta a leveleket, a többieknem Spambe került, de most már Spambe sem teszi (volt egy ADSL --> optikai váltás, de a szolgáltató maradt, dinamikus publikus IPv4 cím maradt).

Szeretném, ha tudnék a saját domainem alól sikeresen küldeni a szolgáltató smarthostjával. Ha jól sejtem, a gmail és a többiek a küldő gép IP-jét vizsgálják, ez a smarthost miatt a szolgáltató gépének fix IP-je, az nem gondolnám, hogy spam listán van (még ha az én aktuális IP-m azon is). Valószínűleg az lesz a baj, hogy nincsenek egyéb dolgok (DKIM? DMARC?) bekonfigurálva a domainhez a DNS leíróban, illetve hogy nincs egy rendes A rekord. Hiába megy ki egy levél a kuldo@domain.hu címről, ha a fentiek miatt eleve a domainem.hu nem is érhető el (csak pl. a www.domainem.hu), joggal gyanakodhat a fogadó oldal. Ezek beállításához pedig sejtésem szerint fix IP kéne.

Azt találtam ki, hogy egy nagyon olcsó VPS szolgáltatást igénybe véve fix IP-hez juthatnék, az IP-cím mehetne az A rekordba, és a VPS-en futó gép szolgálná ki a HTTP kéréseket, nem az itthoni szerver. Levelezéskor a címzett gépe fel tudná oldalni a domainem.hu címet, ennyivel is jobbak lennének az esélyeim, illetve akkor be tudnék állítani DKIM? DMARC? stb rekordokat is. Talán még az MX rekordot is megtarthatnám envagyok.no-ip.org-ra állítva. Mondjuk arra nem megoldás, ha a címzett gépe végigköveti az MX rekordomat, és az egy tiltólistás IP-re mutat... már ha ez érdekli a fogadót.

1) ez így működhet megbízhatóan? Az ismerőseim 90%-a gmailes, tudnom kell nekik sikeresen küldeni és ők nem nagyon nézegetik a spam mappát;

1.1) fontos kitétel, hogy saját szerverrel akarok küldeni, a leveleimet én akarom tárolni (mondjuk ez már régóta megvan);

2) olcsó VPS kéne, minimális biztosított erőforrással, kit ajánlotok? Axfone? MikroVPS? mhosting? Ha nem írtam fentebb nagy hülyeségeket, akkor email szempontjából a VPS-ből csak a fix IP kell, más nem nagyon;

3) szívesen veszem az építő jellegű tanácsokat, illetve a tárgyi tévedéseim javítását ;)

kösz, üdv,

[MEGOLDVA]Digi akadozik most?

Sziasztok!

Úgy érzékelem, mintha a DNS-szerverükkel lett volna gond, aztán az upload konvergál a zérushoz.
Helyfüggetlenül kérdezem. Azért, hogy tovább keressek egy hibát, vagy központi baj lehet?

Előre is köszönöm a válaszokat.

Szerk.: Bocs', én csináltam egy jó kis ütközést lokálisan. Nem a Digi hibája volt.

Magyar Telekom forgalmat priorizál?

Néhány hete azt tapasztalom, hogy általam karbantartott gépekre a http://koji.fedoraproject.org/koji címről Magyar Telekom szolgáltatón lógó gépre legfeljebb néhány 10 kB/s sebességgel tudok csomagot letölteni. Ugyanezeken a gépeken általában gyors az internet elérés. Viszont erről az URL-ről a gépemre gyors a kiszolgálás, de én nem is vagyok MT ügyfél.

Ami eszembe jutott:

1) A scriptemet régen írtam, az URL http és nem https kezdetű. Lehet, hogy titkosítva menne ez gyorsan, tehát lehet, hogy a 80-as portot az MT beszűkíti, a 443-ason mehet az adat gyorsan? (Közben kipróbáltam a https-t, nem segített.)

2) A koji.fedoraproject.org domain mögött több gép van, s a panaszolt gépek távoli, szűk sávszélességű mirrorokhoz csatlakoznak. Ennek ellentmond, hogy a nyár végén cserélték a Fedora infrastruktúráját, új szerverek kerültek beüzemelésre, gyorsabbak a kiszolgálók. Aztán miért mindig csak Magyar Telekom esetén?

3) MT irányból sok fertőzött gép DDoS-olni próbál mindent, ami él és mozog, így esetleg a Fedora kiszolgálója limitálja a sebességet, ha MT felől jön a kérés.

4) A Magyar Telekom valami más szempont alapján diszkriminálja a forgalmat, s kínosan kis sávszélességet ad neki.

Számlatartozás, effélék nincsenek egyik ügyfélnél sem, elletve más helyről gyors a letöltés.

Az általam tippeltek közül melyik lehet, vagy, ha egyik sem, mi a megoldás?

DNS Hungary kamu vagy igaz?

Tegnap egyik cimborám az alábbi emailt kapta:

Feladó: János | DNS Hungary <janos@dnshungary.com>
Date: 2020. nov. 30., H, 10:16
Subject: Az Ön domain neve
To: ...

Tisztelt Uram/Asszonyom!

Tájékoztatni szeretnénk Önt arról, hogy regisztrációs kérelmet kaptunk a xxxxxx domain névre vonatkozóan. Rendszerünkben azt látjuk, hogy Ön a xxxxxx domain név tulajdonosa. Lehetőséget kínálunk Önnek arra, hogy regisztrálja a xxxxxx domain nevet magának.

Ha egy harmadik fél regisztrálja a domain nevet, ennek messzemenő következményei lehetnek. Ez magában foglalhatja a keresőmotorok összezavarodását vagy az Ön hírnevének károsodását.

Mindenesetre elutasíthatjuk a harmadik felet, és átirányíthatjuk a xxxxxx domain nevet a jelenlegi xxxxxx domain névre.

Alapvetően a domain név első választási lehetőségét Ön kapja meg. Ezzel elkerülhetőek a jövőbeni lehetséges problémák.

Tíz évre regisztrálhatjuk Önnek a domain nevet. Domain nevét nem csak regisztráljuk erre az időszakra, hanem védjük is. Az ár évi 9,999 Ft. Az egyszeri teljes ár 99,999 Ft (ÁFA nélkül). Sajnos az éves fizetés nem lehetséges.

Szeretné regisztrálni a domain nevet saját szervezete számára? Kérjük, válaszoljon erre az e-mailre nevével, címével és adóazonosítója megadásával az e-mail kézhezvételét követő 48 órán belül.

Ha rendelkezünk az Ön engedélyével, elutasítjuk a harmadik felet, és regisztráljuk az Ön számára a domain nevet.

Tisztelettel,

János Szabó
DNS Hungary

www.dnshungary.com

 

A fenntartásaim a következők:

Tegnap még nem jött be a honlapjuk.

Kicsit túlárazottnak értem a comos domaint.

A tíz éves konstrukció nekem gyanús.

Ha itt valami nem kóser mit lehet tenni, hogy megkapjuk a a xxxxxx-ot, ami jelenleg nem szabad, de lehet csak be van foglalva.

BGP route server container

Egyik ügyfélnek telebeszélte a fejét $vendor, hogy ami manapság nem konténer az idejétmúlt (lol), ezért szeretnék ha letesztelnénk a route server megoldásaikat konténerekkel. Jelenleg három környezet van BIRD és FRR virtuális gépekkel: (1) tradicionális peering fabric, ahol mindenki peerel a route serverekkel is és egymással is, (2)egy virtuális hosting környezet ahol a tenantok közötti routing megy BGP-vel, de itt csak a route server-el peerel mindenki egymással nem, (3) és végül egy black hole alapú tűzfal megoldás ahol a route serverek az AS minden tagját tudják arra rávenni BGP-vel és URPF-el, hogy bizonyos prefixeket tiltson ha kell. Fontos kiemelni hogy ezek mindenhol "csak" control-plane funkciók, azaz a data path-ban nincsennek benne, hanem a full-mesh leküzdésére szolgálnak, továbbá különböző BGP attribútumokkal útvonal manipulációra vannak használva, azaz sávszél és load igénye alig van, de ha pl. a második környezetben mind a 4 letérdel, akkor minden megáll, tehát a HA fontos lenne.

Én kicsit vonakodom ettől, mert nem nagyon találok kész koncepciót ilyesmire (mert lehet gányolás), viszont lehetne spórolni rengeteg VM erőforrást, hozná a konténer világ minden előnyét (és hátrányát), és mindig van kedvem munkaidőben új dolgot tanulni amiért még fizetnek is :)

  1. Figyelembe véve az igényeket kell nekem a container orchestration vagy elég a sima Docker, esetleg compose?
  2. Ha kell a container orchestration, melyik lehet jobb ilyen célra? Nem világos még, hogy az instance-ok (BIRD vagy FRR konténerek) 179-es portját hogyan tudom betámadni kivülről, mert ha jól látom ezek a rendszerek valami DNS alapú load balancing-al dolgoznak...
  3. Amikor erre keresgélek, mindenhol felbukkan a Calico ami egy nativ BGP routing megoldásnak látszik konténer környezetekben, de ha jól értem ez inkább a sok konténer hálózatait hivatott hirdetni a fizikai hálózat felé?
  4. Nyilván nincs tapasztalatunk container orchestration üzemeltetéssel és az első teszt is inkább funkcionális lenne. A next-next-finish alternativák pl. minikube, micro8s vagy K3s mehetnek production-be, vagy ezek csak tesztelésre jók?
  5. Egyéb javaslat amire érdemes figyelnem?

Köszönöm.