Příspěvky

3331

Sítě / Re:Forward trafficu na jiný server, se zachováním původní cesty

« kdy: 31. 05. 2018, 07:09:42 »

Buď si musíte na tom cílovém serveru pamatovat, že požadavek přišel tunelem, a odpověď odeslat opět do tunelu, nebo si na tom přeposílajícím serveru musíte zapamatovat, odkud paket přišel, změnit jeho zdrojovou adresu na ten přeposílací server (SNAT) a odpověď pak podle zapamatovaných údajů zase přepsat zpátky. Ta druhá varianta je přesně to, co dělá NAT, ale nejsem si jistý, zda je možné nastavit limity linuxového NATu tak, aby držel tabulku spojení po dobu několika hodin. A i pokud by to uměl, nevím, jak se to bude chovat, je to daleko za předpokládaným způsobem použití.

3332

Sítě / Re:Kampaň Turris Mox končí, co může za nezájem?

« kdy: 30. 05. 2018, 15:58:01 »

Vtip je v tom, že skoro celý software a část supportu by museli dělat stejně kvůli Turrisu 1.0.

Vam prijde opravdu vtipne, ze naklady ktere jsou na nejaky projekt se uctuji na jiny projekt? Jak pak urcujete uspech projektu? Ja rozumim, ze Pepa ktery dela support Turris 1 bude delat i support moxu, ale kdyz na moxu bude pracovat 80% pracovniho casu, tak 80% jeho mzdy je na naklady moxu a ne na naklady turris 1 jenom aby mox vysel pozitivne. Ty cisla jsou random, pointu snad pochopite. Uctovani detailnich nakladu na kazdy projekt je zakladem pro schopnost urcit uspech projektu.

Zkuste si přečíst ještě jednou a pořádně, co jsem napsal. Já jsem nepsal nic o účtování nákladů na jeden projekt do nákladů na jiný projekt. Psal jsem o nákladech, které jsou pro všechny Turrisy společné a fixní vzhledem k počtu routerů v oběhu. Takže ty náklady musí být vynaloženy, i kdyby existoval jen Turris 1.0 a Turris Omnia tu situaci nemůže nijak zhoršit. Když je skoro celý software společný pro všechny Turrisy a někdo dělá na tom obecném softwaru, nedělá z 80 % na Moxu, jak mylně píšete, ale dělá třeba z 80 % na všech Turrisech, z 10 % na Turrisu 1.0 a po 5 % na Omnii a Moxu.

3333

Sítě / Re:Kampaň Turris Mox končí, co může za nezájem?

« kdy: 30. 05. 2018, 15:17:55 »

Filipe, vy mate nejaky zdroj informaci, ze doslo k pokryti nakladu? Dle dostupnych cisel prodeje turrisu IMHO nemohli pokryt naklady na R&D, hw, sw a support taky pokud nepracuji za minimalni mzdu. Rekl bych, ze spousta nakladu (treba mzdy supportu) se proste do projektu turris nepocita extra.

Vtip je v tom, že skoro celý software a část supportu by museli dělat stejně kvůli Turrisu 1.0. Takže tyhle náklady pokrývat z peněz za Turris Omnia nemusejí, a když část z nich pokryjou, ušetří jim to náklady za Turris 1.0. Že došlo k pokrytí nákladů na R&D a hw odvozuju z toho, že kampaň na Indiegogo dosáhla požadované částky (dokonce ji osminásobně překročila), přičemž jediné rozumné nastavení limitu kampaně bylo právě takové, aby pokrylo tyto náklady.

3334

Sítě / Re:Kampaň Turris Mox končí, co může za nezájem?

« kdy: 30. 05. 2018, 14:03:25 »

Pro někoho těch několik tisíc lidí celostětově může být úspěch a v množství celosvětově používaných a prodávaných routerů?

Turris Omnia i Turris Mox mířily na segment trhu, který je pro tradiční výrobce nezajímavý, protože je malý. Bylo by od CZ.NICu hloupé, kdyby se pokoušel konkurovat výrobcům routerů a nedávalo by to žádný smysl. Takže nedává smysl porovnávat to s celosvětovými prodeji routerů.

Neúspěch by byl, kdyby se nepodařilo pokrýt náklady. Záleží na vás, jestli opak neúspěchu považujete za úspěch, nebo jestli je neúspěch, pak ne-neúspěch ale ještě ne úspěch (něco jako Klausova nevýhra) a teprve pak úspěch.

3335

Studium a uplatnění / Re:EE x Spring

« kdy: 29. 05. 2018, 22:41:57 »

Spring se obvykle provozuje spolu s Java EE technologiemi. Např. JPA je součástí Java EE, stejně tak servlety,které jsou pod Spring MVC.

Moc si nedovedu představit „naučit se Javu EE“ kvůli pohovorům. Naučit se to neznamená jen si něco přečíst, ale nějakou dobu to používat na nějakém reálném projektu. Určitě je dobré o tom něco vědět, ale jinak je podle mne lepší věnovat čas tomu, abyste měl nějaký svůj kód, který můžete ukázat – ze kterého bude vidět, jak na tom jste. Stejně se nikdy netrefíte přesně do těch technologií, které se v dané firmě používají, protože i stejná technologie se v různých firmách používá různě.

3336

Sítě / Re:Kampaň Turris Mox končí, co může za nezájem?

« kdy: 29. 05. 2018, 22:05:24 »

Jaká dotace ? Žádný z Turris nepostihnul ryzikovou skupinu spotřebitelů dotace na něj nebyly .

Dotace na Turris 1.0 byly – CZ.NIC ho jako svou sondu pronajímal za 1 Kč. Ale chápu, že je to komplikované, když pan Šilhavý píše jen o Turrisu, když ve skutečnosti existují tři různé Turrisy, které mají jiný účel.

Hlavně z argumentů  routerů pro masy brzy v rámci PR vycouvali.

Opravdu CZ.NIC někdy argumentoval routerem pro masy?

3337

Sítě / Re:Kampaň Turris Mox končí, co může za nezájem?

« kdy: 29. 05. 2018, 22:02:20 »

Nesliboval jste, že už nebudete reagovat? To vám to moc dlouho nevydrželo…

Turris, jako součást bezpečnostního projektu, by měl cílit na široké masy, ne na úzké skupiny.

Proč?

Chování i hrozby pro / od úzkých skupin lze vypozorovat levněji, než rozdáváním nebo vecpáváním routerů.

Co je ta „úzká skupina“? Myslíte že třeba všichni majitelé Turrisů jsou u nějakých lokálních ISP a nikdo z nich není u mainstreamu typu UPS nebo ADSL? Navíc mícháte Turris 1.0, což jsou ty sondy, a Turris Omnia a Turris Mox, jejichž účelem na straně CZ.NICu je především zužitkovat zkušenosti s vývojem Turrisu 1.0 a podporu Turrisu 1.0 a zároveň uspokojit poptávku na segmentu trhu, který je nezajímavý pro běžné výrobce.

Jak byste tedy ty sondy dělal levněji?

Když zpětně zjistíme, že i přes subvence je router populární jen u úzké skupiny, pak se dotace minula zamýšleným účinkem.

Ten účinek jste nezamýšlel vy, ale CZ.NIC. A úplně jiný, než zamýšlíte vy. Takže to, že se to minulo vámi zamýšleným účinkem, nikoho netrápí – jedině vás.

3338

Sítě / Re:SSL/TLS/STARTTLS rozdíl

« kdy: 29. 05. 2018, 16:35:57 »

No, klient to obecně ví, a jinak to ani nezkouší...

Schválně jsem napsal co protistrana má podporovat. Protože kontrolu, zda vám útočník z odpovědi serveru nevymazal STARTTLS, těžko provedete tak, že se podíváte, jestli v odpovědi serveru je STARTTLS.

3339

Sítě / Re:SSL/TLS/STARTTLS rozdíl

« kdy: 29. 05. 2018, 15:11:55 »

Na to samozřejmě vývojáři mysleli a pokud se tohle stane, klient v komunikaci nepokračuje.

Tohle platí pro Thunderbird? Protože obecně to samozřejmě neplatí, protože klient obecně neví, zda protistrana má podporovat STARTTLS.

3340

Sítě / Re:Jak funguje DHCP server?

« kdy: 29. 05. 2018, 15:09:43 »

No neviem, či sa chcete za každú cenu robiť múdrym a ako papagáj bez rozmýšľania opakujetie tie isté otázky.

Je fajn, že jste pochopil, že se jinými slovy ptám na totéž. Pokud ale chcete poradit, nezbyde, než abyste na ty otázky odpověděl.

Dohady tu plodíte vy zo zrejmých faktov.

Vy jste žádná zřejmá fakta nenapsal. Že je ignorován záznam, který jste zadal ve webovém rozhraní routeru, není žádné přesné vyjádření v termínech používaných ve správě sítí. Je to lidové vyjádření, které může znamenat minimálně toto:

• Záznam zadaný ve webovém rozhraní se ani neuloží, při návratu do webového rozhraní tam není.
• Záznam se ve webovém rozhraní uloží, ale nijak se nepropaguje DHCP serveru, ten s tímto záznamem nijak nepracuje.
• DHCP server má příslušný záznam v konfiguraci, ale nebere ho v úvahu při zpracování DHCP požadavku.
• DHCP server na požadavek odpoví v souladu s příslušným záznamem, ale odpověď nedorazí ke klientovi.
• Klient se vůbec nedotazuje na IP adresu DHCP serveru.
• Klientovi odpoví jiný DHCP server rychleji.
• Klient neumí zpracovat DHCP odpověď.
• Klient odpověď obdrží a zpracuje, ale nenakonfiguruje podle ní síťové rozhraní.
• Klient síťové rozhraní nakonfiguruje, ale konfigurace je vzápětí vrácena do původního stavu.
• Klient síťové rozhraní nakonfiguruje, ale konfigurace je chybná.

A určitě by se dalo vymyslet ještě spousta dalších možností. Vy nevíte, která z nich to je. Vy totiž ani nevíte, jestli je záznam ignorován – to je jen váš dohad, protože jste něco pozoroval/zjistil, a z toho jste udělal závěr, že je záznam ignorován. Ovšem pokud by byl váš závěr správný, nepotřeboval byste poradit. Pokud potřebujete poradit, budete muset prozradit, co jste doopravdy pozoroval/zjistil, pak vám možná poradíme, na co se ještě podívat, a pak z toho budeme moci udělat závěr, co je špatně a co je potřeba opravit.

Ale je to vaše volba, nejste ani první ani poslední, kdo si přišel pro radu a místo popisu problému popisuje svou představu řešení. Někteří si dali říct, s nápovědou popsali, co se u nich děje a pak bylo obvykle snadné jim poradit. Naopak někteří trvali na svém a žádné použitelné rady se jim nedostalo, i když se rádci snažili.

3341

Sítě / Re:Jak funguje DHCP server?

« kdy: 29. 05. 2018, 14:14:56 »

Pokud opravdu potřebujete poradit, bylo by dobré, kdybyste přestal psát svoje dohady o tom, co se děje, a místo toho přesně napsal, co děláte a co pozorujete.

Áno presne vo webovom rozhraní, tabulka pre pridelenie pevnej adresy.

Ve webovém rozhraní Asus-WRT?

Tento tabulkový záznam je ignorovaný.

Co to znamená? Jak jste na to přišel?

Pokiaľ sa to pokúsim podporiť penou adresou na raspberry (samozrejme rovnakou) nepripojí sa - nemá pripojenie k routru a na net.

Na Raspberry Pi máte Raspbian? Jak tam tu pevnou IP adresu nastavujete? Co znamená „nepřipojí se“? ip link vám vypíše aktivní linku? ip addr vypíše očekávanou IP adresu? ip route vypíše routu na bránu a do internetu? Funguje ping na bránu?

3342

Sítě / Re:Jak funguje DHCP server?

« kdy: 29. 05. 2018, 11:03:50 »

No tu ide o to, že v tabulke adries prepíšem pridelenú adresu inou - tou ktorú ja chcem aby zariadenie malo. Ale táto adresa je ignorovaná. V prípade že zadám pevnú adresu na raspberry jednoducho sa nepripojím.

V jaké tabulce adres to přepíšete? Asi ve webovém rozhraní nějakého routeru, který má název, verzi firmwaru… Co znamená, že adresa je ignorovaná? Jak na RasberryPi zadáváte pevnou adresu? Co znamená, že se nepřipojíte?

3343

Vývoj / Re:Dva stejné regulární výrazy

« kdy: 29. 05. 2018, 10:09:51 »

Pro regulární výrazy neexistuje žádný standard, každá knihovna je má trochu jinak. Platí to i pro ty speciální znaky – hvězdička obvykle znamená žádný výskyt až libovolná počet výskytů, ale některé knihovny pro tento případ vyžadují escapovanou hvězdičku \*, a někde hvězdička tenhle význam nemá a bere se jako normální znak. Což je jediné vysvětlení, které bych měl pro tu konstrukci .*{1,} – že to znamená „libovolný znak následovaný jednou nebo více hvězdičkami“. Ale určitě to nezáleží na Linux vs Cygwin, ale konkrétní knihovny, které se v daném případě používají (a může záležet i na konfiguraci té knihovny).

3344

Sítě / Re:Jak funguje DHCP server?

« kdy: 29. 05. 2018, 10:04:04 »

Myslím, že odpovede sú nedostatočné. Presne tento problém mám s routerom ASUS RT-AC68U.
Typicky pre USB wifi adaptér, pre raspberry pi (jedno aký-zdá sa mi). Môžem reštartovať koľko chcem, či už raspberry alebo router, adresa zostáva tá ktorú dostal adaptér po prvom pripojení.

Restart zařízení ale z pohledu DHCP vůbec nic neznamená, maximálně může jako vedlejší efekt vyvolat nějakou akci DHCP.  Aby bylo možné určit, v čem je problém, musel byste napsat, jaké údaje vrací klient DHCP nebo jak dlouhá je doba výpůjčky IP adresy na zařízení.

Jinak změna přiřazené adresy na DHCP serveru nemusí znamenat, že ji dostane klient přidělenou – záleží na tom, zda je to přiřazení povinné nebo doporučené. Když klient už má přidělenou IP adresu, žádá o prodloužení zápůjčky – a pokud něco serveru v prodloužení nebrání, prodlouží stávající zápůjčku.

3345

Sítě / Re:Rozdíl mezi SSL, TLS a STARTTLS

« kdy: 29. 05. 2018, 07:10:36 »

STARTTLS je nebezpečné v tom, že když může útočník manipulovat se spojením, může obě strany komunikace přesvědčit o tom, že druhá strana žádné STARTTLS nepodporuje. Záleží pak na klientovi, zda vás bude nějak varovat, nebo zda bude pokračovat nešifrovaným spojením. Podstatné je to hlavně u automatického zasílání (když si mezi sebou předávají zprávy různé servery), protože tam není člověk, který by mohl rozhodnout, zda se může použít i nešifrované spojení, a server zpravidla neví, zda protistrana má nebo nemá STARTTLS podporovat – takže obvykle akceptuje i nešifrované spojení a uvedený útok je tedy proveditelný.

V případě SSL/TLS nešifrované spojení nepřipadá v úvahu, útočník ho může rozbít, může zkusit útočit na to, aby se použil starší/slabší protokol, ale nemůže docílit toho, aby spojení bylo úplně nešifrované.

Rozdíl je dále v tom, že že POP3/IMAP/SMTP přes TLS se považuje za jiný protokol a má jiné číslo portu, zatímco to samé s použitím STARTTLS je považováno stále za ty původní protokoly a běží na původních portech, pouze rozšířené o možnost přepnout do šifrovaného spojení.