IPv6 NAT implementáción dolgoznak a Netfilter fejlesztők

Linux

A nemrég megrendezett netfilter workshopon a fejlesztők megegyeztek abban, hogy bizonyos esetekben van létjogosultsága az IPv6 NAT-nak (Network Address Translation | hálózati címfordítás) és mivel a gyártók már dolgoznak a saját implementációikon, nem volna rossz, ha lenne egy jól kitesztelt referenciaimplementáció amelyet mindenki felhasználhatna, ahelyett, hogy mindenki sajátot fejleszt. Patrick McHardy nemrég elérhetővé tette patcheit az ip6tables-hez, az iptables IPv6-os változatához. A bejelentés itt olvasható. További részletek itt.

( PunishR v | 2011. 11. 27., v – 12:03 )

Érdeklődés szintjén megnéznék erről itt egy szavazást:)

( willy v | 2011. 11. 27., v – 12:10 )

hülyeség. a hozzáértők :) már megmondták: mégpedig ilyenre nincs szükség...

Az hogy csinálnak ilyet, pont azt jelenti hogy szükség van rá. Ha nem lenne szükség rá, nem csinálnák. Kevered a szezont a fazonnal. Azt akartad mondani, hogy a hivatalos kommunikáció szerint mindenre jó a ipv6 mostani formája, csak máshogy kell gondolkodni.
Ezen lehet vitatkozni, igaz e az állítás, vagy sem. Azon pedig nem, hogy néhányan úgy érzik szükség van másra és leimplementálják.
A szükség mozgatóereje nem a "megoldhatatlan máshogy" a legtöbb esetben.
A vitát ne nyissuk újra. A címek számosságának problémáját kezeli az IPV6 azonban a NAT és a LSNAT köré telepített és belegondolt funkcionalitást nem váltja ki. Egy lépésben nem vezethető ki. 6 éve ezen törpölnek, de nem akarják elhinni.

Hát ezt sikerült félrevinned. Azok "felülről" vezényelt kezdeményezések, amelyek elbuktak, ne menjünk bele hogy ennek mi volt az oka, és hogy megállapítható e szükségesség. Itt ez a dolog "alulról" indul és pontosan a szükségesség (ahogy kifejtettem az okait) az alapelv ami mentén elindult (nem első, és reméljük első ami nem bukik el)

Ja hogy te a technika okokat keresed? Ne haragudj, én hülye nem tudtam :). ie: Én azt mondtam hogy szükséges. Ennek alapvetően nem kell hogy technikai oka legyen. Nem akarok belemenni a 20x lerágott csontba, hogy miért nem célszerű a NAT-ot elfelejteni, ez a téma 3+ éves múltra nyúlik vissza. Én tudok NAT nélkül élni, mégis látni, ha nem hiányozna a NAT implementáció a ipv6-ból lehet már nem itt tartanánk... Miért nem kérdezed a Józsiékat ők miért döntöttek így, mikor mereven elutasítóak voltak eddig? Szerintem tőlük szép kerek választ kapsz a kérdésedre (már úgy értem olyat ami neked is megfelel).

Kedves nanto, én konkrétan már elgondolkodtam azon, hogy az általam menedzselt rendszereken legyen ipv6. Jelenleg ott tartunk, hogy ha ez az architektúra teljes átdolgozása nélkül menne, akkor pár embernap elég lenne rá, és akár bele is vágnék. De sajnos a NAT hiányában ez biztosan nem működik így, innentől kezdve pedig a feladat mérete a többszörösére ugrik, plusz egy halom bizonytalansági faktor megy bele, így pedig nagyon gyorsan az "akkor majd egyszer elgondolkodunk ezen" kategóriába került át. További probléma, hogy gyakorlatilag lehetetlen olyan architektúrát találni, ami ipv4-en is, és ipv6-on megvalósítható. A NAT hiánya miatt pl. minden szolgáltatásnak külön IP címet kell adni, míg ipv4-en pont nem tudunk külön ip címet adni a dolgoknak, mert az konkrétan nincs, és nem is kapnánk (hiszen használjunk NAT-ot...)

Tehát nem önmagában azzal van a baj, hogy nincs NAT, hanem azzal, hogy egy-az-egyben nem lehet a meglevő ipv4-es architektúrát lecserélni ipv6-ra, változtatás nélkül.

Értem én, hogy ez volt az elvárás, direkt lett ilyen az ipv6, nos, akkor viszont nem kell meglepődni azon, hogy mennyira lassan megy az átállás. Ügyesen tökön szúrtuk magunkat, szó se róla...

Mindenhol külön hálózatként kezelik az IPv6-ot (azaz mintha új infrastruktúrát építenének) mivel máshogy pont az implementáció inkompatibilis volta és hiánya miatt nem lehetséges. Ahogy mondod, nem kell hozzá, de ha lenne, már sokan meglépték volna, így még 2 évig csak hallgatjuk mekkora balfaszok is az emberek, hogy nem látják át mi jó nekik.
Nekem az életemet könnyítené meg a NAT kikreűlése a képből, de ez a mostani megoldás csak ártott. Nem érdemes vitázni egyébként erről, mert egyszerűen más szempontból vizsgálja a kérdést. Pedig nem lehet. Nem újat építünk hanem kiváltunk.

Amit el fogok fogadni oknak: egyetlen konkret dolgot mondj, amit ipv6-on nem lehet NAT nelkul megoldani, es ipv4-en NAT-tal meglehetett.

VPN eléréssel engednek be valahova, policy szerint max. egy kapcsolatod lehet, azon max. 1 ip címet engednek, routing hirdetések teljes mértékben tiltva. A kliens sw zárt forrású, a VPN gazdája adja, bele van égetve a szerver ip címe, SSL-t használ, beégetett CA-val.

Hogy oldod meg azt, ami ipv4-gyel nagyon szépen megy NAT-tal, hogy több gépről el tudd érni a VPN túloldalán levő szervert?

Zárjuk ki azt az opciót, hogy a VPN másik oldalán levő intézmény vezetőjét egy fegyvernek látszó tárggyal addig fenyegeted, amíg nem hajlandó a policy-n lazítani...

Ez nem technikai ok, hanem a partner technikai balfeksege. Egyebkent szerintem vannak erre a NAT-on kivul megoldasok, ha a masik fel ertelmesen implementalna az ipv6-ot, akkor mindenkepp.

A gond ott kezdodik, hogy egy profitorientalt vilagban senki nem fog _normalis_ ipv6 szakemberekre kolteni, mert nem noveli a bevetelt az ipv6 bevezetese, ahhoz a semmihez meg dragak azok, akik ertenek is hozza. Es eloszor szerver oldalon kene rendet tenni, ott meg nem lenne olcso, nem koltseghatekony a normalisan kiepitett ipv6 halozat.

Egyébként elárulom nekem pl. mi a fő gondom az IPv6-al. Elsősorban a layer2 eszközök felkészületlensége. A különböző szenzitív adminisztrációs csomagok szűrési lehetőségének hiánya. Ne pc-be gondolkozz... Nagy számosságú, firmware-el többnyire megoldhatatlan problémák

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6406/prod_…

"Q. Does the Cisco Catalyst 2960 Series support IPv6?
A. Yes. Cisco Catalyst 2960 switches with LAN Base software support IPv6 management and MLD Snooping. The Cisco Catalyst 2960 LAN Lite switches do not support IPv6."

Aki Base image-nél lejebbi imagel használja, meg is érdemli.

Amúgy meg L2-n, max. annyi köze lehet V6-hoz, hogy MLD snoopinggal _hatékonyabb_ legyen, de az IP az akár v4, akár v6, az layer3 beli fogalom.
A switcheket meg egyéb hálózati eszközöket úgyis privát vlan-on keresztül manageled!

( Zahy v | 2011. 11. 27., v – 13:13 )

Azé' ez durva:
"mivel a gyártók már dolgoznak a saját implementációikon, nem volna rossz, ha lenne egy jól kitesztelt referenciaimplementáció amelyet mindenki felhasználhatna, ahelyett, hogy mindenki sajátot fejleszt"

Ha ez lenne a cél, akkor két okból nem kellene a Linux kernehez írni egy új ilyet:

a) mert a GPL miatt nem mindenki használhatja
b) mert már van ennél szabadabb "referenciaimplementáció". Ugyanis a Darren Reed-féle ipfilter egy ideje már tud IPv6-ot NAT-olni. (Hivatkozásnak itt egy példa.) Mondjuk hogy van-e aki használja, az kérdéses, de garantáltan régebb óta elérhető, mint az, amit majd csak most fognak implementálni (a többi gyártó után).

Feltételezem itt a "gyártók" a linuxos routereket, eszközöket gyártókat akarja jelenteni (a Netfilter a Linux csomagszűrője). Mit kezdjenek a linuxos routergyártók a Darren Reed-féle ipfilter-rel? Amúgy sem nagyon elterjedt az ipfilter, ráadásul a BSD világban is elég mostohán kezelték a licence miatt (BSD-nek kinéző licenc, de nem engedélyezi a módosított változatok terjesztését). Ráadásul kérdéses az ipfilter Linuxon mennyire támogatott.

Újszülötteknek:

Theo de Raadt miért dobta az OpenBSD-ből

Az ipfilter weboldala elavult, one man projektnek látszik. Nekem úgy fest, hogy semmi sem szól mellette.

--
trey @ gépház

Fentiek nagyrésze FUD. Megnéztem a rendszeremben benne levő ipf licencet. (Nekem ipf: IP Filter: v4.1.28 (400) van); és a halott weboldalról letölthető 5.1.0-s verzióhoz tartozó IPFILTER.LICENCE fájlt is:
/*
* Copyright (C) 1993-2001 by Darren Reed.
*
* The author accepts no responsibility for the use of this software and
* provides it on an ``as is'' basis without express or implied warranty.
*
* Redistribution and use, with or without modification, in source and binary
* forms, are permitted provided that this notice is preserved in its entirety
* and due credit is given to the original author and the contributors.
*
* The licence and distribution terms for any publically available version or
* derivative of this code cannot be changed. i.e. this code cannot simply be
* copied, in part or in whole, and put under another distribution licence
* [including the GNU Public Licence.]
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* I hate legalese, don't you ?
*/

Természetesen Theo 2001-es hivatkozása ellen semmi kifogásom, de azóta némileg változott a helyzet - pedig ez is 2001-es :-)

Aztán persze az, hogy nem megy Linuxon, az elvben nem stimmel, de most ezért nem kezdek Linuxot telepíteni. Hivatkozás: http://www.phildev.net/ipf/IPFlinux.html valamint fent említett 5.1.0-s forrásban szintén szerepel egy INSTALL.Linux fájl, amiben kb. az szerepel, hogy kell hozzá kernel forrás, és a helyére kell rakni a dolgokat, onnantól ugyanúgy megy, mint bármely egyéb peccsel. Nyilván, mivel annak az INSTALL-fájlnak is 2009-es a módosítási dátuma, bőven belefér, hogy azóta változott annyit a kernel api, hogy már nem lehet hozzáferdíteni. (Mondjuk ez nem lenne meglepő a Linux kernel esetén.) Pláne, hogy 2.4-es és 2.6-os kernelt emleget, holott ugye mekkorát lépett előre a világ, hisz már 3.x-nél jár a kernelverzió.

Abban igazad van, hogy one-man-show. Mellette csak az szól, hogy ez már készen van :-), tudja - valamilyen szinten - az igényelt funkciót, meg egy csomó egyebet. (Jól elcsodálkoztam egyébként, hogy ha nem is olyan szinten testreszabhatóan, mint a Linuxos ipset, de ehhez van ippool funkció, kb ugyanarra.) Valószínűleg kisebb munka lenne az épp aktuális kernelverzióhoz reszelni, mint nulláról újraírni egyet. (Igaz, mivel ott van, hogy nem szabad GPL alatt továbbterjeszteni, lehet, hogy a másik oldali licence-huszároknak is fájna - ez ugyanis nem BSDL-huszár tulajdonság.)

Szóval csak annyit akartam mondani, hogy ha valaki akarná, éppen lehetne használni. Igaz, ez nem illeszkedik a netfilterhez - a mellett viszont valószínűleg elműködne. (Ugyanúgy, ahogy elmegy pl. FreeBSD-n az ipfw és a pf mellett is akár, ha szükséges.)

Még mindig nem értem, hogy miért kellene a Linux natív csomagszűrőjét lecserélniük a linuxos eszközöket gyártóknak egy, a múltjában vitákkal tarkított, alig használt, 1 emberes projektre, aminek a támogatottsága egy emberen múlik, nem a Linux a fő csapásvonala? Mi szól mellette?

A licencről annyit, hogy Reed saját licencet írt. Nem felelt meg neki a BSDL. Ennek oka volt. de Raadt szerint Reed kijelentette, hogy a terjesztés nem engedélyezett. Vitatkozott, sajátosan értelmezte a licencet. Ki akar a bíróságon vitatkozni a szerzővel annak sajátos licencértelmezéséről? Reed lehet, hogy változtatott a licencen (IANAL). Viszont a rossz szájíz ott maradt utána.

--
trey @ gépház

Nem mondtam, hogy le kéne cserélni a csomagszűrőt. Azt mondtam, hogy a felvetés, hogy nincs ilyen, nem igaz.

(A "múltjában vitákkal tarkított" és "egy-emberes project" ellenpéldája: Linus és a Linux-kernel. Ennyit a rossz szájízről. Szóval nem lenne ellenérv, ha arról vitatkoznánk, amit mondasz. De nem arról folyik a diskurzus. Legalábbis a kiinduló hozzászólás nem erről szólt. De mindegy is.)

"Azt mondtam, hogy a felvetés, hogy nincs ilyen, nem igaz."

Ki állította, hogy nincs ilyen?

"A "múltjában vitákkal tarkított" és "egy-emberes project" ellenpéldája: Linus és a Linux-kernel."

A Linux kernelnek a kezdetek óta ugyanaz a licence. Egy széles körben elfogadott licenc, amit a projekt vezetője nem módosítgat kénye-kedve szerint. Felmerülhet a kérdés, hogy az oka annak, hogy az ipf nem "ütött be". Feltehetően komoly szerepet játszott abban, ez a licenc história.

Megtaláltam közben Darren Reed sajátos értelmezését:

http://mail-index.netbsd.org/current-users/2001/05/30/0003.html

"> + * Yes, this means that derivitive or modified works are not permitted
> + * without the author's prior consent."

> Darren,
>
> Can you please explain this change in license to us? What exactly do you
> consider derivitive or modified works? Does this imply that newer version of
> IP Filter can no longer used in other products unless you explicitly approve
> this?

There is no change. It's always been that way - from day 0 - so there
is no going back to an older version which has a different licence.
The licence has only ever granted right to redistribute/use, not modify.

The only difference is those two lines make explicit what was only implied
before. As it points out, it is explaining what the prior sentence means,
not adding any new meaning.

Darren

--
trey @ gépház

Nem tudtam eddig, hogy ha egy program licence GPL-re vált == "mi" beszívtuk, de mindenesetre érdekes. Mindenesetre ha én hardvergyártásra adnám a fejem, Darren Reed szoftverétől a lehető legmesszebb távol maradnék. A "majd ha én megengedem, akkor módosíthatod" Reed-féle borzalom úgy fest a mai napig érvényben van.

--
trey @ gépház

Szerintem a referncia implenentáció két dologra vonatkozik:
- a Linux alapú router/proxy/tűzfalgyártóknak
- mindenki egyéb, aki megnézi, és látja miként működik

A szabadság meg ugye kérdéses, értelmezés kérdése. A BSD szabadabb abban, hogy megszűntetheted a szabadságot és bezárhatod mások előtt - Windows KDC ugye a legjobban ismert példa - és, úgy is, hogy nem lehet elvenni a szabadságot, mert annyira szabad, hogy az is marad. Nekem utóbbi jobban bejön, mert kisebb a kitettségem. A gyártók szempontjából pedig, amíg csak használják a megoldásokat, addig mindegy a kód, a legtöbb alap F/OSS projekt pedig LGPL-lel rendelkezik, ami ugye már jó céges dolgokra. Felhasználhatod, módosíthatod a libet, de ha módosítottad, akkor vissza kell tolnod a közösségbe - ettől erős, és mások munkáját is így tudtad hasznosítani. A saját cucc meg használhatja a libet anélkül, hogy a saját programod forrását ki kellene adnod. Mi kell ennél több?

( dash | 2011. 11. 27., v – 17:27 )

ÁÁÁÁÁÁÁÁ, pedig az ipszilonos videóban kifejezetten kiemelte Kadlecsik hogy IPv6 NAT nem úgy nincs hogy majd egyszer elkészül, hanem soha nem lesz. :D

Néhány esetben hasznos tud lenni az IPv6 NAT. Amitől tartok, hogy vakon azt fogják használni akkor is, amikor NAT nélkül egyszerűbb, gyorsabb, hatékonyabb lenne az adott tűzfal.

Az iptables/ip6tables kódban nagyon sok minden egyesítésre került és ezek közös libxtables dinamikus könyvtárba kerültek. De ami fontos, az a kernel-userspace kommunikáció és a szabályok tárolása. Jan Engelhardt összeállított egy netlink alapú protokollt az elsőre, de azt még tovább kellene csiszolni. A szabálytárolásnál volt kísérlet a blobról láncolt listákra való áttérésre, az sajnos nem elfogadható mértékű teljesítményvesztéssel járna. Előrelépés annyi van, hogy néhány vakvágányt szépen sikerült azonosítani :-).

Mert ahhoz protokollt, és ezzel együtt minden klienst le kell cserélni, hogy egyazon domain névhez két protokoll két külön IP címet használjon (jelenleg az internetes protokollok között elvétve van olyan, amivel ezt meg tudod csinálni, így egy név - egy IP cím hozzárendelés van, bármelyik szolgáltatását akarod igénybevenni).
Azt meg nem követelheted meg a felhasználóktól, hogy szolgáltatásonként más és más domain nevet használjon.
Ez a jelenlegi IPv4-en működik, használják is sokan.
Nem életszerű az az IPv6 stratégia, ami felhasználói szinten látványos változtatások nélkül nem megy.

Nem erről beszélünk, de ezt szerintem értetted is.

Arról beszélünk, hogy a http://mail.futtyfurutty.com az egyik szerveren van, az imaps://mail.futtyfurutty.com pedig egy másik szerveren. Ha mindkettő szerver IP címét beírom AAAA rekordként, egyik szolgáltatás se fog rendesen menni. Ha van 18 szolgáltatásom, hozzá 18 szerverem, akkor a helyzet még rosszabb.

Nem gondoltam erre, mert szerintem ennek nincs sok értelme. Ha van központi menedzsment, akkor bármilyen szerver nevet be lehet állítani a gépeken, ha meg nincs, akkor csak dokumentáció kérdése: smtp.futtyfurutty.com az SMTP szerver, imap.futtyfurutty.com az IMAP szerver, és így tovább.

A helyzet, amit nehezen lehet magyarázni,
hogy miért X év után jutott eszébe valakinek a teamből, hogy valós életszerű/életszagú helyzetekben van létjogosultsága a ipv6 NAT-nak.
De továbbmegyek.. már csak a folyamatosság miatt is meg kellett volna csinálni..

Ez a ciki nem a hóesés..

Ami a redirect-et illeti.. sokan használják arra, hogy az 1024 alatti portokat 1024 fölöttire dobják.. bár öszintén megmondom ez nem tudom mennyire
számít nat-nak, a teljes nat-hoz képest.

"miért X év után jutott eszébe valakinek a teamből, hogy valós életszerű/életszagú helyzetekben van létjogosultsága a ipv6 NAT-nak."

Ezt én sem értem. Lehet, hogy olyan szakik ültek/ülnek ott, akik alapvetően színtiszta hálózati környezetből jöttek, ahol elsősorban "route"-olni kell, addig még elláttak, hogy van NAT, ahol nem elég az IPv4 cím, aztán gondolták, hogy prímán meg lesz oldva. Holott az IPv4 NAT-ot sem csak és kizárólag az IP címek szűkössége indukálja.

Mi csinálunk olyat, hogy tesztkörnyezet generálás, ahol a tesztrendszerek IP címe ugyanaz, mint az éles (egyrészt macerás átállítani mindenhol az IP címeket, másrészt ez +1 jellemző, amiben már nem egyezne az élessel), itt elengedhetetlen a NAT (legalábbis ha fizikailag nincs elkülönítve, márpedig nincs annak érdekében, hogy a felhasználóknak ne kelljen íróasztalok között vándorolni).

Olyanra is használjuk a NAT-ot, hogy alapértelmezés szerint egy szolgáltatást egy kiszolgáló lát el, karbantartás esetén pedig egy másik: karbantartás idejére át van állítva a NAT. Nincsen DNS TTL és egyéb szívások, ami miatt ilyen egyszerű dolgok napokig szétnyúló szívást eredményezhetnek (tudom, erre más technológiák is rendelkezésre állnak, de nem minden esetben vethető be).
De ugyanez a helyzet akkor, ha szolgáltatási környezet van migrálva: sokkal egyszerűbb úgymond "virtuális" szolgáltatási IP címeket publikálni kifelé, mint DNS TTL-eket várni (előkészítés, megfelelő pillanatban átirányítható a szolgáltatás az újra).

Az általad említett folyamatosság is fontos - szerintem is: ha valahol úgy vannak konfigurálva a szolgáltatások, hogy NAT alapon működik minden kívülről, ott mindent újra kell kezdeni ahhoz, hogy NAT nélkül is menjen. És akkor lesz egy hibrid megoldás: IPv4 NAT, IPv6 "route". Nem tartom szerencsésnek.

Én csak örülni fogok az IPv6 NAT-nak. Jobb később, mint soha.

Példáid egyike sem olyan, hogy csak és kizárólag NAT-al lehet megoldani.

Olvassátok el egyszer a NAT követelményeire vonatkozó RFC-ket (4787, 5382): szép összegzései annak, hogy a NAT mennyi bajt okoz az alkalmazási rétegben.

Az egyik fő motivációs erő az IPv6 NAT ellen pont az volt, hogy az IPv6 tiszta lappal induljon és ne terhelje fölöslegesen egy olyan feature, aminek nincs létjogosultsága IPv6-nál - néhány esettől eltekintve, lásd föntebb a linket Ulrich összefoglalójára.

Ez a thread szép illusztrációja annak, hogy amitől tartottam, az be is következik: "folyamatosság" címszóval az IPv4 NAT-ot átviszitek IPv6-ra is.

Tényleg kíváncsi lennék mivel oldanád meg NAT helyett őket, DNS mellőzésével, ami komolytalanság legfőképp a caching miatt..

Egyébként meg elolvastam amit Ulrich irt.. valószínű még csak nem is teljes a listája.. úgy gondolod azok nem elég erős érvek a ipv6 nat mellett?

A redirect 1024 alól 1024 fölé, az komolytalan. Nem hiszem el, hogy nem lehet az alkalmazást tisztességgel megírni, hogy bind-oljon a portra és dobja a privilégiumait. Vagy hogy annyira nehéz lenne kiadni egyetlen setcap parancsot.

A tesztrendszert pédául split-DNS-el szépen meg lehet oldani: akinek kell, az az éleset "látja", akinek meg a teszt, az azt. Nyilván oda kell figyelni a DNS TTL-re, de tervezett tesztelésről van szó.

A szolgáltatás átvételére legegyszerűbb az IP cím vándoroltatása a szerverek között. Az IPv6-nál egy interfésznek tipikusan legalább két IPv6 címe van, tehát nem értem hogy hol léphet föl a "nem minden kezeli jó ... ha egy gépnek több IP-je van" jelenség.

Ulrich listájából a második és harmadikkal (server load balancing, uplink balancing) értek egyet és fogadom el emiatt az IPv6 NAT-ot, az elsővel nem (dinamikus prefixek).

Nem hiszem el, hogy nem lehet az alkalmazást tisztességgel megírni, hogy bind-oljon a portra és dobja a privilégiumait. Vagy hogy annyira nehéz lenne kiadni egyetlen setcap parancsot.

Mert abbol a hibas feltetelezesbol indulsz ki, h mindenki hozzad hasonloan csak szep kodot ad ki a kezebol. Nem kell ahhoz zart forrasunak lennie egy service-nak/szoftvernek ahhoz, h az embernek az eletkedve is elmenjen, h ezeket a nyugoket - foleg munkaidoben - kezelje. Igy maradnak az egyeb megoldasok amik olcsoak, gyorsak es drasztikus beavatkozas nelkul oldjak meg a problemat.

---
pontscho / fresh!mindworkz

Átirányítás: Java esetén nem megoldható, márpedig elég sok Java kiszolgáló alkalmazás fut (tipikusan alkalmazás kiszolgálók). Vagy fusson rootként?

Tesztrendszer: split DNS nem megoldás, mert akkor már változik az IP cím. Sok rendszeren sok IP cím átállítása problémás és további teszteléseket igényelne. Ha választani kell: inkább a NAT problémái (bár ezen a szinten egyáltalán nem találkozunk vele), mint egyéb görcsölések.

Szolgáltatás átvitele: nincs még IPv6 tapasztalatom, de meglepne, ha az eset kevésbé lenne problémás IPv6 alatt, mint IPv4 alatt ismerve a szoftverfejlesztőket és viszonyukat a hálózathoz (például volt már olyan, akinek az is újdonság volt, hogy egy gépnek több IP-je lehet, de nyilván meglehetősen tájékozott is előfordul, ettől függetlenül a termékek nem feltétlenül rózsásak). Sajnos előfordulnak olyan alkalmazások, ahol nehezen oldható meg a szolgáltatáshoz dedikált IP cím használata, mert az alkalmazás azt feltételezi, hogy a gépnek egy IP-je van, és abból indul minden.
Csak emiatt nem szeretnék IPv6 NAT-ot, valószínűleg sikerülne megoldást találni, de ez is egy terület, ahol hasznos a NAT.

> Java 

setcap cap_net_bind_service=ep `readlink -f /usr/bin/java`

és máris nem root-ként bind-olhat 1024 alatti portra.

> Teszrendszer

Egyszerűen nem értem. Miért kellene sok rendszeren IP címet átírni, ha egy név DNS-beli feloldásával az előző IP cím helyett az alkalmazás egy másikat kap vissza? Most akkor az alkalmazás névvel nem működik, csak IP címmel? De akkor meg a DNS amúgy is kiesne és a migráció IPv4-ről IPv6-ra igencsak nehézkes lesz.

> Szolgáltatás

Ez sem teljesen világos nekem: ha szolgáltatás nem csak szolgáltat, hanem kapcsolatot is kezdeményez és azt a hozzá rendelt IP címmel kell tennie, akkor net namespace-be kell zárni.

A redirect-ről meggyőztél.

Bevallom, nekem gőzöm se volt, hogy van már ilyen lehetőség (setcap), amivel a kód módosítása nélkül lehet root-ként 1024 alá menni.

Viszont ez: "A szolgáltatás átvételére legegyszerűbb az IP cím vándoroltatása a szerverek között. " elég hajmeresztő ötlet, ha a szervereid 1000 km-re vannak és játszani kell az IP-kel.:)

Mit értesz azon, hogy "net namespace-be kell zárni"?

A redirect-ről meggyőztél.

Bevallom, nekem gőzöm se volt, hogy van már ilyen lehetőség (setcap), amivel a kód módosítása nélkül lehet root-ként 1024 alá menni.

Engem spec. egyáltalán nem győzött meg Józsi megoldása. A setcapos megoldás ugyan egy-két kategóriával kisebb biztonsági rés, mint rootként futtatni az adott programot, de még így is sokkal kevésbé biztonságos, mint 1024 feletti portra bindolni, és rootként kiadni az iptables parancsot. Mert a setcap nem csak annak az egy szem portnak a forgalmát engedi a programhoz, hanem bármelyik 1024 alatti portét lenyúlhatja a program. További hiányosság, hogy a redirecttel meg tudom csinálni, hogy mondjuk forrás cím szerint más és más helyre redirecteljek, ergó más gépnek más szolgáltatást adok. Erre a setcap nem ad megoldást.

Viszont ez: "A szolgáltatás átvételére legegyszerűbb az IP cím vándoroltatása a szerverek között. " elég hajmeresztő ötlet, ha a szervereid 1000 km-re vannak és játszani kell az IP-kel.:)

VPN, ha már feltétlenül ilyet akarsz csinálni. De igazad van: ha van egy kialakított, meglevő IPv4-es megoldásod, hatalmas bűvészkedést, és a KISS-elv sutba dobását jelenti a dolog.

Mit értesz azon, hogy "net namespace-be kell zárni"?

Pl. lxc. A linux támogat különféle Solaris zóna-jellegű, light-weight virtualizálási megoldásokat. Ráadásul erőforrásfajtánként eldöntheted, hogy mennyire akarsz virtualizálni. Lehet "mindent" kérni, de lehet csak pl. a hálózatot virtualizálni (ennek security szempontból nem sok értelme van, de a buta programokon lehet vele segíteni).

Ha a szerverek egymástól 1000 km-re vannak, akkor egy közös NAT mögé bújtatásuk sem a legjobb megoldás.

> Mit értesz azon, hogy "net namespace-be kell zárni"?

Azt, hogy a szolgáltatást egy net namespace konténerbe kell zárni, és akkor kapcsolat-kezdeményezéskor is a hozzá rögzített IP-t használja és nem a host primary IP-jét. Lényegében egy processzt "virtualizálsz" és így az "saját" IP címe(ke)t kaphat.

setcap: nem ismertem (nem vagyok ezzel egyedül), köszi (nem gondoltam végig, de szerencsés ez? nem lehet ezzel visszaélni, hogy ezután tetszőleges felhasználó tud 1024 alatti portot nyitni java segítségével? vagy akkor korlátozzuk le, hogy ki futtathat adott javát? megéri ez egyáltalán: kilőttük a NAT-ot, de x db többlet dolgot behoztunk?)

Teszt: egyrészt azért gond, mert virtuális gép szintű tesztrendszer generálás van, és legalább n db vm-ben kellene átállítani az ip címet. Ezenkívül vannak olyan alkalmazások, ahol IP cím szerinti hivatkozások vannak. Egyszeri ipv6-re történő migrációt nyilván meg kell ejteni valamikor, de az egy alkalom, nem annyi, ahányszor új tesztrendszer kell.

Szolgáltatás: egyrészt Windows-on is futnak szolgáltatások, másrészt szerencsés vagy, hogy nem találkoztál problémás alkalmazással, harmadrészt vannak szituációk, amikor X technológia a kézenfekvőbb, vannak szituációk, amikor Y technológia.
De mint írtam, ez a szolgáltatások című kérdés a legegyszerűbben áthidalható, ettől függetlenül a NAT egy kézenfekvő megoldás (egyfajta hálózati virtualizációs lehetőség).

Valószínűleg nem azért kezdett több gyártó is megoldást keresni, mert olyan nagyon sok szabadidejük és pénzük van. Meglévő rendszerek logikájának a módosítása nem egyszerű.
Például mi van az otthoni routerekkel, amik például DHCP-n kapnak IP címet: IPv6 alatt hány IP címet tud kapni egy eszköz DHCP-n? Ha új IP címet/tartományt kap, akkor minden belső eszköznek is új IP címet kellene kapnia?

> setcap

Szerveren ne legyenek userek. Vagy ha login szerver, akkor ne azon fusson a java alapú szolgáltatás.

> DHCP

Körülbelül három hónapja otthon, ADSL mögött is használok IPv6-ot. A szolgáltatótól egy /60-at kapok, azaz 16db /64-es subnetet definiálhatok a "hálózatomban". A /60-at DHCPv6-al kapom, befele radvd-vel hirdetem egy Linksys WRT54GL-en, openwrt-vel. Ha új prefixet kapnék, a DHCPv6 átveszi és a radvd majd (tovább) hirdeti.

setcap: bocs, de nem győztél meg. Ez egy olyan problémakör, amikor aközött lehet választani, hogy melyik ujjunkat harapjuk meg. Számos esetben a NAT tűnik a legkevésbé fájdalmasnak, máskor esetleg más.

dhcp: köszi. Otthoni környezetben ez működhet. Mi a helyzet akkor, ha cég van a dinamikus IP-s router mögött, belül kialakított infrastruktúrával? Mi van, ha egy ilyen cég szolgáltatót vált?

A dinamikusan kapott prefixnél van timeout (olyan, mint a DHCP lease time) és annak lejártával minden host átcímzi magát, ha tényleg megváltozott a prefix. Persze ehhez jól be kell állítani a router hirdetéseket és a flagjait.

IPv6-nál a szolgáltató váltást teljesen transzparensen meg lehet csinálni: Procedures for Renumbering an IPv6 Network without a Flag Day

Nyilván nem csak NAT-tal lehet megoldani például a tesztrendszeres dolgot, helyette lehet alkalmazás szintű proxy-val is bűvészkedni, de ez más szempontból nem "szép". Más lehetőség is van? Szívesen tanulnék, akár egy link révén.

A szolgáltatás átirányításra is van más mód, tudom (például egyszerű IP csere, de sajnos nem minden kezeli jól azt - ha egyáltalán tudja valamilyen módon -, ha egy gépnek több IP-je van).

Folyamatosság: igenis fontosnak tartom, hogy a millió rendszert, ami valamilyen módon NAT-ra épül ne kelljen átvariálni gyökerestül. Szerintem nem ez lenne sem az első, sem az utolsó, hogy valamilyen új rendszer kénytelen elviselni egy korábbi rendszer "fogyatékosságait". Bár - felhasználói szemmel (csak használom, a belső működéssel korlátozottan foglalkozok) - a NAT számomra igazán hasznos lehetőség, még akkor is, ha technikai értelemben vannak vele kapcsolatban nehézségek és nem 100%-osan "szép".

Az RFC-ket köszi, el fogom olvasni.

Szia Józsi!

Szerinted mi van abban az esetben, ha pl applikációs proxyt vagy "applikációs" tunnelt transzparensen szeretnék csinálni?
pl
- zorp http proxy -> REDIRECT
- ill módszer ahogy az sshuttle NAT-olja (persze lehetne interfész szinten is, de ez tök kényelmes és gyors) úgy, hogy a tcp kapcsolatokat tunnelbe tereli saját daemonján keresztül ttl alapján matchelve:
-t nat -A PREROUTING -j sshuttle-12300
-t nat -A OUTPUT -j sshuttle-12300
-t nat -A sshuttle-12300 -d célhálózat/mask -p tcp -m ttl ! --ttl-eq 42 -j REDIRECT --to-ports 12300
-t nat -A sshuttle-12300 -d 127.0.0.0/8 -p tcp -j RETURN

A másik pedig -amit nem is tudom, lehetne máshogy-, hogy egy OpenVPN tunnelt kell kinatolnom annak érdekében, hogy a VPN szerver IPcíme kerüljön "azonosításra", melyet ma is aktívan használunk ugyanis az NMHH némi túlbiztosítással IP-cím szűrést csinál -mely max 10 db /mely nem lehet tartomány!/ IP-t kell leadni, s azt követően lehet SSL kliens-szerver autentikációval kapcsolódni -a kulcs/tanúsítvány csere személyesen történik meg-, s ezen felül még a Netlock kulcs is kell aláírásokhoz.. de ez utóbbi ebben a threadben nem lényeges... csak az IP-cím...)

Persze szép törekvés, hogy ne legyen NAT mert akkor rákényszerül az IT utánaolvasni és nem megszokott kényelmes mozdulattal mindenre NAT-ot alkalmazni "jó az úgy" elven, de ettől az a réteg is szív, akik tudják miért használják... valamint mire...

Üdv:
Csabka

Nem igazán látom, hogy ezek az érvek miért is érvek?

* Dynamic IPv6 prefixes: some ISP decide to not give fixed address to people
Eddig ipv4n kapott a user random címet, most ipv6-on. mi változik???

* Server load balancing, DMZ

Ezeknek mi köze van a NAT-hoz? Nem azért szokták csak NAT-mmögé rakni a DMZ-t mert nincs elég IP cím? Tűzfalról még nem hallott a csóka? Azt meg végképp nem értem, hogy a load-balancingnak mi köze van a NAT-hoz.

* Uplink Balancing

Ezt se igazán vágom, hogy miért kéne NAT hozzá. Simán megoldható tűzfallal, ospf-el pl.

# Bocs, ha hülyeséget írok, nem vagyok egy hálózati guru.
* Dynamic IPv6 prefixes: some ISP decide to not give fixed address to people
Gondolom azért, mert normálisan ugye IPV6-nál mindenkinek publikus IP-je lenne (akár több is).
Erre ugye majdnem minden háztartásban igény van. Ha ezt IPV6-nál dinamikusan akarod megoldani, akkor háztartásonként kb mondjuk 20 eszköznek kell dinamikusan változtatni a címét (hűtő, mobil, TV, ...).
Talán ezt nem akarják, hanem csak egy címet a routerét.

* Server load balancing, DMZ
Egy TCP szintű load balancer tulajdonképpen NAT-ol:
http://www.redhat.com/support/resources/howto/piranha/

* Uplink Balancing
Itt dinamikusan át kellene állítani minden eszköz IP-jét egy adott uplink váltás esetén és az fájdalmas lehet akár, csak belegondolva, hogy a váltásnál olyan hálózati kapcsolatok is megszakadnak amiknek NAT-nál nem kell megszakadniuk. (pl. amik két belső hálón lévő gép között aktívak éppen)

* Dynamic IPv6 prefixes: some ISP decide to not give fixed address to people

A cím automatikusan állítódik (otthoni környezetbe plána, dhcp6, mac-ből képződik, stb), a user úgyse címet jegyez meg, hanem domain nevet. Nem értem miért probléma a dinamikus cím, mikor a user ugyse ip cím alapján megy.

* Server load balancing, DMZ
Egy fenéket, már megbocsáss. NAT-olnak, mert egy ip cím kell akkor csak hozzá. Meg nem ismerik a többi lehetőséget... Gány az egész.
Routolhatod is azt a szerencsétlen csomagot.
pl.: http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-DR.html
http://www.linuxvirtualserver.org/VS-DRouting.html

* Uplink Balancing
Nem értem miért kéne az uplink változása esetén átállítani az ip címeidet az eszközökön??? A Megszakadást végképp nem értem. Ha nem NAT-olunk, nem igen van olyan helyzet, hogy ez a megszakadás (megszakadás, fenéket, más útvonalon fognak mozogni a csomagok) az ip szintnél feljebbre kihatással legyen.
Vagy te arra gondolsz, hogy az uplink az két külön szolgáltató két külön tartománya? Mert az meg megint a gányolás, szerver hostingnál ilyen nincs, otthon meg megint elenyésző SZVSZ.

Routolhatod is azt a szerencsétlen csomagot.

IPv6-on van már stable policy-based routing linuxon? Vagy stable LVS IPv6 támogatás?

2.6.39:
| CONFIG_IP_VS_IPV6: |
| |
| Add IPv6 support to IPVS. This is incomplete and might be dangerous. |

Természetesen most arról beszélünk, hogy _elméletben_ meg lehet oldani NAT nélkül a világ összes problémáját, de ha "holnap légy szíves átkattintani a meglevő IPv4 rendszeredet, hogy IPv6 is legyen rajta!", akkor annak a _gyakorlatban_ is kéne mennie, a meglevő stabil sw verziókkal (ergó a 3.42.rc9 linux kernelben frissen megjelent EXPERIMENTAL feature-öket ne emlegessük).

Vagy te arra gondolsz, hogy az uplink az két külön szolgáltató két külön tartománya?

Hát, nem erre gondolt (uplink váltásról beszél), de az uplink balancing, az ezt a szituációt is takarja.

És nem szerver hosting, hanem access layer.

És nem otthon, hanem irodai szinten. Mert otthonra ezt senki nem fizeti meg, ellenben láttad már, mennyi az árkülönbség egy igazi "irodai" szintű net, és egy "otthoni" között?
Kb. 4-5x áron kapod meg ugyanazt a szolgáltatást. Egy valamilyen szinten is megbízhatónak gondolt irodai netszolgáltatás 50-100 rugónál kezdődik havonta, és csak egy szolgáltatóhoz, egy vonalon fogsz csatlakozni.
Ennek a töredékéből veszel két home-stílusú, de még mindig irodainak nevezett (és a nem magánszemély előfizető miatt emelt árú) szélessávú netkapcsolatot. Amire secperc alatt feldobsz IPv4-en egy linuxot, aki arra NAT-ol per TCP connection, amerre úri jókedve tartja, és csókolom. Ráadásul nem vagy egy szolgáltatóhoz kötve (a leállások 60-70%-a a szolgáltató faszsága).

És igen, létezik BGP, de egyfelől a szolgáltató segítségét igényli (és megint ott vagyunk, hogy kedves előfizető, csengesd be az "ólcsó" szolgáltatás árának n-szeresét, hogy szóbaálljunk veled), másrészt az nem skálázódik, hogy minden iroda külön BGP tartományt hirdessen, és PI tartományt kapjon. IPv6-on se. Nem a kevés cím miatt, hanem a full BGP tábla mérete miatt.

2.6.31-es kernel van az LVS-emen, IPv6-tal, lassan egy éve megy produktív környezetbe és még semmi probléma nem volt vele. Egy rahedli ipv6-os dologra írjak, hogy ne használd mert még nincs kész, de az egész kernel soha nem lesz kész...

Nem is BGP kell az irodába, radr cuccos ott van, vagy zebra+ospf.

2.6.31-es kernel van az LVS-emen, IPv6-tal, lassan egy éve megy produktív környezetbe és még semmi probléma nem volt vele.

Ennek örülök.

Nem is BGP kell az irodába, radr cuccos ott van, vagy zebra+ospf.

Két szolgáltató + két külön ipv6 prefix, ehhez hova jön az ospf? Hogy hirdetek egyszerre két (dinamikusan kapott) prefixet bent? Hogy fogják tudni bent a gépek mindkét prefixet használni? Melyik op.rendszer ipv6 stackje tud egyáltalán ilyet? Ha meg csak az egyik prefixből van címük, hogy fognak tudni a másik szolgáltató vonalán beszélgetni?

( NagyZ v | 2011. 11. 28., h – 11:26 )

a NAT64 feature request amugy hozzank is befutott mar, lehet, hogy a fa ala mar bekerul. (NetBSD/npf)

(sot, ha jol tudom, pf -ben benne lesz hamarosan a NAT64)