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] 2 3 ... 11
1
Server / Re:Domenová koncovka (tld) pre osobnú stránku
« kdy: 09. 05. 2021, 20:01:03 »
Co TLD .name? Byla i za pár šupů. Mám prezdivka.name. :-)

2
Ještě bych zahrnul do úvahy podkladovou platformu. Třeba pokud se má kontejner pouštět navíc pod Pacemaker clusterem na CentOS/RHEL. Zde třeba platí, že na CentOS7 je nyní funkční libvirt-lxc, ale bez záruky bude kdykoliv odstraněn, oficiálně podporovaný je Docker, na RHEL/CentOS8 je podporovaný zase Podman, ale budoucnost na těchto platformách míří v dáli někam k OpenStacku.

3
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 21. 04. 2021, 10:18:36 »
Jestli tu jednu adresu doručím zákošovi pomocí PPPoE (de facto standartd) nebo pomocí NAT1:1, případně routovaně /32 (což jsou kapánek bastly), tak na celkovou spotřebu veřejných adres to má shodný dopad.
Samozřejmě pokud půjdu do routovaného /30 segmentu na zákazníka, tak už mám spotřebu navíc, ale to je doména tarifů za vyšší ceny (a to opět zpracuje kdejaké zařízení).

4
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 20. 04. 2021, 18:39:46 »
M_Š: Pro NAT1:1 jsou lenost, náklady, neschopnost lidí, minimalizace potíží uvnitř sítě, obchodní model...
Je třeba si uvědomit, že řada těch ISP jsou low cost na dřeň, síť často obsluhuje minimum lidí s minimem znalostí, kde nastavit routing v síti přes X prvků je problém. Stejně tak použití nějakého dynamického routingu je problém, to už musí něco umět a hlavně řešit, když se něco rozbije=potřebuji schopnější lidi a ne študáka na trvalé vzdálené brigádě atd.
Takže pokud jsem oživil a roztahal síť po okrese na neveřejných adresách, tak veřejky do toho už patlat nechci, protože nemám lidi na uchopení jiného modelu, než NAT1:1, kde to nastaví i poloblbé opice na jednom místě dle kusu papíru.
Kdo síť postavil od základu rozumně, tak obvykle nemá problém s rozumnějšími postupy přidělování IP adres.

5
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 19. 04. 2021, 19:15:31 »
RZ: Nu, řekl bych, že je to celé zde mířeno na SOHO segment, tak bych viděl stále jako majoritu doručení jedné IP adresy pomocí PPPoE a je to standart, který vládne drtivé většině přípojek na doma v Česku i jinde a neviděl jsem ještě SOHO router, který by tento režim nepodporoval. Doručení stylem routa /30 spíše pro vyšší level tarifů "business". A do toho nám vtrhla z důvodů šetření specifika jako NAT1:1 nebo routovaná veřejka /32, proto by u linek řešených takto to mělo být uvedeno, protože toto omezuje využitelnost  z pohledu protokolů nebo klade specifické požadavky na koncové zařízení (pamatuji i RFC, které pro koncové linky navrhovalo /61, ale to se snad nikde neujalo a neviděl jsme SOHO krabičku s tímto).

6
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 17. 04. 2021, 10:11:30 »
Smekám před vytrvalostí....
A přitom je to celé o tom, že ty sítě řady alternativních ISP vznikly jako hurá akce na zelené louce s povýšeným konceptem sítě pro malou firmu a ne jako telco síť. V takové síti práce s jednou IP adresou je "drahá" a tak ji nechtějí dělat jinak, než tím NAT1:1 - houska na krámu, ber za 250+100 Kč/měsíc nebo jdi do business služby aspoň za 3 kKč/měsíc a budeš mít routovaný blok X/Y.
Kdo to stavěl jako "telco", tak to má většinou na PPPoE ke koncákovi, tam přidělení veřejné IP je o kliknutí v managementu a po restartu PPPoE má doručenu veřejku až na port routeru zákazníka.
A kolik je z toho tady písmenek...
Zkrátka našinec musí být obezřetný a vždy se ptát a v objednávce vysloveně specifikovat, že IP bude přímo nastavnea na koncovém routeru na rozhranní, který už mám ve správě, nebude použiti NAT1:1 nebo ani dvojitý NAT1:1 na odnatování a zanatování (protože tohle umí i řada sprasit tak, že to IPsec nerozdejchá), stejně tak nebude na lince žádné blokování provozu, zejména porty 53/UDP+TCP, 25/TCP, ... :-(

7
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 13. 04. 2021, 22:16:40 »
Je vidět, že zákaz osobních soubojů byla chyba. Takovou souboj, kdo dříve zemře při odříkání všech IPv4 adres by byl celkem napínavý a možná kratší, než je tato diskuze. :-)

Asi nemá smysl se hádat, jak kdo to vnímá pod pojmem veřejná IPv4 adresa, když to není nikde pevně kodifikováno. Podstatné je, aby to asi ISPák jasně definoval. Nedělejme si iluze, že běžný koncák to stejně pochopí a ano, pro 99% bude ten NAT1:1 OK. Řada ISP dneska nabízí po zeptání na co to chci, že udělá jen přesměrování pár portů nebo dělá to, že mi dá VPN přístup do vnitřní sítě a pak se už přes neveřejku dostanu domů (typicky přístup na kameru domů, nahodím si VPN na server ISPíka a přes to spojneí už vidím na svoji neveřejku a přes ní se dostnau ke kaměře např).

Hm, jsem si udělal průzkum pěti největších místních ISP okresního formátu (ať přeskočím velkou trojku), na webu vidím:
a) Veřejná IP adresa(NAT 1:1) 99 Kč/měsíc,
b) Veřejná IP adresa (NAT 1:1) 90 Kč / měsíc,
c) Hacklý web, přesměrován na anime porno sever,
d)  Veřejná IP adresa routovaná s maskou  /32  volitelně k Vašemu tarifu 100,- Kč / měsíc,
e) Veřejná IPv4  adresa k základní lince  je zpoplatněna 145,-  Kč /měsíc s DPH.
Takže to většinou poctivě uvádí a u ISP E vím, že je to také /32 routovaně(ISP E je znám i tím, že člověka připojí, jede mu to a ani několik let není schopen začít posílat faktury nebo vůbec info, jak mu za služby vlastně začít platit, takže informační nejasnost u IP adresy zapadá do podnikatelského konceptu).

Takže sumárně asi relativně OK stav informačně a i technicky je stav vyrovnán. :-)


Add ten vypnutý NAT-T u IPsec ve Windows - nebyla podstata problému jinde? Je defautlně zakázáno, aby se Windows v režimu IPSec klient připojil na IPsec server za NATem. Pokud je NAT na straně klienta, tak to defaultně pouští od dob Win2000. Když je detekován NAT na straně serveru, tak Windows potlačí ověření identity protistrany (i když bylo zvoleno, že se má provádět), takže pokud se používá IPSec s certifikáty, tak mi stačí jakýkoliv certifikát podepsaný autoritou, kterou má Win v systémovém cert store a pustí mě to, neprováde se ověření identity protistrany a ani atributů použití - krásnáí možnost MITM útoku, klidně s email podpisovým certifikátem. Proto měly/mají(?) to Wokna default zakázáno. Bylo to i popsáno i v dokumentaci RRAS serveru. Problém odstraněn až při použití AnyConnect a spol kde používají default doménové info pro ověření. Zda už je to odstraněno clekově netuším,neměl jsem potřebu řešit dost dlouho...

8
/dev/null / Re:Je to plnohodnotná veřejná adresa?
« kdy: 13. 04. 2021, 12:18:15 »
Je to třeba brát tak, že je ten NAT1:1 pro řadu alternativních ISP nejjednodušší a často to tak dělá schválně pro odlišení consumer služby od "firemní" za jinou cenu. :-(
A pokud budete prudit moc, tak stejně udělá max to odnatování, dělá jich to tak řada. Na své hlavní bráně to NATne 1:1 na neveřejku a na předávacím rozhraní k Vám to zase odNATne 1:1 na tu veřejku. Co chtít víc za pár šupů měsíčně. :-)

9
Sítě / Re:Orientace jak na VPN
« kdy: 12. 04. 2021, 20:28:24 »
První podstatný bod, zda ta komunikace mezi PLC a tou aplikací v PC je na L3 na bázi TCP/IP s plným routingem nebo je to něco, co používá průmyslový protokol, který vyžaduje L2 propojení (některé, přestože umí IP protokol, tak neumí jinou síť než lokální segment). Další bod u některých protokolů jsou timeouty, kdy LTE síť je "pomalá na odezvy" a komunikace se neudrží. To může trochu omezit jaké krabičky/konfigurace se použije.

Takovéto propojení se řeší nad LTE nejlépe pomocí privátního APN u operátora. Ale pro dvě zařízení trochu overkill, pro větší instalace jsou to desetikoruny za koncový bod/měsíc. :-( Minimálně O2 míval pro takovéto malé instalace na to tarif se speciálním APN, kdy komuinikace šla mimo Internet. Možná by to bylo pro ty dva body levnější než pevná veřejná IP adresa na jednom konci a ubude i obtížného hmyzu z Internetu.
Kolega má takto v Česku propojeny v řádu stovek zařízení na svoji centrálu, kde se dělá dohled a sběr dat z PLC a automatů různě v polích (řízení plynové soustavy). Je to bod-bod na jeho IPčkách, co přidělí, zařízení se vzájemně vidí, žádné NAT/přesměrování portů po cestě a uvnitř toho ještě má VPNku (IPsec), aby do toho operátor neviděl.
Já mám něco podobného world-wide několik set, někde vlastní APN, někde přes lokální Internet, někde satelitní modemy. V mém případě otvírají koncové krabičky 2x SSTP tunely do centrály, kde opět běží dohled, konfigurace (přes Modbus/TCP plus nějaká L2 sračka, co vyžaduje "čistý ethernet", proto SSTP s použitím BCP bridge).

Kolega plynař i elektro jako koncové krabičky používá ty proklínané mikrotiky. :-/ Já jsem zaujat, on ječí radostí, že se zbavil všech těch průmyslových LTE zařízení jako to zmíněné TLB140 a další (požívali cca 5 typů různých výrobců), že s tím byly nekonečné problémy, aby se to udrželo v spolehlivém provozu, že co potřebuje, tak si v tom Mikrotiku doskriptuje. Má použity RB 912R-2nd-LTM, s jednou LTE kartou a dvěma SIMkama, když lehne jeden operátor, přepíná skriptem na druhého. Samozřejmě externí antény vytažené ven z budky.

10
Nu, záleží na čem v tom remote děláš. Pokud výsledkem tvého remote snažení je, že vyvolám generální stop na 300 km rychlodráhy ve Francii, tak takové pojištění se může hodit. :-)
Ale je pravda, že je třeba si to hlídat, protože jsou věci, kam jako kontraktor nemá smysl lézt kvůli nepřiměřeným rizikům.

11
Public liability se žádá v kdejakém oboru, kde někdo další obecně může přijít k újmě. A ne jen ve stavebnictví, nesmíš koukat jen na stavební web. Pokud si mě promotér najme na ozvučení koncertu, tak bude chtít po mě úplně stejné pojištění, jak public liability, tak i professional (malpractice) liability. Pokud mi upadne bedna na borce v první řadě, tak pokud to bude následkem selhání materiálu - řetěz rupnul, nebylo patrné poškození, mám OK revize atd, tak to jde na public, pokud se zjistí, že jsem zapomenul zajistit západku, tak je to nedbalost, kterou kryjí některé typy těch professional pojištění. Odběratel evidetně žádá oboje pojištění dle prvního příspěvku.
A bude záležet do jaké země a jakého oboru. Ono je to někde i tak, že dodavatel se nemůže ve své pojistce jistit na škody subdodvatelem, takže škoda jde přímo na konkrétního subdodavatele, který to podělal (dodavatel ručí za své kmenové lidi a na to musí být pojištěn zase něčím jiným).
A ano, v IT je zmíněný problém s dokazováním, že ke škodě došlo. Když podělám stavbu a místo rozestavěného baráku je hromada suti nebo mi před pódiem leží borec, co místo hlavy má můj reprák, tak je vznik škody "celkem" jasný (ale plnění ze strany pojištovny často dost nejasné). U toho IT to je už problém toho dokázání vzniku škody, když vynechám ty případy, že jsem zakopl a ze serveru udělal schodištní surf, což pojistky na blbost řeší celkem OK. Takže u IT to odběratelé často vědí a řeší to případně i jinak (smlouvy o škodách, kde na to chtějí bankovní záruky a podobné vymyšlenosti).

12
Server / Re:Obnovení svazku QNAP LUN na Linuxu
« kdy: 25. 03. 2021, 23:20:39 »
Kdysi jsem řešil něco stejného, z umřelého QNAPu vytáhout iSCSI disk a pusit ho v linuxu a až došlo nové pole, tak se to zase na něj vrátilo zpět. :-)
Podstatné info bude:
LUNCapacity=1885102
LUNFileCount=2
LUNThinAllocate=FALSE
Dle toho popisu se mi to jeví, že iSCSI disk se navenek jevil a exportoval jako jeden disk o velikosti 1,8 TB. Fyzicky to v QNAPu bylo uloženo rozsaknuté do těch dvou souborů .0000 (prvních 1TB) a .0001 (0,8 TB). Když ty dva soubory spojíš tupě za sebe, tak dostaneš sektorově to, co bylo vidět přes iSCSI. Celá kapacita byla alokována dopředu (v podstatě raw).

13
Sítě / Re:T-Mobile - slovenská GeoIP
« kdy: 24. 03. 2021, 16:08:15 »
Tak hlavně klid. Pokud by se už do toho mělo štourat až tak nesmyslně, tak Teamspeak by padal pod telekomunkační hlasové služby, které nejsou v rámci EU sjednoceny a můžu si s nima dělat co chci, takže klidně blokovat na ČR/SK "trh". A samozřejmě pořád je, že v rámci ochrany sítě před útoky/zahlcením atd můžu provádět blokování jako ochranu před narušením služby pro oprávněné uživatele.

14
Sítě / Re:T-Mobile - slovenská GeoIP
« kdy: 22. 03. 2021, 12:57:51 »
Řekl bych to tak, že operátoři se obvykle nějak snaží, aby ty data v těch GeoIP databázích tak nějak seděla. Aspoň u těch nejprofláklejších, ale nemají šanci to vše obstát a někteří provozovatelé těch DB jsou dost natvrdlí ohledně změn. Ale není to žádná povinnost, jen dobrá vůle. A koncový zákazník má minimální šanci něco u GeoIP DB  změnit (pokud není na něj blok IP veden někde u RIPE a spol, tak se s ním nikdo nebude bavit), takže správně má prskat primárně u provozovatele služby, co ho blokuje (protože jen ten nějak ví, dle čeho ho vlastně blokuje).
Když vezmu, že změnit data u maxmind.com, protože člověk chtěl mít správně údaje na výpisech u speedtest.net (který používá GeoIP od maxmind), tak to bylo na hodně dlouho. Vysvětlit jim, že když jsou data dle RIPE v státu X, tak dané bloky mohou být použity i v místě Y, když tam daný ISP také půdobí...
A nejdebilnější je to u státní správy, když blokuje dle GeoIP. :-(

15
Server / Re:Viac ako jeden web server za verejnou IP
« kdy: 16. 03. 2021, 11:38:49 »
Pro trvalé řešení ta zmíněná reverzní proxy (jde použít cokoliv - haproxy, nginx, ... i v tom apache to jde udělat). Pokud je to jen na hraní a pokus a v roli toho NATu mám Mikrotika, tak pro HTTP umí dělat reverzní proxinu (ale nehodí se to pro nasazení do ostra) a pro HTTPS umí směrovat na základě požadavku TLS host (SNI).

Stran: [1] 2 3 ... 11