Biztonságos internet? Felejtsük már el az IPv4-et!

HUP
Pfeiffer Szilárd (Balasys) előadása a HWSW 2022. július 15-i SYSADMINDAY rendezvényén hangzott el.

Több mint 26 éve fejlesztették ki az IPv6-ot, a világ azonban még mindig az elavult IPv4-et használja. Előadásomban bemutatom, hogyan válhatna pillanatok alatt egy sokkal jobb, nyugodtabb, biztonságosabb hellyé az internet, ha a nagy cégek abbahagynák az ellene való lobbizást, és világszerte bevezetnék az IPv6-rendszert.

( dcsaba v | 2023. 01. 29., v – 21:02 )

Még mindig nem fogytak el az ipv4 címek? Mi volt az a qrva nagy hiszti pár éve? Talán nem a https -re hajazunk, aminek kb az az értelme, hogy az internet szolgáltatók ne tudják telebaszni reklámmal a felhasználókat csak a google.

sudo mount -o ro /hup.hu

> Mi volt az a qrva nagy hiszti pár éve?

de, elfogytak par eve. azok fogytak el amit addig senki se hasznalt. azota cserebere van meg ujrahasznositas. meg adjak-veszik a tartomanyokat egymas kozt a cegek, isp-k.  meg pl. visszaveszik, pl. anno bokezuen osztogattak pl. iskolaknak a /24-eket, most meg visszakerik ha nincs rajta forgalom.

nemreg linkeltek valahol hogy Mo-nak kb 5 millio ip-je van, szoval minden 2. embernek jut 1 :)

amugy az isk-k regota nat-olnak, CGNAT stb. meg a juzerek 90%-a mar ipv6 cimet kap, kiveve aki valamiert visszakapcsoltatta v4-re a routeret, vagy valami kis garazsceg szolgaltatja neki a netet ahol nem keszultek fel v6-ra meg. a nagyok ahol sok ugyfel van mar evek ota v6-ot adnak by default. latom a szervereink logjaban, hogy a forgalom kb 50%-a v6-rol jon, miota bevezettuk.

A CGNAT egy nagy csodafegyver. De lássuk be, sokunknak kényszermegoldás és +1 kör a szolgáltatónál. Néha vissza-visszatérő kör.
Hiába a DynDNS, ha a CGNAT nem enged haza. További hátrány, ha az egyik CGNAT mögötti előfizető miatt bannolják az IP-t például 60 percre, akkor ezzel együtt a te előfizetői végpontod is bannolódik.
Akárhogy is, ez már egyáltalán nem az az IPv4, ahol az előfizetői végpont automatikusan publikus IPv4 címre jogosult. Kényszermegoldás.

Persze IPv6 meg olyan, hogy sok főleg kisebb szolgáltatónál addig húzzák-halasszák, ameddig lehet. Hiszen minden változás újabb ügyfélproblémát okozhat.
Pedig ahogy már írtam:
   1. lépésben összes kliens (kivétel nélkül) IPv6 képes kell legyen (IPv4 mellett)
   2. lépésben lehet IPv6-only szervereket üzembe állítani.
Egyelőre az 1. lépéstől is időben nem látható távolságban állunk. Legalábbis a MINDEN kliens állapotától.

nem...

1. lepesben minden szerver legyen ipv6 kepes (ipv4 mellett). sajnos ettol is rohadt messze vagyunk meg...

2. lepesben johetnek a kliensek ipv6-ra (ezzel nem is allunk annyira szarul, mivel a nagy isp-k mar toljak a v6-ot evek ota)

3. lepesben johet a v4 kivezetese, de mint a fenti videobol kiderul, vannak orszagok ahol 5% alatt vannak, es vszinu sose vezetik be szelesebb korben, szoval ez bukta

Viszont a CGNAT-on keresztüli hazajutás és peer-to-peer kommunikációk problémáján nem segít, ha várunk arra a klienseknél, hogy előbb a szerverek 100%-a legyen IPv6 kompatibilis.
Ezért fontos, hogy a kliensek felé legyen első körben biztosítva az IPv6, és ekkor mehet még erőteljesebb CGNAT mentén az IPv4 címek nyerése, vele együtt az időnyerés. A "maradibb" szervereket pedig CGNAT-on keresztül eléred IPv4-en, a "haladóbb" szerverüzemeltetőkét IPv6-on.

De az, hogy egyik barátom végpontjáról haza tudok jönni IPv6-on, másik barátom hálózatáról pedig nem (mert ott nincs IPv6) és ezért a szolgáltató CGNAT-jában kell kivételt kérni, szóval ez szerintem égetőbb kérdés jelenleg.
Legalábbis abból kiindulva, hogy jelen állás szerint az IPv4+CGNAT szerintem sokáig velünk fog maradni.

nem olyan meglepo. szerver oldalon ott a failover/load balancing, ott az abuse / banning problema, ott van ip-alapu ACL, es meg sok-sok egyeb finomsag, ami ipv6-on *totalisan* maskepp mukodik, mint v4-en.

mi, mikor neztuk ezt par eve, arra jutottunk, hogy 3-4 team 1-2 eves munkaja lenne az ipv6 support, es jol el lett vetve, mert nem hozna annyit a konyhara, mintha azt a sok team-et tenyleges fejlesztesre fognank be.

hat ezert.

Ez mindig így van, ha a cégeken múlna, akkor még mindig mindenki a DOS-on meg XP-n lenne, mert az újabb technológiákra átállás „nem hoz annyit a konyhára”, a „régi is elég jó”, „ne nyúljunk hozzá, amíg működik”, stb.. Ezért van az, hogy végül mindent óriásmultiknak kell kikényszeríteni végső soron, különben a végtelenségig halogatók örökre meggátolnák a technológiai fejlődést, meg szívhatna mindenki a legacy szutykokkal élete végéig.

Ezt minden új technológia bevezetésénél eljátsszák, megy a huzavona, amíg valamelyik nagy, Google, MS, stb. méretű multi meg nem unja, dobatja a régi támogatását, kényszerítve az új adoptálását.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

mert az újabb technológiákra átállás „nem hoz annyit a konyhára”, a „régi is elég jó”, „ne nyúljunk hozzá, amíg működik”, stb..

de okkal am!

Amikor dual-stack ipv4/ipv6-ot csinaltam meg anno 2008 korul, es egy F5-t lottem be IPV6-on load balancolni, konkretan szejjelfagyott az F5, hibajegyet kellett nyitni.

Es meg ma is sok megoldatlan problema van ipv6-n. hogy a legutobbi v6-anyazasomat emlitsem, a kurva hazi routerem (asus, vadiuj, meregdraga gaming cucc) nem kepes fixalni az ip-cimet mac-address-hez v6-n, csak v4-n. Igy eleg nehez a klienseket megbizhatosag szerint csoportositani, szoval siman leb*tam a belso halorol a v6-t ugy cakkunpakk, szorakozzon ezzel, akinek van ra ideje.

De profi kornyezetben is rengeteg hasonlo szivas van, kezdve ugye mar azzal a veregyszeru dologgal, hogy mig a v4-nek 1:1 -ben lehet byte[] es string kozott konvertalni, addig a v6 cimet rengeteg modon lehet irni. vagy azzal, hogy mig az ipv4-nel tipikusan eleg ACL-hez az ip cim egyezese (1 cim), addig v6-nal *mindig* egy prefix match-et kell csinalni, es akar hiszed, akar nem, a legtobb platformnak a MAI NAPIG gond az, hogy 1. parse-oljon egy v6 cimet, 2. megnezze, passzol-e egy adott prefixbe, 3. kirenderelje a v6 cimet, kanonikus vagy human-readable formatumba. Probald csak ki - garantalom, mindegy, melyik nyelvben csinalod, szopni fogsz: nincs, vagy nem ugy mukodik, ahogy gondolod, vagy tetu lassu/optimalizalatlan, vagy (ismeretlen) mellekhatasai vannak. tapasztalatbol mondom.

Szal ezert varnak ki a cegek.

( ha5abe | 2023. 01. 30., h – 07:39 )

Szerkesztve: 2023. 01. 30., h – 07:41

Saját tapasztalat, hogy a szerverek működésébe zavart tud okozni, ha az ipv6 is engedélyezve van. Sok éven keresztül  próbálgattam néha, de végül feladtam.

A steam deckkem keptelen normalis IPV6 routeokat kapni, ezert le kellett tiltani az ipv6-et. Nem ertek hozza ilyen melysegben, telekom routerem van, az iOS mobileszkozok vidaman tudnak IPV6-en netezni, egyszer majd rajovok, hogy a linuxon mi faj neki. A ceges gepen meg policybol van letiltva.

Pl., hogy ha sikerül neki kapcsolódni ipv6-on, később bármilyen okból nem, akkor már meg sem próbálja ipv4-en. Feladja. Ez pl. email-t is szolgáltató szerveren elég zavaró. Ha csak az ipv4 van engedélyezve, akkor az ilyen eset nem fordul elő. Igaz ez már régen volt, de pl. ilyen emlékeim vannak.

( willy v | 2023. 01. 30., h – 08:16 )

Ok, megnéztem. Lehet rosszul nézem, de akkor mit is tudtunk meg ami nem nyilvánvaló?  Kik azok a "nagy cégek" akik akadályozzák az IPv6-ot? Sok dologban áthallásos történet, körberakva olyan dolgokkal amik teljesen függetlenek ettől. Az eszközök nagy részének már a második harmadik generációja van kint azóta mióta az IPv6 elkezdett terjedni, még mindig azok a gyengeségek hátráltatják ami itt ezen a fórumon is ki lett tárgyalva és így 10 év távlatban még mindig tartják magukat, az eszközök szoftveres támogatása javult jelentősen azóta.

Nekem (volt szerencsém 4-5 éve architectként végigszívni egy összetettebb szerver-termék IPv6-osítását) az volt a tapasztalatom, hogy hiába volt már akkor is több generáció óta IPv6 support, mivel nem nagyon használják elsődlegesnek, ezért tele van bugokkal. Túl lassan takarítódnak ki a bugok. Még az OpenSSH-ban is fogtunk IPv6 support bugot. Szinte az összes DB, MQ, clustering megoldás belső replikációs forgalmában volt IPv6 bug. Ha frontend oldalon jól is működik, a cluster belső forgalmát annyira nem teszi senki v6-ra, hogy abban nem derülnek ki a hibák. Nekünk meg ügyfél kifejezetten kérte, hogy IPv6-only módon is tudjunk működni.

Az egyik leggyakoribb problémakör az IPv6 címek írási formájának kezelésével van.

  • Tipikus, hogy a ":"-ról azt hiszi, hogy URL-ben (vagy csak simán címben) a portszám elválasztó karakter, nem kezeli le a []-es jelölést. Többnyire DNS-sel tudod csak workaroundolni.
  • A másik, hogy a v6-os címeknek nincs egy egyértelmű string reprezentációja és rengeteg szoftver stringként komparálja a címeket, nem veszi észre ha két cím eltérő írásmóddal valójában azonos.
  • Vagy megpróbálja a címet kanonikus formára hozni és úgy stringként komparálni, de akad valami sunyi corner-case, amikor hibázik (pl SSH-nál futottunk bele, volt olyan cím, amit más formában rakott be a known_hosts-ba, mint ahogy ellenőrizte, hogy már benn van-e. Így minding azzal jött, hogy ismeretlen a host fingerprint. Saját scriptből kellett betennünk a known_hostsba, hogy olyan formában legyen, amiben keresi).
  • Javascriptben volt kismillio ipv6 cím validátor library és kb midegyiknek volt valami baja. Vagy nagyon kicsi subneteket nem kezelte (/120 és kissebb) vagy a nagyon nagyokat nem (/8 és nagyobb). Nyilván le volt tesztelve a legtipikusabb "/48", "/64"-re oszt jóvan. Az IPv6 cím nem fér be egy javascript-es number-be, ezért kellett mindenféle custom reprezentációkat (tipikusan tömböket) bevezetni, aminél az első és/vagy utolsó elem tömbcímzésében volt lekezeletlen corner case.

Azok a programnyelvek, amik saját maguknak implementálnak TLS-t, DNS klienst stb. szintén igen változatos bugokat tudnak tartalmazni. Főleg python-nal szoptunk sokat:

  • Python-ban a "Green DNS" - ami akarva akaratlanul függőségként beránt egy csomó lib és lecseréli a standard DNS libc-s resolvert egy non-blocking saját python-os implementációra - gyakorlatilag nem tudott normális AAAA-s lekérdezést csinálni. Aztán verzióról verzióra variáltak a viselkedésén, de valahogy az RFC szerinti viselkedést sosem sikerült eltalálni. Másik kedvencem, hogy a fully qualified domain nevek végére is - biztos ami biztos - odabiggyesztette a lokális search domain suffixet. Így lehetett szívni pl a localhost.localdomain.localdomain feloldásával, vagy mondjuk például google.com.localdomain-re, amire ha nem kapott megfelelő választ az upstream DNS szervertől, akkor 60 másodperc timeouttal honorált minden connection nyitást. Ráadásul a GreenDNS immunis minden standard resolver konfigurációra, lokális hosts file-t is teljesen ignore-álta. Nyilván lokális dnsmasq-al meg lehetett patkolni, de akkor is...
  • Python-os cert kezeles szintén össze-vissza bugos volt, ha a cert subject name/subject altname-ben IPv6-os cím volt. Volt olyan verzió, amikor - helytelenül - a certben "DNS" típusú subject altname-et kellett felvenni és abba stringként IPv6-os cím. Persze a "szokásos" stringként komparálási bugokkal. Aztán egyszercsak úgy kijavították, hogy már nem is fogadta el validnak az ilyen certet (enyhe understatement... exceptionnel elszállt az egész), ha a "DNS" típusú mezőben IP címet talált. Persze tudom, certet nem írunk alá IP címre...
  • Amúgy ez is egy általános problémakör volt, szoftverenként igen változatos volt, hogy IPv6-ra pontosan hogyan is kell olyan certet aláírni, amit elfogad validnak.

Teljesen általános probléma még a source cím választás kérdésköre (pl ha a fogadó oldalon tűzfal source alapján engedne be, vagy kliens cert validálásnál):

  • IPv6-nál alap, hogy van legalább 2-3 címed egy interfészen. Egyazon subnetben van pl SLAAC és stateful DHCP, vagy manuális statikus IP címed is. Ha a kliens szoftver nem köti le a socket nyitásnál a source címet, akkor tipikusan a SLAAC-os címet fogja preferálni kimenő kapcsolatokhoz. Ami meg ugye MAC-cím függő, rosszabb esetben még randomizált és periodikusan változik is, és a tűzfalon nyilván nem azt fogod beengedni.

Biztos volt még több is, ami most éppen nem jut eszembe... Nyilván idő közben javulgatott a helyzet, de nem egyszerű.

Régóta vágyok én, az androidok mezonkincsére már!

huba+ ez azert durva, nem gondoltam volna hogy ilyen bugok leteznek meg... mint az ssh-s, vagy a js...

mondjuk az ipv6 -> string az tenyleg egy erdekes kerdeskor, en is szivtam vele a halozat monitorozonknal.

a vege meg nagyon igaz, foleg miota divatba jottek a temporary cimek. ha bindel ra az a baj, ha nem akkor meg az...

Ok, azért ez 4-5 évvel ezelőtti állapot, azóta máshol dolgozok, ahol hírből sem ismerik az IPv6-ot. :) Szóval szeretem azt hinni, hogy azóta javult a helyzet.

De az ssh övön aluli volt nekem is, pláne hogy ügyfélnél derült ki. Ha jól idézem fel az emlékeket, akkor ha pontosan egy darab 16 bites szakasz volt csupa 0, akkor ":0:"-ként rakta be, viszont "::"-ként kereste, vagy fordítva. Nyilván a gyakorlatban a címek kis része ilyen, ezért nem könnyen bukott ki. De már jojózott a szemem, mire kiszúrtam.

Redhatnek lejelentettük (ők voltak a linux vendorunk), aztán már nem tudom mi lett az utóélete.

 

Amúgy kíváncsiságból gyorsan ránéztem a routeremre (otthon magamnak szakmai ártalomból csináltam IPv6-os private hálózatot, ha már az ISP-m nem ad). Csak a linuxos gépeknek van egyáltalán DHCPv6-tal osztott címe. És az is /128-al van felvéve (nyilván így soha nem fogja ezt választani kimenő irányba), míg a slaac-os cím /64. Android -> random cím, melós macbookon MacOS -> random cím. Windows meg nincs itthon, azt nem tudom kipróbálni. Akár ki is kapcsolhatnám a DHCPv6-ot, így tényleg kampózérósemmit érek vele.

EDIT: Mielőtt valaki írná: a ManagedOption és az OtherOption flagek be vannak kapcsolva a radvd-n. Mondjuk az AutonomousAddress flag-et esetleg lekapcsolhatom, az talán változtat a kliensek viselkedésén, de nagy reményeket nem fűzök hozzá.

Régóta vágyok én, az androidok mezonkincsére már!

Picit félreérthető volt amit írtam, 11 éve az L2 ügyféloldali és esetenként a gerinchálózati eszközökben sem rendesen volt ez implementálva (teljesen hiányzott, vagy külön FW kellett hogy menjen) L3 szintjén meg hiányzottak belőle azok a mechanizmusok amik kihasználják a HW gyorsítást (ne minden csomag jusson el a központi CPU-ig) ezek a gyerekbetegségek és a penetráció javult, de mivel ugye másodlagos, ahogy mondod a hibák megvannak. Ennek jó része berögződés alapon, meg a sztenderd hibák. 

Igen vannak implementációs hibák, még a népszerű szoftverekben is, de ezen túl performancia hibák is vannak a legtöbb helyen.

Ezek az aktív development alatt lévő szoftverek, az elavult legacy szoftverek kérdéséig még el se értünk. 

A fennmaradó problémák amire céloztam nagy része főleg designból és annak berögzött védelméből ered (ezek 11 éve itt vannak velünk). 

Na igen, a tesztkörnyezetben voltak Cisco 3750G-k meg 4848-ak. Ezek gyakorlatilag a Cisco egymás mellett élő kortárs termékvonalai voltak, de a 3750G tudott IPv6-on route-olni, a 4848 meg nem. Vagy talán csak úgy ahogy írod, CPU-ból kb 100Mbit-et, ami egy 48 portos gigabit L3 switchhez elképesztően sovány.

Régóta vágyok én, az androidok mezonkincsére már!

( hajbazer v | 2023. 01. 30., h – 09:46 )

Az internet pillanatok alatt egy sokkal rosszabb, nyugtalanabb, sokkal kevésbé biztonságos hellyé válik, amint elkezdik a multik beerőltetni az IPv6-ot.

Pláne, az "adjunk mindennek is publikus címet, mert van elég" idealizmus csúcsra járatásával a lyukakkal teli IoT implementációk világában. Pláne a régebbi rendszerek, routerek, hálózati nyomtatók, szkennerek, egyéb eszközök inkompatíbilitásával és kidobatásával-újravásároltatásával.

Eljön még az idő, amikor az IPv6-ot a multik kikiáltják jövőnek és mindent elsöprő marketing-erőszakkal, FUD-kampánnyal, szándékos elavultatással igyekeznek majd ráerőltetni a felhasználókra. Nekem ez jelenleg egyáltalán nem hiányzik.

A local eszközök elavultatásától nem tartok annyira. Sőt, szerintem mindig maradni fognak IPv4-only alhálózatok. LAN-ban IMHO csak az lesz IPv6, amit tényleg ki akarunk rakni public-ba.

IoT: az se jobb ám, hogy jelenleg a publikus cím hiánya miatt ezeknek az eszközöknek a kilencven-sok százaléka kínai felhőhöz csatlakozik, amin keresztül zárt forrású obskúrus cuccokkal lehet őket baszogatni. Ráadásul a userek nagy részének ott lógnak ezek az eszközök a LAN-ján, így a felhőből ezeken keresztül faszán be lehet törni a privát hálózatra.
A publikus kitettség kezdetétől én azt várom, hogy muszáj lesz valamilyen védelmet beiktatni ezeknek az eszközöknek, így talán lesz végre valami elmozdulás.

Valójában szerintem továbbra is egyetlen IP-re van mindenkinek szüksége user oldalon. Ezen keresztül VPN tunnelen keresztül hozzáférve a helyi eszközökhöz. Így csak a VPN-nek kell biztonságosnak lennie, nem minden egyes eszköznek.
(A helyi rádióamatőr klub hálózatát többedszerre nyomták fel egy publicba kitett kamerán keresztül. Most dolgoznak rajta a fiúk, hogy visszavegyék a Mikrotik router fölött a hatalmat.)

az se jobb ám, hogy jelenleg a publikus cím hiánya miatt ezeknek az eszközöknek a kilencven-sok százaléka kínai felhőhöz csatlakozik, amin keresztül zárt forrású obskúrus cuccokkal lehet őket baszogatni. 

Majdnem elfelejtettem, mennyivel jobbak™ az amerikai felhőhöz csatlakozó okosotthon-kütyük, amiket csak zárt forrású cuccokkal lehet baszogatni. Azok mindentől megvédenek™ és nem™ próbálnak mindent összegyűjteni rólunk és nem™ elemeztetik ki alulfizetett alvállalkozókkal, mit beszélgetünk otthon a szobában.

A publikus kitettség kezdetétől én azt várom, hogy muszáj lesz valamilyen védelmet beiktatni ezeknek az eszközöknek, így talán lesz végre valami elmozdulás.

Vagy muszáj lesz kidobatni a most megvett, nem biztonságos eszközöket, mert amikor multiék kamuinnoválnak egy kicsit, akkor hirtelen eszébe jut a tech-médiának, mennyi veszély™ leselkedik ránk.

Valójában szerintem továbbra is egyetlen IP-re van mindenkinek szüksége user oldalon. Ezen keresztül VPN tunnelen keresztül hozzáférve a helyi eszközökhöz. Így csak a VPN-nek kell biztonságosnak lennie, nem minden egyes eszköznek.

Ebben egyetértünk.
 

Mert az átlagos vevő árérzékeny, mint a picsa.

Mert Kína (egyik) komparatív előnye, hogy bármiből ~bármennyit tud gyártani.

Mert egyszerűbb rendelni egymillió kínai terméket, és azt ellátni szintén kínai "Designed in the US" matricákkal, mint gyártósort építeni és fenntartani.

Ilyesmik jutnak eszembe. :)

Lehetne ezen változtatni? Lehetne. Akarunk rajt változtatni? Nem. Miért nem? Mert a profit rövid távon csökkenne és az nem jó. De hogy a kínaiak is egyre drágábban dolgoznak és ott is szigorodnak a környezet- és munkavédelmi előírások, az is egyértelműe látszik. + a Covid, a szállítási láncok, a konténerhiány, a csiphiány és a kecske... ez már nem az a kínai klónhadsereg mint ami régen volt. Hozták a szintet tudásban is. Akinek ez nem tűnik fe, az húzza ki a fejét a homokból. Itt már nem lehet karban tett kézzel ülni. A következő célpiacuk az elektromos járművek. Most kezdik az olcsó akkukat és olcsó járműveket önteni a drága nyugati piacra. Nagyjából ez a kezdet a nyugati autógyárak végének kezdete. Ha mellétesszük a VolksWagen ID.3 bohóckodását, hogy még mindig nem sikerült végleges szoftvert kiadni, hogy hónapokig, több mint egy évig álltak a legyártott autók mert nem volt használható szoftverük. A BMW sem kapkodja magát, az 50 milliós luxus merciben olyan alap dolgok hiányoznak, mint a dönthető ülés.. és mindezek tetejébe még jól tökörúgtuk magunkat, megy az olcsó orosz gáz a kínai gyárakba, az európaiak meg emelik az árakat mert az akadozó alkatrészellátás tetejébe még az energia is: vagy nincs vagy nagyon drága. Szóval ebből itt nem mostanában lesz olcsó, megfizethető, modern kész termék. Az usa még megtehetné, de ők azt is megtehetik. EU-nak nincs mire várni. Ha megépülnek a közvetlen vasúti összeköttetések is, azok sokat gyorsítanak a tengeri szállításhoz képest és sokkal olcsóbb lesz a légihez képest. Nagyon nagy hátrányban vagyunk és ennek nem Kínában kell az okait keresni. Nyilván ez nem neked szól személyesen, de sokan még mindig mutogatnak. Nem mutogatni kell már, hanem lépni.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Akarunk rajt változtatni? Nem. Miért nem? Mert a profit rövid távon csökkenne és az nem jó.

Ja, csak tegyük hozzá a másik oldalt is, hogy amikor a 200 forintos aliexpress-es szart innentől ötezerért kapnád, akkor meg azon sírnának az emberek, hogy a magyar vállalkozó biztos nyerészkedni akar, azért adja drágán!!!4

Jelenleg a magyar állam és Brüsszel nyerészkedik rajta vámmal. Egy ideig ment a hiszti, aztán mindenki szépen kifizeti a vámot.

Az olcsóság nem ad a létjogosultságot a silány minőségű termékeknek. Azokat alapon tiltani kéne a piacról. Különben előbb-utóbb minden erőforrásunkat elpazaroljuk és feléljük.

Brüsszel nélkül is nyerészkedni akartak. Különben nem is érné meg boltot fenntartani. 2 éve kértem árajánlatot egy kisebb kamerarendszerre. 4 kültéri kamera legalább fullhd, éjjellátóval és egy nvr. Akciósan kaptam egy közel 200 ezres ajánlatot. Természetesen az is kínai ha innen nézzük. És semmivel sem jobb vagy rosszabb mint a többi. Ezek után azért úgy kíváncsiságból körülnéztem a neten. Nem aliról, de kínai cégtől rendeltem EU raktárról a következő csomagot: 8 db Poe kültéri 2K kamera, infrával, 1db 8 portos poés NVR. 8x20 méter szerelt kültéri UTP kábel. Minden kamera mellé járt egy 1A-es táp is passzív tápfeladóval és kültérre a csatlakozáshoz vízálló nyitható tömszelence, valamint tiplik és csavarok, szóval tényleg mindenre gondoltak. Nem is valami noname cucc, hanem ESCAM. Ez a fő profiljuk, régebb óta használom a megoldásaikat és hozza az elvártakat. Ja, igen a csomag ára: 85.000 ft-ba került szállítással és 2 nap alatt itt volt. Csak egy HDD-t kellett vennem bele. Ha megnézzük, ez minimum 4x-es ár volt itthon és az a csomag nemcsak darabszámban nem ért fel a másikig. Úgy gondolom, hogy ez a fajta árazás itthon és az EU-ban indokolatlan. A balatoni árakhoz tudnám hasonlítani, amikor valaki 3 hónap alatt akar meggazdagodni. Dolgozom igazi nagyágyúk cuccaival is, nem akarok most neveket írni, de muszáj lesz pl. egy Hyundai, IdentiVision vagy Milesight rendszer nem kerül annyiba mint mondjuk egy itthon nem értem miért olyan népszerű Hikvision. Pedig brutális a különbség tudásban (konfiguráció, szolgáltatás), supportban, sebezhetőségeket tekintve.

Szóval én otthonra akartam valamit és ennek fényében abszolút indokolatlan volt ez a magas árképzés. Ha piacot veszítenek a hazai kereskedők, abban lehet, hogy van saját tehetségtelenség is.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Teljesen mindegy, milyen felhőhöz csatlakozik. Én se ezt, se azt a felhőt nem szeretem.

Szerintem nem lesz kidobni a meglévő eszközöket. Az új eszközök se lesznek biztonságosabbak. Eleve egy tévút szerintem, hogy dolláros hardverek tömegétől várjunk el biztonságot. Ezeket el kell tenni a picsába külön vlan-ra, megfelelően tűzfalazva.

Majdnem elfelejtettem, mennyivel jobbak™ az amerikai felhőhöz csatlakozó okosotthon-kütyük, amiket csak zárt forrású cuccokkal lehet baszogatni. Azok mindentől megvédenek™ és nem™ próbálnak mindent összegyűjteni rólunk és nem™ elemeztetik ki alulfizetett alvállalkozókkal, mit beszélgetünk otthon a szobában.

Nem, az sem jobb. Kurvára local IoT-t akarok. Egy vezérlővel, amin keresztül "baszogtatom". A felhőjét meg a zárt szarát mindegyik vigye a sunyiba.

A kínai azért mérvadó csak, mert kb filléres. (pl faék PIR mozgásérzékelő vagy kontact között tud lenni 10x-eres különbség és mindegyik felhős, csak a drágábbat nem kínában csinálják) 

"IoT: az se jobb ám, hogy jelenleg a publikus cím hiánya miatt ezeknek az eszközöknek a kilencven-sok százaléka kínai felhőhöz csatlakozik, amin keresztül zárt forrású obskúrus cuccokkal lehet őket baszogatni. Ráadásul a userek nagy részének ott lógnak ezek az eszközök a LAN-ján, így a felhőből ezeken keresztül faszán be lehet törni a privát hálózatra.
A publikus kitettség kezdetétől én azt várom, hogy muszáj lesz valamilyen védelmet beiktatni ezeknek az eszközöknek, így talán lesz végre valami elmozdulás."

A kínai felhő még mindig sokkal biztonságosabb mint kívülről bárki által elérhető IoT ipv6 címek használata. Mert jönnek a "because I can" harcosok majd a IoT eszközök lázadása a háztartásban. Ha nem akarunk kínai felhőt, meg amerikai felhőt arra a biztonságos megoldás ipv6 alatt ugyanaz akárcsak ipv4 alatt: OpenVPN. 

A kínai felhő még mindig sokkal biztonságosabb mint kívülről bárki által elérhető IoT ipv6 címek használata.

Ez igaz. De ahogy a home routerekben teljesen természetes a MASQUERADE szabály a firmware-ben, ugyanolyan természetes lehetne a v6 stackban a forward tiltása a WAN interface felől.

Nem látom a különbséget. A befelé jövő kapcsolatok alapból eldobása (persze a felépültek engedélyezése) pont ugyanazt eredményezi, mint az IPv4-ben a default MASQUERADE. Pont ugyanúgy fog (vagy nem fog) működni a net.

Olyan szabálykészletet kell betenni, ami a default és biztonságos működésre jó, az pedig pont az, hogy ESTABLISHED,RELATED ACCEPT, minden más meg DROP.

Aztán ha a usernek más kell, állítsa be, mint v4-en a portforwardot.

A zixpé csak korlátozottan IPv6 képes. Ha ráküldesz folyamatosan változó prefixekkel RA csomagokat akkor konkrétan órákra képes max CPU használattal letérdelni. A 7-es - ha jól emlékeszem - az első 100 prefix után azt mondja hogy jóból is megárt a sok és ignorálja az újabbakat.

Pláne, az "adjunk mindennek is publikus címet, mert van elég" idealizmus csúcsra járatásával a lyukakkal teli IoT implementációk világában

Szerintem önmagában az, hogy darabszámot tekintve jutna publikus IP cím mindennek, még nem jelenti azt, hogy muszáj tűzfal meg egyéb bizbaszok nélkül kilógatni a hűtőszekrényt az internetre.

( pink v | 2023. 01. 30., h – 09:52 )

Sokkal egyszerűbb lett volna a történet, ha nem találnak ki egy teljesen új stack-et, hanem minden maradt volna ugyanúgy, mint v4-ben, kivéve a hosszabb cím. Így az átállás nem almáról körtére kellene, hogy megtörténjen - amitől mindenki fázik -, hanem almáról egy nagyobb almára.

Ford Fairlane jut eszembe az IPv4 -> IPv6 átállásról: mindenki nagy lelkesen nekiáll, mint a sajtreszelővel rejszolásnak, mert először érdekes. Aztán rájönnek, hogy inkább fájdalmas.

( persicsb | 2023. 01. 30., h – 11:53 )

Az IPv6 iskolapéldája a design by committee és second-system effect problémáknak.

A jövő™ a túltervezett rendszereké és a mesterségesen kreált problémákra adott megoldásoké, amiket majd túlárazva adnak el a túltervező mérnököket foglalkoztató multik, végső soron azért, hogy IT-nagybefektetőéknek még egy buborékkal több legyen a Jakuzziban.

Az IPv6 tervezésénél még sehol nem voltak a nagy multik (1992-ről beszélünk, az egész internet kevesek kiváltsága volt), kutató emberkék raktak össze egy idealizált valamit, nem fősodratú mérnökök voltak, hanem elefántcsonttoronyban élő tudósok. Benne volt a CERN, a Xerox, az IETF emberei, az MIT, a NEARNET. Adott persze bele embert a Cisco, a Microsoft és a Novell is.
Az RFC 1883-mat is a Xerox PARC és az Ipsilon Networks két embere nyújtotta be 1995 decemberében.

Tegyük azt is hozzá, hogy egy cloud-on csüngő-lógó világot nincs értelme úton-útfélen publikus címekkel ellátni.

Így is dollármilliárdokat pazarlunk el az adatközpontok működtetésére. Publikus IP címeken load-balancer-eket használunk.

Egy peer-to-peer világban még lenne is értelme az átállásnak, de ott se erőltetve, gépkidobatva.

Ez így van, de nem tudom mi a bajod az IPv6-tal. Mi ellene az érved. Igen, kompexebb, de mivel a 90-es évek közepéből való, így még nem olyan brutális. Ha ma akarnának helyette valamit kitalálva, az annyira túl lenne bonyolítva, hogy mindenki befosna. Nekem egyébként mindegy, IPv6, vagy valami, amit kitalálnak most, csak ne halogasson mindenki a végtelenségig IPv4-gyel. Ennyi lenne a lényege, hogy ha már van újabb szabvány, és a legtöbb eszköz, szoftver, és nagyon sok szolgáltató támogatja, akkor használjuk, és ne ragadjunk le egy réginél.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( Zsugabubus | 2023. 01. 30., h – 14:34 )

Szerkesztve: 2023. 01. 30., h – 14:43

Ez a legkisebb subnet a /64 egy jó nagy baromság.

Aztán meg az ajánlás, hogy emiatt /48 legyen egy ügyfélnek a kiajánlott címtartomány. 2^(64+16) host / ügyfél? Minek? Hogy ember már végképp ne jegyezhessen meg egy címet?

Ennek ellenére nézem pl. a Digi által kiosztott tartományt, az csak egy sima /64-es, tehát hiába van egy rahedli címem, subnetelni nem tudok velük.

Azt pedig mi garantálja, hogy az ISP-től kapott prefix állandó? Így a belső címeim ki vannak szolgáltatva az ISP kényének-kedvének.

Ez a legkisebb subnet a /64 egy jó nagy baromság.

Nem. Az a nagy baj, hogy IPv4 esetén (kényszerből) lementünk /24 alá.

Aztán meg az ajánlás, hogy emiatt /48 legyen egy ügyfélnek a kiajánlott címtartomány. 2^(64+16) host / ügyfél? Minek? Hogy ember már végképp ne jegyezhessen meg egy címet?

A /48-on belül úgy számozol magadnak, ahogy jól esik. Használhatod helyi hálózati címnek a "nulladik" címet is, de akár az 1-est is. Azt sem bírod megjegyezni?

Ennek ellenére nézem pl. a Digi által kiosztott tartományt, az csak egy sima /64-es, tehát hiába van egy rahedli címem, subnetelni nem tudok velük.

Ha ilyen van, azért a szolgáltatót kell megbaszni, bár emlékeim szerint DIGI-nél csodásan megy a DHCPv6 PD.

( bazso | 2023. 01. 30., h – 14:48 )

Kár belénk az IPv6, amikor az új generációnak már az IPv4 alap tudás is kezd kiveszni, mert "just works". 

Igazából ott várom az IPv6 elterjedését, amikor az is "just works" lesz és konkrétan a júzer már annak sem lesz tudatában, hogy melyiket használja

> a júzer már annak sem lesz tudatában, hogy melyiket használja

ez mar most is igy van, az egyszeru juzerek tekinteteben.

szerintem ha megkerded Marika nenit facebookozas es skype-olas kozben hogy ipv4 vagy v6 cime van, mit fog valaszolni?

Tenyleg, most hogy mondod, nekem is feltunt ez a fajta elbutulas. Apropo, v6: fejlesztoi oldalrol is megfigyeltem ezt; soha nem felejtem el, amikor a fejleszto behivatott szonyeg szelere, mert "ugy allitottam be a http proxyt, hogy az MAC cimeket adjon vissza neha".

Error: nmcli terminated by signal Félbeszakítás (2)

Bár én csak hobby coder vagyok, tehát néha kis C++, bash és nagyjából ennyi. Üzemeltetek főleg hálózatokat, dee azért amikor egy-egy ismerős "programozóval" beszélgetünk, szinte mindig kiderül, hogy amúgy halvány lila fingjuk nincsen alapvető dolgokról. Sokan tényleg annyira nincsenek tisztában a dolgokkal, hogy 1024 a váltószám mert 2-es számrendszer hatványai és a kecske... miért is teszünk különbséget a b és B között, a 8-as váltószám, mi a különbség a kB és a kiB között. (Ugye miért nem 200GiB egy 200GB-os lemez). Ha már a hálózatokról beszélünk, meg sem lepődök semmin. Nem is az a baj amúgy, hogy nem ért hozzá, hanem hogy nem is érdekli mert ő elvan azzal, hogy ezt meg azt a pszeudokódot vagy jackson-ábrát vagy bármit kódold le X nyelven aztán csoki. Ez szerintem nagyon kevés. Tudom, hogy munka van vele és fókuszálni kell mert hibákat vétesz és utána debug, keresés, kutyafülem monoton, stb. De ha már informatikusoknak nevezzük az összes "fejlesztőt"... sőt, ők a nagybetűs informatikusok, legalább az alap dolgokat légyszi. Oké ha egy megasabb szintű protokollal kommunikálnak az eszközök, akkor nem biztos, hogy kell IP vagy MAC, de szerintem van egy minimális általános tudásszint, mint ahogyan ismerjük az ábécé DZS betűjét is.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

( Kobor | 2023. 01. 30., h – 16:07 )

Ipv6 alatt nem lesz DDOS? DOS? Virus? Ipv6-al nem fognak bugzanni a szervizek es nem hackelik meg a szervereket ? Otthoni szamitogepet ? Ne fogjak titkositanni a fileokat majd valtsagdijat kerni erte ?

Esetleg pl egy DDOS eseten automatikusan a source DDOS-olo tiltodik le a sajat ISP-jenel, es nem a tamadott felet vagjuk le az internetrol ( mint sok esetben most )

Szoval hogy lesz biztonsagosabb ?

Egyébként most megnéztem a videót és csak a cím a clickbait. Az előadás valójában sokkal árnyaltabb és reálisabb.

1-2 dolgot említ, ami security szempontból előrelépés lenne: olyan szolgáltatások mint Shodan, nem működne, mert nincs esélye a teljes címtartomány portscannelésére. Ha nincs 6to6 NAT, akkor egy eszköz - egy cím van, így lehet IP alapon bannolni a problémás forgalmat, nem kell félni, hogy járulékos kárként párszáz-párezer más felhasználót is kitiltottál. IPSec AH-val (ami persze nem lett kötelező az IPv6-ban, csak szerették volna) az IP spoofolás kivédhető lenne. Beszélt még arról, hogy ha az IPSec ESP-t sikerült volna kötelezővé tenni, akkor a TLS-re igazából nem lenne szükség, és sokat egyszerűsödne az egész stack, de ez már "történelmileg így alakult".

Az érzésem az volt, hogy többet beszélt egyébként a potenciális buktatókról és hátrányokról. Számomra a cím inkább úgy értelmes, hogy az átmeneti állapot szűnjön meg (preferáltan a v4 kivezetésével), mert a mostani helyzetben a v4 és v6 hátrányait egyesítettük.

Régóta vágyok én, az androidok mezonkincsére már!

( Oregon | 2023. 02. 01., sze – 07:38 )

Szerkesztve: 2023. 02. 01., sze – 07:38

Van itt olyan aki jól elvan az ipv4-gyel, de a videó hatására ipv6 fan lett? (Csak a cikk címe miatt kérdezem)

Ahogy fent is írta valaki, nekem alapvetően nincs bajom a v6-tal (annakidején részt vettünk a népszerűsítésében is).
Az a bajom, hogy IPv4-gyel elég jól elvagyok, komplex dolgokat felkonfigurálok, van hozzá affinitásom, ha gond van, ráérzek, hol keressem.

IPv6 meg unfamiliar. Szerintem nem vagyok ezzel egyedül.

Az IPv6 egész egyszerűen túl komplex ahhoz, hogy egy átlagos tudású, műszaki affinitású, de nem hálózati szakember Józsi pár óra netes olvasgatás után otthon összerakjon magának egy olyan hálózatot, amit akarna, pl. VLAN-okba leválasztott okosotthon eszközökkel (műszaki affin Józsinak van ilyen) stb. IPv4-gyel ezt meg tudja tenni.
 

Mindenre van sok lehetőség, és találd el azt, amit az eszközeid otthon egységesen támogatnak - akár a firmware dolgokról, akár a végfelhasználói szoftverekről van szó.

Szerintem ez nem így van, ezt az látja így aki az IPv4 irányából indult. Az IPv6 komplexitása megvalósítás tekintetében lehet, de ott is inkább egyszerűsít, mivel bizonyos hákolásokat el lehet hagyni.  

A probléma a kompatibilitási kérdés és a "miért csináljam", amíg nem lesz szignifikáns előnye addig ez ilyen mederben fog csorogni, még évek kellenek arra is, hogy ledolgozza az IPv4 sokéves implementációs előnyét.

A video címében el kívánja felejteni az IPv4-et, közben a videó arról szól, hogy mire az IPv6 elérné azt a szintet, hogy mindenki implementálni akarná, már lesz újabb. Ezt 10 éve is lehetett sejteni, ezért nem kellett 10 évet várni. A lobbi pont abba az irányba ment, hogy ha lehet győzzük le azt az obskúrus gondolkodást amivel körömszakadtáig védik bizonyos design hibákat és gáncsolják a megoldási javaslatokat. 

Szerintem ez nem így van, ezt az látja így aki az IPv4 irányából indult. Az IPv6 komplexitása megvalósítás tekintetében lehet, de ott is inkább egyszerűsít, mivel bizonyos hákolásokat el lehet hagyni.

Ezzel teljesen egyet is értek.
Számomra alapvetően szimpatikus az IPv6. Átgondoltabbnak, jobban tervezettnek tartom.
Mégis, mivel készség szinten nem uralom az IPv6 hálót, ódzkodom tőle. Élesben inkább kerülöm, ha arra lehetőség van.

Szerintem ilyen prózai dolgokon múlni tud valaminek a sorsa.

Egy időben itthon tapasztalatszerzés céljából csináltam v6 hálózatot is (kihasználva a HE felé nyitható ipv6 tunnel lehetőséget), de elég rossz tapasztalatot szereztem. Az SLAAC sima ügy, gyakorlatilag szinte out-of-the-box működik, azonban a dhcpv6 bekonfigurálása környékén elég komoly gondjaim voltak, elsősorban azért, mert nem igazán találtam megfelelő dokumentációt. Az isc oldalán gyakorlatilag van man aztán kész, az pedig, hogy a címet bejegyezze a DNS-be - forward és reverse zónába egyaránt - nem akart összejönni, viszont erre a man-nál részletesebb leírást, howto-t egyebeket nem nagyon találtam.

Szóval ha csak szimplán ipv6-ot szeretnék - kliensként - az nem gond, de ha kicsit továbbmennék, ott már nem egyszerű a helyzet, és nem (csak) azért mert IPv4 irányból indultam (ki nem?).

Szerintem itt is azzal lehetett gond, hogy IPv4 oldaláról kívántad bekonfigolni és azt nem tudtad ráhúzni az IPv6-ra. Értem, hogy azt hiányolod, de doksi sem volt hozzá. Szerintem azok a doksik amik nem "Így csináld lépésről-lépésre" jellegűek egy IPv4 fogalmaihoz új embernek is kihívást jelentenek. 

De azóta biztosan más élményed lenne (nem rábeszélés csak mondom, nehéz lerakni egy másik szemüveget)

De akkor ezek szerint a tervezői nem gondoltak arra, hogy egy ilyen komoly váltásnál nagyon komoly oktatóanyagoknak, nagyon jó dokumentációknak kell meglennie - mert alapvetően ez is a humánfaktoron bukik el. Lehet egy rendszer nagyon jóltervezett, nagyon mérnöki, nagyon jó, csak éppen a használói emberek lesznek és nem gépek.

Az szerintem természertes, hogy IPv4 alapon közelíti meg mindenki, ugyanis nincs olyan anyag, ami nem azzal indulna, hogy az IPv6 az IPv4-hez képest milyen. Nem önmagában tekintik a protokollt, hanem mindig az IPv4-gyel összehasonlítva. Tudsz olyan tananyagot mondani, ami önmagában tárgyalja az IPv6-ot? Még maga a specifikáció is az IPv4-re hivatkozik sok helyen, az IPv4-hez képest mutatjabe a protkollt: 

 

Introduction

   IP version 6 (IPv6) is a new version of the Internet Protocol (IP),
   designed as the successor to IP version 4 (IPv4) [RFC791].  The
   changes from IPv4 to IPv6 fall primarily into the following
   categories:

....

     Some IPv4 header fields have been dropped or made optional, to
         reduce the common-case processing cost of packet handling and
         to limit the bandwidth cost of the IPv6 header.

          .....

         

   Extension headers are numbered from IANA IP Protocol Numbers
   [IANA-PN], the same values used for IPv4 and IPv6.

       .....

       

 

A dokumentumban sok helyen úgy fogalmaznak, hogy az IPv4-hez képest mi az eltérés (azaz tudnod kell az IPv4-et is, ha az IPv6-ot meg akarod érteni). Ez didaktikai szempontból is rossz. Szóval nem értem, mi a gond azzal, ha valaki az IPv4 alapról közelíti meg az IPv6-ot, maga a protokoll specfikáció is így jár el. Mutass olyan tanagyagot, ami nem ilyen, hanem 0-ról indítja az IPv6 hálózatok megértését.

Ez kb. egy-másfél éve volt, szerintem nem sokat változott. Az 'IPv4 oldalról kívántad bekonfigurálni' nekem nem mond semmit, kissé bullshit szagú. Ha gondolod, kifejtheted, persze.

nem rábeszélés csak mondom

A szolgáltató nem ad v6-ot (lehet, hogy adna de ha CGNAT az ára, akkor nem kell). A HE tunnel jó volt, csak sajnos dual-stack esetében default az ipv6, így egyszrészt v6 esetén a sávszélességet a tunnel limitálja (ez lenne a kisebbik baj, mert elegendő volt), ráadásul IP tartomány alapján a HE tunnel nem magyarnak látszik, így az olyan szolgáltatások, amelyek csak Magyarországon érhetőek el (pl. a szolgáltató interneten vehető TV-műsora) helyből nem mennek, csak ha lekapcsolom a v6-ot. Pedig játszanék én vele tovább, de az ilyen jellegű problémák miatt egyelőre félretettem az egészet.

A GW egy Ubiquiti Edgemax cucc volt (egy Edgerouter POE5), ez végződtette a HE tunnelt. És persze ezen futott a RADVD a v6 tűzfal, tehát megoldotta az SLAAC-t és a normál kapcsolatot. Ebből a szempontból sikeres volt a beállítás, ment a net ipv6-tal, teszt szerint is minden OK.

Ezen viszont nem olyan egyszerű dhcpv6-ot beállítani, dhcpv6 servernek egy külön gépen (Debian egy Intel NUC-on) használtam isc dhcp servert, ezen kívül ezen a gépen fut a bind is. A címeket mindenki rendesen megkapta (SLAAC), amit el szerettem volna érni, hogy az AAAA és a PTR rekordok be tudjanak kerülni a DNS-be. A megfelelő forward és reverse zónák megvoltak (a forward persze ipv4-en teljesen jól működik, oda beíródtak a rekordok, de az AAAA már nem)