Příspěvky

271

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 13. 04. 2021, 13:15:40 »

No, a úplně stejně to platí i o „veřejné adrese“.

Tohle rádi tvrdí poskytovatelé. Stejně jako svévolné filtrování provozu označují za nutné technické opatření (protože by jinak nezvládali nápory). Naštěstí se to mění a doufejme, že to skončí. Bude to boj ještě na pár let, ale povede se.

272

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 13. 04. 2021, 12:58:40 »

To není žádná kulišárna. Že by ta veřejná IPv4 adresa měla být routovaná až na vaše zařízení je jenom váš ničím neodůvodněný předpoklad. Někdo další by mohl tvrdit, že „má veřejnou IPv4 adresu“ jedině tehdy, když u ní bude zapsán v RIPE. A někdo by dokonce mohl tvrdit, že když mu ISP slíbí veřejnou IPv4 adresu, musí pak ta IPv4 adresa být skutečně jeho, žádné propůjčení.

Pořizujete si přípojku. Na té přípojce má být k dispozici to, co si objednáváte. Rychlost změřená na přípojce, IP adresa na přípojce. Zákazníka nemá zajímat, jestli ta rychlost se ztratí někde po cestě od začátku sítě ISP ke zdířce, ani to, že IP adresa je na nějakém rozhraní mimo jeho sféru.

Je to jako „modem v ceně“ – to také neříká, jestli se stanete vlastníkem toho modemu, nebo zda vám ho jen zapůjčí.

Jedná se o službu, ke které je takové zařízení potřeba. Takovým sdělením je zákazník informován, že služba bude zakončena dodaným modemem (tj. ve sféře užití zákazníka). Informuje o tom, že si to nebude muset zákazník zařizovat sám. Jestli bude pronajatý, zapůjčený, darovaný, odprodaný, je informace z jiného ranku, nesouvisejícího se samotnou službou, ale o majetkových vztazích.

273

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 13. 04. 2021, 12:39:20 »

Pokud potřebujete routovanou IPv4 veřejnou adresu, může to být pro ISP specialita, kterou bude chtít zaplatit.

To už zní jako "specialita šéfkuchaře." Rychlost dodáme (ale jen někdy, ale nevíme kdy), veřejnou adresu dodáme (ale bude na našem rozhraní, ne na Vašem)... To jsou takové kulišárny, ke kterým asi vede nouze o prostředky (hmotné, finanční, lidské), ale proč to má rozplétat zákazník? Rychlost nazývejme rychlostí (garantovanou, maximální, rozptylem), veřejnou IP adresu, kterou nedodáme (ale zanatujeme) nenazývejme veřejnou IP adresou. O nic víc tu nejde.

PS: někdy se člověk nemůže ani spolehnout na to, že je ten NAT bezestavový, i takoví experti jsou.

274

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 13. 04. 2021, 12:24:09 »

Co chtít víc za pár šupů měsíčně. :-)

S tím se dá souhlasit, ale férové by bylo nazývat to pravými jmény.

275

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 13. 04. 2021, 12:11:12 »

Nic vam nebrani si to "od-NAT-otvat" a prezentovat tyhle IP datagramy jako provoz z podsite s onou verejnou adresou (trocha saskarny s NATem a routingem a mate to). Ale k praktickemu provozu mnoha sluzeb to potreba nastesti neni.

To už je taková magie na druhou. Ve skutečnosti je založená na odhadu, že ISP opravdu propouští vše beze změny, nikde na jeho technologích nevisí žádný aplikační NAT helper, ... Pokud jsou pro to předpoklady, pak toto má v rámci služby zajistit provider (i když nevidím moc účel, proč by to dělal odnatováním a nedostal tam IP adresu nějak inteligentněji).

276

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 13. 04. 2021, 11:53:50 »

Jde tedy o tu jistotu, že u veřejné IP žádný takový problém nenastane z principu a bude tam všechno fungovat hned, ale u 1:1 přeložené adresy  je vždy nějaká implementace která může způsobovat odchylky v chování a že překlad může být nějak osekaný a nemusí tam být pro každý kýžený transportní protokol.

Některé protokoly to mají jako svoji podstatu. Např. zmiňovaný IPSec včetně L2TP VPN. Kromě šifrování, ten protokol zajišťuje, že je šifrováno na skutečném počátku tunelu a odšifrováno na skutečném konci. NAT musí ale do packetu zasáhnout, čímž celý protokol ztrácí celou jednu úroveň zabezpečení, která k němu neodmyslitelně patří.

P2P sítě (jakéhokoliv typu, třeba i blbý videohovor) také využívají znalost IP adresy a snaží se navázat spojení přímo. Pokud adresu neznají, i když máte NAT 1:1, tak stejně tyto protokoly využijí neefektivní způsoby práce za NATEM. Zrovna o pár článku níže se píše o řešení Chrome proti NAT Slipstreamingu.

Vyšší protokoly nemohou IP adresu ani detekovat, protože nikdy nevědí, jestli je opravdu pevná, nebo jestli se může změnit.

NAT 1:1 bych za veřejnou IP adresu nepovažoval, plní to jen část požadavků, které se od "opravdové", tedy směrované pevné IP adresy očekávají.

277

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 13. 04. 2021, 07:48:47 »

Problém je, že NAT-Traversal, který v těch registrech s velkou slávou a bez rozmyslu zapínáte, oslabuje bezpečnost IPSecu. Proto je to ve výchozím stavu vypnuté.

[Citation needed]

https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/885348

278

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 12. 04. 2021, 21:05:57 »

Ono obvykle v nabídce bývá „veřejná IP adresa“, a nebývá u ní už specifikováno, co s ní. Jestli vám ji budou routovat nebo NATovat.

Stejně jako bývá (bývala) nějaká pofiderní maximální rychlost, bez bližší specifikace. Není to ideální přístup. Smlouva (a tím pádem i oferta) by měla být určitá. Ve spotřebitelských vztazích je pak potřeba vycházet ještě navíc z toho, že je spotřebitel slabší stranou. Neznám případ, že by se kvůli tomu někdo soudil, ale myslím si, že by poskytovatel tahal za trochu kratší konec.

(Ostatně, od poskytovatele si platíte přípojku, a na ní by měla být ta IP adresa. Ne někde v tajemné dálce poskytovatelovy sítě.)

279

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 12. 04. 2021, 18:55:07 »

Huh, opravdu? Pokud má někdo problém do left dát 10.1.2.3 a do leftid a leftsubnet 81.82.83.84, tak nemyslím že ho reálná veřejná IP spasí.

Tohle je celkem OK, ale docela mě to potrápilo, když jsem na něčem takovém řešil L2TP/IPsec server. Nastavil jsem to, zkusil na mobilu s Androidem a žádný problém. Pak jsem totéž nastavil na notebooku s Windows 10 a prostě jsem se nepřipojil. Docela jsem si zagooglil, než jsem se dobral k tomu, že ty návody z dob Vist, co je třeba přidat do registrů, aby to začalo fungovat za NATovaným serverem, jsou bohužel aktuální i ve W10.

Problém je, že NAT-Traversal, který v těch registrech s velkou slávou a bez rozmyslu zapínáte, oslabuje bezpečnost IPSecu. Proto je to ve výchozím stavu vypnuté.

280

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 12. 04. 2021, 14:44:26 »

NAT 1:1 není přidělená veřejná IP adresa. Ve skutečnosti nevíte, co všechno ISP při překladu provádí. Možná neprovádí nic a chová se to velmi podobně, jako kdyby to veřejná IP adresa byla. Jistota ale není a záleží vždy na provedení.

1:1 NAT lze použít, ale považoval bych to spíš za nouzové řešení. Jedním z problémů, jak bylo zmíněno, je to, že aplikace nemají ani šajnu, pod jakou adresou vůbec pracují a může se to projevovat na nefunkčnosti, nebo neefektivitě protokolů, které se znalostí IP adresy vnitřně pracují.

Setkal jsem se s takovým nastavením u menších sítí a některých freenetů. Usnadňují si tím konfiguraci a správu. Většinu přípojek mají za běžným NATEM a je jednodušší mít pár výjimek pro "exoty", kteří chtějí veřejnou adresu. Nepovažuji to za šťastné, ani za profesionální řešení, jedná se o povyšování nouze na standard, ale taková je situace.

281

Sítě / Re:10G switch Mikrotik?

« kdy: 12. 04. 2021, 14:34:07 »

U 10GbE switchů je nejzásadnější, kolik mají a jak pracují s buffery. Levné 10 GbE switche sice dokáží přepínat určité množství, ale od relativně blízké chvíle přestávají zvládat a výkon prudce klesá. To taky tvoří převážný rozdíl v cenách switchů. (Něco podobného bylo, když přišly 1 GbE switche po 100 Mbitových).

Asi v první řadě je potřeba se podívat na specifikace, kolik packetů za sekundu upřepíná (PPS).

282

Vývoj / Re:Využití Revolut pro OSVČ fakturující mmimo EU

« kdy: 07. 04. 2021, 12:25:34 »

Myslím, že ta celá otázka je nejlépe zodpověditelná účetním, který Vás účtuje. Ten bude muset účtovat o kurzových rozdílech a z ceny jeho práce vyjde, jestli se to vyplatí, či ne. Bohužel, není to tak lehké, že se jen zaúčtuje přesná částka v Kč, která vzejde z převodu.

283

Server / Re:Jak nastavit práva /var/www/html pro víc uživatelů

« kdy: 06. 04. 2021, 09:54:13 »

Kód: [Vybrat]

30 0    * * *   root    find /home/*/www/ -atime +1 -delete

Má být asi

Kód: [Vybrat]

30 0    * * *   root    find /home/*/tmp/ -atime +1 -delete

, ne?

284

Server / Re:Jak nastavit práva /var/www/html pro víc uživatelů

« kdy: 02. 04. 2021, 16:58:22 »

Já jsem doufal, že to půjde nějak jednoduše nastavit direktivou SuexecUserGroup user1 user1 pro každý virtualhost. Čekal jsem, že v dnešní době bude mít nejnovější apache už takové věci dávno v sobě.

Nemá, a nedá se to ani očekávat. Součástí bezpečnosti je i segregace oprávnění, takže by nebylo příliš moudré to nakoncentrovat do rukou apache, či čehokoliv jiného. Pro takové to domácí žvýkání stačí jednoduché nastavení, nepotřebujete oddělovat oprávnění. V produkci by se to už mělo, ale na to, co vím, žádná distribuce nedává řešení out-of-box.

Open source dobře funguje na sdílení programového kódu, ale opravdové know how se už tolik netroubí do světa, a tak internetové návody jsou spíš entry-level.

Ve větším se to řeší přes produkty typu Plesk. cPanel apod., ale obvykle je to stejně plné kompromisů, protože spousta PHP aplikací je napsaná špatně a vyžadují prakticky plná oprávnění.

285

Server / Re:Jak nastavit práva /var/www/html pro víc uživatelů

« kdy: 02. 04. 2021, 14:51:17 »

Open-basedir mi udělá jen stránku typu mujsite.com/~user. shell_exec('whoami') v php vrací www-data (mám ubuntu 18). Funguje nastavení APACHE_RUN_USER v /etc/apache2/envvars, ale to je globální.
Zkouším nějaké návody na SuexecUserGroup a fast cgi a nedaří se mi to udělat. Znáte někdo příklad funkčního nastavení pro nějaký VirtualHost? Chci mít pro každý virtualhost jiného usera, pod kterým pojede jeho php skript.

Je to poměrně dost nastavování, ale jde to.
Nejprve si nainstalujete třeba nginx jako reverzní proxy. Založíte uživatele pro běh proxy a nastavíte, aby pod ním běžel nginx. Osobně doporučuju udělat si na to extra instanci, protože pak se nestane, že si s aktualizací přepíšete něco v /etc/nginx.

Pak založit uživatele pro instanci php-fpm, uživatele pro apache té instance a uživatele, který bude nahrávat soubory.

Apache (v rámci systemd) založit novou instanci, tu nechat naslouchat na 127.0.0.1 a nějakém portu. Celého apache nechat běžet pod extra uživatelem, kterého jste založil (viz odstavec výše).

Na nginx proxy nastavit, který FQDN se mají přesměrovat na 127.0.0.1:port.

V php-fpm nastavit nový pool, který poběží pod uživatelem, kterého jste založil (viz výše).

Tím máte hotové odělení práv od sebe. V tento moment začnete budovat práva mezi sebou, aby jednotlivé části směly vůči sobě to, co chcete. Tím je obvykle přidávání ACL, aby např. apache mohl ke statickým souborům webu, aby php-fpm mělo read-only přístup do aplikace samotné a zápis jen do složek, kam se ukládají provozní data, tempy, ...

Je to poměrně hodně práce a neexistuje na to kuchařka.

Jako první tip: naučte se spouštět více instancí Apache (přes systemd), a naučte se spouštět více instancí PHP-FPM (přes pooly v php-fpmd) a přiřaďte jim extra uživatele (systémové, bez možnosti loginu, bez home, ...) a extra skupiny.