Vlákno názorů k článku IPv6 NAT – chceme ho? od Filip Jirsák - Stačí 2 IPv6 adresy, přerušení konektivity nemá na...

Stačí 2 IPv6 adresy, přerušení konektivity nemá na vnitřní síť vliv. Protokoly na šíření routovacích informací samozřejmě existují a používají se i v IPv4. Na konfiguraci toho moc složitého nevidím, rozhodně je to jednodušší, než udržovat spoustu výjimek v NATu, řešit to, že servery mají zevnitř sítě jiné adresy než z venku atd. I kdybyste to nakonec chtěl řešit NATem, pořád bude mnohem jednodušší na bráně jenom přepsat prefix IPv6 adresy a přepočítat kontrolní součet, než udržovat tabulku spojení, pokoušet se vysledovat spojení v UDP, hlídat rozsahy portů atd.

Jde přes RA nebo jiným standardním zpsobem (který umí všichni klienti implementujícím minimální nutnou IPv6 fukcionalitu) říct "a od teď bude default gw z té druhé sítě než dosud, ale interní prefix té první sítě směruj na gw pořád". Bez toho aby to trvalo X minut? Pokud ano, tak uznávám, že se pletu.

Jinak ten uvažovaný NAT nemusí být 1:N, ale 1:1 tj. každá jedna "interní" adresa se může mapovat na samostatnou "externí".

tak staci aby to podporoval vas domaci router a bude vam to fungovat. Nic vic netreba. Zarizeni se jednoduse pripoji do libovolne dostupne site a ohlasi svemu domacimu routeru kde zrovna je a jakou ma lokalni IP.

Na to nepotřebuju IPv6 Mobility, takhle provozuju už 10 let VPN. Pravda, že s IPv6 je to integrováno přimo v IP stacku, takže to bude možná úspornější a celkově hezčí.

Je tu několik zásadních ALE: 1) musím vůbec nějaký domácí router mít, musí tuto technologii podporovat, a musí být pořád zapnutý. 2) i když splním všechno předchozí, tak si představte můj domácí router na ADSL s uploadem 200 kb/s, poteče-li přes něj veškerý provoz, to se budu mít krásně. Teoreticky by mohl ADSL router signalizovat mému ISP, aby to routoval přímo, a data netekla přes ADSL tam a zpět. Bude-li něco takového technicky možné, nechá si za to ISP řádně zaplatit, to si buďte jisti.

Ve firemním prostředí může být situace trochu jiná (vlastní slušná konektivita a HW pro Mobility GW), ale oni už dávno používají Cisco VPN, což poskytuje ještě nejaké výhody navrch, nebo jiné obdobné řešení.

Závěr je, že IPv6 v oblasti mobility nic přelomového nepřináší. Nebo ne?

Domácí agent může uzlu, který se s tebou snaží komunikovat, signalizovat „redirect“, že jsi dostupný přímo na té a té adrese a pokud tuto signalizaci ten uzel podporuje, tak s tebou potom bude komunikovat přímo.

Jestli to takhle fakt funguje tak si sypu popel na hlavu, moje neznalost. Pokud cílem toho redirectu je koncový uzel navazjící spojení, pak to je dobré, nezávisí to nijak na infrastruktuře ISP (leda by to blokoval). Mám ale strach, jak s takovou "redirect" zprávou budou zacházet výchozí konfigurace různých firewallů. Budu to muset prozkoumat, hlavně s výchozím nastavením FW na Windows 7. I když kdyby to hromadně podporovaly alespoň servery, byl by to úspěch. Nějak mi to ale připomíná IPv4 ICMP redirect...

Je mi jasné, že buď s redirectem počítá přímo koncový uzel (ideální stav), nebo to zpracuje nějaký router "cestou" (to nepředpokládám, že by mohlo být standardní chování), a nebo v nejhorším to bude všechno téct přes toho agenta (a to se bojím, že bude obvyklé chování).

A ještě něco: "IP Mobility Support for IPv4" tu máme od roku 2002, RFC3344. Nějak se to neuchytilo. Asi kvlůli všudypřítomnému NATu? OK.

Jak si ale Mobile IPv6 poradí s různými firewally? To je totiž taky část problému, kterou by to podle mě mělo řešit. Aby bylo "kouzlo" Mobile IP pro mě úplné, mělo by to fungovat v hotelu na WiFi, ve škola na Eduroamu, v cizí firmě, kde mi nechají připojit notebook. Je obvyklé, že na takových místech firewall blokuje příchozí spojení, případně i odchozí na určité porty (SMTP atd.). Poradí si s tím IPv6 Mobile (jako že ta omezení umí obejít)? A bude to pořád fungovat pomocí těch "redirect" zpráv? Nebude náhodou Mobile IP to první, co správci podobných sítí zablokují? Tohle ještě není otestováno in-the-wild, ale vidím tam mnoho prostoru pro různé podvody, útoky, potíže s diagnostikou sítě atd. Nebo je to vše vyřešeno a reálně otestováno?

a ve vnitřní síti používáte rovnou ty přidělené rozsahy veřejných adres

Takže všechna zařízení v síti budou mít 2 IPv6 adresy a 2 výchozí brány (s nějakou prioritou), vlastně ideálně ještě třetí "interní" IPv6 adresu a bránu + statické routy pro tuhle interná síť (ale ty jde myslím propagovat v rámcí RA), aby se při přepnutí konektivity nepřerušila komunikace uvnitř sítě.

Ona to takhle napsat jde hrozně snadno. Ale máte to tak někde v produkčním prostředí v provozu, že tak poučujete? Jak máte v síti třeba další 2 interní routery, musí se na ně nějak šířit informace o přeroutování (resp. aby přestaly propagoval bránu v rozsahu nefunkčního ISP) - je na to nějaký standardní protokol? Aspoň v linuxu?

Nemůžu si pomoct, ale celé tohle je na konfiguraci a údržbu řádově složitější než jedna "privání" IPv4 adresa na stroj v LAN + na edge routeru NAT na zrovna aktivního ISP, nebo klidně load-balancing podle hashe srcIP+dstIP+... přes 5 různých obyčejných připojení (třeba v Mikrotiku je konfigurace této funkcionality na pár minut, a funguje to dobře).

Čistá řešení naráží na administrativní překážky - třeba že ISP musí podporovat něco "navíc", co není součástí základních levných služeb, nebo musí dokonce něco individuálně nastavit na své straně. Už dnes není "žádný" problém mít plně redundantní konektivitu krásně řešenou přes BGP, ale nejde to s jedním ADSL přípojením za 500 Kč a jedním třeba optickým za obdobnou cenu.

na IP V4 není NAT ( tedy pochopitelně Port NAT, tedy NAPT, míněno ve verzi Full Cone NAT - tedy plně hlídaný NAT ) vůbec špatná věc. Jednak mi to přináší výrazně vyšší zabezpečení - byť to není pochopitelně dokonalé, ale nějaké zabezpečení to je. Jednak mi to umožňuje - jak tu padlo - nezávislé adresování vnitřní sítě a to i v rozsahu internetových adres. Pak mi to velmi zjednodušuje práci s více linkami od více providerů. V malém prostředí ( myslím SMB segment, který je ale mejmasivnější - ( síť TU Liberec asi nepředstavuje masovou záležitost, že ? ) mi NAT nijak nepřekáží v publikování běžných prostředků do internetu - běžně ( denní chleba ) tedy mailservery, webservery, vzdálené přístupy a kamery. Nevidím v tom problém, naopak vzhledm k možnosti různého mapování více veřejných adres a různých provázaných vnitřně/vnějších smyček přes ně jdou dělat zajímavé kousky.

Ten Vámi prezentovaný - z mého pohledu extrémně primitivní - pohled na IPV6 totiž předpokládá, že mám jediného providera ( to nemám ani doma - normální člověk, jehož živnost je přímo závislá na konektivitě má i domů nejméně dvě různé linky, běžně na nich visí i doma dohledové kamery a různá ovládání, o malé firmě ani nemluvím ) jediné adresování a jednoduchý model routingu. Ani jedna z uvedených podmínek není splněna ani u mne doma, ani ve většině mnou spravovaných firem.
Další samostatnou kapitolou je obrana proti odposlechu ( jak konkurenčnímu, tak od "Velkého bratra" a určení koncové stanice a osoby. Tady NAT koná a konal a bude konat dokonalé služby.

Obecně na mne celkově - teď nejenom o NATu - působí návrh IPV6 jako megalomanský konstrukt, zaplacený ( Velkým bratrem ) za účelem zjednodušení dohledu provozu. Do tohoto obrazu mi zapadá i - až dementně legrační - snaha o naprostou nekompatibilitu IPV4/IPV6 a návrh omezených přechodů mezi těmito světy pomocí placených můstků u providerů ( zdravím VB u Telefonicy s návrhem výhradně IPV6 linek a routingu přes státně/Telefonické můstky )

Ó velký mágu - v principu samozřejmě v ničem, pokud mohu mít své vnitřní adresy naroutované na dané vnější. Ale mně ze studia RFC a reálných dokumentů vyplynulo, že ty vnitřní bych měl dostat od poskytovatele a že se s tím víceméně automaticky počítá ( malé firmy budou "osvobozeny" od nunosti mít své DHCP a DNS - je častá formulace ), což je ta logika, na kterou si stěžuji a co pak zabraňuje spolupráci s multilinkem. Pokud si ale zvolím svůj vnitřní IPV6 rozsah ( tedy návazně rozjedu svoje IPV6 služby DHCP a DNS, protože psát to ručně nebude ono ), nevidím důvod, proč bych na to neměl aplikovat NAT, který mi přinese další vrstvičku zabezpečení ( no, abychom se nehádali o ten pojem, tak tato technologie přidělá potenciálnímu útočníkovi i zvědavci další problém při přístupu zvenku do mé sítě, což je to, co chci.)

Firewall a NAT rozlišuji již řadu let poměrně přesně, ale tyto technologie jsou s reálném použití natolik provázané ( resp bez vzájemného pečlivého nastavení není výsledek dobrý ). ( No, upřímně - na reálných routerech to ani spojovat nejde, nastavovací menu i příkazy jsou striktně odělené, takže i laik velmi rychle chápe. Ale Váš nápad o nerozlišování se mi líbí, je takový "profesorský", hi )

Mimochodem - tento pocit má zjevně i několik vývojářů,takže mám teď v ruce routřík, kde je jeden samostatný firewall ( packet filter ) aplikován rovnou do pravidel NATu a jiný "normální firewall" se nastavuje a aplikuje zvlášť. Díval jsem se na to napřed docela kysele, ale má to své praktické kouzlo, hi .

Na tu mobilitu bych moc nespoléhal, je to z principu od základu kočkopes (rozumí se potažmo nakonec i z provozního hlediska) a nevěřím, že to bude jednoho dne reálně fungovat (kromě vybraných kombinací dvou konkrétních providerů, kteří se na tom mezi sebou domluví). Vidíte někdo na obzoru "IPv6 mobile roaming pool" na způsob dněšního NICu/NIXu?

V čem je problém, když máte víc poskytovatelů a nemáte NAT?

Jinak jestli si pletete NAT s firewallem, bezpečnosti vašich sítí to rozhodně nepomůže…

„Další samostatnou kapitolou je obrana proti odposlechu ( jak konkurenčnímu, tak od "Velkého bratra" a určení koncové stanice a osoby. Tady NAT koná a konal a bude konat dokonalé služby. “

Tak to tedy nechápu, jak může NAT chránit proti odposlechu. Můžete to rozvést?

Jinak určení koncové stanice a osoby podle IP adresy - privacy extension.

„Do tohoto obrazu mi zapadá i - až dementně legrační - snaha o naprostou nekompatibilitu IPV4/IPV6“

Zvláštní je, že jsem ještě nikde nečetl žádný návrh, jak to udělat kompatibilně.

„zdravím VB u Telefonicy s návrhem výhradně IPV6 linek a routingu přes státně/Telefonické můstky“

ISP může směrovat přes Ministerstvo už teď, je úplně jedno, jestli jde o IPv4 nebo IPv6.

„bez vzájemného pečlivého nastavení není výsledek dobrý“

Jak konkrétně se liší NAT a zakázání navazování TCP spojení zevnitř od zakázání navazování TCP spojení zevnitř?

Jinak ten uvažovaný NAT nemusí být 1:N, ale 1:1 tj. každá jedna "interní" adresa se může mapovat na samostatnou "externí".

Ano, to je myslím dobrý začátek. Pak se jednoho dne někdo zeptá: „Proč tam vlastně máme ten NAT? Není to k ničemu dobré a jenom jsou s tím problémy.“ A problém s NATem bude vyřešen…

Takže abych to shrnul – když máte dva poskytovatele, od obou rozsah IPv6 adres, žádný NAT a ve vnitřní síti používáte rovnou ty přidělené rozsahy veřejných adres, není s tím žádný problém a je to to nejjednodušší použití. Ale je pravda, že se to dá NATem komplikovat.