Kimerült a Microsoft észak-amerikai IPv4 címtartománya, az Azure-on brazil tartományból oszt IPv4 címet az amerikai ügyfeleinek

Internet, Közösségi média

Egyes Azure ügyfelek azzal szembesülhettek, hogy ha virtuális gépet telepítenek az észak-amerikai régióban, majd azon a gépen böngészőjükkel meglátogatnak egy lokalizált weboldalt, akkor nemzetközi (brazil) weboldalon köthetnek ki. Az okot Ganesh Srinivasan, vezető programigazgató vázolta fel a Microsoft Azure blogon.

Ez azért lehet, mert az Egyesült Államok-beli IPv4-es címtartományuk teljesen kimerült, így arra kényszerültek, hogy más, nem észak-amerikai tartományaikból osszanak IPv4 címet az újabb, Észak-Amerikában felmerülő igények kielégítésére. Emiatt úgy tűnhet, hogy az ügyfelek Egyesült Államok-beli szolgáltatásai más területeken találhatók.

A Microsoft képviselője igyekezett hangsúlyozni, hogy attól még, hogy az IP cím alapján úgy tűnhet, hogy a szolgáltatás nem az Egyesült-Államokban van, az attól még fizikailag ott találhó. Emiatt nem kell az ügyfeleknek attól tartaniuk, hogy az adataik kikerültek az országból.

A Microsoft megpróbál együttműködni néhány nagyobb IP geo-location adatbázis-szolgáltatóval annak érdekében, hogy azok frissítsék a szóban forgó IP címekre vonatkozó location bejegyzéseiket.

A részletek itt olvashatók.

( trey | 2014. 06. 13., p – 10:59 )

Nem biztos, hogy a böngészőben megjelenő brazil weboldal lesz a legnagyobb bajuk azoknak a szerverüzemeltetőknek, akik ilyen IP-t kaptak.

--
trey @ gépház

root@OpenWrt:~# cat /proc/version
Linux version 3.10.36 (openwrt@gb-13) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r41163) ) #1 Fri Jun 13 03:30:59 UTC 2014

Az eszköz egy TL-WR741ND v4 router, amiben csak 4 MB flash van. Jótanács: 8 MB flash-es router ajánlott inkább, a 4 MB flash-esben mindig kérdéses, hogy például a webes felület (luci) felfér-e az IPv6 csomagjai mellé.

Most amit felraktam a frissen lerántott image mtd-vel való felírása után:

- luci
- kmod-ipv6
- luci-proto-ipv6
- radvd már nem fér fel a 4 MB flashre, csak ha nincs a webes felület (luci*) felrakva.

WAT?!

Miben különbözik a SNAT mögé dugott kliens attól, hogy a tűzfal csak kifelé enged új kapcsolatot nyitni? (Ok, a SNAT esetében nem látni kívülről, hogy pontosan melyik gép melyik - leszámítva, hogy ez sem feltétlenül igaz, a Linux netfilter pl tudtommal még mindig elég determinisztikusan osztja az IPid-t, source portokat. De az általad hozott példában kb nem oszt nem szoroz.)
---
Régóta vágyok én, az androidok mezonkincsére már!

Például azért, hogy DNAT szabállyal port forwardot tudjál csinálni. Roppant praktikus, amikor egy szolgáltatást - akár ideiglenesen - átteszel egy másik gépre. A kliens semmit sem vesz észre belőle.

Vagy éppen transzparens proxy-t akarsz üzemeltetni, ami DNAT-tal egy mozdulat (pl. összes, 80-as portra irányuló forgalmat ráirányítod a helyi proxy megfelelő portjára) DNAT nélkül azonban szívás (interceptálni kell a route-olt forgalmat, pl. TPROXY és társai, ami pl. Linux-on valamennyire működik, de nem sok minden máson...)

Leginkább sehogy nem címzel SNAT mögötti gépet, viszont amit a kifelé kapcsolódásról írsz is, annak van relevanciája. A biztonsági szakértők mostanában egész jól egyetértenek abban, hogy a támadások többsége nem kívülről érkezik, hanem egy belülről kezdeményezett kapcsolattal kezdődik. Ebben a kontextusban pedig valóban nincs túl sok pozitívuma a SNAT-nak...

A támadások többsége kívülről érkezik. Inkább a sikeres támadások többsége jön belülről. Ez azonban nem jelenti azt, hogy a külső támadók ellen nem kell védekezni. Egyszerűen nem igaz, hogy az SNAT nem ér semmit biztonsági szempontból. Van értelme, de az irányított támadások ellen nem sokat segít, ez igaz. De nem is ezt mondtam.

Egyébként azért zavart haga hozzászólása, mert én nem tudom, hogy ő kicsoda, de én már akkor tűzfalakkal foglalkoztam (tervezés és fejlesztés is), szakmai cikkeket írtam és előadásokat tartottam, mikor ő még valószínűleg általánosba járt és Legózott meg hurkapálcából szélmalmot épített technika órán. Mondjuk 15 éve. Így talán érthető, hogy sértő egy foghegyről odavetett "okosság", amit semmivel nem támaszt alá (nem tud alátámasztani?).

Ki kezdje? Ki szenvedjen el kimutatható üzleti hátrányt?

- Aki kiépíti az IPv6-ot, az miért érdekelt benne? Mert többletkiadásba verheti magát (eszköz, melós óradíj) kimutatható pénzügyi előny nélkül?
- Aki pedig netán dezertőr módon tartalomszolgáltatóként lekapcsolja az IPv4-en a szolgáltatást, az piaci hátrányt (látogató vesztést) csinál magának.

Tehát senki nem épít IPv6-ot, és mindenki szolgáltat tovább IPv4-en (is). Ezzel a kör bezárult.

Ne feledjünk egy hasonló esetet sem. Sok évvel ezelőtt nagymértékben a Youtube-nak köszönhetjük az IE6 kipusztítását, ugyanis ott sem merte senki sem felvállalni az IE6 böngészőt használó látogatók elvesztését.

Ha továbbgondolom az iménti hozzászólásomat, ha a piaci szereplők nem akarják kezdeni, még mindig van egy lehetőség: államok. Egyik a másik után. Fokozatosan, de állami segítséggel az iménti hozzászólásomban írt ördögi körből kijuthat az internet.

Itt vannak például a nagyobb egyetemek, főiskolák, állami intézmények honlapjai. Ha állami koordináció mellett előre figyelmeztetnek weboldalukon, majd tényleg leállnak az IPv4-en a szolgáltatással és csan annyi lesz kiírva ott magyarul, angolul, hogy "Csak IPv6-on elérhető. Ha ezt a feliratot látod, megoldásért fordulj az internetszolgáltatódhoz."

Ez kényszer, de hasonló, mint az analóg TV adás megszüntetése volt. Rengetegen károgták, hogy világvége lesz ez a lépés.
Aztán lekapcsolták. Először csak este egy kicsit (figyelmeztető kép), aztán esténként néhány órát (figyelmeztető kép), végül lekapcsolták (egy hónapig még figyelmeztető képet adott, aztán végleg elhallgatott).

Érdekes módon ebből sem lett világvége, csak egy sok évtizedes, mára idejét múlt technológiát sikerült kivezetni és az általa foglalt frekvenciákat felszabadítani. Azóta pedig az addigi 3 földi műsor helyett most már 30 feletti TV műsort adnak, ráadásul 16:9-ben, igazodva a mostani TV-khez. Az más kérdés, hogy ebből 8 TV műsor fogható ingyen. Lásd: http://mindigtv.hu/ és a fizetős http://www.mindigtvextra.hu/ oldalakat.

Azért az analóg TV és a v6/v4 váltás. Ott eleve a gyártók évek óta olyan tv-t toltak amiben van olyan vevő, tehát az ügyfél ha vett új tv-t akkor max újrahangolás kelett, amit max a szomszéd gyerek megcsinált. Ha ócskább TV-je van akkor vettek dobozt + hangolás esetleg szomszéd gyerek. És kész szerintem sokuk azt se tudja hogy digitálisan jön vagy nem.

Net ennél jóval jóval szarabb. Nekünk vagy 4 esetleg 5 éve van IPv6 tartományunk, hogy a lakosságnál ez mikor lesz. kb 10év. Ugyanis olcsó routerek nem támogatják mai napig, senki nem fog venni 10-15k ért routert mikor bemegy a tescoba oszt 3e kap magának. Oprendszerek nagy része XP, szintén kuka. Mondjuk nem tudom hogy W7 + PPPoE hogy áll ipv6-al, bár gondolom megy neki. Az ügyfelek 90% nak a mostani ipv4+pppoe kombo is meghaladja a képességeit. Tehát ennek bevezetés nálunk semmilyen előnnyel nem járna. Gondolom ez más szolgáltatónál is hasonló.

És ha a klienseknek nincsen ipv6 címe, akkor a szervereknek minek legyen? Ezzel a kör be is zárult.

Fedora 20, Thinkpad x220

Van vele még egy gond. Mi, Pistikék, a v4-et még úgy-ahogy be tudjuk állítani, ha nem is lesz tökéletes, azért működik.
Úgy egy éve nagy lelkesen belevetettem magam a v6 gyönyöreibe és nagyon gyorsan feladtam, mert annyival bonyolultabb(nak tűnik?) a felépítése.
PEBKAC? Lehet... de gyanítom, nem vagyok vele egyedül.
(v4-en dhcp-t, dns-t, megkockáztatom, egy alap netfilter "tűzfalat" be tudok állítani működőre, v6-on... no comment :) )
Szóval én kifejezetten tartok tőle, hogy mi a szart fogok csinálni, ha megérem a v4 pusztulását...

Azt azért el kell mondani, hogy egy ócska wifi router, amire felmegy az OpenWRT bármelyik verziója, az képes kezelni a v6-ot. Akár olyan módon is, hogy a belső háló csak V4, és kifelé V6. Wifi meg az okostelefonok okostv-k okosórák okoshűtők okoskávéfőzők korában nem kuriózum. Szerintem.

Ez ok. Csak mikor kimész az ügyfélhez és kötnéd neki a netet és már vár a 3e ft-os tescos router, ami jó ha ipv4en megy stabilan mit csinálsz?

Elkezdesz rá openwrt-t faragni? vagy megmondod az ügyfélnek hogy ugyanmár vegyen már másik és tegyen már rá openwrt-t stbstb ?

Marad az ipv4 :>

Fedora 20, Thinkpad x220

Szüleimnél T-s net van, hozta a szaki a wifis routert. Nálam UPC net van, hozta a szaki a wifis routert. Ha jól láttam ezeken valami custom firmware van (bár lehet csak logót cseréltek)

Nem tudom más szolgáltatóknál hogy van ez, de nem lennék meglepődve, ha a többség user ma már ingyen kapná a nethez a routert. Akkor meg igazán adhatna a szolgáltató olyat, ami támogatja az ipv6-ot.

Nyilván ez a szolgáltatónál valamennyire többletköltség lesz, mert drágábbak azok a routerek amik támogatják, bár nem igazán értem miért. Ha jól fogom fel ez szoftver kérdése, ha pedig az, akkor nem kellene drágábbnak lennie...

Nem olyan tiszta a helyzet mint pl ipv4-nél. T-com nál ugye pppoe-van legalábbis ADSL-en. Erre kell egy nat oszt csókolom. IPv6-nál, jelenleg 2 pppoe va, v6 és a v4. De a v6 az pppoe-val jön de DHCP-vel kapom meg a /56 os tartományt, amit nekem be kell állítani radvd vel hogy tudjam is használni. Plusz regisztrálni kell a routert egyedi azonosítóját a t-com-nál hogy a dhcpv6-client működjön. Nem tudom hogy ez pl mennyire automatizálható, de egy biztos költség, és semmilyen plusz előnyt nem ad a jelenlegi ipv4 hez. Tehát nem foglalkoznak vele, nemhiába vezették be a natot. Az is olcsóbb. Jahh és a router software-t is le kell fejleszteni azt letesztelni rendesen integrálni a rendszerbe ha van olyan stb. Ez is igancsak költség.

Szóval míg olcsóbb v4 címet szerezni, vagy natolni stb. Addig tuti nem lesz itt semmilyen ipv6 forradalom.

Fedora 20, Thinkpad x220

Lévén, hogy az IPv4 címek árát a szűkösen rendelkezésre álló mennyiség elkezdte felverni, előbb-utóbb anyagilag meg fogja érni átállni. Ez az idő még nem jött el, de előbb-utóbb el fog. Mégpedig szerintem ez először Kínában fog megtörténni.
---
Régóta vágyok én, az androidok mezonkincsére már!

Én a következőket látom ebben:

- az IPv6 szabvány eléggé elbaszottra sikerült, papíron gyönyörű, a gyakorlatban túlbonyolított, több vele a baj, mint az IPv4-gyel volt
- azaz a bevezetéshez kellene egy csomó tanulás, munka és hasonló
- egy csomó hardver nem támogatja, ezeket cserélni kellene
- amihez kell pénz.

Azaz a protokoll is elbaszott és csere is drága - akkor meg minek?

Hát, az alap protokollt nem látom annyira sötétnek.

--> IPv6 fej
--> és rá egy TCP(6)/UDP(17)/ICMPv6(58)/egyéb másik fejléc és benne a TCP/UDP/ICMP csomagbeli tartalom.

Viszont ha bonyolítani kell (auth hdr és társai), a modulárissága miatt megtehető és nem kell ethernet feletti PPP-be erőszakolva vinni az IPv4 csomagot, mint a nem moduláris IPv4 esetén.
A routereknek viszont normál esetben elég az IPv6 fej feldolgozása, az alapján választ útvonalat.

Használata terén a hexa számok és kettőspontok tömkelegét szokni kell,
+ route -6 / ip -6 / ip6tables / radvd
és néhány dologban újat tanul az ember, de a vele való hosszabb kísérletezés után nem látom alapjában véve bonyolultabbnak.

Viszont tény, hogy meg kell tanulni (idő, pénz), át kell konfigurálni (idő, pénz), több esetben új eszközt vásárolni (idő, pénz).

( uid_6201 v | 2014. 06. 13., p – 12:28 )

Kis szemezgetés a fórum archivumából.

---> 2012. Június 6-án lesz a IPv6 hivatalos kezdő napja. http://hup.hu/node/115067

Azóta
1. volt az egyik hostingban IPv6 címem, a többiben nem. Aztán az IPv6 itt is bő fél év múlva elhalt.
2. kérésem ellenére az ISP se otthonra, se a a másik ISP a céghez máig nem adott IPv6 címet. Hostingban sincs.
3. kisérleteztem IPv6 tunnel szolgáltatóval, csak hogy megismerkedjek az IPv6 további néhány gyöngyszemével. Ez a kísérletezés részemről sikeresen befejeződött.

Sajnos elmondható, hogy az IPv6-hoz kis amatőr játékon kívül 2 év alatt semmivel sem kerültünk közelebb se szerver se kliens oldalon. A szervereknek ha nem akarok drágán további IP címeket bérelni, akkor továbbra is http reverz proxy közbeiktatásával teszem elérhetővé a jelentős részüket.

Kliens oldalon mindenki megézheti a neki ma adott helyzetet: http://test-ipv6.com/

( Kobor | 2014. 06. 13., p – 14:22 )

Hmm, en ugy tudtam a LACNIC-nak elfogyott szinte az osszes IPv4-e ( http://www.lacnic.net/en/web/anuncios/2014-no-hay-mas-direcciones-ipv4-… ), ennek ellenere a Microsoft kap?

Amugy az en meglatasom szerint egy jo kis ellenorzes kellene, feneken rugasokkal otvozve, es egybol lenne IP.
Tobb kliensem is van akinek 8 IP ul a szerveren es pl csak egy site-ja van a szerveren. Az o szempontjabol a visszaadas folosleges (ingyen van).
Valamint hany meg hany server/VPS provider van aki egy dedikalt /29-el konfiguralja fel a szervert. Vagy a jobbik esetben egy dedikalt /30-al. Ezek kozul egy par supportal beszeltem es szoba kerult, sokkan nem is ertik hogy miert problema.

Azure-t speci feneken rugnam, 5 eves ceg, miert nem tamogatjak az IPv6-ot mar kezdetektol? Nem kerult volna annyiba mint most egy full eszkoz csere.
Vegulis ez lehetne egy szabaly is : tamogatjattok/szolgaltattok IPv6-on? Nem? Akkor nincs tobb IPv4 sincs.

Vegulis ez lehetne egy szabaly is : tamogatjattok/szolgaltattok IPv6-on? Nem? Akkor nincs tobb IPv4 sincs.

Még azzal is kiegészíteném: fut bármi olyan szolgáltatás ami elérhető az IP-hez tartozó host-on? Nincs? Akkor kérjük vissza azt az IPv4-et, úgysem akarja senki megcímezni.

pl. egy céges /16-os címtartományt feltölteni mondjuk ~200 szolgáltatásokat ténylegesen nyújtó hosttal és pár ezer desktoppal kicsit felelőtlennek tűnik nekem.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Leszámítva a jogi problémát, hogy hogyan is kérjenek vissza IP címeket, azért ez technikailag sem olyan egyszerű. A pazarló /16-oson belül a valóban használt szolgáltatásoknak egyenként új IP-t kéne adni úgy, hogy azok egy darab kisebb subneten belül legyenek, visszabenni a felszabadult subneteket, aztán meg összekuszálni a routing table-ket szomszédos apró, fizikailag teljesen máshol lévő subnetekkel. Meg felmerülnek egyéb problémák is, mint azt a belinkelt screenshot is mutatja: nem adhatsz luxemburgi IPV4-et a kábelnet-előfizetőnek, mert akkor nem fog tudni hozzáférni egy csomó magyar területre korlátozott szolgáltatáshoz.

Persze, hogy jogi katasztrófa (különösen nemzetközi szinten) és technikai gondok is lennének belőle (*) - csak valahol mindig a fejemet fogom, amikor "jajelfogytakazIP-címek", és a világ tele van publikus IP című PityuPC-kkel.

(*): Bár nem lenne őszinte a megértő tekintetem (és/vagy nem tudnám elrejteni az őszinte "megérdemled" mosolyt), amikor látom az összes üzemeltetőt, aki "minek DNS, azzal mindig csak a gond van"-alapon mindenhol fixen IP címekkel játszott és egy ilyen - legyen mondjuk törvényi kötelezettség miatti IP visszaszolgáltatás után - konfigulná újra az összes host-ot a hálózaton :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Hát igen, DNS. Ugyan nem publikus IP tartományban, de ugyanezt látom óriási multinál is: a szerverek, hálózati eszközök IP címe egy darab ősrégi Solaris hosts file-jában van kommentekkel számon tartva, van amelyikre van tartománynév, van amelyikre nincsen, de az alkalmazások és a felhasználók is leginkább IP cím alapján ismerik őket. Ha megváltozna az IP, akkor többszázan sírnának fel, hogy az alkalmazás vagy az asztalra rakott RDP file nem működik. Tiszta hatvanas évek...

Az a legszebb, amikor a /16-ból úgy osztanak részeket az egységeknek, hogy egy egység /24-est kap és a mellette lévő blokk másik egységhez van rendelve. Erre hivatkozva hiába a 65 ezer cím, az adott egység meg natolni kényszerül, hogy elérje a netet minden ottani gép. A címek nagyrésze pedig valószínűleg kihasználatlanul áll.

( xclusiv v | 2014. 06. 13., p – 16:28 )

Erről csak ez jut eszembe:

http://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks

Nézegetve a listát:

3.0.0.0/8 General Electric Company
13.0.0.0/8 Xerox Corporation
18.0.0.0/8 MIT
15.0.0.0/8 Hewlett-Packard Company
16.0.0.0/8 Digital Equipment Corporation
19.0.0.0/8 Ford Motor Company
20.0.0.0/8 Computer Sciences Corporation
34.0.0.0/8 Halliburton Company
40.0.0.0/8 Eli Lilly & Company
48.0.0.0/8 Prudential Securities Inc.
52.0.0.0/8 E.I. duPont de Nemours and Co., Inc.
53.0.0.0/8 Cap Debis CCS
56.0.0.0/8 US Postal Service
57.0.0.0/8 SITA

Ez itt 14 darab /8-as tartomány ha jól számoltam, a kiosztható IP címek kb. 6%-a néhány cégnél (nem szolgáltatók)

44.0.0.0/8 Amateur Radio Digital Communications

Tényleg szüksége van a rádióamatőröknek 16,7 millió címre?

51.0.0.0/8 UK Government Department for Work and Pensions
25.0.0.0/8 UK Ministry of Defence

Tényleg kell 2x16,7 millió IP cím két brit minisztériumnak? (Aztán ott van még tizenvalahány /8-as tartomány a DoD-nál, de ezt inkább hagyjuk...)

És a lexebb:
240.0.0.0/8–255.0.0.0/8 Future Use

Szóval itt van 16 darab /8-as tartomány, amivel majd egyszer talán kezd is valaki valamit? Ezt tényleg nem értem, hogy mire jó...