Příspěvky

226

Studium a uplatnění / Re:Zkušenosti se společností OKsystem

« kdy: 11. 09. 2018, 20:39:20 »

Nepracuji tam, ale jsou znami tim, ze dost se zameruji na statni sektor (napr. - OKAdresy jsou jen pristupnejsi data z rejstriku adres RUIAN), take maji dost zakazek na ruznych ministerstvech alespon dle rejstriku smluv Ale atmosfera / plat atd nemuzu nijak posoudit...

Ano, taky proto je o nich obcas slyset ve zpravach v souvislosti s korupci a podobne. Takze pro juniora javistu asi v pohode, ale nehnal bych se do managementu. Tam muzou zacit hrozit teplaky :-)

Tak pozor, v souvislosti s korupcí se o OKsystemu mluví tak, že dostal žádost o úplatek, kterou odmítnul a celou věc nahlásil, takže do tepláků šel onen náměstek.

227

Studium a uplatnění / Re:Zkušenosti se společností OKsystem

« kdy: 10. 09. 2018, 12:38:58 »

Hola, právě končím školu a narazil jsem na nabídku junior Java vývojáře ve formě oksystem - klasika Java, Spring a Hibernate.
Nemáte někdo zkušenosti s touto firmou, plat, kultura, benefity a tak?
Díky.

Pokud ti nevadí povinné používání Windows a Outlooku, tvrdé hlídání doby přítomnosti na pracovišti a přestávek (OKbase), nemožnost práce z domova a Wi-Fi síť pro soukromá zařízení s captive portálem, pak to bude v pohodě. Jako startovací bod po škole rozhodně doporučuju, člověk si pak dokáže vážit víc společností, které nabízejí větší volnost. Ale možná se za posledních 7 let něco změnilo.

Kanceláře - open space jsou pěkné, obvykle klidné. Lidi jsou většinou v pohodě, ale to záleží případ od případu.

228

Sítě / Re:Ako pristupovat k stroju skrz openvpn

« kdy: 27. 08. 2018, 12:24:38 »

Predpokladam, ze asi je potrebne v OpenWRT spravit routu z 10.8.0.140 do siete 192.168.90.0/24, alebo sa mylim ?

Nejspíš ano. Nejlepší bude, když někde pustíš ping a pak půjdeš s tcpdumpem po jednotlivých uzlech a budeš zkoumat, zda echo requesty postupují až tam, kam mají a pokud ano, zda se stejnou cestou vracejí odpovědi. Tímto snadno identifikuješ to místo, kde dochází k problému, který bude nejspíš skutečně v tom, že někde něco uniká přes výchozí bránu do internetu.

229

Sítě / Re:Přidělování IPv6 adres

« kdy: 20. 08. 2018, 20:20:34 »

On je Starnet dost široký pojem (zahrnující pár desítek koupených/ovládaných sítí). V některých lokalitách dávají jako default příděl /63, takže si můžeš udělat dva /64 segmenty. Větší příděl pak byl za poplatek.

nie je obchodovanie s ipv6 segmentami zakazane? a nie je to na odobranie existujucich pridelenych pre toho ISP? staci jeden "vyhrazny" mail a predavanie by malo prestat

Obchodování s adresami zakázané není, ale oni adresy neprodávají, protože jim ani nepatří. Oni je propůjčují. Zda bude propůjčení bezplatné nebo za úplatu, nebo v balíčku s jinou službou, pravidla RIPE nijak neupravují.

https://www.ripe.net/publications/docs/ripe-707

230

Sítě / Re:Pridelovanie IP adries

« kdy: 20. 08. 2018, 12:20:45 »

Zákazník: Takže doporučovaných /56 není problém?
Starnet: není to problém. Bude třeba ruční konfigurace a vyčlenění rozsahu.

Zdá se, že v té firmě mají rádi administrativu a ruční zásahy. Místo aby dávali každému /56 nebo rovnou /48 klidně i s vědomím, že 99 procent zákazníků z toho použije jedinou podsíť /64, budou raději vymýšlet systém výjimek a řešení individuálních požadavků zákazníka. A zákazníci si pak místo toho pořizují IPv6-in-IPv4 tunely, protože je to pro ně jednodušší. 

231

Distribuce / Re:Gentoo: ma jeste smysl pro nekoho?

« kdy: 06. 08. 2018, 10:31:09 »

Používám Gentoo proto, že tam je snad největší množství dostupných balíků v aktuálních verzích, díky nainstalovaným hlavičkovým souborům lze snadno zkompilovat i software, který v balíčcích není a stejně snadno lze vytvořit i vlastní balíčky.

Nechci používat zastaralý software jako v Debianu, nechci trávit hodiny nad specfiles jako ve Fedoře. Gentoo je v tomhle případě nejmenší nepohodlí. Je dost dobře možné, že Arch je na tom stejně dobře, ještě jsem ho nezkoušel, protože mi Gentoo vyhovuje

232

O serveru Root.cz / Re:Psat blog na Rootu nebo jiné blogové platformě?

« kdy: 08. 07. 2018, 10:12:16 »

když něco zveřejním na Blogu, tak ten samý text potom nesmím zveřejnit na svém webu nebo na GitHubu? [...] nebo je vlastníkem autorských práv Root.cz a tudíž bych článek už nikdy nikde nesměl zveřejnit?

Toto ustanovení je nezákonné. Autorská práva náleží výhradně autorovi a pokud nedostal honorář, nikdo mu nemůže zakázat zveřejnit své dílo někde jinde. Jinak záleží na smlouvě, kterou ovšem nemůže nahradit něco, co si provozovatel portálu dá někam na web, to není pro nikoho závazné.

A který zákon konkrétně takovou věc zakazuje? Nemyslím si, že by se nějaký zákon řešil minimální výši honoráře u licenční smlouvy. Protože ty podmínky služby jsou vlastně licenční smlouva o bezplatnou exkluzivní licenci.

K původnímu dotazu: Blogy na Root.cz jsou mrtvé a více méně jen dožívají. Honorovány nikdy nebyly. Místo blogu je lepší napsat normální článek. Ten je normálně honorovaný v řádu několika stokorun. Pokud chceš nutně blogovací platfomu, pak asi dává smysl medium.com; nicméně tam k tomu není diskuze.

233

Sítě / Re:6in4 na 1:1 NAT

« kdy: 18. 06. 2018, 09:51:41 »

Uvedomil jsem si, ze bych uvital, kdybych se mohl lepe seznamit s ipv6 na prakticke bazi. Chtel jsem si nastavit 6in4 he.net -- mam turris, cili to teoreticky neni tak slozite.
Komplikace je v tom, ze ackoliv mam prirazenou externi IP(v4), muj poskytovatel to dela jinak. Uprimne receno, nevim jak, ale z chovani mi to prijde jako 1:1 NAT, kdy vsechno, co prijde na verejnou adresu A preposle na interni adresu. Na interface mam kazdopadne videt jenom lokalni adresu (10.x rozsah), ale jinak vsechny porty otevrene na mem firewallu jsou z venku (pres tu externi adresu) dostupne.
Z meho omezeneho chapani sitariny je duvod nefunkcnosti 6in4 pod NAT to, ze IP nema porty, cili NAT nedokaze sledovat/multiplexovat spojeni, ale tenhle problem u 1:1 NAT neni, myslim.
Zatim jsem ve fazi "zkusil jsem to a nejde to", ale nevim, na co bych se mel zamerit pri zkoumani? Nejaky napad? Mam to rovnou vzdat?

NAT 1:1 by u 6in4 tunelu neměl být problém, pokud ISP neblokuje jiné protokoly než UDP a TCP, v tomto konkrétním případě protokol číslo 41 – tedy IPv6 uvnitř IPv4. Navíc si He.net vynucuje, aby vnější IPv4 adresa odpovídala na ICMP ping. Jinak by mělo stačit naklikat tunel u he.net a následně jeho paramatry přímo v nastavení WAN ve forisu. A pak samozřejmě debugovat nejdřív pomocí ping6 z routeru, pak z počítače za ním.

Pokud to nefunguje, můžete zkusit požádat ISP, aby přenos protokolu 41 prověřil.

234

Sítě / Re:IPv6 skrz WAN a LAN

« kdy: 14. 06. 2018, 21:05:05 »

(např. fdaa:aaaa:aaaa:aaaa::/64)

Úžasný příklad náhodně generovaného 40bitového identifikátoru. 

Nějak mi uniká, co je na tom špatně? A proč by měl být náhodně generován? Vždyť unique local address si snad může zvolit jaké chce, ne? Dokud nebudou kolidovat s ostatními v lokálním rámci.

Jasně, používejte si co chcete. Co na tom, že někdo někam napsal nějaké MUST, vždyť to funguje, tak o nic nejde.

235

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 17:20:39 »

Nejde přece o IP adresy v síti ISP, ale o IP adresy v lokální síti uživatele (nebo v síti, kam má přístup – třeba přes VPN). Podle mne je to špatné výchozí nastavení, protože třeba ty VPN jsou případ, kdy se může připojovat úplný laik, který neví vůbec nic o tom, že by si v DNS resolveru na svém routeru měl vypínat nějaké divné výchozí nastavení. Pak to akorát vede k tomu, že správce takové VPN bude klientům nutit u svůj DNS resolver. A nedej bože, aby se uživatel připojoval do více VPN současně.

Tak dobře, řekněme že má dvě VPN současně – a chce se připojit na webmail.intranet.firma1.cz a zároveň webmail.intranet.firma2.cz. Obě doménová jména budou dostupná ve veřejném internetu a budou se překládat na privátní adresu 192.168.1.1. A jsme v koncích, stejně se k jedné ze dvou služeb nedostaneme.

Ono ale bude mnohem jednodušší, než dotyčnému vysvětlovat, kde tenhle filtr vypne, poradit mu, jak si DNS resolver nastaví na čtyři jedničky, osmičky nebo devítky, čímž bude uživatel definitivně ochráněn od všech škodlivých odpovědí jeho lokálního DNS resolveru.

Máte ověřeno, že tyhle služby privátní adresy v DNS odpovědích nefiltrují?

236

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 15:29:27 »

Jinak tu řešíme prkotinu – kdo ve své síti privátní IP adresy a na ně směřující DNS záznamy používá, ten je na svém DNS resolveru povolí. Takže problém mohou mít akorát ti, kdo používají jiný DNS resolver, nejčastěji uživatelé připojení přes VPN – tak uživatelům VPN změníme DNS resolver, případně uneseme DNS dotazy, a problém je vyřešen. Já teda únosy DNS dotazů považuju za daleko větší problém, než privátní IP adresy v neveřejných DNS záznamech – jestli vy to máte opačně, je to váš problém.

O prkotinu jde v každém případě. Jen si stojím za tím, že filtrování privátních adres přijatých v DNS odpovědích z veřejného internetu je správné výchozí nastavení. Lidé, kteří vědí, že takové privátní adresy jsou v síti jejich ISP používány by měli nastavení upravit, ne naopak. Protože těch případů, kdy z internetu přijde A záznam mířící do privátního prostoru, který bude dávat smysl, bude jistě daleko méně, než případů, kdy půjde o nějakou chybu.

Nicméně použití vhodného IP rozsahu mimo vyhrazené prefixy RFC 1918 tento problém efektivně eliminuje a mělo by být tím správným řešením pro CDN server před CGN.

237

Sítě / Re:IPv6 skrz WAN a LAN

« kdy: 14. 06. 2018, 12:55:08 »

(např. fdaa:aaaa:aaaa:aaaa::/64)

Úžasný příklad náhodně generovaného 40bitového identifikátoru. 

238

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 12:51:06 »

Ale „veřejné“ DNS přece vůbec neznamená, že je ta adresa veřejná. Přece proto se zavádělo třeba NSEC3, aby nebylo možné DNS záznamy vypsat.

O to vůbec nejde. Jde o to, že ve veřejném DNS stromu, který je globálně dostupný, by měly být pouze globálně dostupné adresy. To nevylučuje použití veřejného DNS pro lokálně dostupné adresy, při kterém se takovéto DNS odpovědi nebudou šířit za hranu lokální sítě. A taková hrana logicky existuje i mezi sítí ISP a sítí zákazníka. Privátní adresy podle RFC 1918 navíc úplně jasně patří do sítě zákazníka, nikoli do sítě ISP, je tedy logické, že router zákazníka bude pokusy o průnik takových adres ze strany ISP blokovat.

Stejnou ochranu má implicitně zapnutou i Unbound.

Což nic nemění na tom, že je to – slušně řečeno – hloupý nápad.

Hloupý nápad to rozhodně není. Přeci nechcete, aby třeba Root.cz umístil do své domény A záznam s adresou 10.0.0.138 a během čtení článků nic netušícím čtenářům na pozadí AJAXem konfiguroval jejich ADSL modem.

239

Sítě / Re:HTTPS na privátní adrese

« kdy: 14. 06. 2018, 10:25:59 »

Je to tedy pitomé chování toho routeru (dnsmasq), nebo by se taková věc opravdu neměla dělat? Jak mám tedy používat HTTPS na privátní IP adrese?

Na routeru lze obvykle nastavit výjimku pro určitou doménu, ale není to zrovna hromadné řešení problému.

Není to pitomé chování routeru. Privátní adresy by se ve veřejném DNS neměly vyskytovat už jenom z toho důvodu, že se k nim veřejným internetem nedá dostat. Stejnou ochranu má implicitně zapnutou i Unbound. Privátní adresy taky vůbec nepatří do sítě ISP jakékoli velikosti, protože zde hrozí riziko konfliktu rozsahu s místem, kam privátní adresy patří, tedy koncovou sítí zákazníka. Zákaznický router předpokládá, že na WAN straně je veřejná síť, ze které žádné odkazy na privátní adresy (= ty na straně LAN) nemají co chodit.

Použijte tedy adresu z vyhrazeného prefixu pro CGN 100.64.0.0/10. Adresy z tohoto rozsahu nejsou v DNS odpovědích filtrovány – přinejmenším ne v Unboundu a ne v dnsmasq. Další možností jsou dokumentační IP prefixy, které si lidé s oblibou půjčují, když chtějí „něco jako veřejnou adresu“. Tam je ale riziko, že po určité době napadne někoho jiného něco podobného a celé se to rozbije.

240

Sítě / Re:Plné info o ASN získané z whois

« kdy: 11. 06. 2018, 10:29:30 »

Jaké informace si představuješ? Samotné whois následované AS<číslo> poví všechna data z databáze o daném autonomním systému. Ještě je možno položit inverzní dotaz, kterým se dají zjistit IP rozsahy daného AS:

whois -r -i origin AS<číslo>

Další zajímavé informace je možné získat we webových službách jako RIPEstat nebo bgp.he.net.