Příspěvky

16

Hardware / Re:Kamera pro sledování domácího mazlíčka

« kdy: 30. 05. 2023, 13:30:51 »

Jestli tomu rozumím, tak tohle je vlastně chybějící IPv6 v praxi, ne? Nebo budeme mít problém se připojit na kameru co je doma i poté, co se plně zavede?

Nejspíš jo, protože firewall na routeru, bezpečtnostní riziko mít to otevřené z venku a stále spoustu konektivit na spoustě míst, kde nebude IPv6 funkční.

17

Sítě / Re:PODA GPON: vlastní SFP a IPv6/IPv4 adresy

« kdy: 24. 05. 2023, 10:43:19 »

Tych IP adries je tolko, ze kazdy atom na Zemi by mohol mat vlastny subnet a este by zostalo. Preto je nepochopitelne, preco su niektori ISP neochotni davat aspon /56.

Už to není dnes pravidlem a omluvou, zejména u sítí, kde IPv6 implementují z fleku na nových prvcích, ale za volbou pro menší prefixy prostě bylo i technické omezení na agregačních routerech, kde prostě nebylo dostatečné místo pro tolik záznamů v routovací tabulce nebo místo v paměti pro správu DHCPv6-PD serveru, aby bylo možné obsloužit stovky tisíc zákazníků, které ty boxy agregují. Bohužel se "tahle řešení" migrují i na ty nové boxy, protože už tak fungují interní systémy a mají to tak zažitý technici.

18

Sítě / Re:PODA GPON: vlastní SFP a IPv6/IPv4 adresy

« kdy: 11. 05. 2023, 17:13:41 »

Ehm ... kazdej normani ISP ti samozrejme ukonci linku presne tak, jak chces. Tzn v pripade optiky budes mit optickej konec bud v podobe nejaky zasuvky na zdi nebo vanu v racku.

O nejaky vymene technologie nemuze byt vubec rec, protoze to by to taky museli sami cele zaplatit (i v pripade ze zarize je jejich).

Navic je to jejich zakona povinost.

Bavime se kupodivu o presne tomtez, jako kdyby ti ceska televize tvrdila, ze muzes pouzivat pouze prijimac koupeny od nich, a nova by ti zas vnucovala nejaky svuj.

Maloobchodní služba ovšem zpravidla nebývá ukončena jen prostým vláknem, ale ethernetem a konečným předávacím místem bývá to RJ45 na ONT. Existují výjimky, ale čím větší operátor, tím menší šance, že se u maloobchodní služby zákazník setká s pochopením.

Výměna technologie na straně sítě je běžná věc a než se taková věc stane, tak si v labu těch 5-10 modelů, co na síti u klientů mají, otestují a ví, že nebude průser a třeba si taky k těm nejstarším kouskům pošlou technika, co to vymění. A taky to přesně bývá ta chvíle, kdy se ta individuální zařízení projeví, protože najednou je problém, s kterým nikdo nepočítal. GPON sítě jsou mnohem složitější, než je Ethernet, telefonní linky nebo třeba DSL.

S hypotetickým příkladem televize to není o ČT a Nově, ale o ČRA, Skylinku nebo třeba IPTV (SledovaniTV, Kuki, O2 TV, ...). Zrovna v případě toho IPTV není jiná možnost, než použít jejich STB nebo software na PC/konkrétní browsery. To, že by šlo IPTV přehrávat přes VLC (a pak tedy jakýmkoliv chytřejším STB) nikdo oficiálně nepodporuje.

19

Sítě / Re:PODA GPON: vlastní SFP a IPv6/IPv4 adresy

« kdy: 11. 05. 2023, 13:15:26 »

cele tema jsem necetl, ale proc vubec provideri nechteji, aby mel zakaznik svuj (i za predpokladu, ze spravny typ) PON konc. bod? Resil jsem to celkove uz asi 4x a nikdy z toho odvareny nebyli....

Zejména kvůli standardizaci pro techniky, zajištění parametrů služby, aby se vyhli dohadám "naše zařízení funguje, nefunguje vaše zařízení, kupte si nový", aby při výměně technologie na svý straně nemuseli řešit kompatibilitu s milionem a jedním různým zařízením, aby mohli pohodlně instalovat updaty do koncových zařízení... To jsou všechno věci, které už jsou sakra znát, když se počet zákazníků blíží už k vyšším tisícům. Ve výsledku je prostě levnější zákazníkovi strčit vlastní krabičku, s kterou bude umět zbytek celý firmy, než řešit individuální problémy.

20

Server / Re:Dlouhé načtení Nextcloudu

« kdy: 10. 04. 2023, 11:29:41 »

Zatial som to nevyriesil, ale prisiel som na pricinu problemu. Na servery nextcloud mam povoleny UFW s portami pre http, https a ssh. Ak UFW disablujem, tak office dokumenty sa nacitaju okamzite. Ak UFW s portami 80, 443, a 22 enablujem, tak prvy dokument sa nacitava az po 6-8 sekundach a dalsie okamzite. vyzera to na problem s firewallom

Firewall by mal fungovat tak, ze bud to blokuje, alebo neblokuje. Teoreticky to neblokuje, ale nejak to tomu vadi. Nerozumiem tomu.

V tom případě si zapnout logování zahozených paketů a pak z toho zjišťovat kam to zkouší komunikovat. https://linuxhint.com/check-my-ufw-log/

Kód: [Vybrat]

sudo ufw logging on
cat /var/log/ufw.log

21

Server / Re:Dlouhé načtení Nextcloudu

« kdy: 05. 04. 2023, 14:42:58 »

Myslim si, ze na 90% to cron vyriesil (mam to nastavene teraz podla dokumentacie na kazdych 5 minut). Len to este overim, ked budem mimo lokalnu siet (nextcloud).
Dokumenty sa v collabora stale otvaraju pomaly (resp. prvy dokument sa otvara pomaly).

Collaboru neznám, tak nemám tušení, zda je to pomalé otevirání vlastnost nebo chyba. Pokud je to vlastnost, neudělámě s tím skoro nic, jen to třeba z 10 sekund půjde stáhnout na 5. A pokud je to chyba, vidím to na problém s DNS nebo s nedostupností do internetu uvnitř kontejneru. Nextcloud samotný si stahuje informace o aktualizacích sebe a balíčků a Collabora může dělat totéž. Pokud by z kontejneru nešlo jít ven nebo to mělo problém s DNS, mohlo by se to projevovat přesně takhle.

Diagnostikovat by to šlo relativně snadno, z kontejneru zkusit spustit ping na nějaká jména, která se málo používají a ještě nejsou nacachovaná, např. moje oblíbené: yahoo.com, atlas.cz
Když se ten příkaz spustí, musí to začít prakticky okamžitě vypisovat po 1 sekundě řádky s odpověďmi. Jak to mezi řádky trvá déle jak sekundu nebo trvá déle než to začne cokoliv vypisovat, tak je něco zle.

22

Server / Re:Dlouhé načtení Nextcloudu

« kdy: 05. 04. 2023, 09:34:57 »

Možná bych to viděl na nějaký problém s DNS, kdy se to zkouší doptat na reverzní záznam a timeoutuje to. A jako další bych viděl problém v tom, že se automaticky nespouští cron skript a tak si to jako fallback spouští při requestech po nějaké době a trvá to, než se cron odbaví.

Background jobs su nastavene defaultne na ajax, nie na cron (pokial myslis toto).

To je právě špatně. AJAX znamená, že když přijde uživatel, tak si to spolu s jeho požadavkem začne odbavovat úkoly, které to dělá samo v pozadí a nejspíš můžou být operace, které jsou blokující a dokud se nevyřeší, tak uživatel čeká.

Správně má být nastaveno cronem, že se Nextcloud skript spouští třeba každých 5 minut a řeší si to ty background tasky samo, bez vlivu na to, zda uživatel posílá nebo neposílá requesty.

23

Server / Re:Dlouhé načtení Nextcloudu

« kdy: 04. 04. 2023, 21:13:59 »

Možná bych to viděl na nějaký problém s DNS, kdy se to zkouší doptat na reverzní záznam a timeoutuje to. A jako další bych viděl problém v tom, že se automaticky nespouští cron skript a tak si to jako fallback spouští při requestech po nějaké době a trvá to, než se cron odbaví.

24

Sítě / Re:diagram cesty paketu - 2x routing decision

« kdy: 01. 04. 2023, 12:23:07 »

1. routing decision(<forward) určuje jestli skončí v local process ,nebo bude puštěn na nějaké výstupní síťové rozhraní

Může to tak být. To schéma je zjednodušené, dnes se na tom systému můžou provozovat VRF nebo nějaké různé network namespaces a tohle je zhruba místo, kde se o tom rozhoduje, kam se to zařadí.

2. routing, D.C. (>forward) určí  na které konkrétní   (-o)  rozhraní půjde.

Ve FORWARD už se ví kam ten paket půjde, takže prošlo zjištěním, že to není lokální proces i nějakým vyhodnocením skrze routovací tabulky a ip rule.

3. routing decision( vlevo, u~local process) mi zůstává záhadou[/b]

Lokální proces přijme paket a pak na něj chce zaslat odpověď. Routing decision tedy není o ničem jiném než o zjištění, kam se ty pakety mají poslat. Když se zjistí, že pro odpověď žádná cesta neexistuje, tak to ani do netfiltru nevstupuje.

(teď mě napadá, je možné aby linux forwardoval z eth3 na eth3?) I když asi moc legitimní use-case mě nenapadají, a nebo to svědčí o špatně designované síti.

Ano je to možné. V praxi se to třeba používá když chceme přeadresovat na síti rozsah ze staré na novou síť a chceme obě dvě sítě nechat nějaký čas paralelně běžět, abychom si vklidu oběhali počítače nebo vyčkali na vypršení DHCP a mezitím tyto počítače mezi sebou komunikují skrze default gw, kde to router odroutuje ze stejného na stejné rozhraní.

25

Sítě / Re:Jak řešit routing z vnitřní sítě ,aby šel na TUN a ne na WAN

« kdy: 30. 03. 2023, 15:03:24 »

Vantomas: tenhle link jsem neviděl. Vyzkouším --save mark a restore-mark, ale iptables -j MARK vidím poprvé.

Rozdíl mezi MARK a CONNMARK je v tom, co se markuje. Jedno markuje pakety a druhé markuje connection. Iptables bohužel neumí přímo poslat paket do nějaké jiné routovací tabulky, to umí až "ip rule", ale ten zase neumí číst connection mark, protože to je institut co existuje v netfilter světě, ale umí číst packet mark.

Packet mark s paketem zůstává dokud paket protéka systémem, ale jak se zakončí na nějakým Apachi a ten pošle odpověď, tak se vytvoří pakety nové a ty už zase žádný packet mark nemají.

Do toho nám pak vstupuje connection tracking, který umí každý takovýhle paket přiřadit k nějakému spojení, které je uložené v tabulce a v tabulce je možné mít uloženou connection mark a podle toho pak něco dělat. Nově vytvořené pakety se k té connection nějak přiřazují sami, bez potřeby expresivního pravidla, ale CONNMARK se podle všeho obnovuje až na žádost.

Je možné, že v tom popisu jsou nějaké nepřesnosti, jsou to pro mě taková zákoutí o kterých vím, že existují, dokáži si je představit při nějakém debuggingu, ale jestli do toho nejdřív vstupuje jedno a pak druhé nebo je to obráceně, to fakt nevím.

26

Sítě / Re:Jak řešit routing z vnitřní sítě ,aby šel na TUN a ne na WAN

« kdy: 28. 03. 2023, 18:17:00 »

Párkrát jsem tenhle problém řešil, kdy jsem potřeboval vracet pakety do stejného interface odkud přišel požadavek. Přesně z hlavy to nedám, neřešil jsem výkonnost, ani nějaké hlubší problémy, které nejsou na první pohled zřejmé, vždy to byla jen taková dočasná řešení na 14 dní, než se překlopí nějaké VPNky, zprostupní vlany v trunku a tak.

Ve zkratce, v default routovací tabulce se dá default gw na jednu konektivitu, pak se přes ip route vytvoří druhá routovací tabulka, kde je default gw do druhé konektivity, přes iptables se omarkují pakety chodící z jednoho interface a pak jinak z druhého interface, je tam nějaká operace pro přenos marku z connection na packet a pak přes ip rule nasměrovat označené pakety do správných routovacích tabulek.

Teď se mi k tomu podařilo v rychlosti vygooglovat https://serverfault.com/questions/1107846/how-to-route-a-reply-packet-to-the-device-it-coming-from

27

Hardware / Re:True RMS měřák s přepínáním

« kdy: 21. 03. 2023, 15:57:22 »

moc nechápu otázku, co je to ne-true RMS?

Otázku chápu tak, že chce měřák na kterém bude přepínač zapnout/vypnout TrueRMS. Třeba aby mohl demonstrovat rozdíl jak měří měřák bez TrueRMS a jak měřák s TrueRMS bez toho, aniž by musel mít na stejné svorky napíchnutý dva měřáky zároveň. Ty příklady s WIFI a USB jsou jen pro to, abychom si představili na co se vlastně ptá.

Osobně žádný takový neznám, protože to co naměří měřák bez TrueRMS bývá lež a tak kdokoliv kdo má měřák, co to měří správně, tak nemá důvod mu dělat lobotomii.

28

Hardware / Re:Výroba překříženého kabelu RJ12

« kdy: 08. 03. 2023, 21:54:50 »

Tady je fotka toho kabelu, který jsem předtím vygoogloval náhodně, ale teď z návodu vidím, že to je ke stejnému modelu.
https://adhesivenetworks.com/product/server-technology-cw-cx-24vy-l30m-switched-pdus-208v-3-phase-50-outlets-l21-30p/

A z fotky to vidím tak, že je drát překřízený 1:1 - prostě jedna kostička tak a druhá o 180 stupňů naopak.

29

Hardware / Re:Výroba překříženého kabelu RJ12

« kdy: 08. 03. 2023, 09:54:04 »

Zkoušel jsem hledat jestli to schéma kabelu nejde najít a na jednom shopu jsem našel jakýsi obrázek kabelu k PDU a podle toho obrázku byla "čárka" na placatým kabelu u obou konektorů stejně - nešlo tedy o křížený kabel. Jelikož neznám přesný produkt, zkusil bych jít i touhle cestou, podle partnumberu si někde najít fotku kabelu a vydedukovat to z toho. Případně PDU rozebrat a kouknout jestli není popsaný pinout konektoru na DPS.

Avšak stále platí, že nejjednodušší je zeptat se výrobce/prodejce.

30

Hardware / Re:Výroba překříženého kabelu RJ12

« kdy: 07. 03. 2023, 12:59:00 »

Nehodlam neco zkratovat, protoze cune vendor si vymyslel neco proprietarniho a ja se "domnival" jak ty draty mam slepit izolackou

Pokud si něco vymyslel vendor propriertárního, tak pokud tu nebude někdo, kdo ten kabel má nebo to nezná, tak se nedá spoléhat na nějaké obrázky na internetu. Běžně se dělá cross kabel tak, že se jedna kostička nacvakne tak a druhá o 180 stupňů otočená, ale jestli to bude i tento případ, těžko soudit.