Příspěvky

1366

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

« kdy: 13. 04. 2021, 12:50:21 »

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

Že by třeba v reklamě bylo napsáno „globálně routovatelná IPv4 adresa routovaná na zařízení zákazníka, které je přímo připojené do sítě ISP“? To by se v té reklamě hezky vyjímalo a nikdo by tomu nerozuměl…

Když tam napíšete „veřejná adresa“, jak je zvykem, „pravým jménem“ to být nemůže, protože je to nepřesné a neříká to vůbec nic o tom, co s tou veřejnou IP adresou bude. 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čí.

veřejnou adresu dodáme (ale bude na našem rozhraní, ne na Vašem)...

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í.

1367

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

« kdy: 13. 04. 2021, 12:34:41 »

Verejna IP to je, pokud dostanete veskery prichozi IP provoz, ktery k vam smeruje, v nefiltrovane podobe. Jestli to je tunelem, nebo NAT-em.. je to jedno, jen to stoji praci navic

Mícháte do sebe veřejnou IPv4 adresu a filtrování, což jsou dvě odlišné věci. I když budete mít routovanou veřejnou IPv4 adresu, pořád může být provoz na ni filtrován. Naopak NAT teoreticky nijak filtrován být nemusí. Používá se bezestavový NAT, který opravdu jen přepíše IP adresu v hlavičce paketu, přepočítá kontrolní součet a pošle paket dál. Ale například ty kontrolní součty ve vyšších vrstvách protokolů jsou problém – protože kontrolní součet v TCP/IP paketu zahrnuje i IP adresy, musí NAT protokolu TCP/IP rozumět a změnit i ten kontrolní součet. Pokud by skrz NAT procházel paket, kterému NAT nerozumí, může jen změnit IP adresy – ale je dost pravděpodobné, že tím paket z pohledu vyšších vrstev poškodí.

Většina lidí chce veřejnou IPv4 adresu, aby se zvenku dostali na své zařízení přes HTTPS, VPN, SSH apod. Na to NAT 1:1 bohatě stačí. Pokud potřebujete routovanou IPv4 veřejnou adresu, může to být pro ISP specialita, kterou bude chtít zaplatit.

1368

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

« kdy: 13. 04. 2021, 08:29:44 »

Áno, čísla portov sú tam nadbytočné, ale každý normálny človek pochopil, že pointa je o tom, že NAT filtruje protokoly. Len Jirsák niečo vytrhol z kontextu a musí zakontrovať.

Nic jsem nevytrhl z kontextu. Ta čísla portů jsou tam pro znalé nadbytečná, pro neznalé ovšem vyvolávají dojem, že v TCP/IP nebo UDP lze používat i vyšší čísla portů, která ovšem neprojdou přes NAT.

Je to tak, ty porty jsem tam psal hlavně kvůli původnímu tazateli.

Jasně, když se někdo v problematice moc neorientuje, je nejlepší ho ještě zmást zavádějící odpovědí.

Předpokládal jsem, že to lidé s IQ > 100 pochopí, ale nevzal jsem v úvahu INKLUZI 

Já jsem se právě podíl, od koho ten komentář je, a pak jsem raději napsal to upřesnění – protože ve vašem případě jsem si fakt nebyl jist, že víte, že rozsah portů 0–65535 je u TCP a UDP omezen definicí protokolu a také počtem 16 bitů vyhrazených pro port v hlavičce.

1369

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

« kdy: 12. 04. 2021, 21:44:24 »

TCP/UDP na porty 0-65535

Pokud by se vám podařilo poslat TCP nebo UDP paket na port mimo rozsah 0–65535, zaznamenal byste první aut v historii IP protokolu…

Ono sú tu aj iné protokoly ako TCP a UDP. Napr. pre spomínaný IPSec zaujímavý ESP.

Jiné protokoly než TCP a UDP ovšem nejsou TCP nebo UDP protokol. O jiných protokolech jsem v tomto vlákně psal jako první, a od té doby jsem opravdu na jejich existenci nezapomněl. Odpovídal jsem přesně na to, co jsem citoval.

1370

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

« kdy: 12. 04. 2021, 21:03:50 »

TCP/UDP na porty 0-65535

Pokud by se vám podařilo poslat TCP nebo UDP paket na port mimo rozsah 0–65535, zaznamenal byste první aut v historii IP protokolu…

1371

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

« kdy: 12. 04. 2021, 21:01:46 »

Což nic nemění na tom že veřejná ip adresa je terminus technicus a ISP by ji neměl nabízet, pokud umí nabídnout jen NAT. Protože pokud uživatel žije s tím, že má veřejnou IP adresu, nebudou mu pak fungovat příslušné návody na rozběhání služeb apod.

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.

1372

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

« kdy: 12. 04. 2021, 14:43:42 »

Tak děkuji za odpovědi, šlo by jen zmínit, jaké důvody by to mohly být? Když vlastně to žádné funkce neubírá.Jediný problémek mě napadl,že právě v případě potřeby zjištění té veřejné IP nestačí se podívat na přidělenou adresu ale mít ji někde poznamenanou nebo ji odněkud vytáhnout. Řekl bych že to je jen striktní vnímání tohoto pojmu, protože skutečně veřejná IP to není, přestože tak vypadá, chodí a kváká.

I ten důvod, že aplikace nevidí svou veřejnou IP adresu, může být podstatný. Některé protokoly pracují s IP adresou – třeba FTP v aktivním režimu (který je výchozí) posílá v rámci svého protokolu informaci, na jakou IP adresu se má protistrana připojit. Ve vašem případě samozřejmě pošle tu z privátního rozsahu – a funguje to jenom tehdy, když NAT u poskytovatele FTP rozumí a tu IP adresu v protokolu FTP nahradí.

Obecný problém je pak v tom, že NAT obvykle pracuje o vrstvu výš, než pracuje routování. Pro routování stačí rozumět protokolu IP, podle hlavičky cílové IP adresy se prostě paket pošle dál. NAT 1:1 by sice mohl jenom přepisovat hlavičky v IP datagramu a o detaily se nestarat (pak by ale nefungovalo třeba to aktivní FTP). Obvykle je NAT 1:1 implementován jako speciální případ obecného NATu – a obecný NAT potřebuje rozumět protokolu nad IP. Např. u TCP/IP musí sledovat, do kterého spojení pakety patří (protože obecný NAT musí měnit i porty, v případě TCP/IP tedy musí změnit všem paketům v jednom spojení port stejně). Tím pádem NAT obvykle podporuje nějakou sadu protokolů (třeba TCP/IP, UDP/IP a ICMP), ale je klidně možné, že nějaké speciální nebo novější protokoly podporovat nebude. Takže je třeba možné, že SCTP vám skrz NAT 1:1 neprojde. Kdybyste ale měl skutečnou veřejnou IPv4 adresu, normálně by vám fungoval.

1373

Vývoj / Re:Google/Facebook Oauth2 pri architekture SPA + mikrosluzby

« kdy: 12. 04. 2021, 10:27:43 »

Nedari sa mi zial najst oficialnejsi zdroj pri pouziti social oauthu so SPA. Vacsina prikladov vratane toho na blogu je, prihlasovanie na server side appke, po prihlaseni na google stranke, opat prebehne redirect na serverovu appku kde sa stane ta springova magia. Ak ale vyvijam SPA klienta, tak ten oauth prebehne predpokladam tam, otazka teda je, ako komunikovat so springom v tomto pripade, co mu poslat atd.

Použití Spring Security spolu s SPA je popsáno v dalším tutorialu: Spring Security and Angular, ale už je to komplikovanější. Token musíte na straně serveru (Springu) ověřovat vždy. Jediný rozdíl je v tom, jestli authorization token vyměňujete za access token v prohlížeči nebo na serveru, což je jen implementační detail.

1374

Vývoj / Re:Google/Facebook Oauth2 pri architekture SPA + mikrosluzby

« kdy: 11. 04. 2021, 21:31:07 »

Jak jsem psal, nevymýšlel bych kolo. Nejprve bych to implementoval podle toho tutoriálu Springu, a až vám to bude fungovat a budete rozumět tomu, jak to funguje, můžete to upravovat. Když to budete vymýšlet sám, nevíte, jestli tam někde nemáte díru. U té implementace ve Springu se dá přeci jen předpokládat s větší pravděpodobností, že to je správně.

1375

Vývoj / Re:Google/Facebook Oauth2 pri architekture SPA + mikrosluzby

« kdy: 11. 04. 2021, 09:56:55 »

Nevymyslal by som nic noveho, ale pouzil by som Open ID Connect (OIDC) - to vlastne autentifikacia, ktoru poskytuje Google, Facebook,...  OIDC != OAuth, OIDC je rozsirenie postavene nad OAuth (ale vacsina ludi si to aj tak zamiena).

SPA potrebuje Authorization Code Flow with PKCE (zabudni na stary implicit flow, silent refresh v iframe a pod).
Backend iba verifikuje/authorizuje token, ziaden redirect na login, ale max vrati 401/403 a SPA frontend si tento chybovy stav musi poriesit.

A nebo jste si taky mohl ten odkaz rozkliknout…

1376

Vývoj / Re:Google/Facebook Oauth2 pri architekture SPA + mikrosluzby

« kdy: 10. 04. 2021, 18:35:27 »

Nevymýšlel bych nic nového, vaše požadavky jsou úplně standardní, takže stačí postupovat podle základního tutorialu: Spring Boot and OAuth2.

1377

Odkladiště / Re:KB - ověření všech odchozích plateb KB klíčem

« kdy: 10. 04. 2021, 09:18:36 »

To je vážně tak složité z pozice banky použít něco jako procedury nad databází?

Představujete si to jak Hurvínek válku…

Jakmile vidím, že je odchozí transakce, spustí se její ověření KB klíčem

Píšete o platbě kartou, což je něco jiného, než odchozí transakce z účtu. V případě debetní karty byste to ještě s přimhouřením obou očí mohl považovat za jednu transakci, i když ve skutečnosti se peníze na účtu jen zablokují. V případě kreditní karty to už nijak okecat nejde – tu částku platí banka a teprve na konci zúčtovacího období vám předloží účet ke splacení.

Co je ještě podstatnější je to, že ověřování je pro klienty otravné, a banka se tedy snaží ověření minimalizovat. Jednotlivé transakce posuzuje a ověřování požaduje podle toho, jak riziková jí ta transakce připadá. Takže můžete být klidný, pokud banka u nějaké transakce nepožaduje potvrzení, nepovažuje ji za rizikovou – a pokud by to přeci jen byla neoprávněná platba, s vysokou pravděpodobností byste uspěl s reklamací.

No a pokud údaje o své platební kartě zadáváte bůhvíkam a bojíte se, že je někdo zneužije, má to jednoduché řešení – pořiďte si kartu jen pro tyhle případy, nastavte na ní nulový limit a zvyšte ho jenom když budete provádět platbu. Pak zase limit nastavte na nulu.

1378

Sítě / Re:oteverni portu 25565 na o2 smartbox

« kdy: 04. 04. 2021, 22:32:04 »

Máte na ten Smartbox vůbec přidělenou veřejnou IPv4 adresu?

1379

Sítě / Re:oteverni portu 25565 na o2 smartbox

« kdy: 04. 04. 2021, 20:23:50 »

Testujete ten otevřený port opravdu na IPv6?

1380

Windows a jiné systémy / Re:vadí něčemu že na androidu SeLinux je Disabled(permissive)

« kdy: 03. 04. 2021, 17:43:12 »

Myslím, že řádově větší nebezpečí je, že tam máte roota a že nepoužíváte Android od výrobce telefonu. Obecně platí, že čím víc zabezpečení je ponecháno na volbě uživatele, tím větší znalosti musí uživatel mít, aby to dokázal zabezpečit.