Lokální adresy v síti ISP

[zett_cz]

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

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.

[Reklama]

[czechsys]

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

[smrt28]

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?

[robac]

Ř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ě"...

[zett_cz]

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.

[Reklama]

[zett_cz]

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

[Medo77]

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 .. :-)

[SB]

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?

[messagebus]

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.

[Radek Zajíc]

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.

[Filip Jirsák]

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.

[Filip Jirsák]

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 ;-)

[Radek Zajíc]

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.

[robac]

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

[robac]

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