Příspěvky

2101

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 19:52:03 »

Tak jistěže nezáleží na tom co si myslím nicméně slovy RFC já mám za WAN public a ne private...

No evidentně tam máte private.

2102

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 19:42:45 »

Na WAN mám veřejnou IP. Nevím proč by mi na veřejnou IP mělo lézt cokoliv z RFC 1918. Takže si nemyslím, že uvnitř internetu jsou adresy z RFC 1918 "legálně" tak jak jste napsal.

Nezáleží na tom, co si myslíte, ale co je napsané v RFC. messagebus si to také myslel, dokonce se oháněl RFC, ale pak to tam nenašel a teď vaří z vody. Adresy dle RFC 1918 nejsou globálně routovatelné, což ale nevylučuje, že mohou být routované v nějaké menší síti. A vy jste zrovna v síti, kde routované jsou.

2103

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 19:28:35 »

Na WAN blokuji jen RFC 1918, zákazníci ISP mají adresy z rozsahu 10.0.0.0/8. Pokud jdou kamkoliv ven mimo síť ISP jdou přes veřejnou IP, pokud jdou na server který je u stejného ISP byť má veřejnou IP tak jdou přes lokální adresy.

Takže řešením je ten rozsah 10.0.0.0/8 u vás neblokovat. V čem je tedy problém?

2104

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 19:27:43 »

A odpoved je: Jednoznacne ano - viz uvod RFC1918.

A podle vás z toho ISP plynou nějaké povinnosti? A opět, RFC má jednotlivé části číslované, odkažte na konkrétní část, ze které takové povinnosti plynou. Zatím jste svá tvrzení ničím nedoložil.

2105

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 17:11:37 »

Pane Jirsaku, prectete si ta RFC. Pripadne si je nechte prelozit.

Chápu. Žádná ustanovení, se kterými by ISP byl v rozporu, jste nenašel. Takže zkoušíte argumentační fauly.

Jiste, je tam jen "should", "strongly recommended", "An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above.", "However, they cannot have IP connectivity to any host outside of the enterprise." apod.

Podle vás ISP spadá nebo nespadá pod ten termín enterprise?

2106

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 16:50:33 »

Na hranicni router s udajne verejnou IP zvenci prichazeji pakety se zdrojovou adresou z RFC1918 a vy tomu tleskate.

Netleskám.

Jenom jsem se slušně dotázal, s kterým konkrétně ustanovením nějakého RFC je to v rozporu. Vy se stále vymlouváte, ale konkrétní ustanovení jste neuvedl. Zatím to vypadá, že uváděná RFC neznáte vy a že v nich hledáte něco, co v nich není.

RFC 1918 specifikuje adresy, které nejsou globálně routovatelné. Nevidím tam ale nic, co by říkalo, že se nemohou objevit na vnějším rozhrnaí vašeho hraničního routeru.

Poskytovatel zpusobuje problemy zakaznikovi

Problémy způsobuje nedostatek IPv4 adres. Poskytovatelé se to jen snaží různými způsoby řešit.

nejenze chce zakaznika omezovat v nasazeni u nej adres z RFC1918

Nechce. Ale když nemáte dostatek globálně unikátních adres, tak se holt používají ty neunikátní, a pak logicky dochází ke konfliktům. Můžete si vybrat jakou chcete síť, ale jakmile začnete propojovat přes VPN více sítí, zvyšuje se riziko, že v jiné síti narazíte na konflikt s tím vaším rozsahem.

ale jeste se tvari, ze to je problem zakaznika.

Pokud ten provoz zahazuje zákazníkův firewall, je to problém zákazníka.

To jsou vety.

Ke mají predikát?

Obavam se, ze jste uplne ztratil nit nebo si me s nekym pletete.

Nepletu. Vy tu ISP káráte za to, že nemá dostatek globálně unikátních IPv4 adres, a používá tedy IPv4 adresy, u kterých není zaručena unikátnost, tudíž samozřejmě mohou kolidovat s IPv4 adresami používanými v síti klienta. Jediný rozdíl je v tom, že u některých rozsahů je ta pravděpodobnost vyšší, u některých nižší.

Co jim brani postupne prejit na adresy podle RFC 6598, kdyz historicky maji RFC1918?

A co jim zaručí, že nebudou mít jiného zákazníka, který bude na routeru dropovat adresy dle RFC 6598, nebo je nebude používat ve své síti?

Nehledě na to, že si „postupně přejít“ asi představujete jako Hurvínek válku.

Mimochodem, od vašeho původního „neznalost RFC“ jsme se dostali až k současnému „možná nepoužívají tu nejvhodnější variantu“. Což už je něco úplně jiného.

2107

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 16:27:46 »

Ale ze platici zakaznik ten rozdil vidi, to jste zaregistroval?

Kdyby zákazníci neviděli rozdíl v tom, jestli mají všichni globálně routovatelné IP adresy nebo nemají, nebyl by nedostatek IPv4 adres žádný problém. Jenže IPv4 adresy už dávno došly, internet ale primárně stále funguje na IPv4, takže je potřeba se s nedostatkem IPv4 adres nějak vypořádat. Vaše teoretizování o tom, jak by bylo hezké, kdyby všichni měli veřejné IPv4 adresy, je hezké, akorát bohužel nezapadá do dnešní reality.

2108

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 15:58:56 »

Cemu neni rozumet ve vetach "Private Address Space" a "Shared Address Space" ?

To nejsou věty. A „privátní“ je dost široký pojem, RFC 1918 má 8 stran textu – na to, abyste mohl někoho obviňovat z neznalosti textu, to chce trochu víc, než jen váš vlastní výklad jediného slova.

2109

Server / Re:Centrální ověřování pro Let's Encrypt

« kdy: 04. 12. 2019, 15:07:57 »

Tady to vypadá na špatný návrh.
Zamyslete se ještě jednou a příjdete na to, že centrální opravdu nepotřebujete.

Co je na tom špatného? Mně to naopak připadá správné, o vydávání certifikátů se stará jeden bod, který může např. ověřovat, zda ten, kdo žádá o vydání certifikátu, na to má právo. Nechtěl bych, aby každé zařízení v síti mělo práva měnit DNS, aby mohlo vložit validační záznam pro svou potřebu.

2110

Sítě / Re:Lokální adresy v síti ISP

« kdy: 04. 12. 2019, 14:13:57 »

Obhajovat neznalost RFC (mj. 1918 a 6598)

Můžete být konkrétnější, uvést konkrétní body z uvedených RFC?

Pozadovat synchronizaci pridelovani IP adress napric vsemi zalazniky je opravdu pozoruhodny pocin

Aby se tohle nemuselo dělat, byl vymyšlen jeden globální jmenný prostor internetových adres, tím pádem může mát každé zařízení svou vlastní unikátní adresu. Někteří tvrdí, že to není potřeba, někteří tvrdí, že to potřeba je, že už IPv4 adresy dávno došly a je potřeba tlačit na co největší rozšíření IPv6, aby takovéhle problémy nevznikaly.

2111

Server / Re:Problém s Let's encrypt

« kdy: 04. 12. 2019, 13:17:28 »

Nedá. Pro centrální ověřování je podle mne nejjednodušší používat právě ověřování přes DNS záznamy.

2112

Server / Re:Let's encrypt + wedos + wordpress + angular na subdoméně

« kdy: 04. 12. 2019, 07:52:18 »

To nijak nesouvisí s nastavením serveru, ale s HTML kódem. Máte tam odkazy na zdroje stahované přes HTTP. Důvod, proč se nezobrazí iframe, by měl být vidět v konzoli prohlížeče – může být problém v tom, že se stránka vůbec nenačte, nebo pokud je to v Angularu, možná se jen nespustí nebo havarují skripty a stránka se sice načte, ale je prázdná.

2113

Sítě / Re:Lokální adresy v síti ISP

« kdy: 03. 12. 2019, 22:50:16 »

Pozor, to z puvodniho prispevku nevyplyva. Tahle situace nastava typicky ve chvili, kdy ISP prideluje "verejne IPv4 adresy" (ve skutecnosti provadi 1:1 NAT na nejake NAT gatewayi). Pak skutecne muze dojit k asymetrickemu routovani provozu a nenavazani spojeni (protoze pro onoho uboheho klienta se jedna o neplatne sezeni a jeho firewall ho zahodi). Ma to i svuj nazev: nenakonfigurovany NAT hairpinning.

Autor v puvodnim prispevku pise o verejne IPv4 adrese, ale uz neuvadi, jestli ma adresu primo na serveru, nebo jestli ISP dela 1:1 NAT. Ma-li IPv4 adresu primo na serveru a ISP mu ji routuje, pak nastava ten stav, ktery jsem popsal ja.

Ano, v předchozím příspěvku jsem psal o situaci, kdy je „veřejná" IPv4 adresa řešená NATem 1:1, protože tahle varianta tu popsaná nebyla a je to jedna z možností (tazatel nenapsal, jak přesně má veřejnou IPv4 adresu přidělenou).

Pokud má veřejnou IPv4 adresu přidělený skutečně až tazatelův server a ta IPv4 adresa je v síti ISP normálně routovaná, je podle mne řešení ISP trochu zvláštní, nicméně žádnému standardu neodporuje a chyba je spíš na straně tazatele, který iniciativně na firewallu blokuje i legitimní příchozí provoz (o kterém ovšem nemusel vědět a nemusel vědět, že je legitimní). Navíc ty IPv4 adresy v síti ISP mohou být v konfliktu se sítí tazatele.

Ale v zásadě je pořád problém v tom, že je málo IPv4 adres, a teď se z toho všichni snaží nějak vybruslit s co nejmenšími ztrátami. Druhá otázka je, zda při tom někdo nepáchá víc škod, než je nezbytně nutné.

2114

Sítě / Re:Lokální adresy v síti ISP

« kdy: 03. 12. 2019, 15:26:50 »

Poc na FW nepovolit pripojeni na VPN z lokalnich adres?

Pokud je problém skutečně v tom, že ISP přiděluje veřejné IP adresy pomocí DNATu, ale už nedělá SNAT na provoz ze své sítě, povolení na firewallu nepomůže. Problém je totiž v tom, že odpovědní paket neputuje zpět k NATujícímu zařízení, ale přímo k odesílateli, tudíž se na něm neprovede NAT a odesílatel dostane odpověď s jinou IP adresou, než kterou odeslal – tím pádem si paket nepřiřadí ke správnému spojení a zahodí ho.

Nebo zbývá ještě jedna možnost řešení – pozvat si nějakého odpůrce IPv6, který vám vysvětlí, že NAT přece nezpůsobuje žádné problémy ;-)

2115

Sítě / Re:Lokální adresy v síti ISP

« kdy: 03. 12. 2019, 14:08:54 »

Asi je to klasický problém, kdy na NATu dělají jen DNAT, ale ne SNAT – tím pádem paket od klienta dorazí na NAT, přepíše se cílová adresa, paket přijde k vám, ale má pořád původní zdrojovou adresu klienta. Váš server odpoví na tuto adresu, takže paket se vrací přímo ke klientovi (nejde přes NAT), klient tedy dostane paket se svou cílovou adresou, ale ve zdrojové IP adrese je vaše privátní adresa,  na kterou on ovšem nic neposílal – tudíž paket zahodí.

Správné řešení je, aby si to ISP opravil. Pokud je to pro něj problém (což bych chápal, překonfigurovat NAT pro celou síť nemusí být jednoduché, hlavně na ověření, že tím něco nerozbijí), měli by jiné neplacené řešení navrhnout oni – chyba je na jejich straně. Mimochodem, pokud je problém v tom chybějícím SNATu, záleží na přesné konfiguraci NATu, zda by veřejná IP adresa pomohla – zda dělají SNAT n atu veřejnou IP adresu a zda ho dělají „včas“, aby se uplatnil i tehdy, když paket bude mířit zpět do jejich sítě.

Vy to můžete vyřešit tak, že se klienti vašeho ISP budou připojovat přímo na vaši privátní IP adresu, tím pádem úplně obejdete NAT vašeho ISP.