Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - M_D

Stran: 1 ... 11 12 [13] 14 15 ... 19
181
Tak záleží o jakou pozici a kam jde. Bude na posouzení doktora a jak se to v daném konkrétním případě projevuje. Principiální překážka to nebude, ale komplikace ano. Důležitým plusem je, pokud je to podchyceno, léčeno a daný spolupracuje/plní léčbu bez nějakých excesů.

182
Sítě / Re:O2 xDSL IPv6 veřejná IP
« kdy: 06. 10. 2020, 09:43:17 »
A nenabízí O2 stále APN internet.open? Pokud člověk se připojuje přes default APN internet, tak měl neveřejnou IPv4 (a stále i teď má) a spojení z inetu nešla, za jednorázový poplatke šlo aktivovat používání APN internet.open, v tom případě nebyl provoz k mobilu blokován (fungovalo i ICMP) a mobil přímo dostal dynamickou veřejku (existovalo i APN internet.open.s, což byla služba se statickou veřejkou, ale tam už byl měsíční paušál).
Kdysi jsme to používali, takže pokud by šlo stále APN internet.open použít podobně i s profilem IPv4v6, tak by to byl způsob (tenkrát za to chtěli cca pětistovku jednorázově), nechtěná data došlá z internetu se samozřejmě plně započítávala. :-)

183
Sítě / Re:O2 xDSL IPv6 veřejná IP
« kdy: 02. 10. 2020, 12:15:53 »
Jak to má O2 nebo TMO řešeno interně nevím, ale vím, že se čas od času na nějaké lince IPčko změnilo, ale je to dost raritní záležitost, takže jestli u cca 70 přípojek se změní u dvou ročně... Takže i když to není garantováno, dá se považovat IPčka za "pevné".
U TMO se i změnil IPv6 příděl i v situaci, kdy koncové zařízení ohlásí jiný DUID. A také hlídá, že když se v síti objeví dvě zařízení se stejným DUID, tak to zapnuté později IPv6 nedostane, jak se první vypne, tak ten příděl dostane to druhé.
Ale je fakt, že jsem to zkoušel naposledy vloni, přeci jen se postupně od TMO prchá jinam. :-)

184
Sítě / Re:Jak propojit bezdrátově dva domy?
« kdy: 02. 10. 2020, 12:09:58 »
Chdák tazatel, to se mu z toho zase udělalo...
Pokud stačí výkon 5 GHz wifiny, na těch 60 m to fungovat bude i v zarušeném prostředí, na horách bych čekal větší rádiový klid, pokud nejde o exponované místo. To 60 GHz je luxus, ale za víc pěnez. Registraci na webu ČTU podléhají venkovní instalace, pokud to dají jednotky umístěné uvnitř za oknem, tak se nic neřeší (a vím, že na 80 m takto z okna do okna to funguje).

Add optika: Cena single mode/multi mode je v podstatě podobná, pokud se bavíme o běžném domácím 1 nebo 10 Gbps. Jak se začne jít na 40 Gbps a více, tak začne být rozdíl cenově fatální. Ale to asi netrápí tazatele s wifinou.

Add to hádání o metalickém propojení: Prvně, psal o horách, takže než dojde na bouřku tak u venkovního převěsu 60 m klidně může skončit první zimu, až přijde pořádná námraza... Add blesk, klidně může nastat situace, že kabel v zemi je na tom hůře než převěs vzduchem. LukePole je asi štastný člověk, ale těch situací, kdy se hledá upálený kabel v zemi je víc než dost. Když blesk zasáhne zemi, tak pokud je v okolí v podzemí kabeláž/trubky, tak dochází k přeskoku (a často na větí vzdálenosti, než ve vzduchu - zem má menší izolační pevnost než vzduch), kdy běžně blesk přeskočí v zemi na rozvody 20 metrů daleko, občas se dá najít situace i 50 metrů, pak se po tom kabelu šíří na obě strany a doběhne až kam doběhne, někdy třeba o několik km vedle zase prozarí z kabelu ven. Situací na téma hledání takto zničených přeražených dalkových metalických tras je dost, zvláště v horách, když pak pomocí OTDR hledáte, kde se to stalo - na jedné straně kopce do kabelu, o kopec vedle z kabelu. Ano, přechodem masivně na optiku těchto problémů silně ubylo u telco rozvodů (ale i tam může nastat nevěřícno - příčinou byl připoležený vyhlédavací metalický kabel, blesk skočil na něj, teplo od přechoďáku ho přetavilo, ale s ním i chráničku a poškodilo to i optický kabel o pár cm pod ním, OK taková šance blesk:bagr je možná 1:10000). Samozřejmě platí, že po elektrickém vedení vám do baráku dorazí mnohem větší výkon, než po telefonu/ethernetu, ten kabel toho moc nesnese, ale i tak to stačí na odpálení dost elektroniky a někdy dost nenápadně - typicky se vlivem přepětí přes telefonní kabel doma oddělá ethernet port v routeru, ale DSL část je OK, najednou jen Ethernet blbne...

Add zemnění Ethernet rozvodu a dopad různých potenciálů: Norma IEEE 802.3 pro Ethernet BaseT/TX říká, že metalický rozvod se může používat jen tam, kde rozdíl zemních potenciíálů koncových míst není větší než 1 Vrms, konce jsou napájeny se stejné distribuční soustavy, nepřekračuje se hranice jednoho vnitřního objetu. Pokud není něco z toho splněno, má se použít optika nebo prvky, kde výrobce jasně dovoluje takové použití.

185
Sítě / Re:O2 xDSL IPv6 veřejná IP
« kdy: 30. 09. 2020, 11:36:17 »
SB: Zaspal jsi dobu, O2 to tak má už roky, že v ceně tarifu je jedna neveřejná IPv4 a jeden /64 blok IPv6 (když nepočítám spojovák na PPPoE straně).
Také radím, kde není další návaznost na služby, tak raději vzít to TMO, kde máš jednu veřejku IPv4 a IPv6/56. Pozor, v té základní ceně u TMO ta IPv4 a IPv6 prefix není také pevný! Ale je fakt, že se prakticky nemění a stejně se to chová i na O2 přípojce.

186
Sítě / Re:O2 xDSL IPv6 veřejná IP
« kdy: 30. 09. 2020, 10:00:19 »
Ano, dnes v ceně DSL domácí přípojky u O2 dostaneš jednu neveřejnou IPv4 adresu (100.64...) a přes DHCPv6-PD ti dají jeden dynamický /64 IPv6 blok k použití na LAN straně.
Zda se přes IPv6 dostaneš do konfigurace modemu bude záležet hlavně na tom, zda to konkrétní modem/router podporuje. :-)

187
Sítě / Re:Jak propojit bezdrátově dva domy?
« kdy: 30. 09. 2020, 09:55:43 »
Pokud to fakt nejde spojit drátem/optickým propojem, tak pokud je to přímá viditelnost a 60 metrů, tak bych použil něco na bod-bod v 802.11ad, čili 60 GHz pásmo a měl to jen jako bridge propoj jen s jedním routerem na hraně k internetu.
Na tu vzdálenost bude fungovat cokoliv, i kdyby to mělo být postaveno na okně. Samozřejme drát bude za tisícovku, optický patcord za dvojku, 60G propoj tak za 4 litry (za oknem), něco v lepším provedneí na venkovní montáž za šestku.
(Např. s MikroTik Wireless Wire to jde jednoduše zkusit a uvidíš, pokud máš viditelnost od okna k oknu).

188
M.Š. možná chtěl říci, že switch daný port na základě odpovědi od Radiusu dynamicky strčí do určité VLANy? Celkem běžně použivané, že segmentuji stroje do sítě dle oddělení atd, takže to udělá na základě 802.1x (a je jedno zda na wifi nebo metalický ethernet) a lidi se stroji můžou volně cestovat v rámci vesmíru.
IMHO bych nemíchal 802.1x a DHCP snooping, každý řeší něco jiného. 802.1x nedovolí připojit neautorizované zařízení (nebo ho hodí do nějaké guest VLANy) a DHCP snooping následně hlídá, aby si dovolené zařízení nezměnilo IP na něco jiného, než mu poslal DHCP server. Obvkyle asi oboje používat současně. :-)
DHCP snooping bývá někdy společný s IP gueardem, který hlídá zase statické IP na portu. Pak bývá i oblíbený DHCP guard, který zase hlídá, že blokuje cizí DHCP servery, ať si někdo nespustí svůj falešný. A v telko segmentu zase funkce DHCP helper ve switchi, která přidává do DHCP požadavku doplňující info odkud žádost jde, takže pak přiděluje DHCP server IPčka koncovému zařízení na základě toho, kde je zařízení připojeno a ne MAC adres (takže když si koncák doma vymění router za jiný, tak dostane stejnou IP, protože je to pořád stejná koncová linka).
Pokud mám tupý switch, co nic z toho neumí, pak nezvývají nějaké ty obezličky typu ARP reply na routeru předtím, třeba Mikrotik to má relativně připraveno na toto, takže se dá celkem na pár kliknutí, ale neuhlídám už, kde mi pak klient po těch switchích obvykle cestuje...

189
Samotné DKIM to neřeší. Dříve to řešil ADSP záznam v DNS, který to říkal:
_adsp._domainkey.example.com. in txt "dkim=all|discardable|unknown"
Nicméně je to historic, asi se to nikdy pořádně neujalo, dneska je existence platného DKIM podpisu jeden z faktorů při vyhodnocování  DMARC. V rámci DMARC jde jen předepsat jak moc přesně musí sedět doména podpisu s From doménou  (adkim=r|s).

190
Sítě / Re:RouterOS nastavení trunk portů
« kdy: 26. 08. 2020, 09:24:49 »
Jinak, jak vidím ještě ten obrázek, tak není uvedne typ, ale pokud je to nějaký ten malý pětiportovoý router, tak v základu je konfigurován tak, že ether1 je zapojen přímo do CPU a ether2-5 je zapojee do switch chipu, protože na ether1 je v základu očekáván WAN port, takže z něj stejně musí vše do CPU, přežvýká a vyplivne další linkou do switch chipu. Takže pokud chci zapojení portů dle obrázku, tak v menu switch switch1 volba switch all ports připojí i ether1 do switche. Tím ale veškerá komunikace mezi CPU a vším ostatním prochází jen jednou interní linkou, takže je lepší se udržet toho, že WAN je na ether1 a se switchem blbnu na ether2-5.
A pak ether2 je evidetně jako access port, takže vlany nežádoucí na něm, tak pak paranoik:
...
/interface bridge port
add bridge=bridge-lan interface=ether1
add bridge=bridge-lan interface=ether2 pvid=1 frame-types=admit-only-untagged-and-priority-tagged
add bridge=bridge-lan interface=ether3
...

191
Sítě / Re:RouterOS nastavení trunk portů
« kdy: 26. 08. 2020, 08:50:51 »
Ano, takto udělané to bude vždy celé řešit CPU a je to metoda snad několik let mrtvá, ale stále funkční.
Udělám jeden bridge a do něj dám ether1 až ether4, pod bridge vlans vyjmenuji všechny VLANy, které se toho bridge týkají, určím na kterém portu je která přípustná, která je/není tagovaná na jednotlivých portech. Pokud daná VLANa má být pak v daném routeru i zpracovávaná na L3 a routováno do/z ní, tak ji přidám i na vlastní bridge a následně pod interface vlan jen pro tuto udělám vlan interface nad tím bridge, na to pak dávám IP, firewall pravidla atd.
Takto konfigurace způsobí, že router vše co jde, tak přenese do HW offloadingu a zbytek bude řešit CPU, to už bude záviset na schopnosti konkrétního modelu.

/interface bridge
add name=bridge-lan pvid=1 frame-types=admit-all
/interface bridge port
add bridge=bridge-lan interface=ether1
add bridge=bridge-lan interface=ether2
add bridge=bridge-lan interface=ether3
add bridge=bridge-lan interface=ether4
/interface bridge vlan
add bridge=bridge-lan untagged=ether1,ether2,ether3,ether4,bridge-lan vlan-ids=1
add bridge=bridge-lan tagged=ether1,ether3,ether4,bridge-lan vlan-ids=2
add bridge=bridge-lan tagged=ether1,ether3,bridge-lan vlan-ids=3
add bridge=bridge-lan tagged=ether3,ether4,bridge-lan vlan-ids=4
add bridge=bridge-lan tagged=ether3,ether4,bridge-lan vlan-ids=5
/interface vlan
add name=vlan2 interface=bridge-lan vlan-id=2
add name=vlan3 interface=bridge-lan vlan-id=3
add name=vlan4 interface=bridge-lan vlan-id=4
add name=vlan5 interface=bridge-lan vlan-id=5
/ip address
add address=192.168.1.1/24 interface=bridge-lan
add address=192.168.2.1/24 interface=vlan2
add address=192.168.3.1/24 interface=vlan3
add address=192.168.4.1/24 interface=vlan4
add address=192.168.5.1/24 interface=vlan5

Pokud některé VLAN má router jen přepouštět mezi porty na L2 úrovni, tak pro ně je /interface vlan ..., /ip ... zbytečné. Až toto bude fungovat, tak se daném bridge zapne filtrování VLAN, aby začal router vynucovat konkrétní vlany na dané porty (/interface bridge set bridge-lan ingress-filtering=yes vlan-filtering=yes). Zde obvykle dojde k propadu výkonu, protože hodně těch swich chipů má podporu pro VLANy, ale neumí v HW filtrování.

192
Nu, jak pomocí Unifi controleru bude ovládat ty APčka od jiného výrobce, co už má?
Stejně tak, kdyby ty APčka měl všechny od Mikrotiku, tak může použít CAPsMAN funkcionalitu a řídit ty AP všechny z toho routeru úplně stejně, jak u UniFi z jeho controleru na pár kliknutí. A ani by nemusel řešit VLANy po cestě, protože komunikace AP-CAPsMAN na tom routeru se tuneluje případně uvnitř UDP komunikace (může i nemusí).
Jinak pokud by ty AP, co má doma, uměla protokol LwAP, tak Mikrotik je uměl také centrálně spravovat, ale musí se do něj hodit balíček CAPsMAN v1, který se už nerozvíjí, aktuální řada CAPsMAN v2 má LwAP vyhozeno a řídí jen další rádia od Mikrotiku.

193
Studium a uplatnění / Re:Přechod na IČO
« kdy: 13. 08. 2020, 14:58:16 »
Teda, chudák původní tazatel. Jste mu to zamotali. K tomu, smlouva o výkonu funkce jednatele ano/ne a co pak řídí vztah jendatele proti spoečnosti:
a) smlouva uzavřená není - platí občanský zákoník, část o příkaznictví od § 2430,
b) smlouva je uzavřená písemně - platí obsah smlouvy s přihlédnutím k požadavklm zákonu o obchodních splečnostech (smlouva pak musí být dle § 59 a dále).
Z obou případů pak plynou různé věci. Pokud z toho něco mám mít a nedělám to dobrovolně zadarmo ve svém volném čase, tak musí být případ B.

194
Studium a uplatnění / Re:Přechod na IČO
« kdy: 09. 08. 2020, 10:16:48 »
Nu, nevím, že by se jako právě založený one man sro dostal k akcím, kde by mělo jít o totální škody.
Takže by nějaká rozumná forma komerčního pojištění mohla stačit na běžné blbosti.
A pokud se k takovým akcím dostanu, tak kolem sebe vidím, že první bod je, že pokud chci věc dělat, tak podepisuji blankosměnku a příslušnou směněční smlouvu na sebe, jako soukromou fyzickou osobu, kdyby náhodou s.r.o. padlo/zmizelo/přestalo komunikovat. A úplně stejně to je, když se hlásí s.r.o. s majetkem XX MKč a XXX zaměstnanci, jen tam je obvykle víc těch společníků, co to podepisují na sebe. Až časem stačí, že to řeší bankovní záruka a patřičná záruční listina (když bez průseru jako velké sro dodávám 15+ let nebo je dodavatel velká a.s.), pokud jde o akce, kde to zákazník řeší.

195
A není to klasický LFN problém? Mám tlustou síť s větší odezvou. Nevím poslední verze, ale dříve SMB ve Woknech dovolilo odeslat max 10 paketů bez potvrzení, takže pokud mám delší odezvu sítě a kapacita sítě může být víc než 10 paketů po cestě, tak nedosáhnu na přenosový strop. Navíc, pokud Windows zjistí, že má linka větší odezvu, tak provádí pak snižování přenosové rychlosti. Něco z toho jde poladit v registrech, viz: https://docs.microsoft.com/en-us/windows-server/administration/performance-tuning/role/file-server/ a např. volba DisableBandwidthThrottling

Stran: 1 ... 11 12 [13] 14 15 ... 19