Linux 3.7: IPv6 NAT

  • Add protocol-independent NAT core: commit
  • Add IPv6 NAT support: commit

( goodbyte v | 2012. 12. 30., v – 11:12 )

Nem arról volt szó hogy IPv6-ba nem lesz (nem kell) NAT? Akkor most mégis ?

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

Nem is lenne rá szükség, csak néhány idióta képtelen mást megtanulni "mer' ez már egyszer bevált" (legalábbis ránézésre jó volt), képtelen annyira utánaolvasni a dolgoknak, hogy felfogja, hogy mit jelent az, hogy egy tartományt kapsz a szolgáltatótól, ezenfelül képes 2012-ben még mindig elhinni, hogy a NAT pótol egy jó csomagszűrőt (nem), miközben meggyőződése, hogy csomagszűrést nem lehet mindenben legalább olyan jóra beállítani, mintha NAT is ott lenne (de).

Vagy tegyük fel, hogy valaki még értene is az IPv6-hoz, az ügyfele nem képes egy tartománynak access jogot adni, hanem csak egy IPv6-os címnek, mert fogyatékosok, akkor ha több gépről szeretne odacsatlakozni, bármennyire is okos lenne alapból hozzá, kénytelen ezt a csúnya megoldás kategóriás NAT-ot használnia. :(

vagy mondjuk vegyük azt az esetet, hogy a "fogyatékosok" nem technikai-onanizációt akarnak, és nem azért hiszik magukat különbnek, mert be tudnak állítani egy IPv6 alapú hálózatot. Hanem több dolog miatt szeretnék, ha belül lenne IPv4 a régi eszközökhöz és gépekhez, és IPv6 az új rendszerben.

Nekünk egy ügyfelünk privacy okokból jelentette ki azt, hogy a munkaállomásokon V6 addig nem lehet, amíg nincs hozzá NAT. Nem akarják, hogy az intézményen kívül is követni lehessen az egyes munkaállomások tevékenységét az IP cím alapján.

Ezzel műszakilag nem igazán lehet vitatkozni, a mögöttes okokat pedig nem ismerem..

De IPv6-nal minden gepen be kell allitani, nem? Vagyis, az IPv6 egyik hatranya szerintem pont a decentralizaltsaga, mivel nincs egy kozos pont, ahol minden bejovo forgalmat szurni lehetne. De lehet, hogy tevedek, mert en csak alapszinten ertem az IPv6 logikajat...
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Igen, csak a jómunkásember intézményi rendszergazdák nem arról híresek, hogy rajonganak az egészen új logikát követő technológiák elsajátításában, bevezetésében. Több évtizedig az volt a gyakorlat, hogy a hálózati mindenes gépen (routing, firewall, dns, etc) szabályozzák a belső hálózat és az Internet viszonyát, és nem munkaállomásonként.

--
http://neurogadget.com/

Ez a kisebbik problema, nagyobbik gond, hogy a konfig fajlok menedzsmentje sokkal nagyobb effort, mint egy kozponti gep managmentje.

Mert nem mindegy, hogy ha valamit valtoztatni kell a halozaton, akkor csak egy gepet kell modositani, vagy az osszeset. Mivel Linuxra meg mindig nincs olyan megoldas, mint windowsra a GPO, igy nem trivialis a megvaltozott konfig fajlok teritese a kliensgepekre. A kozponti konfiguracio menedzsment cuccok (cfengine, puppet) meg azert nem jok, mert halozatot konfiguralunk, ezek meg halozaton mukodnek... nem a legjobb parositas.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az alapvető felállás nem fog változni. 'N' fele megy a csomag, ahol 'N' a kapcsolatok száma, mert valahogy átadják a tartomány(oka)t. Ezez a pontok azok, ahol a csomag, session, protokoll és egyéb szűrés megvalósul.

Nyilván ilyen hálózatokban felértékelődik a szerepe a hardveres tűzfalaknak, de egy jobb tűzfalban most is külön engeded a forgalmat meg külön natolsz.

"Nem akarják, hogy az intézményen kívül is követni lehessen az egyes munkaállomások tevékenységét az IP cím alapján."
Azt ugye tudod, hogy ennek a megvalósításához nem elég a NAT önmagában?
Elég sok layerbe bele kell nyúlni hozzá (adott esetben a legfelsőbbig). Ha pedig már ilyet csinálsz, alkalmazásszintű tűzfalat használsz, azaz a NAT teljesen felesleges...

Sikerült műszakilag vitatkoznom vele?
--
zsebHUP-ot használok!

Érvnek jó, de csak az IP címen alapuló követést akarják megakadályozni. Ez nem indok arra, hogy proxy (tűzfal) legyen -ami mindenki dolgát megnehezíti- addig, amíg van egyszerűbb megoldás (V4+NAT). Végszükségben persze megfelelne, de a V6 nem végszükség, még csak nem is szükség..

Meg lehetne oldani azt is, hogy x összegért kérhetsz újat a szolgáltatódtól (IPv6 esetén új tartományt, akár olyat, amit még senki nem használt), y összegért kérhetsz dinamikusat.

Jó, tudom hogy a default dinamikus IP, fizetős fix IP nagyobb fejős tehén a szolgáltatónak a vállalati környezetek miatt.

Amúgy kaptam már olyan IP-t a (nagy multi) szolgáltatómtól kb. egy éve, amelyet a Youtube (Google) se látott Magyarországi IP-nek. (pár videóra csak én kaptam not available in your country üzenetet az ismerőseim közül). Ez magától elmúlt azóta.