Příspěvky

76

Hardware / Re:Odporucte 24port switch do racku

« kdy: 14. 11. 2020, 22:49:19 »

Doživotní záruku pokud vím nabízí např. Zyxel, D-Link, HPE a TP-Link. Díval bych se na řady GS1920, DGS-1210, Aruba 1930, T1600G. Hloubku 25 cm splňuje pouze D-Link - buď DGS-1210-24P nebo DGS-1210-28P/MP a TP-Link T1600G-28PS.

77

Sítě / Re:DVB-T2 streamování do lokální domácí sítě

« kdy: 09. 11. 2020, 12:06:34 »

Nechci dělat reklamu, ale ASM dokonce komerčně nabízí řešení streamování televizního vysílání po IP založené na TVHeadEndu (viz http://ftp.asm.cz/ASM/Skoleni/20200123-Workshop-20120-1.pdf od strany 50). Akorát používají (nejspíše kvůli spolehlivosti) tunery ve formě interní karty a ne přes USB. I když USB tunery by tam fungovali nejspíše také.
Byl jsem na jednom školení, kde to řešení popisovali. Jedno z úskalí je na straně přijímačů - najít vhodnou TV, aby to přes HDMI CEC šlo ovládat vše jedním ovladačem je občas boj. Pak jde ještě o dimenzování sítě, každý přehrávač má vlastní unicast stream. Reálné zkušenosti z nasazení neznám.

Osobně koaxiální vedení nezatracuji, ale do budoucna mi také přijde lepší vysílání lokálně šířit formou IPTV. Minimálně v případě více koncových zařízení. Mám několik argumentů pro:
- většinou stejně existují síťové rozvody, které stačí využít, nemusí se tahat koax
- lze šířit i bezdrátovou cestou, např. mezi budovami, či na dlouhé vzdálenosti optikou či jinou technologií
- při změně standardů / zdroje signálu není třeba měnit koncová zařízení, stačí pouze vyměnit technologii ve zdroji streamu
- lze stejným způsobem streamovat i jiné, neTV videa, např. bezpečnostní kamery, reklamní videa, či jiné přenosy. Modulovat to do DVB-T lze samozřejmě také, ale je to finančně náročnější.

78

Sítě / Re:Mikrotik router a Apache server na linuxe - nepřístupný z veřejné IP

« kdy: 02. 11. 2020, 09:38:54 »

Blbne mi editace příspěvku, takže jen krátce. Souhlas s M_D, v pravidlech z mého příspěvku byly ještě chyby, prosím ignorujte.

79

Sítě / Re:Mikrotik router a Apache server na linuxe - nepřístupný z veřejné IP

« kdy: 02. 11. 2020, 09:08:41 »

Odstřelil jsem ty 3 chainy z natu a dal tam jen jednu a to:
/ip firewall nat
add action=accept chain=dstnat comment="Accept Pi-Hole Server Traffic" port=\
    80 protocol=tcp src-address=192.168.88.251
a taky to nafachá. Rád bych dal Compala jen do role modemu, ale má silnou wifi a to v obou pásmech naráz. Kdybych mohl na stejné místo dát AP od mikrotiku co to zvládne taky a bude mít LAN na gbit pak ano, ale mám RB760iGS kvůli jeho hardware.

Ale ne, musí tam být více NAT pravidel:

/ip firewall nat
****přesměrování portů z WAN:
add chain=dstnat dst-address=192.168.1.1 protocol=tcp dst-port=80 \
  action=dst-nat to-address=192.168.88.251

****přesměrování portů z LAN pro dotazy na veřejnou IP:
add chain=dstnat dst-address=verejna_ip protocol=tcp dst-port=80 \
  action=dst-nat to-address=192.168.88.251

****odchozi src nat do internetu:
add chain=srcnat out-interface=ether1 action=masquerade

****hairpin src nat pro dotazy z lokalni site:
add chain=srcnat src-address=192.168.88.0/24 \
  dst-address=192.168.88.251 protocol=tcp dst-port=80 \
  out-interface=bridge action=masquerade

80

Sítě / Re:VLAN podle MAC adresy

« kdy: 01. 11. 2020, 23:23:14 »

Nepíšete co to je za firemní nespravovaný switch. Třeba bude umět client / port isolation a pak by se to možná dalo řešit např. pomocí surveillance / voip vlan na následném DGS-1100.
Spíše bych to ale viděl na tagování už přímo v koncových zařízeních - což zase ne každé zařízení umí.
Nejjednodušší opravdu bude, když tam dáte také spravovaný switch a VLANy nastavíte dle zařízení pro konkrétní porty.

81

Sítě / Re:Mikrotik router a Apache server na linuxe - nepřístupný z veřejné IP

« kdy: 01. 11. 2020, 23:10:08 »

Taktéž bych doporučoval se zbavit dvojitého NATu. Compal by to měl umožňovat, pokud nemáte ovšem od UPC ten jejich dualstack-lite.
Pokud to budete provozovat ve stávajícím stavu, předpokládám, že máte na UPC routeru směrovaný adekvátní porty na Mtik.
Pak si ještě přidejte toto pravidlo:

/ip firewall nat
add chain=dstnat dst-address=verejna_ip protocol=tcp dst-port=80 \
  action=dst-nat to-address=192.168.88.251

82

Sítě / Re:Mikrotik a OpenVPN?

« kdy: 01. 11. 2020, 22:57:56 »

Mám-li Mikrotik jako router, ukončuji VPN zde. Mám-li server s AD, ověřuji pomocí NPS vůči doméně. Na Mikrotiku používám primárně SSTP, případně L2TP s PSK pro Android a Linux klienty. Lze i IKEv2, zatím jsem netestoval. Konfiguruji split tuneling. Mikrotik router pouze s HW akcelerovaným šifrováním. Výhodou řešení je navázání na doménu (pro uživatele jeden login, částečný SSO -> po ověření do VPN pak stejný login windows používá i do SMB) a nativní VPN klienti v klientských OS. VPN profil pro WIndows klienty lze konfigurovat automaticky pomocí GPO. Mikrotik ve spojení s NPS podporuje více VPN profilů, lze ve firewallu rozlišovat různé skupiny a dle toho řídit přístup do sítě z VPN.

83

Sítě / Re:VDSL bez modemu

« kdy: 22. 10. 2020, 11:00:11 »

Ještě k tomu VDSL modemu jako SFP modulu (https://www.versatek.com/product/vx-160kit-vdsl2-sfp-modems-co-rt/ resp. https://www.versatek.com/product/vx-160ce-vdsl2-sfp-modem-remote-telco-grade/).
Bylo pár pokusů o tuhle variantu. Dostupný je ale asi jen jeden SFP modul, který například nepodporuje profil 35b (pro tarif "až 250 Mbps") a nikdo reálně neví, o kolik horší performance oproti "teminátoru" má.

U nás (ČR) se dá sehnat např. toto: https://www.asm.cz/cs/182642-vdsl-modul-xtendlan-xl-mgb-vdsl2-r2 , ale ta kompatibilita nebude zaručena. Nedávno jsme instalovali (resp. chtěli) tento převodník: https://www.asm.cz/cs/195671-konvertor-planet-vc-231 místo smtrboxu a bohužel se nechytl. Přitom stejný převodník jsme úspěšně před půl rokem nasadili u jiného zákazníka a na stránkách u něj inzerují možnou kompatibilitu s O2 (!). Takže neoficiální alternativy jsou vždy trochu krok do neznáma, a co není vyzkoušené Cetinem, či některým operátorem může být problém. Minulý týden jsem např. dostal informaci z O2, že Terminátory zatím nenabízí, protože jejich interní (O2) testování nedopadlo úplně ke spokojenosti. Nicméně jeho volně prodejné alternativě bych asi věřil více než alternativním výrobcům.

84

Sítě / Re:Menší RD - nastavení VLAN k izolování návštěv

« kdy: 10. 09. 2020, 09:36:00 »

Tak myslím, že to Mikrotik dává pěkně.

Myslím, že můžete být v klidu. Neoptimalizovanost konfigurace by se u vás projevila jen v určitých případech, které ve vaší síti nejspíše nenastanou. Jednalo by se např. o intenzivní datovou komunikaci (>500Mbit) mezi fyzickými porty mikrotiku v rámci jedné VLANy. A to ještě za určitých "okolností".

85

Sítě / Re:Menší RD - nastavení VLAN k izolování návštěv

« kdy: 09. 09. 2020, 08:41:31 »

U levnějších modelů nepodporuje zabudovaný switch vlan table, takže to na výkon vyjde na stejno (letí to přes CPU). Nicméně doporučují to konfigurovat na bridgi jakožto dobrou praktiku.

Paradoxně u levnějších modelů switch chip podporuje více funkcionalit jak např. v RB4011 / 1100AHx4 (ale tam už je zase silné CPU). Pokud uživatel nepoužívá vlan filtering na bridge (troufám si tvrdit, že moc uživatelů se smart switchem nebude), pak je provoz skrze bridge offloadován switch chipem. HW offloading je na routerech podporován pouze na jednom bridge.

86

Sítě / Re:Menší RD - nastavení VLAN k izolování návštěv

« kdy: 08. 09. 2020, 22:38:16 »

Návod na VLANy jsem použil tento:
https://vaclavkrejci.cz/Mikrotik-nastaveni-VLAN-a-trunku

V rychlosti jsem mrknul na návod a bohužel musím konstatovat, že konfigurace bridge/vlan je tam hodně zmršená. Ano, je to funkční, ale neoptimalizované a zbytečně to degraduje výkon routeru. Správně má být pouze jeden bridge a na něm teprve pověšené VLANy.

87

Server / Re:DKIM - jak reciver mail server vi, ze maily maji byt podepsane

« kdy: 02. 09. 2020, 16:37:09 »

Dobrý den,
sice jsem to nikde explicitně neviděl napsané, nicméně k tomu by měl sloužit DMARC. DKIM skutečně nevynucuje podepisování na dané doméně. Pořád to je ale na podpoře příjemcova serveru, zda umí ověřovat DKIM a rozumí DMARCu.

88

Sítě / Re:Krimpování Cat6a kabelů

« kdy: 19. 08. 2020, 20:56:26 »

Před 14 dny jsme finišovali SKS také na CAT 6a, AWG 22. Hned, jak jsem ty kabely viděl jsem věděl, že se ani nebudu snažit na to krimpovat konektory. V racku zakončené na stíněném patch panelu, v kancelářích v zásuvkách. Kde by se kabel zapojoval přímo do zařízení (např. AP) jsem volil beznástrojový CAT 6a keystone a krátký patch do zařízení. Je tedy otázka, zda je nutné konektory skutečně konektorovat a raději je nezakončit jiným způsobem (zásuvka / patch panel se svorkovnicí dimenzovanou na AWG 22).

89

Sítě / Re:Optika v novostavbě, na co si dát pozor ?

« kdy: 24. 07. 2020, 08:48:47 »

Jen upozorňuji, že práce s tímto kabelem není úplně snadná, je dost tuhý a má celkem velké poloměry oblouků, pokud ho nechcete "zlomit". Pokud to budete protahovat i delšími husími krky, tak bacha na zatáčky. Taktéž na to nenakrimpujete běžné RJ45 konektory. Zásuvky dělané pro 6A jsou v pohodě. AP řešíme zakončením kabelu pomocí 6A keystone ( např. https://www.pcmega.cz/detail/DATACOM-STP-Keystone-10G-RJ45-CAT6A-samorezny/562837?zoneId=) a pak krátkým CAT6 patch kabelem k AP.

Co se týče výběru switche - záleží, co od něj chcete za funkcionality, ale na ten základ (VLANy apod) stačí v podstatě cokoliv s managementem.

90

Sítě / Re:Pokrytí RD Wifi

« kdy: 15. 07. 2020, 07:35:22 »

Chceš-li Mtik, pak mohu doporučit kombinaci RB3011 + cAP AC řízené CAPsMANem.
- RB3011 je rackmount, 2x5xGbE portů, ARM dualcore, HW akceleraci AES (např. pro VPN), na domácí použití dostačuje
- cAP AC podporuje PoE, má dva GbE porty, HW je ac-wave2 (třeba ho časem OS využije), CPU je taktéž vícejádrový ARM
- řízená wifi pomocí CAPsMANa je jednodušší na provoz a správu více AP, jednotný firmware pro router i AP
- nevýhodou je dělení portů na RB3011 do dvou skupin (switch čipů) - komunikace mezi nimi probíhá přes CPU (i tak to není ale výkonově problém)
- další nevýhoda je potřeba PoE injektorů k AP, RB3011 není PoE, resp. má jen jeden PoE Out port.