Presentació Guifi.net Mallorca al SAX2019

Presentació realitzada per part meva al SAX 2019, explicant els supernodes principals de Guifi.net que hem construït a Mallorca.

Presentació guifi Mallorca SAX2019 (PDF)

Instal·lacions de supernodes, FTTT vs CTTT

Quan un ja ha muntat uns quants supernodes, i en manté uns quants més, comença a cercar opcions i formes d’alimentar i connectar els equips diferents. Això està bé, però hem de ser molt curosos i respectar al màxim possible els estàndards (inclús els que ens marcam nosaltres) per no fer-nos perdre temps.

Així mateix, complicar excessivament les instal·lacions amb empalmes, tubs corrugats, caixetes i dispositius ens pot dur a perdre molt de temps, paciència i problemes futurs. Els empalmes i alguns dispositius actius poden generar punts crítics de fallada extra completament innecessaris.

En definitiva, val més afegir pocs elements i ben posats que no mil trastets i dispositius de qualsevol manera. Una nota mental que sempre me pos al cap (tot i que em falla): estam construint infraestructura, no fent una obra d’art.

Tot i així, és molt fàcil que t’invadeixi la paranoia quan has sofert sobretensions, caigudes de llamps, diferencials que es banyen i antenes penjant. Per això, sempre acabes intentant millorar la instal·lació d’una o altra manera.

Una de les coses més interessants i crítiques de qualsevol supernode és l’alimentació i la protecció dels elements actius. Qualsevol element actiu pot sofrir sobretensions (per la caiguda d’un llamp o per problemes en la xarxa elèctrica) i talls en el subministrament (gràcies, Vall de Sóller Energia per donar-me tants de mal de caps en un any). En aquest sentit, sempre tenc en ment dues aproximacions, cadascuna amb els seus avantatges i inconvenients. Les anomen FTTT (Fiber To The Tower) i CTTT (Copper To The Tower), perquè en anglès tot sona més guai.

Supòsits

Suponem un supernode amb les següents característiques:

• Antenes en màstil, rack dins recinte.
• Ja existeix un SAI.
• Capacitat base de 8 antenes. Capacitat ampliada de 16.
• Ha de permetre l’existència d’una DMZ, aïllada de sobretensions.
• Un mínim de 100mbit d’ample de banda en l’enllaç per antena.
• Tirada de 35m des del rack fins la torre

A. CTTT (Copper To The Tower)

CTTT és el model clàssic i més intuïtiu de muntar supernodes. Simplement, es tracta de passar cablejat UTP apantallat (o FTP o el que sigui) cap a la torre o màstil des de l’interior del recinte, connectat directament al router. L’alimentació PoE s’injecta als cables UTP de forma normal, amb PoEs Mikrotik o Ubiquiti. El de tota la vida.

CTTT. Fletxes en verd: SPF, vermell: elements actius, blau: elements passius (òptic), negre: ferros

Alguns avantatges d’aquest sistema són:

• El sistema més simple, senzill i intuïtiu.
• Per instal·lacions amb poques antenes (<8) surt més barat precisament per la seva senzillesa.
• Més fàcil de muntar.
• Només UN (1) SPF (Single Point of Failure), suposant que tenim SAIs o alimentació redundada. El router.
• Fins ara ens ha funcionat amb tots els supernodes.
• Cada antena disposa d’1 port del router complet (generalment ja gigabit). Això, en la majoria d’enllaços sense fils, tampoc és tan important.

Els desavantatges que té són:

• Tudadissa de cable de coure. Per cada antena, un cable. 8 antenes, 8 cables. Si la tirada és llarga, gastam una bobina sencera de cablejat.
• Evidentment, el forat que hem de fer a la paret per passar 8 cables de coure és més gros.
• 8 cables, si no són bons o feim tirades llargues, poden sofrir interferències.
• Una sobretensió pot afectar els cables Ethernet i la instal·lació elèctrica.

Costos d’un desastre:

Generalment, els efectes que tendrà una caiguda d’un llamp o un problema de sobretensió greu són imprevisibles. Si cau un llamp, en aquest cas ens fregirà les antenes, el router i les fonts d’alimentació dels PoE.

Si hi ha equipament delicat darrere el supernode, també el fregirà. És molt recomanable connectar-lo al router mitjançant un cable de fibra per no danyar els ports Ethernet de l’equipament delicat.

En el pitjor dels casos, es ficarà dins la línia elèctrica i també afectarà altres equipaments. Tot i així, això pot passar independentment de la nostra activitat. Per això el més intel·ligent és col·locar protectors de sobretensions transitòries al quadre elèctric.

Costos CAPEX aproximats

Per a 8 antenes.

• 300m de cable F/UTP coure, suposant 8 tirades de 35m. 200€

Si hi ha equip delicat darrere, haurem de comprar, també i si el volem tenir protegit:

• Convertidor de mitjans: 20€.
• 1 latiguillo fibra + transceivers. 20€ (a fs.com)

Total: 240€.

Costos ampliació aproximats

Ampliar a més de 16 antenes suposa haver de passar més cable i, en la majoria de casos, habilitar un switch nou al rack per aquestes antenes.

L’opció simple és posar el switch a dins. Se’ns incrementen els SPF: el router, el switch i l’enllaç.

Ampliant el supernode a un màxim de 16 antenes

• 300m de cable F/UTP coure, suposant 8 tirades de 35m. 200€
• 1 switch per a les altres antenes (no ens basta el router). 150€

Total: 350€

Una variant del CTTT és el que podem batejar com CTTT+:

A.1 CTTT+

Aquest sistema és com CTTT però posant un switch PoE entre el router i les antenes per alimentar-les. Aquest sistema protegeix el router de ESD i permet emprar-lo per connectar-hi equip delicat. Així mateix, ens permet reiniciar les antenes aturant la corrent del PoE des del switch.

Avantatges

• Relativament senzill, tot i que s’hauran de configurar VLANs.
• No tenim elements delicats a fora.
• Protegim el router i el que hi connectem (a diferència de CTTT, tenim els ports del router disponibles per posar-hi coses)
• Podem reiniciar les antenes. Molt útil en llocs on volem gestió remota de dispositius.

Inconvenients

• Molt de coure
• Interferències
• Més car

Augmentam en un el SPF (switch i router), però a canvi podem reiniciar les antenes. El cost del desastre només seria el switch, apart de les antenes.

Costos CAPEX aproximats

Per a 8 antenes.

• 300m de cable F/UTP coure, suposant 8 tirades de 35m. 200€
• CRS112p: 130€
• 1 latiguillo fibra + transceivers. 20€ (a fs.com)

Total: 350€

Costos ampliació aproximats

Opció 1: Canvi equipament

• Nou router rb4011: 180€
• CRS328: 280 €
• 300m coure: 200€

Total: 660€.

Opció 2: . Relaxam condicions.

No mantenim la condició de 100mb/s per antena (capacitat de commutació de 62 mb/s per antena)

• 300m de cable F/UTP coure, suposant 8 tirades de 35m. 200€
• CRS112p: 130€
• 1 latiguillo fibra + transceivers. 20€ (a fs.com)

Total: 350€

B. FTTT

En FTTT, la cosa es complica. Enlloc de passar un cable de coure per cada antena, es passa un sol cable (generalment de fibra) destinat exclusivament a dades. Per l’alimentació, es passa un parell de cables elèctrics de coure. A la torre, es col·loquen un o vàris switchos. La idea és evitar posar molt cablejat i que una sobretensió es coli pels cables UTP i que entri dins la instal·lació. Si va pels cables d’alimentació la sobretensió se la menjarà la font d’alimentació i el circuit elèctric i no el router.

Conceptualment, el que diferencia FTTT de CTTT és la posició del router. En CTTT el router està connectat per coure (i per tant desprotegit, com si estigués fora) i en FTTT està connectat per fibra (i per tant protegit).

FTTT. Fletxes i cercles en verd: SPF, vermell: elements actius, blau: elements passius (òptic), negre: ferros

Alguns avantatges del sistema són:

• Menys cablejat. Una sola fibra OM3 pot proporcionar fins a 10gbps.
• Més fàcil d’escalar. Instal·lar una antena nova just requereix treure un cable nou del switch de la torre.
• Aïllament respecte sobretensions a l’interior de l’edifici pels cables UTP.
• Menys interferències als cables.

Alguns desavantatges:

• Més car que CTTT. Sobretot OPEX, com les pèrdues en cas de desastre.
• Molts més elements actius. I, per tant 4 SPFs! (punts de fallada) Suposant que tenim SAIs o alimentació redundada, són:
  • El router
  • El cable de fibra i els transceivers
  • La font i el cable d’alimentació (haurem de fer empalmes)
  • Els switch o switchos de la torre
• Més espai ocupat al màstil, obliga també a passar tub sí o sí, a més de potser muntar empalmes a la torre (ugh).
• Hem de configurar VLANs. Es complica la gestió.

Realment, l’aïllament per fibra dels equips de l’interior, respecte CTTT, ens aporta només protecció al Router. Els equips delicats, en CTTT, també poden protegir-se amb fibra afegint un nou switch.

Costos d’un desastre:

Si cau un llamp, en aquest cas ens fregirà les antenes, les fonts d’alimentació dels PoE i els switchos penjats a la torre. És a dir, salvam el router, però fregim els switchos de la torre.

Com amb CTTT, també es poden veure afectades les fonts d’alimentació i la xarxa elèctrica. Per això, amb aquest mètode només evitam exposar les boques ethernet del router.

Costos CAPEX aproximats

Per a 8 antenes.

• Font alimentació. Hem d’afegir una font d’almenys 100W ja que les de les PowerBox no són suficients. 30 €
• Cable fibra 35m + òptiques (preus fs): 17€+10€=27€.
• Dues Powerbox PRO: 100€ * 2=200€
• 35m Cable coure 2.5mm2, dos colors = 30€
• 35m tub corrugat exteriors = 40€

Total: 327€

Costos ampliació aproximats

Ampliant el supernode a un màxim de 16 antenes.

Es complica una mica, ja que si volem complir els 100 mbits per antena mínims farà falta passar una altra fibra o ampliar l’òptica a 10GB. En aquest cas, no ens serveix la PowerBox Pro i hem de passar a altres solucions com la sèrie Edge Point EP S16 de 16 ports d’Ubiquiti. En aquest cas el preu puja de 400€.

Una altra opció és afegir dues powerbox més, un switch de fibra i fer més enllaços.

Opció 1: EdgePoint EP S16. La forma més elegant.

• Font alimentació. Hem de comprar un EdgePower: 200€
• EdgePoint EP S16: 400€
• 2x Òptiques SFP+: 32€
• Router nou: Mikrotik amb SFP+ (RB4011): 200€

Total: 832€

Opció 2: 2x powerbox Pro + tirada de fibra

• Dues Powerbox PRO: 100€ * 2=200€
• Font alimentació. Hem d’afegir una altra font d’almenys 100W ja que les de les PowerBox no són suficients. 30 €
• Cable fibra 35m + òptiques (preus fs): 17€+10€=27€.
• 35m Cable coure 2.5mm2, dos colors = 30€
• Switch de fibra per connectar les dues fibres que arriben. CRS106-1C-5S = 60€
• 2x Cel·les SFP – Coure: 32€

Total: 379 €

Opció 3: 2x powerbox Pro. Relaxam condicions.

No mantenim la condició de 100mb/s per antena (capacitat de commutació de 62 mb/s per antena)

• Dues Powerbox PRO: 100€ * 2=200€
• Font alimentació. Hem d’afegir una altra font d’almenys 100W ja que les de les PowerBox no són suficients. 30 €
• 35m Cable coure 2.5mm2, dos colors = 30€

Total: 260 €

Conclusió

	CTTT	FTTT
CAPEX	240,00 € (350€ si CTTT+)	327,00 €
Ampliació (opcio 1)	350,00 €	832,00 €
Ampliació (opcio 2)	350,00 €	379,00 €
Ampliació (opcio 3)	350,00 €	260,00 €

 

Quan, per tant, ens interessarà l’esquema CTTT?

• Quan la tirada entre el recinte i la torre/màstil sigui curta, o quan no hi hagi recinte.
• Quan no hi hagi elements a protegir (equips de tercers etc.) o quan el cost del router no superi els 200€ – 300€. Té sentit protegir un sol router de 130€, quan l’alternativa requereix exposar switchos a l’exterior que poden costar 200€ o més?
• Quan treballar a la torre sigui complicat i necessitem estar el mínim possible enfilats. (P. ex. Alfàbia).
• Quan la torre estigui exposada a ambients extrems que poden rovellar o fer malbé els dispositius i caixetes.
• Quan tenguem espai suficient per passar cablejat.
• Quan no disposem de molts diners
• Quan el supernode no s’hagi d’ampliar gaire (+8 antenes) en un futur.

Quan ens interessarà l’esquema FTTT?

• Quan la tirada entre el recinte i la torre/màstil sigui molt llarga.
• Quan l’espai per passar cablejat sigui limitat.
• Quan el router i els equips exposats siguin molt cars. En particular, quan siguin més cars que els switchos exteriors exposats.
• Quan treballar a la torre o màstil sigui relativament senzill.
• Quan es prevegi que el supernode arribarà a acollir més d’una dotzena d’antenes.

Preguntes que ens hem de fer

Resposta afirmativa, FTTT +1 punt, resposta negativa CTTT +1 punt

1. La tirada fins a la torre/màstil és de més de 25 – 30m?
2. Tenc espai al màstil per posar una caixeta? Podré treballar-hi còmodament?
3. Té previst allotjar (segur segur) més de 8 antenes?
4. Les condicions atmosfèriques són bones? Els elements (empalmes, cables etc) estaran segurs?
5. El router (i altres elements interiors necessaris del supernode) és molt car?
6. Tenim males terres o mala instal·lació elèctrica?

 

 

Remodelació final de Victòria44

El supernode de Victòria44 és el primer repetidor de Guifi.net que instal·làrem a l’illa de Sóller i ha passat per moltes etapes, cadascuna d’elles prou més interessant. Del 2013, i del primer enllaç que muntàrem a Sóller, ja en fa 6 anys!

Inicialment era un terrat antic, ple d’uralita rompuda i quatre màstils de TV rovellats. Els cables estaven passats de qualsevol manera fins a l’interior, amb un switch Vertical Horizon cedit pel programa reutilitza de la UIB. Quan es posava en marxa, semblava un avió a punt d’enlairar-se.

Es va reformar la terrassa i amb ella el supernode. Vàrem comprar i instal·lar un màstil nou. Posteriorment, compràrem també un rack i col·locàrem switchos i routers a dins per no dependre de la Omnitik UPA. Un eixam de LOCO M5 i SXT embrutaven l’espai radioelèctric per donar cobertura als usuaris de la zona. Així mateix, començàrem a rebre queixes de que el màstil estava massa enmig del terrat.

A mesura que les cases del veïnat es connectaven, el rack interior cridava desesperadament una reforma i una posada en ordre.

 

Quan començàrem amb el projecte de Gotes, planificàrem la reforma en dues parts:

1. Adeqüació del rack interior instal·lant un patch panel. Adeqüació del sistema elèctric.
2. Moure el màstil a una zona més adequada.

 

Part 1. Adeqüació del rack

Un dissabte sencer de feina. Consistí en el següent:

1. Refer l’esquema de connexions de les cases del voltant. A partir d’ara, una casa, un node de Guifi.net.
2. Col·locar un patch panel per les connexions que venen de fora.
3. Comprar cablejat nou
4. Refer grimpat de tots els cables.
5. Posar un SAI.
6. Llevar tots els PoE i posar un Alfa (injector PoE)
   
7. Posar un tèrmic a un carril DIN. Podem enganxar l’Alfa al carril DIN i enrackar-lo.Al final no ho vàrem fer
8. Deixar la RB2011 i el TPLink / switch/ RB HeX (si cal) ben fixats a la safata enrackable que ja hi ha.

El resultat va ser bastant vistós

A final d’estiu de 2018, un llamp va espatllar alguns dispositius i vàrem haver d’improvitzar alguns arreglos.

Part 2. Transport del màstil a un altre lloc

Un any més tard, maig 2019, els astres s’alinearen i planificàrem finalment la translació del màstil a una altra posició.

Es decidí instal·lar el màstil als ferratges del terrat del costat que s’havien col·locat per suportar plaques solars tèrmiques.

La idea era modificar l’esquema amb el que anomen FTTT (Fiber To The Tower). Bàsicament, consisteix en dur alimentació CC separada de les dades, que s’uneixen amb un cable de fibra. A la torre/màstil s’instal·la un switch de fibra amb sortides PoE. L’objectiu és evitar problemes de sobretensions als ports ethernet tot aïllant les dades i estalviant cable. En aquest cas en concret, amb aquest sistema ens estalviam uns 200m de cablejat.

Instal·làrem un switch CRS112p a dins una caixeta a sota el màstil. Aquest switch proporciona PoE out, té 4 ports de fibra i pot ser alimentat en CC. El switch s’alimenta amb un parell de cables de corrent d’1.5mm2.

Les feines a fer eren:

• Col·locar suports pel màstil a l’altre terrat enganxats a les plaques
• Passar tub corrugat per exteriors des de l’escala fins a les plaques
• Passar cables corrent (2x) i fibra per dins del tub corrugat
• Col·locar òptiques i endollar fibra
• Col·locar caixeta i treure latiguillos per les antenes
• Dins del rack, preparar transformador + PoE per encendre el switch
• Moure antenes i màstil i endollar antenes al switch
• Reconfigurar RB2011 perquè crei VLANs sobre el port SFP1.
• Enganxar cable terra a la canal i al màstil

Vam tenir uns quants problemes per fer que funcionessin les VLAN (de fet, encara no hem resolt el problema). Bàsicament, no configuràvem bé la RB2011 per a que fes un bridge d’una VLAN sobre el port SFP i una boca ethernet.

Foto final:

Connectant les preses de terra d’un supernode (1)

En primer lloc, donar les gràcies a en Jaume Fiol per la seva ajuda que, sense ell, això no hagués estat possible.

Recentment un llamp va destruir part dels dispositius d’un supernode ja que gran part de la corrent va introduir-se pels cables ethernet. Amb això vaig començar a investigar la part més elèctrica de les instal·lacions de supernodes. Tot i que no hi ha mai solucions màgiques contra els llamps o el dany ESD (Electrostatic discharge), la principal causa de què alguns dispositius de l’interior del supernode es veiessin afectats va ser en gran part perquè les terres no estaven ben instal·lades.

Si la infraestructura hagués comptat amb una instal·lació de terres adient, la majoria de la corrent que va provocar el dany elèctric s’hagués drenat pels cables de terra i no hagués entrat dins la casa.

Aquest és un post d’un seguit de publicacions on aniré explicant com hem anat adaptant els diferents supernodes per tal de tenir-los elèctricament segurs i aïllats.

Consideracions generals

Generalment, hi ha vàries coses a tenir en compte a l’hora de muntar les preses de terra per una instal·lació informàtica i de telecomunicacions:

• El cablejat de terra ha de conduir-se a una petita fossa i s’ha de connectar a una piqueta de coure enterrada en la seva totalitat  que, per normativa, ha de ser d’almenys 1,5m.
• Si el cable de terra ve dels màstils de les antenes o d’un parallamps, es recomana que sigui de secció de 35mm2 de diàmetre i vagi a parar a una piqueta diferent.
• Les terres han d’unir-se sempre amb un cablejat de al menys la meitat del cable més gruixat (18mm2 en aquest cas). Si no, poden produir-se diferències de potencial entre terres i generar problemes amb els equips informàtics.
• Una vegada connectades les terres, han de comprovar-se amb un mesurador de terres que ha de donar una resistivitat inferior a 50 Ohms per cases i menor a 10 Ohms per torres de telecomunicacions.
• El conjunt de cables que d’alguna manera estan en contacte amb les terres (pantalles de cables FTP, tomes de terra dels Shukos, cables de terra individuals etc.) NO poden formar bucles entre ells, sinó que han de fer una topologia d’estrella. Si formen bucles, poden generar el que es coneix com a Grounding Loops, que no és més que renou electromagnètic que pot afectar els cables.
• Per això, mai connectarem els ordinadors amb cables FTP, sempre UTP, ja que els ordinadors duen ja preses de terra. La presa de terra de l’apantallat ha de fer-se al commutador.
• Pels dispositius de màstils, és recomanable que les seves tomes de terra estiguin desacoplades de les terres interiors. Si s’alimenten amb un dispositiu PoE i es connecten a la terra dels màstils ja és suficient, ja que el transformador, tot i estar dins la casa, en principi tendrà la terra desacoplada*. Per seguretat extra, es poden connectar amb fibra o posar elements de protecció de sobretensions.

Un possible esquema podria ser aquest:

*Una excepció són els PoEs d’Ubiquiti, que tenen la terra dels PoEs pontejada directament a la pantalla dels FTP.

Instal·lació d’una toma de terra pels màstils al supernode AlqueriaDesComte40

Enllaç al supernode: https://guifi.net/ca/node/60610

Les metes d’aquesta instal·lació són:

• Ajuntar els màstils a una presa de terra comuna
• Fer baixar un cable de terra de 35mm2 per la façana el més vertical possible
• Connectar la presa a una pica dins una arqueta
• Interconnectar aquesta terra amb la terra de la casa per fer la unió equipotencial

Part 1. Preparació de l’arqueta

En primer lloc, picàrem la terrassa fins a tenir un forat suficientment gros on posar l’arqueta i clavar la piqueta.

Clavàrem la pica amb l’ajuda d’un martell rotatiu i encimentàrem l’arqueta.

Part 2. Preparació de la regata que ajunta l’arqueta de la nova pica amb l’arqueta de la pica de la terra de la casa.

Picàrem el costat de la paret per fer una regata i rodejàrem el pou per dins la terra fins arribar a l’altra arqueta.

Part 3. Connexió dels màstils al cable de terra

Ja a la teulada, connectàrem dos màstils al cable de terra. Pontejàrem dos cables i férem un enllaç dins d’una caixeta estanca mitjançant una borna sigma.

Part 4. Descens del cable de terra fins a l’arqueta nova

Per fer descendir el cable, primer tiràrem un cordill des de la teulada fins abaix de tot. Col·locàrem el cordill a la posició desitjada i lligàrem el cable de 35mm2 a ell. Estiràrem el cordill i fermàrem el cable a la teulada per tal que no caigués.

Llavors, posàrem vaselina al cable i el férem passar tub H de PVC. Empenyérem el tub de dalt a baix. Travàrem el tub als tacos que prèviament havíem clavat a la paret. Finalment, unírem el cable a la pica d’abaix juntament amb el cable que venia de l’altra arqueta.

Guifi.net a l’escola Es Puig

D’un temps ençà la regidora d’educació de l’Ajuntament de Sóller ens exposà el problema que tenien les escoles de la vall amb l’accés a Internet. A la majoria d’escoles no hi arribava connexió de fibra i, a les que hi arribava, l’Ajuntament per motius legals no hi podia efectuar cap contracte.

En alguns llocs, les escoles de les Balears que tenen recursos o inclús a través de les AMPAs poden pagar-se una connexió de fibra òptica. Tot i així, l’accés a Internet principal de les escoles està lligat a un concurs públic que depen de la Conselleria d’Educació i no de cada centre. Aquest accés a Internet no és substituïble perquè aprovisiona una connexió VPN que dóna cobertura a varis serveis de gestió dels centres, el famós Xarxipèlag.

Donada la bona ubicació de l’escola Es Puig, la solució que els proposàrem es basava en la realització d’un projecte pilot que consistia en la instal·lació d’un supernode de Guifi.net a l’escola. Llavors, Gotes.org, la cooperativa sollerica que treballa amb Guifi.net i amb la qual treballam actualment, aprovisionava un accés a Internet d’alta velocitat pels professors i la instal·lació de dos punts d’accés WiFi perquè es poguessin connectar. El supernode es manté amb les aportacions que paguen els usuaris connectats a aquest tram de la xarxa.

Aquest supernode té els següents requeriments:

• Trobar un punt elevat a l’escola que no molesti i tengui el màxim de visió possible.
• Trobar un petit espai on instal·lar un SAI i un router.
• Espai per passar cables des d’aquest punt fins al SAI i router.
• Permetre l’ampliació del node a fins a 5 antenes.
• Donar accés a aquesta xarxa a dos punts de l’escola.

Material

Decidírem optar per instal·lar:

• SAI APC Smart-UPS
• HeX PoE (RB960 PGS)
  
• Troncal cap a un dels supernodes del centre de Sóller RB911G-5HPacD amb antena RF-Elements Station Box XL
  
• Sectorial RB922uags-5hpacd amb una antena Horn d’RF-Elements
• Cable de xarxa per exteriors
• 2 TP-Link WR841N

 

Instal·lació

El primer pas fou passar uns quants cables des del terrat de l’edifici fins al rack, fent-los passar pels rodapeus de les parets i per l’estructura de ciment que aguanta les plaques solars.

Després instal·làrem el màstil i les antenes

Finalment, l’interior. El HeX PoE ajuda moltíssim a tenir organitzats els cables, ja que ens evita tenir PoEs escampats per tot. El TPLink és per donar Internet als mestres.

Visió del supernode

Veus ca teva?

Ampliació

Per evitar possibles problemes elèctrics, una possible ampliació seria moure el HeX PoE a fora a l’exterior i alimentar-lo mitjançant PoE, que estaria desconnectat. Podria incloure’s també un ETH-SP per protegir l’interior de sobretensions. Aquest HeX estaria connectat amb l’interior únicament amb una fibra òptica, que es convertiria amb coure mitjançant FTC de Mikrotik i es connectaria al TPLink.

Així mateix, per alimentar el transformador es podia col·locar un petit quadre elèctric amb un tèrmic, diferencial i un protector de sobretensions.

Gotes.org: la cooperativa sollerica d’accés a Internet

L’inici del projecte Gotes.org es remonta a finals de 2016. En Bartomeu tornava de Barcelona i ens reunirem un dia per parlar de varis temes frikis. Entre pizzes del Círculo i cerveses sortí la idea de reimpulsar la xarxa de comuns a Sóller que jo havia estat desenvolupant durant uns anys pel meu compte i de forma no professional.

Sorgiren aviat els dubtes i l’etern dilema sobre si professionalitzar i comercialitzar la xarxa lliure és legítim o no. El dilema s’esfumà aviat. Els motius per decidir tirar endavant eren bàsicament els següents:

• No es pot seguir mantenint una infraestructura sense que els usuaris que l’empren paguin pel manteniment. El cost del hardware i de les hores de feina no el pot assumir un sol particular.
• Dúiem moltes hores invertides en aquest projecte. Moltes hores: si no ens reportaven algun tipus de benefici, encara que fos el benefici just per fer créixer la xarxa, ens podíem arribar a cremar.
• Guifi.net té una proposta de model de negoci consolidada que resol com fer créixer la xarxa lliure sense que ningú se n’apropiï, tot mantenint-ne els valors originals.
• El fet de tenir una cooperativa i un projecte consolidat ens permetia tenir una certa base de recursos per poder fer créixer aquest i altres projectes.

Després d’això, decidirem contactar també amb en Pepllu, un amic també friki i inquiet com nosaltres perquè fos el tercer soci de la cooperativa.

Foto: Pepllu. La il·luminació que ve de baix fa la foto un poc creepy.

Que per cert, no decidirem muntar una cooperativa només pels avantatges fiscals. Les cooperatives tenen uns objectius socials que complir més enllà de fer doblers. Aquesta idea casava perfectament en el model de desenvolupament que volíem implementar.

Per un dels projectes que hem fet, en Bartomeu va escriure un text explicant la idea de Gotes.org i contextualitzant-la amb Guifi.net:

Què és Gotes.org

Guifi.net és la xarxa de transport de dades on es connecten els usuaris. Un cop connectats poden accedir als serveis que hi hagi dins la xarxa Guifi.net o connectar-se entre ells. No obstant la intenció de la majoria d’usuaris es emprar Guifi.net per arribar un punt on hi hagi Internet i així poder dotar les seves llars de connectivitat a Internet.

Donat que l’accés a Internet és demanda majoritària dels usuaris de Guifi.net el projecte Gotes.org pretén donar tal servei. D’aquesta manera els usuaris podran accedir lliurement i sense cost a la xarxa Guifi.net i els que vulguin Internet podran fer-ho contractant el servei a Gotes.org. D’aquests contractes entre usuaris i Gotes.org sorgirà el capital que el projecte Gotes.org aprofitarà per fer créixer i mantenir la xarxa física de Guifi.net.

Tot i la separació de xarxa de transport de dades i servei a Internet l’efecte final a l’usuari serà una connexió a Internet exactament igual que la que podria proporcionar qualsevol altre operador convencional, amb la diferència d’estar donat suport a un projecte que contribueix a l’empoderament local de les telecomunicacions.

Així doncs per una banda tendrem la infraestructura física que serà de propietat mancomunada i de lliure ús per a qualsevol ciutadà – també anomenada de comuns – i, per l’altra, hi haurà un servei d’Internet ofert sobre la xarxa d’un projecte Solleric Gotes.org que serà el sustentarà econòmicament el desenvolupament de la xarxa Guifi.net.

Gotes.org i Guifi.net, similituds i diferències.

Entendre quin és el paper de cada entitat és crucial per entendre la direcció del projecte.

1. Guifi.net és un projecte ja consolidat a d’altres llocs nascut el 2004
2. Gotes.org és un projecte que es consolidà legalment a principis de 2017
3. Guifi.net és una fundació sense ànim de lucre.
4. Gotes.org és una cooperativa.
5. Guifi.net és un projecte nascut a Catalunya d’àmbit estatal.
6. Gotes.org és un projecte solleric que actuarà dins l’àmbit de la vall.
7. Guifi.net serà el responsable legal i propietari dels equips i dispositius (antenes) de la xarxa.
8. Gotes.org no tendrà infraestructura física ja que la donarà a Guifi.net perquè sigui xarxa de Comuns.
9. Guifi.net no dóna servei d’accés a Internet, simplement connecta usuaris entre sí.
10. Gotes.org dona servei d’internet a la gent que el contracti i sobra la infraestructura que cedeix a Guifi.net.
11. Guifi.net és una xarxa física d’antenes i dispositius.
12. Gotes.org és un servei virtual sobre la xarxa.
13. Tant Guifi.net com Gotes.org son entitats que fomenten l’accés de les persones a la xarxa i la seva interconnexió.
14. Tant Guifi.net com Gotes.org son entitats que posen per davant les persones i els valors en front al benefici econòmic que empren per tal de fer viable i sostenible el projecte.

Remodelació del supernode del Pujol den Banya

Anys després de l’última actualització he decidit tornar a escriure per aquí. No haver escrit durant tot aquest temps no vol dir que no haguem fet res, sinó tot el contrari. Tot i tenir l’electrònica una mica abandonada, la xarxa Guifi.net s’ha anat ampliat i expandint.

Per donar cabuda als nous clients que es connecten a la xarxa i poder oferir un servei més professional i unes mínimes garanties de qualitat, hem desenvolupat varis “estàndards” tant de software com de hardware alhora de construir supernodes. Un dels supernodes antics que s’aguantaven amb pinces era el supernode del Pujol den Banya, per la qual cosa ens decidírem a millorar-lo.

 

Tot i que les antenes i la placa eren bones, la instal·lació era bastant precària. Es tractava d’una caixa estanca de plàstic amb una antiga RB450G pelada. La instal·lació elèctrica era un cable d’exteriors (això sí, per dins un tub corrugat) empalmat a un lladre de tres schukos. Les caigudes de corrent eren constants i la temperatura placa s’elevava fins a 100ºC durant l’estiu.

Així va aguantar prop de dos anys, fins que decidirem remodelar el supernode al desembre de 2017. Els requisits, aquesta vegada, eren:

• Allunyar la instal·lació de la casa, preferiblement al dipòsit que es trobava a uns 25m.
• Fer arribar alimentació elèctrica fins al dipòsit.
• Instal·lar un SAI i bateries monitoritzats.
• Instal·lar una Routerboard nova.
• Permetre l’ampliació del node a fins a 4 antenes.
• Instal·lar un enllaç de backup cap a un altre supernode de Sóller.
• Encabir-ho tot dins una caixa estanca d’exteriors.

Material

Pel que fa a les antenes, decidirem mantenir les mateixes que ja hi havien. Aquestes eren una Ubiquiti Rocket AirMax M5 i una Ubiquiti Nanobeam M5. Pel que fa a la RouterBoard, canviàrem la vella 450G per una flamant Routerboard HeX. Per l’enllaç de backup, decidirem instal·lar una Mikrotik DISC Lite apuntant cap al supernode d’Astúries 42.

Pel que fa al SAI, adquirirem un SAI APC Smart-UPS. Massa gros i pesat pel meu gust, i ara, després d’uns mesos, diria que poc professional.

Pel que fa al cablejat, instal·làrem un cablejat d’exteriors multifil trenat però connectarem als extrems connectors RJ45 femelles enlloc de mascles. La intenció era col·locar aquests connectors dins caixetes Rover d’antena de TV. Al final, això no va ser del tot bona idea perquè a més de car resultava molt engorrós. Molt més senzill simplement grimpar un mascle.

Per que quedi clar… Instal·lacions exteriors a torre: femella a mascle, multifil trenat. Preferiblement no CCA. Instal·lacions interiors: femella a femella sempre, un sol fil de coure. FTP o UTP mentre no sigui a llocs amb molta interferència és igual.

El dispositiu APoE08G és una molt bona opció per tenir els PoEs ben ordenats a dins el rack o dins la caixa. Es tracta simplement d’un conjunt de PoEs junts i alimentats per la mateixa entrada de 12V a 48V. Una idea simple però que ajuda a que les instal·lacions quedin molt més estètiques i ordenades.

Per la caixa, trobarem a darrera hora una caixa de distribució elèctrica bastant gran a Bricomart. Aquesta caixa disposava de varis carrils DIN.

Per tal que els dispositius quedessin ben fixats, era important tenir peces per enganxar-los al carril DIN. En primer lloc, necessitàvem tomes pels cables que venien de fora. Cada una costava 10€, massa car per ser un simple tros de plàstic. Necessitàvem també clips per enganxar la resta d’elements, com el transformador, la routerboard o l’APoE08G.

La solució a tot això va ser imprimir-ho amb la impressora 3D. Una solució barata i eficient 😉

Dia d’autos

La primera feina i la més complicada va ser la de transportar l’electricitat des d’una banda de la finca fins a l’altre punt. Per això vàrem haver de col·locar un tub de prop de 25m per davall del marge fins a la zona on anteriorment estava el supernode per fer un empalme.

Consell per a la posteritat: fixar primer el tub i passar la guia després. Mai al revés…!

Mentrestant, un altre equip anava muntant la caixeta i començava a col·locar el cable FTP.

 

 

La caixeta casi enllestida:

Una vegada la caixeta va estar muntada i havíem dut el cable cap a l’altre posició, ens vàrem haver de sincronitzar al màxim per desmuntar el màstil d’un extrem, fer l’empalme i transportar-lo a la parra en el mínim temps possible. Al final va funcionar de meravella a la primera. Llàstima de dos problemes que ens trobàrem al moment:

• Les femelles del màstil feia un curtcircuit ja que el recobriment FTP de la femella feia mal contacte amb els cables grimpats. Un error terrible de disseny i que demostra que el sistema de grimpar femelles a l’extrem del màstil ens va dur més mals de caps que solucions.
• L’antena sectorial tenia configurat un watchdog que la reiniciava si no responia als pings de google. Com que es va fer un canvi en el disseny L3 el ping fallava i reiniciava l’antena cada 15 minuts. Me’n vaig adonar en arribar a casa i ho vaig aturar.

Finalment, hi tornàrem uns dies més tard per col·locar l’antena de backup.

Coses a millorar…

• Primer fixar el tub, després passar la guia i el cable…!
• Posar un SAI més dimensionat i professional. Una placa OpenUPS amb bateries, per exemple.
• Simplicitat: evitar posar elements de més que no aporten millores substancials, com ara les femelles al màstil.
• Caixes grosses per tenir espai per col·locar els elements.
• Evitar posar cable FTP si no estam a zones amb interferències d’equips electrònics propers, ja que pot ser pitjor. Si no està correctament muntat, la pantalla ens pot fer d’antena. A més, ens sortirà més car.

Afegir noves mètriques a Ganglia

Ganglia és un sistema de monitorització per clústers de computació de codi lliure i bastament utilitzat. Hi ha poca documentació i tot i que posar-lo en marxa és molt fàcil, crear noves mètriques per monitoritzar i noves gràfiques és bastant tediós.

Compartesc el que he estat fent aquests dies a la feina per aquí:

Afegir una nova mètrica a Ganglia (mètode 1)

Ganglia permet dues maneres d’afegir noves mètriques i gràfiques per monitoritzar. La primera és la més senzilla i, també, menys personalitzable.

Executam a cada màquina que vulguem monitoritzar la mètrica la comanda gmetric. Vegeu un exemple:

#!/bin/bash

clush -bw foner[1,2,11-14,101-142] gmetric –name NumUsuaris –value `python /home/joan/scripts/estadistiques/ganglia/grepnusuers.py` –type int16 –units Unitats

És recomanable posar aquest script al crontab perquè es vagi mirant sempre.

A la web de Ganglia, per poder-les veure haurem de posar el paràmetre ?m=NumUsuaris per veurer-la.

Afegir una nova mètrica a Ganglia (mètode 2)

El segon mètode és molt més complet i permet afegir mètriques i visualitzar-les a la pàgina web, amb vistes personalitzades.

A) Afegir un nou plugin amb Python

Les darreres versions de Ganglia permeten afegir noves mètriques mitjançant scripts de Python.

Escrivim un mòdul d’exemple (NO ESTIC SEGUR QUE ELS COMENTARIS FUNCIONIN):

cat <directori_ganglia>/etc/conf.d/modutilusu.pyconf

modules {

module {

name = “utilusuaris” #Nom del fitxer .py, l’script de python, sense l’extensió.

language = “python”

}

}

collection_group {

collect_every = 86400 #Cada quant de temps, en segons, ees comprovarà la mètrica (s’executarà l’script)

time_threshold = 90

/* Load Averages */

metric {

name = “util_user” # Nom de la mètrica

value_threshold = “1.0”

title = “Utilitzacio dels usuaris mes actius” #Descripció. NO POSEU ACCENTS

}

}

Llavors afegim el mòdul. Aquí un d’exemple:

cat /usr/local/ganglia-3.6.0/lib64/ganglia/python_modules/utilusuaris.py

#!/usr/bin/env python

# -*- coding: utf-8 -*-

###########################

#

# Reporta el percentatge d’utilitzacio

# dels 5 usuaris que mes empren el foner

# cada mes

#

###########################

import os

from os import listdir

from os.path import isfile, join

from subprocess import Popen, PIPE

import threading

import time

import urllib2

import traceback

import re

import copy

LIMIT_USU=3 #Tall per fer el recompte

descriptors = list()

#Reportam des de dia 31 del mes anterior al dia 31 del segon mes anterior

sstart = time.strftime(“%Y”)+’-‘+str(int(time.strftime(“%m”))-2).zfill(2)+’-‘+”31″

send = time.strftime(“%Y”)+’-‘+str(int(time.strftime(“%m”))-1).zfill(2)+’-‘+”31″

def get_value(name):

comanda = “sreport -p -n user topusage Start=”+sstart+” End=”+send+” TopCount=40 | grep -v ‘|cti|'”

#La comanda ens traurà tots els usuaris, ordenats per utilització.

items0=Popen(comanda, stdout=PIPE, shell=True).stdout.read()

lines = items0.splitlines()

acc=0.0

i=0

for line in lines: #Iteram entre totes les linies que ens ha retornat la comanda

if i==LIMIT_USU:

val=acc

vline=line.split(“|”)

acc=acc+float(vline[4])

i=i+1

return val/acc

def create_desc(prop):

d = Desc_Skel.copy()

for k,v in prop.iteritems():

d[k] = v

return d

def metric_init(params):

global descriptors, Desc_Skel

Desc_Skel = {

‘name’ : ‘XXX’,

‘call_back’ : get_value,

‘time_max’ : 60,

‘value_type’ : ‘float’,

‘units’ : ‘proc’,

‘slope’ : ‘both’,

‘format’ : ‘%d’,

‘description’ : ‘XXX’,

‘groups’ : “Foner_Mensual”,

}

#Aquest append aafgeixeix una mètrica més al Ganglia. Podem copiar aquestes línies tantes vegades com vulguem per crear noves mètriques.

descriptors.append(create_desc({

“name” : “util_user”, #Nom de la mètrica. IMPORTANT!

“value_type” : “float”,

“units” : “segons”,

“call_back” : get_value,# Funció que s’executarà per extreure el valor.

“format” : “%.3f”,

“description”: “Utilitzacio 3 usuaris mes actius”, #NO POSEU ACCENTS

}))

return descriptors

def metric_cleanup():

#_Worker_Thread.shutdown()

pass

if __name__ == ‘__main__’:

try:

params = {

‘url’ : ‘http://localhost:7070/server-status&#8217;,

‘collect_ssl’ : False

}

metric_init(params)

for d in descriptors:

v = d[‘call_back’](d[‘name’])

print ‘value for %s is %.4f’ % (d[‘name’], v)

except KeyboardInterrupt:

os._exit(1)

B) Afegir una gràfica

Podem fer-ho de dues maneres:

B.1) Nou report:

– A /var/www/html/ganglia2/graph.d/ podem incloure un json com el següent:

{

“report_name” : “treballs_coa”,

“report_type” : “standard”,

“title” : “Apache HTTP codes”,

“vertical_label” : “req/sec”,

“series” : [

{ “metric”: “treb_totals_fat”, “color”: “3333bb”, “label”: “Treballs totals fat”, “line_width”: “2”, “type”: “stack” },

{ “metric”: “treb_totals_thin”, “color”: “ffea00”, “label”: “Treballs totals thin”, “line_width”: “2”, “type”: “stack” },

{ “metric”: “treb_totals_test”, “color”: “dd0000”, “label”: “Treballs totals test”, “line_width”: “2”, “type”: “stack” },

{ “metric”: “treb_totals_totes”, “color”: “ff8a60”, “label”: “Treballs totals totes”, “line_width”: “2”, “type”: “stack” }

]

}

I a http://10.240.0.20/ganglia2/graph.php?g=treballsencoa_inst_report el veurem.

O bé a:

http://10.240.0.20/ganglia2/graph_all_periods.php?c=foner&r=hour&s=by%20name&hc=4&mc=2&st=1406894244&g=treballsencoa_inst_report&z=large

D’aquesta manera podrem fer que surti a la pàgina principal del Ganglia, afegint el nom d’aquest report al fitxer següent:

cat /var/lib/ganglia-web/conf/default.json

{

“included_reports”: [“load_report”,”mem_report”,”cpu_report”,”network_report”,”treballsencoa_inst_report“]

}

B.2) Nova vista:

Una altra manera que ens permet tenir-ho més ordenat consisteix en crear una nova vista. Vegeu com fer-ho:

Al directori /var/lib/ganglia-web/conf/default.json afegiu un nou fitxer view_<nom>.json, i ens apareixerà com una nova vista. Afegiu, per exemple, el següent:

{

   "default_size" : "medium",

   "view_name" : "Example graph view",

   "items" : [

      { 

         "aggregate_graph" : "true",

         "graph_type" : "line",

         "host_regex" : [

            {

               "regex" : "foner1.bullx"
 #Expressió regular per treure els nodes que reportaran.
            }

         ], 

         "g_title" : "treb_totals_fat",

         "metric_regex" : [

            {

               "regex" : "treb_totals_.*"
 #Expressió regular per treure les mètriques a monitoritzar.
            }

         ],

         "title" : "Example graph",
 #Títol
         "vertical_label" : "Units",

         "glegend" : "show"

      }
,
      { 

         "aggregate_graph" : "true",

         "graph_type" : "line",

         "host_regex" : [

            {

               "regex" : "foner1.bullx"

            }

         ], 

         "g_title" : "treb_thin_fat",

         "metric_regex" : [

            {

               "regex" : "treb_thin_.*"

            }

         ],

         "title" : "Example graph",

         "vertical_label" : "Units",

         "glegend" : "hide"
 #Amaga la llegenda
      }

   ],

   "view_type" : "standard"

}


C) Atenció amb:
Afegir noves mètriques pot ser un poc tricky, en el sentit que podeu quedar travats facilment. Vegeu alguns consells:

– Comproveu els paths dels fitxers de configuració. Vigilau, que si el directori és /usr/local/ganglia-3.6.0 i els paths estan malament no avisarà i simplement no es mostrarà.

– Modificar un plugin, ja sigui el .pyconf com el .py, sense reiniciar el dimoni gmond fa que el Ganglia deixi de graficar sense avisar. Comprovau-ho una vegada hàgiu creat o modificat els vostres scripts!

– Compte amb els caràcters “’” i accents al .pyconf i al .py.

– Els fitxers de configuració dels plugins NO necessiten estar a tots els nodes. Si estan només a un, només aquest serà l’únic que reportarà la mètrica.

– Si posau caràcters extranys i deixa de graficar, probablement el fitxer .rrd contendrà errors i l’haureu d’esborrar. Fent-ho perdreu totes les dades d’aquella mètrica per sempre! Es tracta de borrar el fitxer corresponent al directori /var/lib/ganglia/rdd

Compilant els drivers del TP-Link WDN3200 en Ubuntu 14.04

Avui m’ha arribat el trastet aquest, que disposa d’un xip de 802.11 ac (doble banda 2’4 i 5 GHz). No acaba de funcionar correctament en Ubuntu 14.04, i compilar-ho de la forma que surt googlejant no acaba de funcionar tampoc amb el nou kernel 3.13.

Aleshores, feim el següent:

$ wget http://www.ctheroux.com/publicfile/DPO_RT5572_LinuxSTA_2.6.0.1_20120629_EDITED.tar.bz2.bz2
$ tar xvjf DPO_RT5572_LinuxSTA_2.6.0.1_20120629_EDITED.tar.bz2.bz2
$ cd DPO_RT5572_LinuxSTA_2.6.0.1_20120629

Modificam el fitxer os/linux/rt_linux.c i cercam la línia 1207. Modificam el següent:

pOSFSInfo->fsuid = current_fsuid();
pOSFSInfo->fsgid = current_fsgid();
pel següent:
pOSFSInfo->fsuid = __kuid_val(current_fsuid());
pOSFSInfo->fsgid = __kgid_val(current_fsgid());

Llavors:
$ sudo make
$ sudo make install

I a creuar els dits

Alternativa al proxy a Guifi.net amb VPN

Molts usuaris dins Guifi.net troben incòmode el fet d’haver d’emprar un servidor proxy per accedir a Internet des de dins la xarxa. I no els falta raó: Molts dispositius mòbils, inclús moltes aplicacions de Windows o inclús de Linux, són complicades de configurar perquè emprin un proxy. Sent plenament conscients que el principal objectiu de Guifi.net no és “Internet gratis”, no podem obviar que en un inici si no li donam una utilitat a la xarxa ningú l’emprarà. I una de les millors utilitats que li trobarem ara per ara és precisament compartir l’ADSL. Val la pena, per tant, trobar un sistema més còmode que el servidor proxy.

El nostre objectiu és, per tant, trobar una manera de compartir la nostra connexió ADSL amb qui nosaltres vulguem, podent estar segur de què només qui noltros vulguem la fa servir i podent limitar i controlar la connexió d’aquests usuaris (p.ex. no permetre que visitin segons quins llocs). La intenció és que, al menys a la part del client, la configuració d’aquest sistema sigui molt simple i que només s’hagi de fer una vegada.

 

La idea

La idea que tenim, aleshores, consisteix en fer servir un servidor VPN a un dels nodes, a la vegada connectat a l’ADSL i a Guifi.net, que enruti el trànsit dels clients cap a fora. A l’altre extrem de la xarxa de Guifi.net, els clients VPN poden ésser tant dispositius finals (portàtils) com APs domèstics. En el cas dels APs domèstics, es distribueixen dos SSIDs: un d’obert i que només permet accedir a les rutes de Guifi.net, i un de privat, que encamina tot el trànsit que no va a cap IP pública de Guifi.net a través del túnel VPN.

Tot i que el concepte és senzill, el fet que la VPN conformi una xarxa diferent requereix de regles de firewall complexes, de masqueradings i d’enrutaments entre xarxes.

Esquema de com seria la infraestructura d’un servidor VPN amb múltiples clients dins guifi.net

 

Topologia de la xarxa

Com que la infraestructura dels nodes híbrids* és, o hauria de ser, idèntica entre tots ells, suposarem que cada node es composa d’una antena connectada al supernode, que fa de router entre la xarxa privada interna (192.168.1.0/24) i la xarxa pública de guifi.net (10.0.0.0/8). Aquesta antena fa NAT i una IP interna privada arbitrària (per simplicitat, suposem 192.168.1.1).

 El nostre router client d’VPN, però, no serà l’antena, perquè aquesta no ens pot proveir d’una WiFi dins la casa. Aquest nou router haurà d’anar connectat directament a l’antena, a la xarxa 192.168.1.0/24, amb la IP 192.168.1.2. Per no haver de crear més xarxes, més NATs i més IPs, vaig decidir que la WiFi privada també estava dins la xarxa 192.168.1.0/24, mentre que la pública es trobaria a la xarxa 192.168.0.0/24 amb IP 192.168.0.1.

 D’aquesta manera, qualsevol usuari hauria de tenir com a porta d’enllaç per defecte el router client VPN. El propi router client VPN hauria de tenir com a ruta per defecte la interfície tun de la VPN, però també hauria de redirigir tot el que fos 10.0.0.0/8 i 172.16.0.0/16 cap a l’antena (192.168.1.1).

Així mateix, el Firewall permetria l’accés de la WiFi tancada cap a la VPN, mentre que no en permetria l’accés per la WiFi oberta, la qual només podria enrutar-se per l’antena 192.168.1.1.

És prou complicat d’entendre, i el batibull és considerable, però es veu més clar amb un esquema:

Esquema de com funcionaria un node client de guifi.net amb un client VPN. Aquest dibuix correspondria als cercles blaus de l’esquema anterior.

Router

El router client VPN emprat per fer les proves és un tp-link wr841n v9, molt barat i assequible, però amb unes característiques decents pel que volem fer, tot i que amb mancances de memòria flash. Això provoca que per instal·lar el client OpenVPN amb l’OpenWRT sigui necessari compilar el firmware de nou amb el paquet ja instal·lat. Jo ho vaig fer amb l’ImageBuilder de l’OpenWRT sense més complicació.

Una de les coses a tenir en compte del router és si serà capaç de córrer com a client VPN donant servei a varis usuaris sense sobrecarregar-se en excés. Els seus 32 MB de memòria semblen ser suficients, ja que l’ús de memòria pareix mantenir-se sempre més o menys constants (El procés OpenVPN sembla menjar-se’n un 13%). El processador es posa al 40% quan hi ha una càrrega d’una pàgina pesada. Caldrà veure com es comporta amb un nombre major de clients.

 

Servidor

El servidor que hem fet servir per provar és un Ubuntu Server 14.04 prou antic (AMD Athlon(tm) 64 X2 Dual Core Processor 4200+), però no crec que tengui cap problema per córrer com a servidor d’OpenVPN.

Com els proxies, aquest servidor necessita de dues interfícies: Una a guifi.net i una a Internet. La interfície de guifi.net està dins la xarxa de casa, darrere el clàssic NAT d’un router normal i corrent.

Vegeu el fitxer /etc/openvpn/openvpn.conf:

dev tun #Tun o Tap, Tap és per tunnels a L2

proto udp #UDP o TPC…

port 1194 #Defines the port to connect

ca /etc/openvpn/easy-rsa/keys/ca.crt #This defines where keys and cert are kept

cert /etc/openvpn/easy-rsa/keys/server.crt

key /etc/openvpn/easy-rsa/keys/server.key

dh /etc/openvpn/easy-rsa/keys/dh2048.pem

server 10.8.0.0 255.255.255.0 #Rang d’Ips dels clients VPN

status /var/log/openvpn-status.log # fitxer de log

verb 3 # Quantitat de missatges de log

push “redirect-gateway” # MOLT IMPORTANT perquè els clients assignin el serv. VPN com a def. gw.

push “dhcp-option DNS 10.91.9.66” # IMPORTANT perquè els clients tenguin com a DNS el serv. VPN

log-append /var/log/openvpn #log

comp-lzo # Compressió lzo

management 127.0.0.1 1194 # Per management

I la configuració de les interfícies de /etc/network/interfaces:

auto lo

iface lo inet loopback

 auto eth0

iface eth0 inet static

address 10.91.9.66

netmask 255.255.255.224

up route add -net 10.0.0.0 netmask 255.0.0.0 gw 10.91.9.65

up route add -net 172.16.0.0 netmask 255.255.0.0 gw 10.91.9.65

down route del 10.0.0.0 netmask 255.0.0.0 gw 10.91.9.65

down route del 172.16.0.0 netmask 255.255.0.0 gw 10.91.9.65

 # The primary network interface

auto eth1

iface eth1 inet static

address 192.168.1.2

netmask 255.255.255.0

gateway 192.168.1.1

up iptables -t nat -A POSTROUTING -o eth1 -j SNAT –to-source 192.168.1.2 # feim snat del que surt per la LAN de casa nostra.

up iptables -A FORWARD -i tun0 -d 192.168.1.0/24 -j DROP # És MOLT important això perquè sinó els clients de guifi.net podrien accedir a les IPs de la nostra LAN interna de casa.

 

Control de l’ample de banda dels clients al servidor
Segurament serà molt necessari poder limitar l’ample de banda que volem oferir a la xarxa guifi.net. Amb la comanda tc podem limitar l’ample de banda de eth0 (la interfície de xarxa que està dins guifi.net).

La limitació és que no podem especificar que si la petició va a la nostra màquina (DNS, ftp, http etc.) no tengui en compte la restricció d’ample de bnada, però tot i que hi ha formes de solucionar-ho tampoc no és molt important en el meu cas.

tc qdisc add dev eth0 root handle 1: htb

tc class add dev eth0 parent 1: classid 1:512 htb rate 512kbit

tc filter add dev eth0 protocol ip parent 1: prio 1 u32 match ip \ dst 0.0.0.0/0 flowid 1:512

També podem crear un script a /etc/init.d que ens ho faci.

 

A nivell d’usuari…

Per configurar un router que li faci de client VPN, simplement es necessita:

– Un router tp-link wr841n v9,

– La imatge del firmware preconfigurada que podeu descarregar aquí

– Cables, endolls, etc.

Una vegada graveu la imatge del firmware al vostre router, quan vos hi connecteu per ssh per primera vegada s’executarà un script de configuració del router. Llavors, només queda canviar la contrasenya de root, reiniciar-lo i endollar l’antena a un dels ports del switch de la LAN.

Per altra banda, l’usuari haurà de copiar els certificats del servidor VPN al directori /etc/openvpn perquè el sistema funcioni.

 

Conclusions

Compartir Internet mitjançant guifi.net amb aquest sistema hauria de ser molt més senzill i no requerir cap tipus de configuració al client. Després de fer algunes proves de càrrega i d’estabilitat, podem concloure que aquest sistema podria funcionar de forma estable i amb varis clients connectats a la vegada. Encara fa falta fer algunes proves, per això ja he encomanat 5 routers més per començar a distribuir!

Adjunts:

Imatge pel WR841N V9 amb els fitxers de configuració preparats i amb un script d’ajuda. Entrau al 192.168.1.2 per telnet una vegada flashejat! Pensau que hi faltaran els certificats, que heu de sol·licitar a l’admin del servidor vpn.

openwrt-ar71xx-generic-tl-wr841n-v9-squashfs-factory.bin.zip (pensau a llevar-li el .odt)