UberGeek

Dacă tot se termină adresele IPv4 și RDS a început să ofere adrese IPv6, mi-am luat inima în dinți și am zis „hai să încerc și eu, măcar să văd dacă merge”.

Setup-ul folosit? Foarte simplu – una bucată router Cisco 881W, plus una conexiune RDS fiber-link.

Etapa 1 – citirea documentației.

Aflu că trebuie să activez serviciul online la RDS – nu-i problemă, 2 click-uri și se rezolvă.

După ce îl activez, aflu că „tot ce trebuie să faceţi în acest moment pentru a începe testele este să adăugaţi cuvântul “ipv6test” (case sensitive) în câmpul “Service Name” al clientului PPPoE”.

Pare simplu, numai că… oricât sap prin documentația Cisco, nu reușesc deloc să găsesc cum se setează „Service Name”. Sau, mai exact, găsesc doar cum se folosește el pe partea server-side, nu și cum (sau dacă) l-aș putea seta eu ca și client.

Noroc că dau pe net peste techtorials.ro . Unde Liviu listează exact configurațiile necesare. Profit de ocazie pentru a-i mulțumi încă o dată!

Etapa 2 – configurația propriu-zisă.

În cazul meu, interfața externă (PPPoE) este Dialer1 (peste interfața fizică FastEthernet4), iar interfața internă (spre LAN) este VLAN1. Configurația de adăugat arată cam așa:

ipv6 unicast-routing
ipv6 cef

ipv6 route ::/0 Dialer1 FE80::1

interface FastEthernet4
pppoe enable
pppoe-client dial-pool-number 1 service-name “ipv6test”

interface Dialer1
ipv6 enable
ipv6 address dhcp
ipv6 dhcp client pd PD_PREFIX

interface Vlan1
ipv6 address PD_PREFIX ::C:15C0/64
ipv6 enable

Pare simplu… n-ar trebui să îmi ia mai mult de 10 minute să îl configurez…

Etapa 3 – versiuni și licențe.

Începe distracția – constat că sunt comenzi care nu sunt acceptate. De exemplu “ipv6 address dhcp”, sau “ipv6 client dhcp pd”.

Bănuiesc inițial o problemă de versiune IOS, așa că fac un upgrade. Din păcate, nu ajută – se pare că un simplu feature de CLIENT DHCP este considerat de Cisco „advanced IP feature”. Ceea ce înseamnă că am nevoie de licență separată (Advanced IP Services) pentru a realiza configurația. Mă văd nevoit să amân testul până când reușesc să instalez licența.

Etapa 4 – descoperirea bug-urilor…

Am licența, configurez router-ul, și… încep să găsesc bug-uri. Mai exact:

• pe IOS 15.x ( testat pe 15.1(3)T1 și 15.2(1)T1 ) , Prefix Delegation nu funcționează deloc. Văd cum se primește prefixul prin DHCP pe interfața externă, variabila PD_PREFIX e populata corect, dar prefixul nu apare și pe interfața internă. Apar în schimb o serie de erori destul de urâte – %SYS-2-BADPOOL si %ALIGN-3-SPURIOUS (erori de alocare/acces la memorie)
• pe IOS 12.4(22)T Prefix Delegation funcționează corect, dar nu este suportată comanda „ipv6 address dhcp” (da, suportă Prefix Delegation via DHCPv6, dar nu știe să ia și adresă prin DHCPv6! Nu mă întrebați cum…). Am reușit însă să îl conving să își ia adresă prin autoconfig ( „ipv6 address autoconfig default” pe interfața externă ).
• IOS 12.4(24)T5 a fost singurul IOS dintre cele testate care a mers OK. Și pare să meargă în continuare.

Per total, mi se pare îngrijorător faptul că tocmai codul recent din 15.x este cel cu probleme. Lucru care mă face să îmi fie un pic teamă de momentul în care vom fi nevoiți să trecem la IPv6 în producție…

Am auzit de el de mai bine de 10 ani. L-am așteptat cu înfrigurare, teamă, curiozitate… Și de fiecare dată a apărut ceva care l-a amânat.

Ei bine, se pare că se întâmplă. APNIC a primit încă 2 blocuri /8, ceea ce înseamnă că au mai rămas doar 5 blocuri nealocate. Conform politicilor IANA, ultimele 5 blocuri vor fi alocate rapid, câte unul pentru fiecare RIR.

Mai departe, RIR-urile vor aloca IP-uri către ISP-uri și utilizatori. Când se termină și rezervele… well… it’s IPv6 or this.

Cum în ultima vreme mă joc cu niște migrări măricele de zone, mă tot plimb pe site-ul RoTLD. Dacă tot am vorbit (și eu și Meekuu) de genialul mod în care se face validarea NS-urilor, nu pot să nu mai adaug două comentarii:

1. Stau de câteva minute să sap ca să îmi dau seama dacă parola de administrare a domeniului se trimite în clar sau nu. Până la urmă se pare că e HTTPS, dar nu e tocmai frumos să deschizi un link https într-un frame. Nu de alta, dar utilizatorul nu are nici o modalitate de a verifica certificatul primit.

Se pare că băieții care au făcut implementarea au fost colegi de clasă cu cei care au făcut implementarea 3DSecure (care e fix la fel de inspirată )

2. Nu pot să nu menționez modalitatea de plată cu cardul. Care presupune completarea unui formular cu toate datele cardului, și trimiterea lui prin fax împreună cu copie față-verso după card (adică număr card, nume deținător, CVV, absolut tot ce este necesar ca să îți dispară toți banii din cont). Și da, trebuie să ai o naivi^H^H^H^H^H încredere nemărginită că hârțoaga respectivă este procesată și stocată în mod sigur. Nu de alta, dar eu personal sunt foarte greu de convins că ea nu rămâne aruncată pe un birou, unde numai cine nu vrea nu poate înhăța datele respective.

Ambele mi se par niște lucruri cumva… neașteptate. Mai ales venind de la cei care se ocupă de aproape tot ce înseamnă Internetul din .ro.

Acum ceva timp (când s-a desființat Thawte Web of Trust) am avut ocazia de a obține în mod gratuit un certificat SSL VeriSign. Ei bine, am pierdut ocazia respectivă – o condiție obligatorie pentru obținerea certificatului era reprezentată de validarea datelor deținătorului domeniului (informațiile whois). Și se pare că RoTLD este singurul registrar din lumea asta care refuză complet publicarea datelor respective în cazul în care deținătorul este persoană fizică (nu, cuvintele nu îmi aparțin – cei de la VeriSign au spus, textual, „așa ceva nu se poate – orice registrar trebuie să facă publice informațiile respective!”). Ei bine, la RoTLD se poate protecție cu forța.

Dar să trecem la subiect. La subiectul unor servere DNS care există și răspund bine-mersi, dar RoTLD se jură că „acest nameserver nu există. Vă rugăm contactaţi administratorul domeniului părinte!”.

Eu unul dețin mai multe domenii .ro (ubergeek fiind unul dintre ele). Și rulez propriile servere DNS. Pe care le mai mut din când în când, ocazie cu care trebuie să le schimb și IP-ul. Ca urmare, ca să nu trebuiască la fiecare mutare să schimb adresele IP ale NS-urilor pentru 10 domenii pe rotld.ro, am ales să configurez un singur set de NS-uri (fie ele ns1.ubergeek.ro și ns2.ubergeek.ro), și să le folosesc pe ele pentru toate domeniile. Dacă mă mut cu NS-urile, le schimb într-un singur loc (pe pagina de configurare a ubergeek.ro), și scap de bătaia de cap.

Soluția merge de ceva ani, și m-a ajutat foarte mult. Ca urmare, am încercat să aplic ceva asemănător și într-o anumită instituție de învățământ pentru care mai fac muncă voluntară . Acolo aveam ns1.yyy.zzz.ro / ns2.yyy.zzz.ro, și am rugat oamenii care aveau domenii găzduite acolo să folosească doar NS-urile respective.

Nu a trecut mult timp și am început să primesc mesaje cu „nu merge”. Inițial am crezut că greșesc utilizatorii, și folosesc formularul de „adaugă NS pe domeniul curent”. Dar nu – am încercat și eu, și… surpriză! „Acest nameserver nu există!”.

Cum naiba nu există? E configurat corect la părinte – NS-urile pentru zzz.ro au configurate cele 2 NS-uri ale mele, împreună cu glue-urile (adresele IP) corespunzătoare. Am ping în adresele respective. Serverele sunt autoritative pe zona pe care vreau să o configurez, și răspund corect la cereri. Cum naiba îmi spui tu că „nu există”??

Ca urmare, mă decid să pun mâna pe telefon și să aflu răspunsul direct de la sursă (inițial am vrut să trimit un mail, dar nu credeați că autoritatea care se ocupă de numele de domenii Internet are și o adresă electronică de contact pe site, nu??). Să văd și eu ce înseamnă la ei „nu există”.

Sun, și trec pe la vreo 3 oameni până să dau de cineva care părea de la tehnic. Și care chiar părea dispus să mă ajute. Și începe o conversație de vreo 30 de minute, care a fost cel puțin… fascinantă.

De ce? Pentru că persoana cu care am vorbit (deși chiar bine intenționată, și dispusă să mă ajute) nu avea răspunsurile. Și mă tot punea on-hold, și îl întreba pe altul. Și după vreo 15 minute, a început să uite să mă pună on hold, și am avut plăcerea să aud pe fundal „ce puii mei vrea? Am treabă! Spune-i să facă așa, și gata!”, sau „Dacă mi-l dai la telefon, îi închid și am rezolvat problema!!”

Până la urmă reușesc să prind la telefon „vocea din fundal”. Și aflu că e obligatoriu ca NS-urile configurate să „existe la ei” (mai exact, să fie configurate glue-urile pentru ele pe TLD-ul corespunzător).

Ceea ce… pentru mine e cam neplăcut. Pentru că eu am un subdomeniu. Sunt autoritativ pe o zonă mică, pe yyy.zzz.ro. Nu am control asupra TLD-ului (zzz.ro), și nici nu ar trebui să am. Pentru că asta este toată ideea din spatele DNS-ului – delegarea responsabilității!

Încerc să îi explic și lui faptul că e ciudată restricția. Și el îmi spune că e normal ca ei să aibă în baza lor de date toate serverele NS pentru .ro (?!), și că restricția „e la fel la orice registrar”. Pun mâna pe tastatură și îi spun că nu pare să fie chiar la fel peste tot – am domeniu.net cu NS-uri ns1/ns2.xxx.sk. Și nu a comentat nimeni că „nameserver-ul nu există”. Îmi spune că dacă vreau pot să pun NS din .com pentru domeniile din .ro (!), dar dacă vreau să pun din .ro trebuie să existe la ei. Îi mulțumesc pentru explicații, și închid. Nu mai e nimic de zis, și nu are rost să mă cert.

Pe de o parte, chiar înțeleg și atitudinea de „lasă-mă naibii în pace, că am de lucru”. Am avut-o și eu de destule ori la viața mea (AJ știe ). În plus, am o bănuială că tehnicii respectivi nu sunt atât de bine plătiți încât să stea să dea explicații detaliate pentru orice procedură implementată.

Pe de altă parte însă, undeva chiar se exagerează. Se impun niște restricții aberante, care nu ajută pe nimeni. Nici măcar pe ei, pentru că restricțiile respective nu îi ajută să mențină informațiile din baza de date la zi (am reușit să introduc un nameserver care era configurat la ei, dar nu era rezolvat de NS-ul superior, și ca urmare era complet useless).

[ Cititorii mei fideli au observat probabil (ambii ) faptul că nu am mai postat nimic de mult timp. Motivele sunt destul de simple, legate de „real life getting in the way” și „I didn't really care enough about anything to post it” . Totuși, din când în când mai apare câte o poveste interesantă, și simt nevoia să o postez. ]

După ce HP s-a certat cu Cisco (și cu EMC acum ceva timp), acum a reușit să se certe și cu Oracle. Ajungându-se până la punctul în care Larry Ellison (CEO Oracle) spune că a devenit „virtually impossible for Oracle and HP to continue to cooperate and work together”.

Motivele (cel puțin cele publice ) le găsiți aici. Așteptăm cu interes evoluția evenimentelor…

Mâine, 5 mai, este ziua în care se va realiza deployment-ul DNSSEC pe toate serverele root. Dacă aveți vreun PIX/ASA care să filtreze mesajele DNS, vedeți aici ce modificări sunt necesare pentru a suporta pachetele (semnificativ mai mari) necesare pentru noul format de mesaje.

Un porumbel african a avut o misiune nobilă: trimis să demonstreze că Internetul lor merge prost, a reușit acest lucru. Știrea a apărut prin mai multe locuri, inclusiv aici și aici.

Știrea a fost preluată și de presa de la noi, care reușește să scape „porumbelul românesc”: „O companie de tehnologie IT, din Africa de Sud, a început să folosească porumbei pentru a transmite date, pentru că păsările sunt mai rapide” (da, citatul este FIX așa cum a apărut în „presă”!!)

Parcă văd cum șefii de la marii ISP-uri de pe la noi își convoacă subalternii: „Uite, băi, ăia au reușit să facă treaba asta cu porumbei!! Noi de ce n-o facem tot așa, că uite, e mai ieftin și mai rapid?!”

Mare dreptate avea Meekuu atunci când vorbea de „strânsa legătură” dintre jurnaliștii noștri și mediul IT…

A durat ceva timp (7 ani ), dar în sfârșit standardul 802.11n a fost aprobat.

http://mobile.slashdot.org/story/09/09/11/2220223/IEEE-Approves-80211n-Wi-Fi-Standard

Citeam un articol despre un sistem care permite datelor trimise electronic să „dispară” (sau, mai degrabă, să devină inaccesibile) după o perioadă de timp.

Sistemul pare chiar interesant (citiți pagina oficială a lui pentru detalii – practic cheia de criptare este sparta in multe bucati, si trimisă într-un sistem P2P. Unde… dispare în timp ). Sau, pentru și mai multe detalii, citiți direct documentul tehnic [PDF] . Și da, autorul principal este o româncă.

Revenind totuși la articolul din Cotidianul, nu pot să nu comentez – parcă unele cuvinte ar fi fost bine să rămână în engleză…

• “În plus, conceptul de “cloud computing” (informatică în nori) lua avânt semnificativ”
  
• “ păstrarea confidenţialităţii datelor stocate în norii informatici”
• “utilizatorii nu pot să spună unde, cum şi pentru cât timp datele lor sunt stocate în aceşti nori.”
• “încercăm să le oferim utilizatorilor control asupra unui anumit aspect al datelor lor stocate în nori sau în web”
• “am început să lucrez la probleme legate de migrarea către norii informatici.”

DD-WRT este unul din cele mai populare firmware-uri open-source folosite de routere. Ei bine, se pare că build-urile recente au fost afectate de o vulnerabilitate destul de gravă.

Practic este suficient un HTTP request care să treacă prin router pentru a permite… remote command execution pe echipament. Ca root (!).

Detalii despre vulnerabilitate aici și aici .