Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: zett_cz 03. 12. 2019, 09:19:44
-
Řeším situaci s jedním ISP (ne malým). Máme server s veřejnou IP u něj v síti, na serveru je VPN na kterou se klienti běžně připojují. Bohužel klienti ve stejné síti (ISP) jako je server kteří nemají koupenou veřejnou IP se nepřipojí protože se připojují z lokálních IP adres a firewall na serveru je blokne jelikož na WAN nepustí z venku nic z RFC 1918.
Podle ISP je řešením koupě veřejných adres pro klienty. :o
U žádného jiného ISP se mi toto ještě nestalo, je toto řešení OK nebo mám tlačit na ISP aby si síť nastavil jinak?
Díky za podněty!
Z.
-
Hm, no ti ostatni klienti by se meli pripojovat verejnou adresou...V tom ma isp pravdu. Spis je podivne, ze na tu danou verejnou ip se dostavaji klienti z lokalni ip, meli by jit prece pres nejakou verejnou ip jako kdyz jdou smerem do site (NAT). Ta sit je podivna...
-
Poc na FW nepovolit pripojeni na VPN z lokalnich adres? Ja mel neco podobneho. V lokalni siti jsem se na vlastni verejnou adresu nedostal. Problem se vyresil sam, kdyz jsem "lepsi" VR300 TP-Link vymenil za originalni Comtrend modem od WIA prepnuty do PPPoE bridge modu a za nim USG router. Najednou vsechno funguje jak ma.
BTW proc nenapises rovnou, o jakeho ISP jde?
-
Řeším situaci s jedním ISP (ne malým). Máme server s veřejnou IP u něj v síti, na serveru je VPN na kterou se klienti běžně připojují. Bohužel klienti ve stejné síti (ISP) jako je server kteří nemají koupenou veřejnou IP se nepřipojí protože se připojují z lokálních IP adres a firewall na serveru je blokne jelikož na WAN nepustí z venku nic z RFC 1918.
Tak si změňte nastavení firewallu a je hotovo, ne? IMHO je nastavený špatně, když blokuje adresy, které jsou za WAN "legálně"...
-
Klienti u jiných ISP problém nemají, jedou z nějaké veřejné adresy ven a to samozřejmě funguje. Pouze klienti u stejného ISP se připojují z lokálních adres 10.0.0.0/8 i když se připojují na veřejnou IP adresu serveru.
RFC 1918 jasně říká, k čemu jsou ty adresy určeny takže nevím proč by mi měli lézt z internetu na WAN.
Připojení z vlastní LAN na vlastní WAN je jiný problém který mně netrápí...
Jméno ISP není přece podstatné...
Z.
-
Tak si změňte nastavení firewallu a je hotovo, ne? IMHO je nastavený špatně, když blokuje adresy, které jsou za WAN "legálně"...
To si právě nemyslím,...
-
Mam podobnu skusenost, kedy ISP pouziva vo svojej infre 192.168., a zakaznici musia koordinovat svoje lokalne LAN rozsahy, nakolko lezie z 192.168.102.x, do WAN, kde v tom istom rozsahu su servery ISP, a podobne ... No haluz ...
Cize tak, ze v LAN si spravim co chcem nehrozi, nakolko mi nemusia korektne fungovat veci smere do internetu .. :-)
-
Sítím moc nerozumím, ale nedává to smysl:
1. Jestli blokujete na serveru jen lokální adresy (RFC 1918) a ne z CGN (RFC 6598), které adresy mají pak zákazníci? Neptal jste se některého (pokročilejšího) z nich?
2. Je-li CGN za jednou veřejkou a váš server za druhou veřejkou stejného poskytovatele, je jeho povinností tyto 2 adresy proroutovat, nevidím zde žádnou omluvu, proč by tomu tak být nemělo. Spíš to smrdí podezřením, že i váš server je v CGN a na jeho okraji je natován na veřejnou adresu - díval jste se, zda máte opravdu na rozhraní toho serveru veřejku a z jakých adres chodí na server požadavky zákazníků?
3. Necháte si jméno oněch "profesionálů" pro sebe?
-
Mam podobnu skusenost, kedy ISP pouziva vo svojej infre 192.168., a zakaznici musia koordinovat svoje lokalne LAN rozsahy, nakolko lezie z 192.168.102.x, do WAN, kde v tom istom rozsahu su servery ISP, a podobne ... No haluz ...
Cize tak, ze v LAN si spravim co chcem nehrozi, nakolko mi nemusia korektne fungovat veci smere do internetu .. :-)
A jste si jist, ze v podepsane smlouve nestoji, ze ISP znamena Intranet Service Provider? :)
Rozhodne bych sel k nekomu jinemu.
-
Vymente ISP
nebo
Povolte RFC1918 rozsahy ve firewallu
nebo
Presunte server jinam
RFC toho rikaji spoustu, ale nektera pravidla se v dobe vycerpani IPv4 adres nedodrzuji. Vitejte na Internetu roku 2020.
Pro zajimavost: kolik platite ISP za tuto pripojku?
Mimo tema:
ISP si v urcite dobe zvolil, ze jeho klienti budou mit na svych WAN rozhranich adresy z RFC1918. Dnes by pravdepodobne zvolil 100.64.0.0/10, ale tehdy byla situace jina.
ISP kvuli Vam preadresovavat vsechny klienty nebude; provoz od nich k Vam jde, zda se, standardnim routingem (nejblizsi cestou, mimo NAT box tohoto operatora). Z pohledu RFC jsou mozna adresy 10.0.0.0/8 pro privatni site, de facto jsou ovsem v pripade tohoto ISP v "Internetu".
Az (pokud) budou mit klienti i Vas server IPv6 konektivitu, provoz pujde stejnou (primou) cestou, jen adresy budou z GUA bloku (2000::/3).
Je to tedy cele spis o psychologii: hledat zpusob a pripustit si, ze klienti pripojujici se na VPN z 10.0.0.0/8 maji legitimni duvod a port na firewallu otevrit, nebo trvat na RFC 1918 a hledat duvod, proc mit zablokovane pristupy z RFC 1918 adres.
-
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.
-
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 ;-)
-
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.
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.
-
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.
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.
+1
Ještě bych dodal, že Hairpin NATu se za normálních okolností chcete (třeba jako ISP) vyhnout. Hraniční router/firewall/... je zbytečně zatěžován provozem, který má jít pouze v rámci vnitřní sítě.
-
Tak si změňte nastavení firewallu a je hotovo, ne? IMHO je nastavený špatně, když blokuje adresy, které jsou za WAN "legálně"...
To si právě nemyslím,...
Můžete, prosím, upřesnit, co si nemyslíte a proč?
Že ISP používá ve své síti adresy z RFC1918 je jedna věc (a u ISP v ČR naprosto běžná věc), jiná věc je, že zjevně blokujete legální provoz a pak na diskusích brečíte, že Vám to nefunguje...
-
Můžete, prosím, upřesnit, co si nemyslíte a proč?
Že ISP používá ve své síti adresy z RFC1918 je jedna věc (a u ISP v ČR naprosto běžná věc), jiná věc je, že zjevně blokujete legální provoz a pak na diskusích brečíte, že Vám to nefunguje...
Pouzivat ve sve siti muzete adresy libovolne, ale jakmile se jeden vas klient pri kontaktu s druhym jevi tak, ze jeho IP je z rozsahu RFC1918, tak jste naprosti diletanti a podvodnici a hanba vam.
-
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.
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.
+1
Ještě bych dodal, že Hairpin NATu se za normálních okolností chcete (třeba jako ISP) vyhnout. Hraniční router/firewall/... je zbytečně zatěžován provozem, který má jít pouze v rámci vnitřní sítě.
A jak to udělat, aby to nešlo přes edge router?
-
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é.
-
...ISP používá ve své síti adresy z RFC1918 je jedna věc (a u ISP v ČR naprosto běžná věc)...
To zní jako omluva lenosti poskytovatelů...
...zjevně blokujete legální provoz a pak na diskusích brečíte, že Vám to nefunguje...
Mno, problém bude asi v tom, že pod "veřejná adresa" si každý představujeme něco jiného. Já například adresu, která se vyskytuje na rozhraní MÉHO zařízení, ne kdesi v ...
-
A jste si jist, ze v podepsane smlouve nestoji, ze ISP znamena Intranet Service Provider? :)
:D :D :D
-
...Hairpin NATu se za normálních okolností chcete (třeba jako ISP) vyhnout. Hraniční router/firewall/... je zbytečně zatěžován provozem, který má jít pouze v rámci vnitřní sítě.
No jo, když to holt hošani někde vohnou, tak je to pak třeba zase někde rovnat, což překvapivě nemusí být zadarmo...
-
Pořád tu nevidím název toho intranetového poskytovatele...
-
Pouzivat ve sve siti muzete adresy libovolne, ale jakmile se jeden vas klient pri kontaktu s druhym jevi tak, ze jeho IP je z rozsahu RFC1918, tak jste naprosti diletanti a podvodnici a hanba vam.
Není to zvláštní, nejsou podvodníci ani diletanti. Takové nastavení je naprosto normální a dělají to téměř všichni už od chvíle, kdy na internetu není dost veřejných IP adres pro všechno (a zároveň ještě není takový nedostatek, aby se NATovalo úplně všechno).
Máte prostě v síti několik rozhraní/vlan. Pro lepší zákazníky s veřejnou IPv4 adresou máte rozhraní s adresou třeba 192.0.2.1/24, pro horší zákazníky máte rozhraní s adresou 10.0.0.1/24. Celé je to v rámci vaší sítě, všechny směrovače díky směrovacímu protokolu vědí, které adresy jsou pověšeny na kterém routeru, bez ohledu na to, zda jsou veřejné nebo ne. Síť nemá žádné zábrany předávat data mezi veřejnými a privátními adresami, ostatně ty směrovače vůbec nezajímá, jestli ta adresa je napsána v nějakém RFC 1918 nebo ne.
Tímhle způsobem se dřív komunikovalo třeba s management rozhraními, které je potřeba mít dostupné po IP, ale není nutné je mít dostupné i z internetu. Teprve když chcete těm zařízením v síti s privátními adresami zajistit komunikaci se zbytkem internetu, musíte dát na hranici sítě NAT box, který přeloží privátní adresy na veřejné tak, aby se požadovaný provoz měl jak vrátit do naší sítě. Pokud ale někdo s privátní adresou v rámci naší sítě komunikuje s veřejnou adresou v rámci naší sítě, nedává žádný smysl tento provoz honit přes NAT box, protože naše síť moc dobře ví, kde která privátní adresa leží a není tedy žádoucí provoz narušovat vkládáním NATu.
Řešení pro tazatele tedy nejspíš je nakonfigurovat správně firewall, aby počítal s tím, že na WAN straně se mohou legitimně objevit i privátní adresy. Zároveň by se měl ISP zeptat, jaké privátní adresy používá a pro svou VPN použít jiné, protože pokud se objeví stejná adresa na WAN i ve VPN, nebude to fungovat.
-
Není to zvláštní, nejsou podvodníci ani diletanti. Takové nastavení je naprosto normální a dělají to téměř všichni už od chvíle, kdy na internetu není dost veřejných IP adres pro všechno (a zároveň ještě není takový nedostatek, aby se NATovalo úplně všechno).
Máte prostě v síti několik rozhraní/vlan. Pro lepší zákazníky s veřejnou IPv4 adresou máte rozhraní s adresou třeba 192.0.2.1/24, pro horší zákazníky máte rozhraní s adresou 10.0.0.1/24. Celé je to v rámci vaší sítě, všechny směrovače díky směrovacímu protokolu vědí, které adresy jsou pověšeny na kterém routeru, bez ohledu na to, zda jsou veřejné nebo ne. Síť nemá žádné zábrany předávat data mezi veřejnými a privátními adresami, ostatně ty směrovače vůbec nezajímá, jestli ta adresa je napsána v nějakém RFC 1918 nebo ne.
Tímhle způsobem se dřív komunikovalo třeba s management rozhraními, které je potřeba mít dostupné po IP, ale není nutné je mít dostupné i z internetu. Teprve když chcete těm zařízením v síti s privátními adresami zajistit komunikaci se zbytkem internetu, musíte dát na hranici sítě NAT box, který přeloží privátní adresy na veřejné tak, aby se požadovaný provoz měl jak vrátit do naší sítě. Pokud ale někdo s privátní adresou v rámci naší sítě komunikuje s veřejnou adresou v rámci naší sítě, nedává žádný smysl tento provoz honit přes NAT box, protože naše síť moc dobře ví, kde která privátní adresa leží a není tedy žádoucí provoz narušovat vkládáním NATu.
Řešení pro tazatele tedy nejspíš je nakonfigurovat správně firewall, aby počítal s tím, že na WAN straně se mohou legitimně objevit i privátní adresy. Zároveň by se měl ISP zeptat, jaké privátní adresy používá a pro svou VPN použít jiné, protože pokud se objeví stejná adresa na WAN i ve VPN, nebude to fungovat.
a) Tak mozna to nejsou podvodnici :), ale nevzdelanci a diletanti to jsou. Obhajovat neznalost RFC (mj. 1918 a 6598) u ISP je navic chucpe.
b) V dane (spatne a zakaznikem nezavinene) situaci (ktera se ale mohla historicky vyvinout, to zas jo) naopak dava velmi dobry smysl "honit tento provoz pres NAT box", budto navzdy nebo dokud si to sami diletanti nezaridi nejak jinak. Muzou si treba precist RFC6598, kdyz maji malo verejnych IP. Jedna vec je pouzivat adresy dle RFC1918 uvnitr site ISP (to opravdu muzete dle libosti) a uplne jina pridelovat je koncovym zakaznikum.
c) Pozadovat synchronizaci pridelovani IP adress napric vsemi zalazniky je opravdu pozoruhodny pocin :) Vidim uplne zretelne, s jakym nadsenim to kdejaka matka samozivitelka resi :)
-
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.
-
Můžete být konkrétnější, uvést konkrétní body z uvedených RFC?
Cemu neni rozumet ve vetach "Private Address Space" a "Shared Address Space" ?
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.
Nerikejte, ted jeste prosim navod na pripravu caje.
-
Já nevidím rozdíl mezi použitím 10.0.0.0/8 a 100.64.0.0/10 uvnitř sítě "ISP". Oba jsou dostatečně velké a tedy málokdy použité v síti zákazníka. A ani jeden nesmí na internet ...
Je také nutno si uvědomit, že zmíněné RFC je z roku 2012. A většina ISP vznikla v boomu v prvním desetiletí tohoto století. To mají s každým novým RFC vše předělávat?
A jelikož ten boom byl jaký byl, málokdo dokázal okamžitě provozovat síť jen na veřejných adresách (drahé a stejně vlastně málo) a teprve později nasadit něco, o čem se v tu dobu ani neuvažovalo.
A většina těch ISP bylo z IT, nikoliv z telekomunikací, tedy nápady jako PPPoE je naprosto minuly.
Zpětně se dobře kritizuje.
Pokud je server v takové síti, tak se prostě bude muset přizpůsobit on. Ať už rekonfigurací, nebo odchodem jinam.
-
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.
-
Já nevidím rozdíl mezi použitím 10.0.0.0/8 a 100.64.0.0/10 uvnitř sítě "ISP". Oba jsou dostatečně velké a tedy málokdy použité v síti zákazníka. A ani jeden nesmí na internet ...
Ale ze platici zakaznik ten rozdil vidi, to jste zaregistroval?
Zpětně se dobře kritizuje.
Nekritizuji zpetne, kritizuji dnesni pristup.
Pokud je server v takové síti, tak se prostě bude muset přizpůsobit on. Ať už rekonfigurací, nebo odchodem jinam.
Chapu, poskytovatel prece nebude pro zakaznika neco delat, ze?
-
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.
-
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.
To vase "trochu vic" je cele toto vlakno. Na hranicni router s udajne verejnou IP zvenci prichazeji pakety se zdrojovou adresou z RFC1918 a vy tomu tleskate. Poskytovatel zpusobuje problemy zakaznikovi a nejenze chce zakaznika omezovat v nasazeni u nej adres z RFC1918, ale jeste se tvari, ze to je problem zakaznika.
PS To jsou vety.
PPS Mam se prepnout do modu JIRSAK?
-
Zpětně se dobře kritizuje.
Nekritizuji zpetne, kritizuji dnesni pristup.
Kritizujete dnešní přístup, ale jindy, kdy se vám to zrovna hodí, předhodíte nám tu hypotetickou matku samoživitelku, která rozhodně nebude nic překonfigurovávat:
c) Pozadovat synchronizaci pridelovani IP adress napric vsemi zalazniky je opravdu pozoruhodny pocin :) Vidim uplne zretelne, s jakym nadsenim to kdejaka matka samozivitelka resi :)
Právě kvůli téhle matce mají ISP stále ve své síti adresy podle RFC 1918 namísto adres podle RFC 6890
-
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.
Obavam se, ze jste uplne ztratil nit nebo si me s nekym pletete.
-
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.
To vase "trochu vic" je cele toto vlakno. Na hranicni router s udajne verejnou IP zvenci prichazeji pakety se zdrojovou adresou z RFC1918 a vy tomu tleskate. Poskytovatel zpusobuje problemy zakaznikovi a nejenze chce zakaznika omezovat v nasazeni u nej adres z RFC1918, ale jeste se tvari, ze to je problem zakaznika.
Ty pakety nepřichází z venčí, ale ze sítě ISP. Je s nimi možné bez problému obousměrně komunikovat, tak kde je problém?
Proskimoval jsem RFC 1918, nenašel jsem nic, co by naznačovalo, že není možné komunikovat mezi veřejnými a privátními adresami bez NATu.
I z pozice majitele toho hraničního routeru budu radši, když mi provoz bude chodit z privátních adres přímo, třeba proto, že budu moci snáze identifikovat konkrétní původce toho provozu. Nevidím důvod, proč by mi to mělo vadit.
-
Právě kvůli téhle matce mají ISP stále ve své síti adresy podle RFC 1918 namísto adres podle RFC 6890
Ja vam nerozumim. Co jim brani postupne prejit na adresy podle RFC 6598, kdyz historicky maji RFC1918? Pocinaje treba temi zakazniky, kterym adresy dle RFC1918 zvenci jejich routeru vadi?
-
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.
-
Ty pakety nepřichází z venčí, ale ze sítě ISP. Je s nimi možné bez problému obousměrně komunikovat, tak kde je problém?
Pro zakaznika pakety prichazi zvenci, nevidim zde zadny prostor pro diskusi - viz nize.
Proskimoval jsem RFC 1918, nenašel jsem nic, co by naznačovalo, že není možné komunikovat mezi veřejnými a privátními adresami bez NATu.
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.
I z pozice majitele toho hraničního routeru budu radši, když mi provoz bude chodit z privátních adres přímo, třeba proto, že budu moci snáze identifikovat konkrétní původce toho provozu. Nevidím důvod, proč by mi to mělo vadit.
Ale vsechny hranicni routery alespon prozatim nejsou vase nebo ano?
-
Pane Jirsaku, prectete si ta RFC. Pripadne si je nechte prelozit.
-
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?
-
Chápu. Žádná ustanovení, se kterými by ISP byl v rozporu, jste nenašel. Takže zkoušíte argumentační fauly.
To jsou vase techniky, me do toho nezatahujte.
Podle vás ISP spadá nebo nespadá pod ten termín enterprise?
Otazka ale stoji jinak: Spada klient pod termin enterprise?
A odpoved je: Jednoznacne ano - viz uvod RFC1918.
-
Sítím moc nerozumím, ale nedává to smysl:
1. Jestli blokujete na serveru jen lokální adresy (RFC 1918) a ne z CGN (RFC 6598), které adresy mají pak zákazníci? Neptal jste se některého (pokročilejšího) z nich?
2. Je-li CGN za jednou veřejkou a váš server za druhou veřejkou stejného poskytovatele, je jeho povinností tyto 2 adresy proroutovat, nevidím zde žádnou omluvu, proč by tomu tak být nemělo. Spíš to smrdí podezřením, že i váš server je v CGN a na jeho okraji je natován na veřejnou adresu - díval jste se, zda máte opravdu na rozhraní toho serveru veřejku a z jakých adres chodí na server požadavky zákazníků?
3. Necháte si jméno oněch "profesionálů" pro sebe?
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.
-
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.
-
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?
-
Tak si změňte nastavení firewallu a je hotovo, ne? IMHO je nastavený špatně, když blokuje adresy, které jsou za WAN "legálně"...
To si právě nemyslím,...
Můžete, prosím, upřesnit, co si nemyslíte a proč?
Že ISP používá ve své síti adresy z RFC1918 je jedna věc (a u ISP v ČR naprosto běžná věc), jiná věc je, že zjevně blokujete legální provoz a pak na diskusích brečíte, že Vám to nefunguje...
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.
-
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.
-
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?
Tak jak jsem již psal... Z mého pohledu mám za WAN celý internet a odtud mi skutečně dovnitř nic z RFC 1918 nepoleze stejně tak jako neleze z RFC 1918 nic od nás. Když ten rozsah povolím tak tu mám tolik šumu v logu že "nevím" co s tím. Pro mně za mně ať to má takto ISP nakonfigurované, ale pokud jeho zákazníci s adresami z RFC 1918 mohou do internetu přes nějakou veřejnou IP adresu tak na mou veřejnou adresu polezou taky tak.
-
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.
Tak jistěže nezáleží na tom co si myslím nicméně slovy RFC já mám za WAN public a ne private...
-
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.
-
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.
Evidentně tam mám public, čtu IP na WAN 46.1x3.x0x.1yy.
-
A v traceroute do Internetu mate jen verejne IPv4 adresy?
-
Evidentně tam mám public, čtu IP na WAN 46.1x3.x0x.1yy.
Psal jste o tom, co máte za WAN rozhraním, ne jakou IP adresu máte na něm.
Ale hlavně, pokud chcete dokázat, že ISP dělá něco špatně, měl byste najít to ustanovení RFC, které porušuje. Chápu, že vám vadí i to, že narušuje vaši představu, kterou jste měl o privátních IP adresách – ale to ještě neznamená, že dělá něco špatně.
-
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.
Teda, takhle sproste lhat, to je dno, Jirsaku. Neumet prohravat v pokrocilem veku je trapne :) Cemu presne jsi nerozumel ve vete "An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above." ?
-
Psal jste o tom, co máte za WAN rozhraním, ne jakou IP adresu máte na něm.
Ale hlavně, pokud chcete dokázat, že ISP dělá něco špatně, měl byste najít to ustanovení RFC, které porušuje. Chápu, že vám vadí i to, že narušuje vaši představu, kterou jste měl o privátních IP adresách – ale to ještě neznamená, že dělá něco špatně.
Copak, sam jsi navrhoval adresni plan nejakeho pokripleneho ISP?
-
Teda, takhle sproste lhat, to je dno, Jirsaku.
Já bych to, co předvádíte, nenazýval lhaním. Jenom se vykrucujete.
Neumet prohravat v pokrocilem veku je trapne :)
Na věku nezáleží. Ale když nejste schopen u osmistránkového textu ukázat na konkrétní ustanovení, ale pořád nepřiznáte, že v textu nic takového není, to už trapné je.
Cemu presne jsi nerozumel ve vete "An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above." ?
Potřebujete tu větu přeložit? zett_cz potřebuje adresu pro externí komunikaci a dostává veřejnou IP adresu 46.1x3.x0x.1yy. Veřejná IP adresa 46.1x3.x0x.1yy nepatří do těch třech privátních bloků vyjmenovaných v RFC.
Copak, sam jsi navrhoval adresni plan nejakeho pokripleneho ISP?
Copak? No jenom to, že jsem po vás chtěl jenom takovou maličkost, abyste v RFC ukázal na konkrétní ustanovení, které podle vás ten ISP porušuje. A vy se od té doby akorát vymlouváte a urážíte. Úplně zbytečně, protože každý, kdo čte tuhle diskusi, dávno ví, že jste konkrétní porušované ustanovení RFC neodkázal, takže akorát vypadáte jako srab, který neumí přiznat omyl.
-
Potřebujete tu větu přeložit? zett_cz potřebuje adresu pro externí komunikaci a dostává veřejnou IP adresu 46.1x3.x0x.1yy. Veřejná IP adresa 46.1x3.x0x.1yy nepatří do těch třech privátních bloků vyjmenovaných v RFC.
No jenom to, že jsem po vás chtěl jenom takovou maličkost, abyste v RFC ukázal na konkrétní ustanovení, které podle vás ten ISP porušuje. A vy se od té doby akorát vymlouváte a urážíte. Úplně zbytečně, protože každý, kdo čte tuhle diskusi, dávno ví, že jste konkrétní porušované ustanovení RFC neodkázal, takže akorát vypadáte jako srab, který neumí přiznat omyl.
Ja to teda napisu jeste jednou naposled, chapu, ze to muze nekomu trvat dele, nez to pochopi: "An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above."
Oriskem zustava, co s vasi utkvelou predstavou, ze RFC1918 je jen o zett_cz. Na to bude potreba odbornik z uplne jineho oboru. Mozna, ze by mohl zaroven vyresit i vasi dalsi obsesi - ze jsem vasim sluhou a mam vam hledat cislovani ruznych textu.
-
No, jen ta věta z RFC1918 "An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above." má návaznost na předchozí text a ten v podstatě říká, že pokud někdo požádá o přidělení IP adres od IANA a spol, tak nikdy nedodje k přidělení adres z těch tří bloků privátních adres.
Jinak to RFC také říká, že uvnitř dané organizace má fungovat komunikace mezi hosty, kteří používají globální adresy i ty lokální. Takže ten druh provozu je v pořádku. Jen ty stroje s privátní adresou, pokud chtějí do globálního internetu, tak musí jít přes něco, co už bude mít globální adresu (NAT nebo proxy).
Ano, dneska by bylo vhodnější, aby ISPík používal pro klienty bez veřejek 100.64/10 - někteří přešli, někteří to používají jen pro nové linky, někteří to ignorují a jedou dál po staru - takových ISP jsou v ČR tisíce.
-
No vidíš, já bych řekl, že pod tento termín právě kvůli tomu úvodu nespadá. Provozovatel VPN serveru neprovozuje síť autonomně. Je součásti sítě toho ISP, který už tu síť tak se vší pravděpodobností provozuje. Nebo lze asi říci jinak - má svoje vlastní AS.
Otazka ale stoji jinak: Spada klient pod termin enterprise?
A odpoved je: Jednoznacne ano - viz uvod RFC1918.
-
Ja to teda napisu jeste jednou naposled, chapu, ze to muze nekomu trvat dele, nez to pochopi: "An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above."
K tomu, abyste tu větu pochopil, vám ale nepomůže, když jí budete jen pořád dokola kopírovat. Musíte si ji také přečíst.
-
Tak jak jsem již psal... Z mého pohledu mám za WAN celý internet a odtud mi skutečně dovnitř nic z RFC 1918 nepoleze stejně tak jako neleze z RFC 1918 nic od nás. Když ten rozsah povolím tak tu mám tolik šumu v logu že "nevím" co s tím.
Chcete říct, že šumu z adres RFC1918 je mnohem víc než šumu ze zbytku veřejného internetu? Pokud ano, tak je skutečně v síti ISP asi něco špatně.
Pro mně za mně ať to má takto ISP nakonfigurované, ale pokud jeho zákazníci s adresami z RFC 1918 mohou do internetu přes nějakou veřejnou IP adresu tak na mou veřejnou adresu polezou taky tak.
Proč tohle chcete? Máte jedinečnou možnost logovat skutečnou adresu zdroje provozu, máte možnost přímého obousměrného spojení bez prostředníků. A vy byste místo toho radši, aby tam ISP strčil NAT, za který své zákazníky schová a kvalitu spojení tím poškodí a jediný argument pro to je, že se vám nelíbí zdrojové adresy na vstupu. To je dost chabý argument pro to, aby kvůli němu ISP přebudovával svou síť.
Mimochodem, v RFC 1918 se také píše, že:
Addresses within this private address space will only be unique within the enterprise, or the set of enterprises which choose to cooperate over this space so they may communicate with each other in their own private internet.
Což je přesně tento případ, tedy až na to, že s ISP na koordinaci privátních rozsahů aktivně nespolupracujete (ale měli byste).
-
Mam ten dojem, ze se tady diky osobnimu sporu pana messagebus s panem Jirsakem straci samotna podstata dotazu.
Tazatel resi na foru svou neschopnost nastavit si firewall. Kdysi jsem mel pripojeni od jednoho ISP s verenou IP a na serveru mi bezela sluzba. Mel jsem na firewallu zakazany vstup adres ze subnetu urcenych pro lokalni site. Pak prisel clovicek, ktery chtel vyuzit muj server. Ja nelenil zavolal poskytovateli, dotazal jsem se na jeho subnet, vysvetlil mu, proc to chci vedet, on mi jej rekl a ja povolil. HOTOVO. Dnes mam internet od jineho ISP, ktery dela NAT neverejnych a ja vidim na svem WAN vzdy jen verejnou IP. Jde jen o komunikaci s ISP a o nastaveni.
Takze ze mne je to v poradku. ISP ma svou sit nejak udelanou a tak to je. Pokud nejsi ochotny komunikovat misto na foru se zastupcem ISP, pak to bude pro tebe vzdy tezske.
Mimochodem ted mam u jednoho cloveka od tamnejsiho ISP verejnou zpusobem NAT 1:1 a to je teprve prasarna a hajzlovina. Komunikace vramci jeho site nejde a odmita s tim cokoliv delat. Jo a ja to na foru neresil komunikuju s ISP. Dopadlo to tak ze uz mam pozadavek jinde kde jsem si pred tim overil se obch. zastupcem ISP jejich strategii a funkcnost.
-
Právě kvůli téhle matce mají ISP stále ve své síti adresy podle RFC 1918 namísto adres podle RFC 6890
??? Měl jsem za to, že rozhraní k poskytovateli obvykle dostává adresu z DHCP, tj. automaticky...
-
Mam ten dojem, ze se tady diky osobnimu sporu pana messagebus s panem Jirsakem straci samotna podstata dotazu.
Tazatel resi na foru svou neschopnost nastavit si firewall. Kdysi jsem mel pripojeni od jednoho ISP s verenou IP a na serveru mi bezela sluzba. Mel jsem na firewallu zakazany vstup adres ze subnetu urcenych pro lokalni site. Pak prisel clovicek, ktery chtel vyuzit muj server. Ja nelenil zavolal poskytovateli, dotazal jsem se na jeho subnet, vysvetlil mu, proc to chci vedet, on mi jej rekl a ja povolil. HOTOVO. Dnes mam internet od jineho ISP, ktery dela NAT neverejnych a ja vidim na svem WAN vzdy jen verejnou IP. Jde jen o komunikaci s ISP a o nastaveni.
Takze ze mne je to v poradku. ISP ma svou sit nejak udelanou a tak to je. Pokud nejsi ochotny komunikovat misto na foru se zastupcem ISP, pak to bude pro tebe vzdy tezske.
Mimochodem ted mam u jednoho cloveka od tamnejsiho ISP verejnou zpusobem NAT 1:1 a to je teprve prasarna a hajzlovina. Komunikace vramci jeho site nejde a odmita s tim cokoliv delat. Jo a ja to na foru neresil komunikuju s ISP. Dopadlo to tak ze uz mam pozadavek jinde kde jsem si pred tim overil se obch. zastupcem ISP jejich strategii a funkcnost.
Bohužel u nás není v zásadě žádný výběr z mnoha ISP a proto jsme se s místním poskytovatelem dohodli na veřejné IP, nějaké rychlosti a optiku jsme si od něj natáhli sami. Řeč o připojení do LAN nikde nebyla a nikdo neřešil jak komunikují stroje uvnitř sítě ISP. V momentě kdy jsme kvůli narůstajícímu počtu externích spolupracovníků zřídili VPN se zjistilo, že někteří se na VPN nepřipojí a proč se nepřipojí. Firewall byl původně nastavený tak, že ven ani dovnitř nešlo nic z RFC1918, je to určité bezpečnostní nastavení které léta aplikuji. Samozřejmě teď je FW nastavený tak aby klienti mohli pracovat. Jestli je tu někdo neschopný tak to určitě nebudu já. Jen jsem se zeptal jestli je u ISP "obvyklá" taková konfigurace a jestli ho mám tlačit do změny a nebo se na to vybodnout a nechat to být...
-
Právě kvůli téhle matce mají ISP stále ve své síti adresy podle RFC 1918 namísto adres podle RFC 6890
??? Měl jsem za to, že rozhraní k poskytovateli obvykle dostává adresu z DHCP, tj. automaticky...
Rozhodně to není automatické. Ano, kde se WAN strana k ISP konfiguruje nějak rozumně (DHCP / PPPoE / TR-069), tak to ISPík může změnit bez interakce s koncovým zákošem. Ale upřimně, když se podívám, tak hodně alternaticních ISP jede statickou ruční konfiguraci WAN portu zákazníka - tento mechanismus totiž klade nejméně nároků na další logistiku uvnitř sítě ISP. Provozování věcí jako DHCP server, PPPoE koncentrátor, TR server, to je vše rocket science, která přesahuje jejich schopnosti (vždyť řada z nich nemá ani vlastní DNS resolver pro zákazníky a forwardují DNS někam dál, třeba na 8.8.8.8 :-).
-
Proč tohle chcete? Máte jedinečnou možnost logovat skutečnou adresu zdroje provozu, máte možnost přímého obousměrného spojení bez prostředníků. A vy byste místo toho radši, aby tam ISP strčil NAT, za který své zákazníky schová a kvalitu spojení tím poškodí a jediný argument pro to je, že se vám nelíbí zdrojové adresy na vstupu. To je dost chabý argument pro to, aby kvůli němu ISP přebudovával svou síť.
Taky si říkám, že zett_cz docela riskuje, že si to tady přečte nějaký technik od jeho ISP, a upraví konfiguraci speciálně pro něj tak, aby vyhovovala Zettovým představám. Tedy sebere mu veřejnou IP adresu z jeho WAN, přidělí mu tam privátní IP adresu a NAT z té veřejné IP adresy bude dělat někde na svém zařízení. Pokud je to nějaký menší ISP, udělat navíc jedno v pravidlo v NATu nebude problém, zett_cz bude mít přesně to, co chce, akorát bude mít ve výsledku horší službu, protože nebude mít veřejnou IP adresu routovanou ale NATovanou.
-
Jen jsem se zeptal jestli je u ISP "obvyklá" taková konfigurace a jestli ho mám tlačit do změny a nebo se na to vybodnout a nechat to být...
Jak zaznělo, je to běžný stav ke smíření se s ním. A dokonce je to ještě ta lepší varianta. Dají se také najít "taky ISP", kde vůbec nefunguje, aby spolu mohli zákazníci komunikovat mezi svými koncovými přípojkami přímo. Musí jít s použitím nějakého prostředníka mimo síť daného ISP.
-
Tímto bych debatu ukončil, já mám vše funkční, ISP ke změně nedotlačím, změnit ISP taky není jednoduché. Díky všem za diskuzi.
Z.
-
Jestli je tu někdo neschopný tak to určitě nebudu já. Jen jsem se zeptal jestli je u ISP "obvyklá" taková konfigurace a jestli ho mám tlačit do změny a nebo se na to vybodnout a nechat to být...
Pokud byste chtěl tlačit ISP do změny, bylo by vhodné najít to ustanovení RFC, které údajně ISP porušuje. Zatím je to „sice je vše v souladu s RFC, ale mně a ještě jednomu člověku na diskusním fóru se to velmi nelíbí“, což pro ISP asi pádný argument nebude.
A ještě než začnete na toho ISP tlačit, rozmyslete si, za to vaše „nelíbí se mi to“ vám vážně stojí za to, abyste si dobrovolně nechal zhoršit službu z routované veřejné IP adresy na NATovanou. Protože kvůli vám ISP všem vašim spolupracovníkům zdarma veřejnou IP adresu dávat nebude, NATovat tu vaši veřejnou IP adresu by pro něj bylo nejlevnější řešení. (Kdysi po internetu kolovala historka ze supportu nějakého ISP, kde si zákazník stěžoval, že má moc nízký ping a chtěl ho zvýšit – čemuž technici s radostí vyhověli.)
-
Jestli je tu někdo neschopný tak to určitě nebudu já. Jen jsem se zeptal jestli je u ISP "obvyklá" taková konfigurace a jestli ho mám tlačit do změny a nebo se na to vybodnout a nechat to být...
Pokud byste chtěl tlačit ISP do změny, bylo by vhodné najít to ustanovení RFC, které údajně ISP porušuje. Zatím je to „sice je vše v souladu s RFC, ale mně a ještě jednomu člověku na diskusním fóru se to velmi nelíbí“, což pro ISP asi pádný argument nebude.
A ještě než začnete na toho ISP tlačit, rozmyslete si, za to vaše „nelíbí se mi to“ vám vážně stojí za to, abyste si dobrovolně nechal zhoršit službu z routované veřejné IP adresy na NATovanou. Protože kvůli vám ISP všem vašim spolupracovníkům zdarma veřejnou IP adresu dávat nebude, NATovat tu vaši veřejnou IP adresu by pro něj bylo nejlevnější řešení. (Kdysi po internetu kolovala historka ze supportu nějakého ISP, kde si zákazník stěžoval, že má moc nízký ping a chtěl ho zvýšit – čemuž technici s radostí vyhověli.)
Veřejnou IP adresu mi nikdo zdarma nedal.
Stále jsem přesvědčen, že RFC1980 mluví o intranetu - uzavřených podnikových sítích a vzhledem k tomu, že poskytovatel připojení do internetu (ISP) takových sítí může připojit stovky nebo tisíce nemají tyto adresy co hledat za mým WAN rozhraním které je dveřmi do internetu (public) nikoliv intranetu (private).
Tímto vám ještě jednou děkuji za přínosnou a plodnou diskuzi ale nepřesvědčil jste mne.
Z.
-
Pokud byste chtěl tlačit ISP do změny, bylo by vhodné najít to ustanovení RFC, které údajně ISP porušuje. Zatím je to „sice je vše v souladu s RFC, ale mně a ještě jednomu člověku na diskusním fóru se to velmi nelíbí“, což pro ISP asi pádný argument nebude.
A ještě než začnete na toho ISP tlačit, rozmyslete si, za to vaše „nelíbí se mi to“ vám vážně stojí za to, abyste si dobrovolně nechal zhoršit službu z routované veřejné IP adresy na NATovanou. Protože kvůli vám ISP všem vašim spolupracovníkům zdarma veřejnou IP adresu dávat nebude, NATovat tu vaši veřejnou IP adresu by pro něj bylo nejlevnější řešení. (Kdysi po internetu kolovala historka ze supportu nějakého ISP, kde si zákazník stěžoval, že má moc nízký ping a chtěl ho zvýšit – čemuž technici s radostí vyhověli.)
Proc vlastne sem vubec prispivate, kdyz tomu vubec nerozumite?
PS Fakt, ze vas vubec napadne, ze by mu mel ISP sebrat jeho verejnou IP adresu, kdyz mu vadi, ze ISP nedodrzuje RFC u jinych klientu, nesvedci o vasich dobrych charakterovych vlastnostech.
-
Stále jsem přesvědčen, že RFC1980 mluví o intranetu - uzavřených podnikových sítích a vzhledem k tomu, že poskytovatel připojení do internetu (ISP) takových sítí může připojit stovky nebo tisíce nemají tyto adresy co hledat za mým WAN rozhraním které je dveřmi do internetu (public) nikoliv intranetu (private).
V roce 1996, kdy RFC 1918 vyšlo, to tak skutečně bylo myšleno, protože tehdy bylo běžné, že ISP pracovali pouze s veřejnými adresami. Carrier grade NAT přišel až mnohem později. Skutečně by bylo lepší, kdyby provozovatelé CGN používali jako privátní adresy ty podle RFC 6598 a byl tak vyloučen konflikt s privátními adresami v koncových sítích, ale spousta ISP zavedla CGN ještě v době, kdy RFC 6598 nebylo a nemají motivaci celou síť přeadresovávat. I tak by vám ale na WAN rozhraní s veřejnou IP adresou chodil provoz z neveřejných IP adres, jen by to nebyly ty rozsahy z RFC 1918.
…kdyz mu vadi, ze ISP nedodrzuje RFC u jinych klientu…
Už jste konečně našel něco v nějakém RFC, co tento ISP nedodržuje? Já stále čekám…
-
V roce 1996, kdy RFC 1918 vyšlo, to tak skutečně bylo myšleno, protože tehdy bylo běžné, že ISP pracovali pouze s veřejnými adresami. Carrier grade NAT přišel až mnohem později. Skutečně by bylo lepší, kdyby provozovatelé CGN používali jako privátní adresy ty podle RFC 6598 a byl tak vyloučen konflikt s privátními adresami v koncových sítích, ale spousta ISP zavedla CGN ještě v době, kdy RFC 6598 nebylo a nemají motivaci celou síť přeadresovávat. I tak by vám ale na WAN rozhraní s veřejnou IP adresou chodil provoz z neveřejných IP adres, jen by to nebyly ty rozsahy z RFC 1918.
Nepiste sem prosim lzi. Adresy podle RFC6598 nejsou privatni ale sdilene. Adresy podle RFC1918 jsou privatni a ISP je muze ve sve siti pouzivat dle libosti, akorat je nema co pridelovat klientum, protoze to vytvari kolizni situace. Jak lze omlouvat ISP, ze generuje bordel protoze "nema motivaci" dodrzovat doporucene postupy IETF? Proc by mu melo vadit, ze mu chodi na WAN rozhrani nejake neverejne adresy, kdyby mohl normalne nastavit firewall?
Už jste konečně našel něco v nějakém RFC, co tento ISP nedodržuje? Já stále čekám…
Vse relevannti jiz bylo napsano. ISP nema co pridelovat svym klientum privatni adresy. Pokud jste se rozhodl ignorovat zjevne veci, je to vas problem, cekejte dale.
-
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.
Evidentně tam mám public, čtu IP na WAN 46.1x3.x0x.1yy.
Problém je jednoduše v tom, že tomu nerozumíte...
To, že Vám ISP routuje veřejnou IP v rámci svého AS neznamená, že "máte za WAN public". Za WAN máte evidentně privátní síť Vašeho ISP.
Na interface toho zařízení (pokud to podporuje) můžete mít ve stejnou chvíli terminovány adresy z public i private rozsahů. To je naprosto normální a není na tom nic špatně. Pak budete říkat co? Že za WAN máte napůl public a napůl private?
-
ISP nema co pridelovat svym klientum privatni adresy. Pokud jste se rozhodl ignorovat zjevne veci, je to vas problem, cekejte dale.
Takže jste postupně od „diletanti a podvodníci“ přes „nevzdělanci a diletanti“ a „porušují RFC“ dospěl až k tomu, že vlastně žádné RFC neporušují, pouze jednají v rozporu s něčím, co vám je zjevné. Já bych to uzavřel, že ten nevzdělanec a diletant jste tu vy.
-
Takže jste postupně od „diletanti a podvodníci“ přes „nevzdělanci a diletanti“ a „porušují RFC“ dospěl až k tomu, že vlastně žádné RFC neporušují, pouze jednají v rozporu s něčím, co vám je zjevné. Já bych to uzavřel, že ten nevzdělanec a diletant jste tu vy.
Zas mi neco podsouvas? Radeji si nech prelozit toto: An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above.
-
messagebus: Vytrháváš z toho RFC jednu větu z kontextu. Podstatná je i ta hned předchozí. Nic to neříká o tom, že ISP na WAN port tvého CPE nemůže přidělit IPčko ze seznamu z RFC1918. Říká to jen, že IANA/RIPE/.. nepřidělí IP z těchto segmentů někomu k užívání.
Ano, bylo by lepší, aby ISP použil ty 100.64/10 dle RFC6598. Nicméně i toto RFC v čísti 3 uvádí, že ISP může pro CPE používat IP dle RFC1918 pokud ví, co dělá. :-)
Nicméně původní tazatel se s tím už vyrovnal a nějak smířil. Může navrhnout ISPíkovi, aby přešel na to 100.64/10 nebo zkusit hledat připojneí u jiného.
Opravdu si myslím, že třeba variantu, aby v tomto případě musel ISP uplatnit CGNAT, aby na můj router s veřejkou přišel od ostatních lokálních zákošů jen veřejka, tak může nadělat i problémy. Některé VPNky nemusí rozdýchat, pokud se na server spojuje víc klientů schovaných za stejný NAT. Např. PPTP (snad už nikdo nepoužívá) nebo některé implementace IPsec. Průchod přes NAT může být delší než přímá cesta a může se i stát, že při té přímé cestě obcházím nejen NAT, ale u některých ISP i omezování rychlosti, takže takové spojení jede na max kapacity drátů, místo ořezání na placený tarif atd.
-
messagebus: Vytrháváš z toho RFC jednu větu z kontextu. Podstatná je i ta hned předchozí. Nic to neříká o tom, že ISP na WAN port tvého CPE nemůže přidělit IPčko ze seznamu z RFC1918. Říká to jen, že IANA/RIPE/.. nepřidělí IP z těchto segmentů někomu k užívání.
Ano, bylo by lepší, aby ISP použil ty 100.64/10 dle RFC6598. Nicméně i toto RFC v čísti 3 uvádí, že ISP může pro CPE používat IP dle RFC1918 pokud ví, co dělá. :-)
Az na to, ze enterpise neni ISP - je tam uvedena definice i priklady vetsich enterprise - letiste, banka...
A hlavne v te predchozi vete neni IANA, ale Internet Registry - seznam IR pro CZ: https://www.ripe.net/membership/indices/CZ.html (https://www.ripe.net/membership/indices/CZ.html) Coz jsou prave ISPcka (tedy nejsou tam ti ruzni pokoutni s antenama z plechovek, co vsemu rozumi lepe nez IETF)
Nicméně původní tazatel se s tím už vyrovnal a nějak smířil. Může navrhnout ISPíkovi, aby přešel na to 100.64/10 nebo zkusit hledat připojneí u jiného.
Me na tom fascinuje, jak velky problem je proste rict "aha, sakra, to je dobra prilezitost to zacit delat lepe".
-
Zas mi neco podsouvas? Radeji si nech prelozit toto: An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above.
Proč bych vám něco podsouval? Vy se znemožňujete úplně sám. Pořád dokola sem kopírujete jednu větu, kterou jste pořád ještě nepochopil. zett_cz požaduje IP adresu pro externí konektivitu, a dostal jí. Jiní klienti toho ISP nepožadují IP adresu pro externí konektivitu, a nedostali ji. Žádný problém v tom není, ISP nejedná v rozporu s RFC, jenom vy pořád melete nesmysly a kopírujete sem pořád dokola jednu větu, o které víte, že žádné vaše tvrzení nedokazuje.
Bohužel vás zradilo to, že jste dost chytrý na to, abyste si uvědomil, že nemáte pravdu, ale už ne dost na to, abyste svou chybu přiznal. Kdybyste byl přesvědčen, že máte pravdu, byl byste konkrétní, v čem přesně ISP jedná v rozporu s tou větou. Jenže vy dobře víte, že ISP s ní není v rozporu, a že kdybyste se pokusil ukázat na konkrétní porušení, musel byste tvrdit něco, co v té větě není. Takže tu jen dokola opakujete nesmysly, že si tu větu mám přečíst nebo si ji mám nechat přeložit – snažíte se argumentačními klamy vyvolat dojem, že vy tomu rozumíte a já ne. Bohužel jsou ty vaše argumentační fauly příliš průhledné a je příliš nápadné, že jste ani napopáté nedokázal napsat, co a jak ISP konkrétně porušuje.
Az na to, ze enterpise neni ISP - je tam uvedena definice i priklady vetsich enterprise - letiste, banka...
A v čem přesně ten ISP nesplňuje onu definici?
Me na tom fascinuje, jak velky problem je proste rict "aha, sakra, to je dobra prilezitost to zacit delat lepe".
Vždyť vy ani nejste ochoten přiznat, že jste se zmýlil – což je trivialita ve srovnání s přečíslováním celé sítě.
-
Az na to, ze enterpise neni ISP - je tam uvedena definice i priklady vetsich enterprise - letiste, banka...
A hlavne v te predchozi vete neni IANA, ale Internet Registry - seznam IR pro CZ: https://www.ripe.net/membership/indices/CZ.html (https://www.ripe.net/membership/indices/CZ.html) Coz jsou prave ISPcka (tedy nejsou tam ti ruzni pokoutni s antenama z plechovek, co vsemu rozumi lepe nez IETF)
Definice "enterprise" je uvedena hned v 1. bodu RFC1918 - je to jakýkoliv subjekt, který se rozhodl provozovat síť s TCP/IP protokolem a řídit si v něm přidělování adres. To splňuje ta banka, letiště, ISP i domácí LAN Franty z Horní/Dolní.
Že je tomu tak, dosvědčuje i bod 3 v RFC6598, kde se rozebírá používání IP dle RFC1918 v přístupové síti ISP ajejich použití na WAN straně zákaznických CPE.
Ehm, ano, ten seznam LIRů jsou typičtí ISP od kterých získáte IPčka, třeba EQUA banka, Sberbank CZ a další. Jde o seznam členů RIPE, co tam vstouili, aby pro sebe získali obvkyle nějaké IPv4/IPv6/AS v nějakém větším rozsahu, než připouštelo PI (samozřejmě je tam i řada ISP nebo sdružení několika ISP). Pokud jsem ISP a nemám ambice mít vlastní IP/AS, tak tam nelezu a využiji IP, který jsem si vyjendal od svého upstreamu z jeho přídělu (stav většiny alternativních ISP v ČR).
Jinak opět, ta část RFC1918 hovoří o procesu přidělení globálních IP pro provoz uvnitř mé sítě, takže chci přidělit prostřednictvím LIRa IPčka pro použití uvnitř mé sítě (řekněmě LAN strana), které pak budou globálně dosažitelné zvenčí. A RFC říká, ře nedostanu přiděleny IP z těch privátních segmentů. Jaké IP se použije na spojovací lince mezi mou sítí a mým ISP (řekněmě WAN strana), tak to je věc zcela jiná, klidně to mohou být link-local adresy, který platí jen na tom spojení a nikam dál nejdou (nebo to může bát i IPless linka, pokud to daná technologie umí).
Me na tom fascinuje, jak velky problem je proste rict "aha, sakra, to je dobra prilezitost to zacit delat lepe".
Asi řada ISP takovou potřebu nemá a pokud je k tomu nedokážu přesvědčit, pak mi nezvývá, než hlasovat útěkem jinam...
-
Nepiste sem prosim lzi. Adresy podle RFC6598 nejsou privatni ale sdilene.
…což je jen jméno. Na jejich vlastnosti to nemá žádný vliv, chovají se ve všech ohledech úplně stejně jako RFC 1918, jen je jejich povolené použití mnohem přesněji specifikováno. Pokud použití slova „privátní“, či „neveřejné“ v souvislosti s RFC 6598 považujete za lhaní, tak si prosím nahraďte všechny výskyty těchto slov za „globálně nesměrovatelné“.
A hlavne v te predchozi vete neni IANA, ale Internet Registry - seznam IR pro CZ: https://www.ripe.net/membership/indices/CZ.html (https://www.ripe.net/membership/indices/CZ.html) Coz jsou prave ISPcka (tedy nejsou tam ti ruzni pokoutni s antenama z plechovek, co vsemu rozumi lepe nez IETF)
Ano, v tomto máte pravdu, skutečně všichni v řadě IANA – RIR – (někdy NIR) – LIR jsou internetovými registry. A žádný z nich nikdy nepřidělí adresy podle RFC 1918. Protože pokud by přidělil, musel by to dokumentovat v příslušené Whois databázi a to mu žádná z databází nedovolí právě proto, že dané rozsahy již jsou zarezervované.
Každý LIR i RIR či NIR je ale zároveň Enterprise, takže může bez problému pro svou privátní potřebu, stejně jako pro potřebu spřátelených organizací, adresy podle RFC 1918 používat.
-
A jste si jist, ze v podepsane smlouve nestoji, ze ISP znamena Intranet Service Provider? :)
Rozhodne bych sel k nekomu jinemu.
Sedím takhle doma na pr... zadku... ...a najednou jsem na to přišel! Poskytovatel obvykle nedává veřejné adresy, protože všichni chtějí jen připojení K internetu (tj. z domu ven k Zeměkouli), nikdo přece nežádá připojení Z internetu (tj. domů)!
Záhada je vyřešena. Chtějte vždy i připojení Z internetu.