Reading time: < 1 minute
A l’article An overview of the IEEE 802.11 standard’s evolution (versió PDF) he trobat un quadre resum de les tecnologies 802.11a/b/g/n que m’ha sembla interessant tenir ben localitzat per això el penjo aquí.
Reading time: < 1 minute
Llàstima que estic destrossat que acabo d’arribar a casa i que ja no són hores d’estar a l’ordinador. Així doncs, de moment us haureu de conformar amb veure la foto de “La Fonera” que ja m’ha arribat, de fet, molt més ràpid del que l’esperava. Les males llengües m’havien dit que hi havia gent que feia mesos que l’esperava, és raro perquè aquest model jo diria que no fa tan que va sortir, però bé. Si ho diuen per algo deu ser.
Reading time: < 1 minute
La gent de Cisco ha elavorat un document tècnic per les masses. O sigui, s’explica detalls del funcionament intern d’un switch de xarxa local ethernet (LAN) però a través de metàfores i d’altres recursos que simplifiquen moltíssim els detalls tècnics. És un document ideal per quan s’ha d’explicar el concepte a gent no tècnica. A més també inclou una animació en flash sobre el tema que és molt gràfica i senzilla d’entendre.
Reading time: 3 – 4 minutes
Aquesta empresa de capital risc acaba de presentar un mini-caixa de la mida d’una targeta de crèdit, amb dues connexions ethernet una cap a l’ordinador i l’altre cap a internet. La idea és fer de firewall personal per ordinadors aïllats o com a molt protegir petites xarxes de fins a 5 o 6 ordinadors connectant-hi un petit switch (o HUB). Com no podia ser d’una altre manera aquesta caixeta porta un Linux que s’encarrega de fer el que a Yoggie en diuen Personal Security Gatekeeper, o sigui donar funcions de:
Tot això en ordinador ben petit però ben potent al mateix temps, de fet, esta disponible en dues versions la versió basic i la pro; les característiques del hardware són les següents:
El producte es comercialitzarà al novembre a través de distribuidors a EUA, UK i Alemanya. El model basic costarà uns 180$ i el Pro uns 220$. Realment crec que relació qualitat preu és un molt bon producte per molts tipus d’usuaris. Sobretot en el camp del SOHO o els RoadWarriors que van per tot arreu amb el portàtil. Esta clar que pels professionals de les TIC no és res de l’altre món però pels usuaris en general crec que per fi hi ha una bona alternativa a les appliances que treuen les companyies d’antivirus que sota la meva opinió en general són lamentables i una presa de pel.
El producte l’he tret de linuxdevices per variar, concretament de l’article Tiny Linux gadget protects Windows XP laptops. Si com a mi el que més us ha agradat del producte és la placa base podeu ampliar informació sobre el tema a l’article Freescale ships “SideShow” devkit — but where’s the Linux?. També podeu buscar més informació a google amb la keyword “Bulverde“.
Reading time: 2 – 2 minutes
Com ja vaig comunicar a la gent d’eBosc, el tema de la xarxa del poble té els dies comptats ja que estem cansats de moltes coses i com sempre passa amb aquestes iniciatives només acabes guanyant enemics. Sort que hi ha excepcions com en el cas de Guifi.net.
El que volia comentar és que jo al igual que el Ricardo Galli no fm’he pogut resistir a demanar-me el meu Fonera. De fet, sempre he cregut que això de Fon era una molt bona idea. De fet, google, ebay i Skype també ho pensent així que algo deu tenir de bo. Amb molts punts negres i difícil de creure totes les animalades que se’n deien i diuen. Però al cap i a la fi una cosa que vull provar i no deixar que m’ho expliquin i prou.
De moment encara no he rebut l’AP però ja anuncio que sóc un ‘fonero’, buf! quanta gent em voldrà matar. Però no totes les bones idees venen del món OpenSource que això no vol dir que en publiquin el codi, que és el que han dit que estan apunt de fer la gent de Font en els propers mesos. A veure com hauràn evolucionat el famós OpenWRT, em moro de ganes de poder-ho criticar… sóc com una vella.
Reading time: 1 – 2 minutes
GUI per clients d’VPN universal, suporta openVPN, cisco VPN client, FreeS/WAN (Linux 2.4.x), ipsec-tools support (Linux 2.6.x/BSD native), PPTP support (pptpclient). A més s’encarrega de fer la gestió de certificats i perfils dins d’un mateix tipus d’VPN. Realment molt útil si com jo heu de tenir a mà múltiples sistemes de connexió remots per diferents empreses i entorns de xarxa molt canviants.
Val la pena que hi doneu un cop d’ull a la infinitat de funcionalitats que ofereix el programa. A més de ben segur que el podeu fer correr amb l’idioma que més us agradi i, com no, esta suportat al portage de gentoo. Així que ja només queda que proveu l’kvpnc i a veure si us agrada tan com a mi.
Reading time: 2 – 2 minutes
Els artícles on explico com configurar EAP/TLS en català i en anglès tenen més de 8.000 visites el primer i més de 17.000 el segon. Doncs bé, degut a les preguntes d’algún d’aquests lectors de l’article acabo de fer un petit i ràpid cookbook de com afegir TTLS a la configuració TLS de l’article. De fet, si teniu clars els conceptes podeu montar-vos una autenticació EAP/TTLS amb PAP intern amb menys de 15min.
Bàsicament l’únic que afegim a la configuració del EAP/TLS és la capacitat d’afegir un nou sistema d’autenticació després d’establir el túnel segur entre el servidor radius i el client que es vol autenticar a la xarxa wifi. En aquest exemple per tal de simplificar les configuracions el protocol utilitzat per aquesta autenticació és el PAP. Amb aquest simple sistema he enmagatzemat el nom d’un usuari i una paraula de pas necessaris per autenticar el client després d’establir el túnel gràcies al seu certificat de client.
Obviament si no voleu usar PAP podeu modificar la configuració per usar CHAP, MsCHAP, o qualsevol altre sistema que volgueu. Si aquest article desperta tan interés com els altres ja l’aniré polint, però la veritat ara mateix no tinc ganes de posar-me a explicar tots els detalls de les configuracions que ja vaig explicar en el seu dia. Així doncs si ús cal ajuda la demaneu.
El cookbook el podeu trobar al wiki.
Reading time: 2 – 2 minutes
A principis d’estiu vaig comentar que el switch havia estat apunt de fer figa. En una falça alarma que va resultar ser la font d’alimentació del mateix. Doncs bé, resulta que avui he perdut gran part de la tarda intentant saber perquè carai un PC no parava de perdre paquets dintre de la xarxa local. Després resulta que això passava també entre servidors de la xarxa de casa. Un desastre!!! conclusió el switch esta mig mort i he hagut de demanar auxili al Jordi perquè em portés un HUB. Per cert, més vell que el anar a peu. Així doncs, ara mateix tinc la xarxa sota mínims. Però demà marxo a València per feina i no torno fins dimecres així doncs fins dijous no crec que pugui posar-hi un switch decent.
Finalment he comprobat que realment hi ha alguna diferència entre els switch econòmics de 3com i els switch exageradament econòmics com el Conceptronic (de 8 ports per uns ~20€) que tenia funcionant fins ara. Així doncs, a partir de dijous poso un 3com o algo millor i no se’n parli més. A casa dels clients estic fart de montar-los i fer-los treure fum amb nivells de tràfic exagerats i sostinguts durant anys i anys. Mai he tingut cap disgust i després del que avui m’ha passat a casa ja no me la torno a jugar.
Reading time: 9 – 14 minutes
Basant-me en un parell d’articles de Network Systems Design Line vaig escriure l’article IPv6: repassant les novetats tècniques, doncs bé s’han publicat les parts 3 i 4 que continuen amplicant la introducció feta a les parts 1 i 2 que vaig repassar en el meu article. La part número 3 parla específicament de les característiques de les capçaleres IPv6. Part realment important i interessant en aquesta nova versió IP. Així doncs dedicaré aquest article a resumir la part 3 de l’article de Networki System Design Line que parla sobre les capçaleres IPv6.
Per entendre quines són les motivacions que han provat els canvis en la capçalera IPv6 cal tenir clar quins eren els camps de la capçalera IPv4.
La nova capçalera IPv6 intenta millor els principals problemes de la IPv4 a través de:
Així doncs, les capçaleres d’IPv6 es defineixen al RFC 2460 i queden com segueix:
Bàsicament les extensions de capçalera són una segona capçalera, opcional, que s’usa per donar les funcions que es donava en IPv4 a través del camp, de mida variable i màxim de 40bytes, Otpions. En IPv6 podem fer aquestes extensions de capçalera tran grans com ens interessin, sempre que respectem la mida màxima del paquet.
A continuació podem veure un exemple d’una capçalera bàsica, i d’una capçalera amb uan extensió de capçalera.
A l’RFC 2460 podem trobar les definicions de les extencions de capçalera. Podem trobar-hi, una descripció, el format i la funcionalitat.
La capçalera Hop-by-Hop és una extenció de la capçalera bàsica, es defineix en el camp Next Header, de la capçalera bàsica, amb el codi 0. És la única extenció de capçalera que s’ha de processar per tots els nodes del camí entre l’origen i el destí del paquet. S’úsa per exemple per facilitar la expedició de dels Jumbograms (després s’explica què és això), o també facilita que els routers es passin informacions d’expedició (forwarding).
Les opcions que transporta aquesta extenció de capçalera es codifiquen en un format que es diu TLV, a continuació es pot veure un diagrama del format.
Tots els nodes que hi ha en el camí rebran aquesta capçalera i la processaran. Si algún dels nodes no entengues les opcions que conté la capçalera i que ha de processar generaria un paquet de tipus ICMP. Tot i que no totes les opcions han de generar forçosament aquest missatge ICMP, amb això s’eviten problemes d’atacs de denegació de serveig per inundació de paquets ICMP.
És important tenir en compte l’impacte en el rendiment que té el fet de processar les capçaleres hop-by-hop en cada un dels routers. Una de les funcionalitats que té és el fet de suportar paquets molt grans. La capçalera bàsica només permet una mida que es pugui definir en 16bits, o sigui, de com a molt 65.536 octets.
Les extensions hop-by-hop contenen un camp de 32 bits de llargada que pot representar paquets molt grans, anomenats Jumbograms. Quan volguem usar el camp de 32bits de la capçalera hop-by-hop el camp Payload length de la capçalera bàsica el posarem a 0, amb això s’idenfica un paquet Jumbogram.
A través de l’RFC 2711 es defineix l’opció Router Alert que a través de la caçalera hop-by-hop permet enviar intruccions d’expedició (forwarding instructions). Per exemple, per fer reserves d’amplada de banda amb RSVP. O per alertar als routers que han de processar paquets multicast, això es fa a través dels paquets Multicast Listener Discovery.
Com el propi nom indica, aquesta extenció de la capçalera bàsica es refereix nomes a les Option de la direcció de destí. Per exemple s’usen amb MIPv6. El codi usat en el camp Next Header a la capçalera bàsica és el 60.
Identificada amb el codi 43, al camp Next Header. S’usa per reforçar el camí a seguir per alguns paquets. El camí el defineix l’origen, i podria no coincidir amb el camí calculat pels routers intermitjos.
La capçalera routing header conté un camp de tipus (type) que permet saber amb exactitut a funcionlitat d’aquesta capçalera. En aquest moment hi ha dos tipus de funcionalitats definides:
La fragmentació requereix molt de procés en els nodes. Per tal d’evitar les necessitats de sobrecarregar els processadors dels nodes a IPv6 no s’admet la fragmentació de paquets. Abans d’enviar un paquet, l’origen ha de passar per un procés de descobriment de PMTU. Això determinarà quina és la màxima mida que pot tenir un paquet per aquell camí sense que es fragmentin els paquets. Malgrat els routers ja no han de controlar el problema de la fragmentació els nodes destí si que han de saber recomposar un paquet fragmentat. Per tal de poder-ho fer, s’usen les extensions de capçalera Fragment Option Header.
Aquesta capçalera s’assembla a la capçalera IPSec AH (RFC 2402) usada en IPv4. Aquest sistema autentica l’origen d’una transmissió i assegura la integritat del paquet. El camp Next Header l’identifica amb el codi 51.
S’assembla a la idea implmentada en IPSec ESP (RFC 2406) en IPv4. Identificat amb el codi 50 al camp next header.
Definit a l’RFC 3775 i usat en les comunicacions entre nodes mòbils, nodis corresponents (correspondent nodes) i amb agents domèstics (home agents) en l’establiment i el control de bindings. Identificat amb el codi 135 al next header field.
Amb aquest article n’hi ha prou per veure que el tema de la capçalera s’ha cuidat moltíssim i que hi ha infinitat de combinacions que permeten extendre la capçalera bàsica per gaire bé qualsevol necessitat que se’ns ocurreixi. A més si ens cal fins hi tot podem crear noves extencions per les nostres necessitats. Sota el meu punt de vista aquest és un dels avantatges més potents en IPv6.
Reading time: 10 – 16 minutes
Aquí teniu la continuació que us vaig prometre de les bases de la VoIP. Aquest article intentaré fer-lo tan entenedor com l’anterior però no serà senzill perquè els temes ha parlar són ja força tècnics i especialitzats. Malgrat això és molt necessari tenir-los clars sinó quan toquem sistemes de VoIP reals no sabrem a que es refereixen els manuals o els altres companys quan ens expliquen els motius pels que passen les coses. O simplement, perquè fan falta certs dispositius en les configuracions.
Altre cop he de fer referència a Network System Design Line, aquest cop a l’article How VoIP works: Protocols, codecs, and more (local).
En l’article de les bases de la VoIP va quedar molt clar el procés que segueix una trucada de VoIP. També es va insinuar la importància del temps que es triga en mostrejar les ones analògiques de la veu (digitalitzar la veu) i l’espai que ocupa aquesta digitalització. Això repercutirà de forma directa en el temps que triguem en transportar aquesta informació fins a l’altre extrem on es farà el procés invers fins que l’interlocutor senti la nostre veu.
Bé doncs, en aquest document em centraré en explicar que es fa després de digitalitzar la veu, o sigui, es comprimeix aquesta informació abans de ser transportada perquè ocupi menys espai (això ho fan els codecs). Per altre banda, cal que pensem que quan enviem un email o una fotografia a través d’una xarxa IP aquesta informació no és sensible al temps. O sigui, ens és igual que trigui uns segons més o menys en arribar això no afecta en el missatge que es transporta. Obviament en una conversa això no és així i aquests paquets han d’arribar prou ràpid a l’altre extrem perquè la sensació de “temps real” sigui suficient.
Les xarxes IP, per defecte, són xarxes de tipus best-effort això vol dir que tots els paquets que viatgen a través d’elles intenten passar el més ràpid possible però sense cap tipus d’arbitratge. Parlant en plata, la llei del més fort. Per tant, es tracta inicialment d’un entorn poc indicat per transportar informació sensible al temps. Per exemple, informació en temps real (o streaming) d’audio i/o video.
Per tal d’adequar millor aquest medi a les comunicacions sensibles al temps s’usen tècniques de QoS. O sigui, intentem montar un sistema d’arbitratge en els nodes de la xarxa per tal de prioritzar el tràfic sensible al temps. Per exemple, el tràfic de VoIP. Si la xarxa en la que s’ha de treballar no té gaire càrrega de tràfic això no és massa important. Cal tenir present que internet no és una xarxa amb QoS. Per tant, és un entorn hostil per les nostres trucades de VoIP.
Entrant una mica en temes tècnics, el que hem d’aconseguir pel que fa als retards (delay) de la xarxa entre els dos extrems són temps inferiors a 100ms. Tot i que amb retards per paquet de 100 a 200ms poden arribar a passar trucades ja es poden començar a donar fenomens molestos pels interlocutors. Sovint problemes d’echo.
Quins són els problemes que hem d’intentar evitar que tingui una xarxa IP per poder-hi passar VoIP sobre d’ella:
En el següent gràfic podem veure quins són tots els passos, un per un, que segueix la nostre veu fins arribar a l’interl·locutor. Com podem veure cada un dels passos té una serie de codecs, protocols i normes associades que a continuació es descriuen.
Com ja s’ha comentat el primer que es fa després de mostrejar la veu (digitalitzar) es codifica i comprimeix per tal de reduir els requeriments d’amplada de banda. Aquest procés el porten a terme els codecs.
Els paquets de dades comprimits es mouen a través de les xarxes gràcies a un protocol de transport. Els gateways s’encarreguen d’enrutar aquests paquets entre diferents xarxes IP (o d’altres tipus, si cal) fins que els paquets arriben al seu destí. Quan arriba al destí es decodifiquen (i descomprimeixen) els paquets rebuts i es converteixen altre cop en audio.
El model de 7 capes OSI defineix qualsevol procés de networking (interconnexió digital en una xarxa). Si hi ha dos extrems que volen tenir una sessió de comunicació, les dades que aquests generen comença a la capa 7, patint les encapsulacions necessaries fins arribar a al medi de transmissió (per on viatgen les dades: cable, aire, llum, etc) a l’altre extrem passa el procés invers des del medi fins a l’usuari. Bé doncs això és el que ens mostra el següent gràfic i ens col·loca cada un dels protocols en una de les capes.
El primer que ens cal per establir una comunicació en VoIP és un protocol de sessió que ens indiqui com informem a la xarxa que existim, com intentem comunicar-nos amb altres usuaris o com rebem les comunicacions d’altres usuaris. Els dos protocols més coneguts que s’encarreguen d’això són H.323 i SIP. Malgrat n’hi ha molts d’altres com ara IAX (protocol usat per Asterisk).
L’H.323 és un estàndard de la ITU originariament desenvolupat per enviar veu i dades en temps real (videoconferencia i similars). Malgrat això una de les primeres aplicacions que va tenir va ser la VoIP. De fet, el H.323 més que un protocol és en si és un grup de d’estàndards, codecs i protocols que diuen com establir una comunicació multimedia a través d’una xarxa IP. Per exemple, el protocol de senyalització que usa H.323 és el H.225 i el protocol de negociació de funcionalitats el H.245.
El SIP el va definir la IETF a l’RFC 3261. Es va desenvolupar especialment per la telefonia IP. De fet, es considera una solució molt més neta i senzilla que l’H.323. SIP s’usa amb SDP per tal de descobrir usuaris; a més ofereix la capacitat de descobrir funcionalitats i de gestionar trucades. SDP és esencialment un format que descriu com fixar els paràmetres d’inicialització per tal d’intercanviar la informació multimèdia. Bàsicament SIP/SDP és analoga a H.225/H.245 en el protocol H.323.
El protocol SIP ens permet a més establir connexions entre dos extrems sense la necessitat de disposar d’un servidor. Tot i que no és l’habitual. Ja que normalment el que fan els clients SIP és registrar-se contra un servidor públic per tal de mostrar-se a la resta de clients de la xarxa.
Els protocols de senyalització descrits anteriorment són els responsables d’establir les configuracions a usar en una sessió multimèdia entre dos usuaris. Però aquesta informació de senyalització viatjarà per la xarxa a través dels protocols de transport de sempre, o sigui, UDP (no orientat a connexió) i/o TCP (orientat a connexió).
El protocol RTP ofereix un servei d’entrega de paquets amb informació d’audio i video que ha de ser servida en temps real. Aquest protocol usa com a protocol de transport el UDP per minimitzar la capçalarela (la capçalera UDP és molt més petita que TCP). A canvi d’això no pot garantir l’entrega dels paquets que transporta (UDP no és orientat a connexió, no hi ha retransmissió de paquets perduts), a més tampoc pot garantir que l’ordre en que entrega els paquets sigui el correcte.
Estructura d’un paquet RTP:
Així doncs el que intenta fer RTP és afegir aquelles funcionalitats que no li dona UDP per tal de que les dades que transporta siguin el màxim útils possible. Les funcionalitats que dona RTP a UDP són: nivell de QoS, marques de temps (timestamps), números de seqüència i confirmació de recepció per cada paquet enviat. També pot suportar esquemes de correcció d’errors per fer més rebustes les dades que transporta, fins hi tot algunes opcions de xifrat bàsiques per les dades del paquet.
Obviament això carrega una mica el paquet UDP, en aquest gràfic podem veure una comparació amb el preu que paguem per obtenir totes aquestes funcionalitats.
RTCP és un protocol complementari a RTP i s’usa per enviar informació de control, com a ara el número de paquets perduts, jitter, retard, etc. És molt útil per saber quina és la qualitat de la sessió que estem mantenint. Gràcies a la informació d’aquest protocol podem saber la necessitat que té la nostre xarxa de que li donem suport de QoS. O la necessitat de canviar els codecs que estem usant per ajustar-nos millor a les necessitats de la xarxa en la que treballem.
A dalt de tot de la pila VoIP hi trobem els protocols encarregats de comprimir la informació que s’ha mostrejat de la font de digitalització (la nostre veu, imatges de video, etc). Els factors que determinen la eficència d’una codec són: el nivell de compresió (quan més comprimeixi millor), temps compresió i descompresió (quan menys trigui en fer el procés millor), suport a la perdua de paquets (capacitat de reproduir la informació original sense tenir tots els paquets en el destí), correcció d’errors, cost intel·lectual (cal pensar que no tots els codecs són lliures, n’hi ha molts de pagament).
Codecs d’audio:
Amb aquest document ja em fet un repas a grans trets dels elements que composen una comunicació de VoIP. Quan ens diposem a configurar un sistema de VoIP trobarem moltes altres sigles, codecs, protocols, etc. però aquest document ens serveix com una referència bàsica sobre la que començar a treballar mentre anem adquirint experiència en aquest món tan interessant.