Una breve actualización general

Publicado 20 abril, 2019 por Nachintoch
Categorías: Discución.

Tags: , , , ,

Hola a todos, he vuelto después de un largo tiempo sin publicar nada por acá; no estaba muerto y desgraciadamente tampoco andaba de parranda.

Decidí por primera vez, en un tiempo aún más largo, que es momento de publicar un post un tanto más personal de actualización. Y es que desde que definí el tema que seguiría este blog, al principio y por mucho tiempo lo considere únicamente como un medio de consulta; que ha funcionado bastante bien, pero creo que justamente ese crecimiento implica que las cosas tendrán que ir cambiando poco a poco.

Y por cosas, me refiero a los otros instrumentos que utilizo para difundir y compartir sobre computación, software libre y tecnología; como Gitlab y mi página web, hasta ahora cada uno de estas herramientas se han relacionado poco y cada una parece tener un rumbo especial.

En los últimos años mi vida a dado varios giros; unos más bruscos que otros, y ahora creo tener un panorama más amplio y un enfoque más claro de lo que busco en diferentes aspectos principalmente en lo que quiero en mi vida profesional, que en consecuencia me ha llevado a pensar qué rumbo tendrán estas publicaciones.

Quiero compartir un poco sobre estos giros; en parte porque creo que puede ser una buena experiencia y reflexión, y para mí han sido una serie de experiencias que cambiaron mi perspectiva sobre muchas cosas.

A finales del año pasado deje el trabajo en el que estaba. Al principio todo parecía ir de maravilla; pero al final tuve varios desencantos bastante fuertes que se sumaron a otras experiencias similares que voy a resumir más adelante. Así que con toda la presión que significa el desempleo; al final me decidí a hacerlo.

Aproximadamente un mes después me encontré con mi entonces tutor de la licenciatura; tenía más de un año de haber registrado mi proyecto de tesis y tenía hecho todo el proyecto, teníamos las pruebas, tenía casi la mitad de la tesis hecha y por más de un año no había podido hacer mucho.

Aprendí a la mala que no es posible hacer una tesis con solo dos horas diarias.

Un trabajo de calidad, de la importancia y el significado que tiene una tesis, difícilmente puede realizarse con todo el esmero y calidad que merece con solo dos horas diarias. Cuando menos es un trabajo de medio tiempo. Idealmente es un trabajo de tiempo completo.

Cada vez veo más memes y comentarios acerca de la terrible cultura laboral que tenemos aquí en México. Como aquél que dice

mexico-pais-donde-no-pagarte-las-horas-extras-se-le-llama-ponerse-la-camiseta-id-ggdcg

Y es que es solo uno de los factores que hacen a nuestra cultura laboral terrible. Quizá este y el problema salarial sean los factores más escandalosos en nuestra cultura laboral, pero no son los únicos aspectos negativos; quizá solo son dos aspectos de los más rezagados en cuanto a derecho laboral.

Al principio te venden los empleos con las mejores proposiciones: horarios flexibles, bonos, valoración del desempeño, buen ambiente, etc. En cuanto te contratan los problemas suelen salir al aire inmediatamente; pero llegamos con una imagen que nos hace ignorarlos y creer que son parte del ambiente de trabajo.

Hace alrededor de 13 años tuve mi primer trabajo. Era menor de edad, mi situación familiar era complicada y conseguí un empleo en una cocina. Trabajaba duro haciendo de todo. Picaba verduras, preparaba las aguas, ayudaba a preparar la comida; salía a repartir, tomar pedidos, hacer limpieza…

Y entre todas esas actividades yo pensaba en mi ingenuidad: cuando termine la prepa me va a ir mejor. Durante el bachillerato tuve al rededor de cuatro empleos más; todos los dejé por que me exigían más tiempo del que estaba dispuesto a darles (no porque fuera un vago, sino porque me interesaba tomar mis clases y hacer mi tarea). Y en todo caso, ¿el esparcimiento no es un derecho humano? ¿una persona; independientemente de su situación económica, no tendría derecho a disfrutar de un tiempo para ella misma?

El punto es que hasta hace unos años, mis empleos casi siempre eran de medio tiempo; pero por diversas causas, llegaba un punto en el que se empezaban a convertir en trabajos de tiempo completo. Algunos de ellos los dejé también por malas condiciones laborales, principalmente el que no te den el material o la preparación necesaria para desempeñar tus tareas y por su puesto las clásicas condiciones para que te paguen a tiempo y de forma integra.

Quizá a algunos les suene extraño que exija preparación; pues se supone que se contrata personal ya capacitado para realizar sus tareas. Pero dependiendo que hagas, puede ser necesario recibir capacitación o preparación, y tu empleador debe cubrir esos gastos. De hecho en software esto es muy común, puesto que las tecnologías avanzan; así como las metodologías de uso de las plataformas y de desarrollo también cambian, todos los profesionales de las TIC y campos afines tienen derecho a recibir preparación continua por parte de su empleador (su empleador no se tiene que convertir en escuela, pero puede pagar cursos en línea, contratar consultores o a entrenadores).

Además, puesto que el tiempo de preparación es destinado a realizar sus actividades, esas horas de estudio deberían de alguna forma formar parte de las horas productivas de los empleados. De esta forma, ese tiempo no impactaría de forma directa en el tiempo personal de los empleados; y así lo puede aprovechar de otras maneras, incluyendo aprendiendo otras tecnologías que le parecen atractivas en lo personal.

De lo contrario, solo le quitamos su valioso tiempo a las personas; parece que los empleadores creen que las personas aparecen y desaparecen del universo cuando entran y salen de los espacios de trabajo; pues esas personas tienen que invertir su tiempo en dormir, transportarse de su hogar al espacio de trabajo, se tienen que preparar para salir de su casa y al regresar del trabajo; hay un gran numero de actividades que consumen una parte significativa de un día y ni siquiera forman parte de la jornada laboral.

Y si encima tienes que llegar a casa a aprender un montón de cosas de forma autodidacta, a revisar pendientes, resolver bomberazos (no me hagan empezar con los bomberazos, cualquier problema urgente o situación no prevista, es muestra de una estructura débil de la organización y su mala administración en uno o más niveles) o hacer reportes; solo se extiende el espacio de trabajo y la jornada laboral de esa persona y su vida se convierte en su vida laboral.

Creo que en cierto punto, la mayoría de las personas pasamos por esa etapa; en la que nuestra vida es nuestra vida laboral. Y eso no es sano. Al principio puede parece ser lo mejor; todo promete, pero luego las cosas se quedan en promesas. A veces  dan probaditas, como aumentos, o vacaciones o un puesto. Pero cuando lo analizas fríamente, te das cuenta de que casi siempre (en mi experiencia siempre, pero les daré el beneficio de la duda; aunque no mi confianza); es puro atole con el dedo.

Por allí escuchas que pese a tu aumento, sigues estando por abajo del promedio salarial de otras personas en tu mismo puesto. O que van a dividir tu aumento entre varias personas. Descubres que tus logros y propuestas se mancharon con el nombre de alguien arriba de ti; que solo está allí por que como tú ha habido mucho otros que cayeron en su trampa y algunos siguen esperando que se cumplan sus promesas.

Promesas vacías que se mezclan con eterno ruido de las ciudades. Al final, te encuentras con un montón de metas sin cumplir, ¿y todo a cambio de qué? La experiencia siempre es buena y se agradece, porque al final nos dan conocimiento. Pero como dicen no solo de amor vive el hombre.

Y aunado a todo esto, siempre he sentido que mi salario jamás ha reflejado el valor de mi trabajo. Y por un margen importante, aún considerando todas las prestaciones que he llegado a tener (que tampoco es que sean muchas). Al final, con toda mi preparación, cuando pongo en retrospectiva mi vida laboral; he alcanzado puestos y nombramientos bastante altos pese mi edad y otros factores, pero la realidad es que mis condiciones laborales han cambiado muy poco en los últimos 13 años. Así que ¿porqué debería seguir ese camino?

Sé que mi caso no es el de todos; pese a la realidad asquerosa de nuestra cultura laboral (pues la he confirmado con todos mis conocidos), aún es posible que una buena vida laboral trabajo, sea el resultado de una buena trayectoria escolar. Pero en todo caso, lo más importante es no dejar de aprender; porque solo el conocimiento nos hace íntegros y nos hace libres; la mejor forma de explotar tu libre albedrío es con un panorama amplio que solo el conocimiento puede aportar, para así llegar a metas más altas.

Ahora sé que quiero dedicarme por completo a la academia; donde si bien muchos de estos problemas están presentes, y existen otras formas de injusticia laboral, me he identificado mucho con el equipo con el que desarrollé mi tesis y en los últimos meses he estado colaborando con ellos en una forma que me es muy agradable.

Al final, me siento muy satisfecho y contento de haber alcanzado esta meta que me puse hace tantos años en medio de una situación complicada, titularme ha sido lo mejor que me ha pasado en mucho mucho tiempo. Una parte de mi quisiera haber tenido la oportunidad de trabajar en mi tesis tiempo completo y haber realizado más pruebas, más versiones del proyecto y un texto con resultados más contundentes; pero tuve que tomar una decisión y al final estoy satisfecho con mi trabajo.

Así que, con la nueva visión y objetivos que tengo planteados; como comenté al principio, también tengo un nuevo panorama. Así que; qué sigue, que va a pasar con este blog y las otras herramientas.

El blog puede que no tenga cambios mayores; hasta ahora me ha gustado como a ido creciendo y los recursos que ofrece, así que trataré de publicar al menos cada una o dos semanas como hacía hace tiempo. Lo que si pienso cambiar es el estilo del blog, me gusta pero la letra es muy pequeña y tengo la impresión de que tiene una experiencia ya gastada.

La página web sí pienso reformarla un poco. Redistribuir el contenido y reflejar los objetivos de este proyecto de divulgación y promoción de forma más clara en su portal. Con este post, también me doy cuenta que el sitio web es quizá uno de los lugares inapropiados para poner los consejos y hints que pretendo compartir (por ejemplo, en este post acabo de contar cómo es que un trabajo de tiempo completo y un proyecto de tesis son muy difíciles de tener en paralelo; más una pequeña vociferación sobre cultura laboral en México). Así que esa sección va a desaparecer de la página y aparecerán en formato de historias o fábulas aquí en el blog.

También, desde diciembre tengo unos vídeos sobre armado de computadoras en los que explico de forma general los componentes de la PC que armo en los videos: vamos desde qué es el software, hasta los orígenes del teclado y el funcionamiento de un monitor. No estoy seguro de cuando podrá estar lista toda la serie (son cuatro videos), pero es posible que lance los primeros antes de septiembre (tengo varios proyectos; ¿entienden mi problema en participar en proyectos con horarios indeterminados espontáneos?)

Y lo que sí va a estar apareciendo a partir de hoy (o el lunes en el pero caso), es que voy a empezar a publicar las notas sobre un curso de Android en el que estoy participando actualmente. Esto es algo que había querido hacer hace unos años; pero por distintos motivos, no es sino hasta ahora que tuve la oportunidad de colaborar en un curso llamado “Programación de Dispositivos Móviles” para la licenciatura en Ciencias de la Computación que ofrece la Facultad de Ciencias de la UNAM.

El número de borradores para este blog también ha ido creciendo durante todo este tiempo; como siempre, encuentro un tema interesante en el proyecto en el que este trabajando y empiezo a planear un post; pero por muchos de los factores que describí en párrafos anteriores, me quedaba corto el tiempo y tuve que dejar inconclusas todas esas publicaciones, pero espero en las próximas semanas también comenzar a retomarlos.

En fin, ya saque lo que tenía que sacar. Espero encuentren interesante estas anécdotas y mis ideas. Por lo pronto, es momento de comenzar a publicar las notas del curso de Android; así que, como siempre, el límite es la imaginación.

Y tu capacidad de crédito.

 

Anuncios

Recomendaciones para viajar al caribe mexicano

Publicado 6 marzo, 2018 por Nachintoch
Categorías: Caribe, Vacaciones

Tags: , , , , , , , , , , , ,

Hola, hola a todos!

Si solo te interesa leer los tips, puedes omitir los detalles y solo leer estas tajetas.

Ya hace rato que no público nada por aca; y si hay alguien que aún siga este blog desde hace por lo menos dos años, sabe que eso pasa cuando me cambio de trabajo. Pero a diferencia de la mayoría de los trabajos que he tenido, este ha sido el mejor y el que más feliz me ha hecho.

También se darán cuenta por el título, de que esta no es una publicación habitual en este blog. Usualmente hablamos de tecnología y desarrollo de sistemas, pero el desarrollo de software es solo un trabajo. A veces aparecen oportunidades que uno no puede dejar pasar. Así es como llegue al estado de Quintana Roo, México a hacer un viaje con el que soñé durante muchos años; pero que honestamente no creí poder hacerlo realidad.

Estando en esta planicie rodeada de manglares y playas, tuve una sensación de libertad y admiración que alegran… hasta que te pasan la cuenta en dolares estadounidenses.

20180220_143256[1]

Cuando buscas información sobre que hacer, como llegar y que precauciones tomar cuando estas en este paraíso maya, las primeras páginas de búsquedas se llenan de resultados de agencias de viajes, publicaciones pagadas y propaganda de secretarias de turismo (federales y locales); que son poco informativos, por eso he decidido escribir este post, con la esperanza de que otros compatriotas mexicanos y visitantes centro y suramericanos, puedan tener un poco más de información cuando lleguen a esta tierra que a veces te hace sentir que no perteneces a ella, como si se tratara de una nación extranjera.

Y bueno, tras la ya tradicional larga introduccion; comencemos…

A menos que vengas de una situación económica en la que pagar 200 pesos mexicanos por una jarra de café de aproximadamente un litro te parezca razonable (no lo es), te recomiendo evitar los resorts y hoteles “elegantes” en la riviera maya. A nosotros nos invitaron y no sabíamos que esperar, por lo mismo creo que eleve mucho mis expectativas (este tipo de lugares son impresionantes solo al entrar).

Estos resorts están diseñados para complacer principalmente turistas estadounidenses y todos los servicios y productos son tremendamente costosos (incluso para ellos). En general, hemos notado que en la península de Yucatan, el dólar “gringo” es moneda de cambio local. En restaurantes, tiendas locales y hasta en los supermercados se puede pagar en dolares. Lo malo, es que los muchos precios que manejan, están calculados en dolares y los precios fluctúan de un día al otro; junto con el dólar.

Tip 1 del viajero: considera comprar dolares cuando estén baratos si piensas viajar a la península de Yucatan, o dobla el presupuesto en pesos mexicanos de lo que esperas gastar.

Aún tengo la duda de si en verdad la tesorería local cobra impuestos en dólares; pues muchas de nuestras facturas iban con la conversión de moneda. Hasta donde entiendo, ningun estado mexicano cobra en otra moneda que no sea la nacional (MXN, peso mexicano); por lo que hasta donde entiendo, esta es una forma de abuso. Desde impuestos adicionales por noche de estancia en los hoteles hasta peajes aparecen en USD.

Los servicios de los resorts no son la excepción, la comida se ofrece en porciones pequeñas por el precio de un buffet. Entiendo que el café sea caro en Ciudad de México porque se tiene que importar el café desde Estados lejanos en los que se le cultiva o de otros países, pero Quintana Roo está muy cerca de los principales productores de café en México; y el café es mucho más caro que en la capital del país… Es mucho mas caro que en Guadalajara o Aguascalientes, de donde se tiene que importar de todavía más lejos.

Y no sólo lo es el café (me obsesiono con el café porque lo consumo con frecuencia como la mayoría de los programadores 😛 ). La fruta y otros productos que se supone son locales, tienen precios muy muy altos. Solo en mercados en las ciudades se puede encontrar comida a precios razonables. Y aún así, no encontramos comida a precios similares a los de la capital.

Tip 2 del viajero: si quieres comer fuera, ubica un mercado en una ciudad.

Un poco más sobre los resorts. Los servicios que ofrecen no son tan buenos como presumen y muchos estamos de acuerdo con que sus precios no los valen.

Debido a regulaciones locales; por amenazas de huracán, no está permitido construir cerca de la playa. Por lo mismo, muchos de estos resorts no tienen vista al caribe; lo que es un poco triste si como yo eres de la montaña y quieres algo de variedad a la vista.

Pero esto no pasa en las ciudades portuarias, donde la mancha urbana toca la playa. Muchos hoteles con precios más accesibles tienen habitaciones con vista al mar. Al menos en Playa del Carmen esto es una realidad. No tendrán spa, gimnasio y cientos de hectáreas que recorrer; pero si a lo que vienes es a disfrutar del caribe, puedes encontrar todo eso en la ciudad o ir a un resort solo por alguno de esos servicios (yo recomendaría más quedarse en la ciudad; o en todo caso ubicar un buen lugar sobre la carretera).

También considera que puedes hospedarte en un airbnb y que en las ciudades tienes a la mano incluso más servicios que en los resorts y a mejores precios.

Los resorts, suelen contar con playas, pero no son mucho más bonitas ni menos ocupadas o limpias que las públicas. Las playas de Quintana Roo son algo rocosas; de arena fina que no quema y muy bonitas. Uno pensaría que las playas en los resorts son remodeladas para remover rocas (sin arena fechar formaciones de corales) pero no es el caso y son igual de bonitas que las playas públicas. Además, a causa del cambio climático, las playas tienen muchas algas (públicas y privadas) y nadar en el mar entre rocas y algas es algo compilado en todos los casos.

Tip 3 del viajero: considera hospedaje en un hotel sencillo en una ciudad como Playa del Carmen, Tulum o Cancun; o un airbnb antes de alojarte en un exuberante resort.

20180220_142942[1]

Tip 4 del viajero: La ocupación y calidad de las playas públicas y privadas es muy similar, a menos de que en realidad lo desees, no gastes de más en visitar una playa privada.

Ya para dejar la alimentación de lado, otro tip: en las ciudades puedes encontrar supermercados (locales y otros bien cocidos, como Walmart o Soriana); hacer el super y tener en el hotel ingredientes para preparar tu comida, es otra opción mucho muy económica para aprovechar mejor tu presupuesto en conocer el caribe mexicano.

Tip 5 del viajero: compra lo que necesites en un supermercado y evita altos costos en “tiendas” de complejos hoteleros

Ahora, ¿como te trasladas de una ciudad a otra? Hay varias opciones. Las más costosas son los transportes privados y autobuses ADO; pero en mi opinión, el transporte público es la mejor opción.

Es de buena calidad, son “combis” (como las llamamos en Ciudad de México), pero tienen asientos cómodos, aire acondicionado y son rápidas. Cuesta 25 pesos el pasaje de Puerto Morelos a Playa del Carmen o $40 de Puerto Morelos a Cancún; no está nada mal.

El pase de diapositivas requiere JavaScript.

Tip 6 del viajero: usa el transporte público para ir de una ciudad a otra.

Así como en Puebla, Guadalajara, Aguascalientes, en Ciudad de México; o basicamente cualquier otra entidad, los taxistas abusan de quienes no son locales, así que recomiendo evitar tomar taxi.


Si eres mexicano, hay pequeñas agencias de turismo que ofrecen precios especiales para los nacionales. Para apelar a ellos es muy importante que tengas a la mano una identificación oficial, lo mas fácil es portar tu INE (y de todos tus acompañantes) o tu licencia de conducir (aunque sea expedida por tu estado de origen).

Tip 7 del viajero: Lleva documentos oficiales que te acrediten como mexicano para acceder a descuentos de turista.


Estos descuentos, nos motivarían a tratar de visitar Cozumel, otro de mis destinos soñados. Desgraciadamente, el estar en el muelle de Playa del Carmen, el ferry de Barcos Caribe en el que íbamos a subir explotó de un costado en el área de pasajeros poco antes de que nos cortaran boleto. Hubo heridos y se cerró el puerto de Playa del Carmen tras el incidente.

He buscado las causas de la explosión y aun no son claras; el pasado 27 de febrero de 2018 encontraron explosivos en otro de estos ferry, por lo que al parecer es un viaje arriesgado. El puerto marítimo de Playa del Carmen tiene vigilancia mínima, es más fácil abordar un barco en él que un autobús en una terminal terrestre. Es territorio federal sin vigilancia, como Ciudad Universitaria.

Otra cosa que se sabe de la explosión, es que la línea de ferry está estrechamente ligada con el ex-gobernador (PRIista por si faltara decirlo) de Quintana Roo Roberto Borge, quien es uno de los tantos ex-gobernadores perseguidos por la justicia por varios cargos de corrupción.

ferry-caribe

Tip 8 del viajero: por lo visto; hacerse a la mar en el caribe puede estar exento de hundirse por sobrepeso y el ataque de piratas, pero aún así es bastante peligroso. Para llegar a Cozumel quizá la mejor forma sea en avión o avioneta.

Hay pequeñas avionetas que salen de Puerto del Carmen a Cozumel; algunas incluyen tours, quizá sea la mejor forma de visitar la isla.


A nosotros nos fue muy bien sin una tarjeta de crédito (en el sentido de que no fue indispensable para contratar tours y otros servicios ni como limitante para disponer de efectivo o hacer pagos). Solo habría que tener cuidado de hacer bien el presupuesto para evitar quedarte sin dinero.

Tip 9 del viajero: puedes hacer (casi) lo mismo con una tarjeta de débito que con una de crédito; no es indispensable una tarjeta de crédito para acceder a la mayoría de los servicios que se ofrecen en la penísula de Yucatán.


Ya para terminar, una recomendación que al principio pensé en no mencionarla; pero tras lo ocurrido no puedo dejar de hacerlo.

Es muy importante no bajar la guardia ni distraerse ni un momento. Soy de la capital y puede sonar raro que diga esto. A nosotros nos pasó que estando en la playa, nos distrajimos por un intervalo de tiempo mínimo, un par de minutos, y fue tiempo suficiente para que me robaran mis lentes que había dejado a un lado: ni siquiera estaban plenamente desatendidos…. ¡y ni siquiera estaban en buen estado!

En el aereopuerto de Cancún, nos “bajaron” una pila de emergencia para dispositivos móviles en la revisión de equipaje (ambos estamos seguros de haberla pasado de una mochila a la maleta que se fue en la bodega, ¡porque la pasamos de la mochila a la maleta justo antes de entregarla a la banda transportadora del aereopuerto!) En el mercado de Playa del Carmen, una persona quiso persuadirnos para sentarse en nuestra mesa. No lo permitimos y de todas formas; al final, se fue sin pagar: quiería dejarnos su comida a nuestra cuenta por lo visto… Fueron varias experiencias desagradebles de ese tipo…

En México (el país), se tiene la creencia de que la capital es una de las ciudades más inseguras y peligrosas. Si bien, hay zonas en las que hay que andar con cuidado y algunas otras de las que es mejor ignorar su existencia; no es tan malo como el Estado de México (que casi rodea la capital). Pero aquí por la casa, tengo la confianza de que si quiero salir por botana a la 1 de la mañana, puedo hacerlo con la confianza de regresar íntegro, con el cambio y la bonata. Y no, no vivo precisamente en una zona “nice” precisamente; pero la capital no es taaan insegura como el muchos de los mexicanos creen.

Para ponerlo en prespectiva: he perdido menos en los últimos diez años en la capital comparado con lo que perdí en una semana en Quintana Roo. No sufrí violencia y no me sentí físicamente amenzado; pero un robo es un robo.

Tip 10 del viajero: ten mucha precacuión con la gente que se te acerca en Quintana Roo, no desatiendas tus pertencias ni por un minuto. Ten cuidado con lo que entregas en el aerepuerto, a los botones de los hoteles y cualquier otro tercero que pueda manejar tus pertenencias.

No quería hacer este comentario en un principio porque muchos de los habitantes de la zona son en realidad muy amables y tienen una “vibra” muy alegre. Pero al final, eso también nos afecto mucho en el viaje.

Ten cuidad también con las (muy comunes) políticas de no rembolso, pues muchos perdieron bastante tras la explosión del ferry (muchos tours no fueron reembolsados, y pueden ser algo costosos).


Y bueno, espero que estos consejos les sean útiles a más de uno. No quisiera ser tan negativo respecto a un destino tan maravilloso, pero la verdad es que es un destino dificil. A nosotros nos llegaron a hacer sentir discriminados hasta en el hotel y por ningún motivo deberías presentarte a una presentación de ventas.

Me alegra haber conocido aunque sea una parte pequeña de la península, pero no creo volver por allá a menos de que sea necesario. No se tomen tan a pecho mis comentarios, la mayoría de nuestros problemas los tuvimos con y en el hotel (el Vidanta); y pues fue un viaje complicado, pero en fin.

Procuraré darme tiempo pronto para compartir con ustedes contenido más habitual, tengo varias recomendaciones que quiero compartirles sobre MongoDB, desarrollo de Web Services con Python y C++ (sí, C++), big data y administración de procesos. Pero eso será en otra ocación.

Por lo pronto, espero que muchos de ustedes tengan la oportunidad de descansar pronto y viajar a donde mejor les plazca; al fin y al cabo que el límite es la imaginación… Y políticas y aduanas y tarifas sorpresa…

Firewall ¿qué es? ¿para qué sirve?

Publicado 18 agosto, 2017 por Nachintoch
Categorías: Debian, Informática, Seguridad informática, Tecnología, web

Tags: , , , , , , ,

Hola a todos,

acercándonos a la recta final de esta larga serie de posts sobre configuraciones de red para sistemas Debian, vamos a terminar aplicando un firewall para tener un mejor control sobre el contenido al que tienen acceso los usuarios.


Pero, ¿qué es un firewall? ¿para qué precisamente sirve? Bueno, empecemos por responder la primer pregunta.

Un firewall es un software; un programa de computadora, que restringe tráfico con ciertas características de forma local en un equipo. Es importante notar que las restricciones de tráfico son locales: un firewall (en principio) no afectan a otros equipos.

Estas restricciones de tráfico pueden realizarse por dos motivos principales:

  • Seguridad. Una de las prácticas de seguridad más importantes y básicas es “cerrar” todos los puertos que no usemos en nuestros equipos.
  • Productividad. El administrador de red puede restringir las páginas que son visitadas para evitar distracciones; principalmente en ambientes laborales.

Vamos a detallar un poco lo que quiere decir el primer punto.


Para que un programa pueda conectarse a internet (en general, para que un programa pueda comunicarse con otro remoto), necesita de un “puerto” o “socket”.  Los puertos son una de las varias abstracciones que se hacen para comunicar dos programas que se ejecutan en equipos diferentes.

Esto se debe principalmente al deseo de poder comunicar dos equipos que pueden tener una arquitectura completamente diferente, sistemas operativos diferentes e incluso usar tecnologías diferentes para conectarse a la red.

Por ejemplo, podemos suponer que el servidor que hospeda este blog, es parte de una gran infraestructura distribuída de muchos racks de servidores que ejecutan Linux y se conectan entre sí por Ethernet, pero muy probablemente tienen salida a internet por fibra óptica.

Pero por otro lado, podemos leer el blog usando cualquier tipo de laptop; manufacturada por cualquier fabricante y que ejecuta distintos sistemas operativos; no necesariamente linux. Puede ser un equipo de sobremesa e incluso cualquier variedad de dispositivo móvil. Además, todos estos pueden conectarse a la red usando tecnologías muy diferentes; como USB, Ethernet, WiFi, 3G, 4G, etc…

Para que pueda existir todo este ecosistema de equipos tan diferentes que al final de cuentas pueden comunicarse por red, las redes IP (y muchas otras) utilizan un “stack”, una pila de capas de abstracción; donde cada capa se encarga de abstraer uno o varios aspectos que podrían ser diferentes en los equipos que se comunican: como el sistema operativo, el tipo de la interfaz de red, la velocidad de procesamiento, etc. Este stack a su vez está basado en un estándar (teórico) llamda “modelo OSI”.

Sin entrar en mucho detalle en estas capas de abstracción (las más “profundas” pueden confundir a aquellos que no estén acostumbrados a términos técnicos o no programadores); la primer capa se conoce como la de aplicación. Es decir, esta “capa” no son más que los programas que se conectan a la red. Aquí también están los servidores web, los servidores DNS y DHCP; de los que hemos hablado en post-anterior.

La segunda capa es la de transporte. Esta abstrae los mensajes que producen las aplicaciones; cualesquiera que sean y los envuelven en otro tipo de mensaje. Aquí es donde involucramos a los puertos.

En la mayoría de los casos, una computadora tiene una o dos tarjetas de red; pero también ejecuta muchas más aplicaciones que desean conctarse a internet. Por ejemplo, puede haber múltiples servicios preguntando por actualizaciones de las aplicaciones a las que pertenecen cada cierto tiempo; y cada pestaña de un navegador web, suele solicitar su propia conexión a la red.

Si el sistema operativo le asignara la tarjeta de red completa a la primer aplicación que solicitara acceso a internet, todas las demás quedarían bloqueadas y esperando por tiempos indefinidos por acceder a la red. Sería casi imposible usar un navegador sin obtener frecuentemente un mensaje de error porque “no es posible conectar”.

Para que todas (o la mayoría) de todas estas aplicaciones que desean conectarse al mismo tiempo a la red puedan hacerlo; al solicitar acceso, deben de indicar el número de puerto por el cuál quieren recibir mensajes del exterior.

Podemos pensar en los números de puertos cómo en direcciones que tendrían plataformas en un puerto real. Los botes o barcos que lleguen al muelle (la tarjeta de red), tendrán que dirijirse a una y una sola plataforma específica para anclar y desembarcar. Así, los barcos deben sber a cual de las plataformas deben anclarse y entregar su carga, para que llegue a su destino.

Los mensajes en los que son envueltos los mensajes que salen de la capa de aplicación, indican el número de puerto por el que deben salir; mismo por el que se espera que llegue la respuesta del programa remoto al que está destinado el mensaje original. La capa de transporte tiene algunas funcionalidades adicionales, pero por simplicidad y para los fines de este post; vamos a quedarnos sólo con esta de los números de puerto.

Los números de puerto son tan importantes para la comunicación en redes IP, que de hecho los primeros números de puerto; entre el 1 y el 1024 están reservados y usualmente se requieren privilegios de administrador o súper-usuario para permitir que una aplicación haga uso de ellos. Se dice que están reservados, porque están asociados a programas o protocolos muy comunes en internet; y básicamente se da por hecho que si un mensaje está destinado a un cierto número de puerto reservado, podemos estar casi seguros de que se trata de un mensaje en cierto formato, con cierto protocolo o creado por cierta aplicación.

Algunos de los números de puerto reservado son los siguientes:

  • 20 FTP
  • 21 FTP
  • 22 SSH (SFTP)
  • 23 Telnet
  • 53 DNS
  • 67 DHCP
  • 80 HTTP
  • 161 SNMP
  • 443 HTTPS
  • 666 Doom

Cuando un puerto no está asociado a ninguna aplicación ene ejecución y el sistema recibe un mensaje dirigido a ese puerto, el sistema simplemente descarta el mensaje; pues el destinatario no existe en ese momento. Es como recibir una carta dirigida a alguien que ya no vive en una casa.

Sin embargo, los distintos programas que se ejecutan en el sistema; incluyendo aquellos propios del sistema operativo que se encargan de la administración de la tarjeta de red y la asignación de puertos, pueden ser vulnerables a la recepción de ciertos mensajes con un formato especial que permite explotar vulnerabilidades de estos programas.

Algunos ataques por parte de hackers de sombrero negro, son perpetrados de esta forma; uno de los casos más conocidos recientemente fue heartbleed, que explotó una vulnerabilidad de este estilo en los certificados que usa HTTPS para obtener un pequeño segmento de memoria que permitía desencriptar los mensajes seguros.

Por esta razón es útil restringir el acceso remoto a ciertos puertos; cerrándolos a pesar de que puedan estar ligados a una aplicación en ejecución. Esta es una de las principales funciones de un firewall, una forma de evitar el acceso de terceros a nuestro equipo.

Un firewall puede evitar que mensajes de red que procedan de ciertos puertos, direcciones IP o usuarios no conocidos sean rechazados ANTES de que pasen a la aplicación que los espera, justamente para evitar este tipo de ataques. También permite que el equipo local se concecte a ciertos puertos, direcciones IP o nombres de dominio (aka páginas web), creando limitaciones en las conexiones que se puede crear el equipo.


En resumen: los firewall son un programa de computadora bastante útil que puede ayudarnos a aumentar nuestra seguridad en línea al evitar que ciertos equipos o usuarios remotos; o cualquiera, se conecte con cierta aplicación o número de puerto en nuestro equipo.

También son usados para evitar la intercepción de mensajes en línea y reducir el SPAM. Por lo que antes de simplemente cerrar el diálogo del sistema que te invita a configurar un firewall, deberías considerar hacerlo seriamente (además de actualziar el equipo).

Justo en el siguiente post y último de esta serie, aprenderemos a configurar un firewall en Debian usando IPTables. Otros firewall para otras plataformas son más amigables con el usuario y pueden resultar más fáciles de usar; por lo que si usas otro sistema operativo que no sea Debian, recomiendo arduamente que revises tu configuración para mantenerte seguro.


El límite es la imaginación. Y el número de puertos seguros en un servidor remoto.

Cómo usar una PC con Debian como punto de acceso inalámbrico a internet

Publicado 8 agosto, 2017 por Nachintoch
Categorías: Informática, Tecnología

Tags: , , , , , , , , , , , , , , , , , , , , , , ,

Hola a todos!

Este quizá ha sido el post más difícil de redactar de entre todos los que he publicado en este blog. Antes de publicar tutoriales o manuales de cualquier tipo, siempre realizo los pasos que indico; principalmente cuando estoy experimentando o intentando hacer algo nuevo… Y en este caso, me topé con (¿casi?) todos los problemas que me pude haber encontrado… Al final del post dejaré una bociferación; no solo con el afán de desquitarme, sino también con la esperanza de ayudar a otros que pudieran tener los mismo problemas.

Este es un post particularmente útil para los usuarios de laptop; ya que las computadoras portátiles suelen tener más de una tarjeta de red y necesitamos que la PC a configurar como punto de acceso tenga más de una tarjeta de red. No importa cómo sean las tarjetas de red: sí cuenta con red celular, Wi-Fi, Ethernet; y tampoco importa cómo estén conectadas las tarjetas de red a la computadora; es decir, podemos usar una PC de escritorio con tarjeta ethernet tradicional y un “adaptador” Wi-Fi USB (lo que nos permite usar una PC de escritorio como punto de acceso WiFi) y como acceso a internet podemos usar una interfaz de red virtual USB creada al conectar un dispositivo Android que comparte red por USB.

Vamos a compartir internet usando una PC con Debian de forma muy similar a cómo se hace una “Zona WiFi portátil”  en Android. Antes de continuar, toma en cuenta que algunos gestores de red en Debian ya cuentan con una opción que automatiza este proceso, por lo que es conveniente verificar que puedas hacer esto de entrada con tu gestor de red.

 

 

 

El pase de diapositivas requiere JavaScript.


Bien, con esto dicho; empecemos por detectar las tarjetas de red con las que cuenta el equipo y cómo las reconoce (como las nombra) el sistema; de forma que podamos referirnos a ellas adecuadamente durante el proceso de configuración. Para esto, usamos el comando “lshw -class network”:

bash1

En el ejemplo anterior, podemos ver dos interfaces de red; cuya descripción se encuentra después de cada línea que únicamente dice “* network”. El comando nos proporciona cierta información útil para este procedimiento, como el nombre descriptivo de la interfaz, su identificador, su nombre virtual y su tipo.  Como podemos ver en la imagen, “eth0” es el nombre que recibe una interfaz de Ethernet y “wlan0” es una interfaz de WiFi.

Vamos a usar HostAP para proteger nuestra red inalámbrica, por lo que es necesario asegurarnos de que contamos con HostAP. También HostAP nos provee de un driver que nos ayuda a evitar problemas con la administración de la interfaz de red inalámbrica, pues no todos los drivers soportan actuar como punto de acceso inalámbrico. Sin embargo, existen casos donde no será posible configurar la tarjeta de red como punto de acceso inalámbrico por limitaciones de los dirvers o de la interfaz de red misma. Si tienes problemas al intentar seguir estos pasos, lo más recomendable es buscar si es sabido que tu tarjeta o “adaptador” de WiFi soporta funcionar como punto de acceso inalámbrico.

Así, para asegurarnos que tenemos todos los componentes necesarios, ejecutamos el siguiente comando (con permisos de super usuario):

# apt-get install iw wireless-tools hostapd bridge-utils

Ahora, debemos configurar HostAP. Abrimos el archivo /etc/default/hostapd y editamos la línea que inicia con DAEMON_CONF. Si está comentada (inicia con el caracter ‘#’), la descomentamos (quitamos el ‘#’).

Debe quedar así:

DAEMON_CONF="/etc/hostapd/hostapd.conf"

Ahora, el archivo al que apunta DAEMON_CONF puede no existir en su sistema. De hecho, este tutorial está hecho pensando en que el archivo /etc/hostapd/hostapd.conf no exista. Si existe, puede comentar o eliminar (bajo su propio riesgo) el contenido anterior, o crear un archivo nuevo y usarlo en lugar de hostapd.conf; por simplicidad, recomendaría crearlo en el mismo directorio /etc/hostapd

Debemos editar el arhcivo /etc/hostapd/hostapd.conf (o el que desee crear/editar), para configurar hostapd y definir nuestro punto de acceso inalámbrico. Sin embargo, aquí es importante hacer una observación aquí: la configuración recomendada por la mayoría, es hacer un puente de red usando una tarjeta de red virtual… Sin embargo, no todas los dirvers y no todas las tarjetas de red permiten crear este puente de red. Así que si esto no es posible, podemos dar la vuelta al problema usando redireccionamiento NAT como puente de red.

Si al intentar efectuar estas configuraciones, no podemos usar exitosamente nuestro punto de acceso inalámrico; podemos intentar buscar el mensaje de error:

can't add wlan0 to bridge br0: Operation not supported

Mediante los comandos:

# systemctl status networking.service
# journalctl -xe

Entonces lo más conveniente es usar la configuración con redireccionamiento NAT.


Si usamos un puente de red

Editamos /etc/hostapd/hostapd.conf de la siguiente forma:

interface=<wlan0>
bridge=br0
driver=nl80211
auth_algs=1
ignore_broadcast_ssid=0
logger_syslog=-1
logger_syslog_level=0
hw_mode=g
ssid=<Nachintoch-CT-WAP>
channel=11
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=<"Si encuentras una SSID con el nombre "Nachintoch-CT-WAP" por allí, ten por seguro que esta no es la contraseña y esa no cuenta como software libre ;)">
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
  • En la primer línea; que dice “interface“, asegúrate de escribir el nombre adecuado de la interfaz de red inalámbrica que quieres usar como punto de acceso inalámbrico. En mi caso (y en la mayoría de ellos), es wlan0.
  • En la línea 9; donde dice “ssid”, escribe el nombre que quieres que vean los posibles usuarios de tu red inalámbrica.
  • En la línea 15, escribe la contraseña que quieres usar en tu red inalámbrica. Está contraseña está asociada a un cifrado WPA2, la cual es relativamente segura (cualquier cosa es mejor que WEP, ¿no?). Debe ser de al menos ocho caracteres, pero usar al menos 12 eleva bastante la seguridad y qué mejor que usar caracteres en mayúscula, minúscula, números, símbolos especiales y la sangre de un unicornio.

Ahora, vamos a definir el puente de red br0 que usamos en la configuración anterior pero no necesariamente existe. Una vez más, el tutorial está pensado en que br0 no existe. Si ya tienes un puente de red configurado, recomendaría crear uno nuevo (br1 por ejemplo). En estos casos, asegúrate de usar el puente de red que configures en el archivo /etc/hostapd/hostapd.conf en lugar de br0.

La configuración anterior puede hacerse una sola vez. La sigueinte debe modificarse cada vez que queramos definir el unto de acceso.

Para crear el puente de red, editamos el archivo /etc/network/interfaces. Agregamos lo siguiente:

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 10.5.5.1
    netmask 255.255.255.0

auto br0
iface br0 inet dhcp
bridge-ports eth0 wlan0

Aquí es importante que sustituyas adecuadamente los nombres de las interfaces de red que estés usando: en mi caso, la salida a internet está asociada a eth0 y pretendo usar wlan0 como punto de acceso inalámbrico.

Además, si usas una configuración de Ethernet estática, debes cambiar la línea 3 para indicar la dirección IP que utilices; ya que si tu gateway no tiene DHCP configurado, no podrás conectar a Internet, y en consecuencia tu red inalámbrica actuará sólo como red local… Lo cual puede ser suficiente si solo quieres levantar un servidor de juego local o una red para un aula.

Es importante tomar en cuenta que no hemos configurado ningún servidor DHCP, por lo que la máquina que quieres usar como AP tiene una IP fija, no podrá proveer más direcciones para los demás dispositivos que se quieran conectar a la red inalámbrcia y los clientes no se podrán conectar automáticamente. Para sortear este problema, puedes crear una subred y configurar tu propio servidor DHCP dentro de la máquina. También puedes asignarles IP fijas si lo deseas; (casi) todos los dispositivos, incluso los Android, permiten cambiar la configuración IP dinámica en estática.


Si usamos redireccionamiento NAT

Editamos /etc/hostapd/hostapd.conf de la siguiente forma:

interface=<wlan0>
driver=nl80211
hw_mode=g
ssid=<Nachintoch-CT-WAP>
channel=11
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=<"Si encuentras una SSID con el nombre "Nachintoch-CT-WAP" por allí, ten por seguro que esta no es la contraseña y esa no cuenta como software libre ;)"> 
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

El resto de las configuraciones deberían funcionar sin mayor problema. Si tienes problemas con las configuraciones que sugiero, recomiendo que revises las capacidades físicas de tu adaptador de red inalámbrico y del driver; pues por ejemplo, quizá no soporta el modo “g”, pero soporta “a”.

Como en el caso de puente de red; podemos dejar la cnfiguración anterior para todas las veces. La siguiente debe efectuarse cada vez que se quiere definir el acces point.

Ahora, debemos configurar el redireccionamiento NAT. Para ello, damos en consola los siguientes comandos:

# iptables --flush
# iptables --table nat --flush
# iptables --delete-chain
# iptables --table nat --delete-chain
# iptables --table nat --append POSTROUTING --out-interface <eth0> -j MASQUERADE
# iptables --append FORWARD --in-interface <wlan0> -j ACCEPT
# sysctl -w net.ipv4.ip_forward=1

Lo siguiente es configurar un servidor DNS y DHCP. Podemos hacer esto como lo he detallado en post anteriores:

Nota: Para crear el access poont, levanté el servidor DHCP (y DNS) sobre la interfaz wlan0 en lugar de eth0 como hice en los ejemplos.


Debemos apagar el gestor automático de la red; pues vamos a usar la configuración fija que acabamos de describir. Para ello, ejecutamos el siguiente comando con permisos de súper usuario:

# service network-manager stop

Si usamos puente de red

Ahora, reiniciamos el servicio de red, limpiamos la configuración de la interfaz a usar como salida e iniciamos HostAP:

# service networking stop
# ip addr flush dev eth0
# service networking start
# service hostapd restart

Si usamos redireccionamiento NAT

Debemos definir; junto con la configuración de DNS y DHCP el modo de asignacón de IPs en la subred y de la interfaz de saida eh0.

Dejo aquí un par de archivos de configuración que puede ayudarlos a automatizar estas tareas:

http://www.nachintoch.mx/libraries/posix/wap-up.sh

http://www.nachintoch.mx/libraries/posix/wap-down.sh


¡Y listo! ahora nuestro equipo ha quedado configurado como un AP y podemos conectarnos a él desde otros. Si la configuración DHCP o IP es correcta también, tanto el equipo configurado, como los que se conecten a él, deberían poder acceder a internet.


Si usamos puente de red

Para terminar con el punto de acceso, debemos comentar las líneas que agregamos a /etc/network/interfaces:

# auto eth0
# allow-hotplug eth0
# iface eth0 inet dhcp

# auto br0
# iface br0 inet dhcp
# bridge-ports eth0 wlan0

Si usamos redireccionamiento NAT

Debemos eliminar la IP estática que hayamos asociado a la interfaz inalámbrica wlan0 y dar de baja el servidor DHCP y DNS.


En ambos casos, debemos comentar también la referencia al archivo de configuración de HostAP para evitar que se cree el puente de red br0 que puede interferir con la configuración de la tarjeta inalámbrica; por lo que comentamos la línea que creamos/editamos en /etc/default/hostapd:

# DAEMON_CONF="/etc/hostapd/hostapd.conf"

Si usamos puente de red; finalmente, restablecemos los servicios (estos son comandos en consola como súper usuario, no comentarios en un script) y damos de baja el puente de red:

# service hostapd stop
# service networking stop
# ip link set br0 down
# service networking start
# service network-manager start

Recordemos que podemos cambiar eth0; no solo por otra interfaz ethernet, si no por cualquier otra; como modem telefónico, 3G, o interfáz virual USB.


Antes de terminar, quiero compartir mi (frustrante) experiencia al escribir este post…

Antes de publicar cualquiera de mis tutoriales, verifico que su contenido sea correcto y realizo los pasos que describo para verificar que obtengo el resultado deseado. Así, puedo agregar comentarios y posible fallas y soluciones a problemas durante el procedimiento.

En este caso, no pude determinar concretamente qué me dio tantos problemas; si el software o el hardware, pues la tarjeta de red original de mi laptop era una Intel PRO/Wireless 3945ABG y pese a varias horas de esfuerzo, no logré ponerla en modo maestro… Aún desconozco si eran limitaciones del driver o del hardware.

Para que podamos configurar una interfaz de red cómo AP (access point), necesitamos que soporte dos modos: AP y master. Esto debe ser tanto por hardware como por driver. El dirver de Debian para esta tarjeta de red es el iwlegacy; contenido en el paquete iwlwifi; el cual NO es software libre, es provisto por Intel. Pero como es un dispositivo viejo, se cosidera obsoleto e Intel ya no le da mantenimiento… Como a mi ATI Raedon X1300… Gracias Nvidia e Intel, Linus Trovals ya ha hecho el gesto…

Busqué parches, intente cambiar las configuraciones que aquí exhibo, quise darle la vuelta al problema de muchas formas y ninguna me llevó a ningún lado (con la Intel 3945ABG). En todos los foros, la respuesta es “consigue otra interfaz de red” o simplemente no había respuesta; y eso que encontré foros de 2008, 2011… Me desesperé y mejor me puse a cocinar…

Mientras cortaba papas en cuadritos para un arroz que al final quedo bastante bueno; pero que necesitaba un poco más de sal, recordé que tenía una interfaz de red inalámbrica botada por allí…

Parece que a muchos de mis colegas les ofende que les pregunten si les pueden arreglar su compuatadora; a mi no me molesta: sí, si puedo, el precio es accesible y garantizo resultados. A veces de plano me dan máquinas descompuestas para vender por partes. Y en otras veces, yo mismo me quedo con piezas que pienso me pueden servir, porqué son piezas que suelo reemplazar en otras máquinas a reparar o que puedo usar yo mismo (en parte, ¡así es cómo he ido mejorando mi laptop!)

Recordé esto y buscando entre mis curiosidades, en efecto encontré una Qualcomm Atheros AR9285.

Regresé a mi escritorio y empecé a googlear de nuevo. Ambas tarjetas de red son PCI-Express; ¡bien! puedo insertarla en el puerto de la motherboard… Bueno, tuve esperanza de que funcionara por hardware, pues no encontré la lista negra ni blanca de interfaces de red inalámbrica soportada por la motherboard de mi equipo. Sin embargo, la Atheros tiene dos antenas y la Intel 3945ABG también es de dos antenas… Eso es buena señal de que puedan ser compatibles.

El driver de la Atheros viene incluido en el kernel de Linux y en Windows también, es bien sabido que soporta los modos AP y master… Empecé a creer que había encontrado la solución a mis problemas y luego empecé a desarmar mi laptop. Levanté el teclado y el horror: la Intel 3945ABG es una tarjeta PCI-Express de tamaño “normal” y la Atheros AR9285 es mini; y el puerto está sobre la motherboard sin otra placa de la que la pudiera sujetar… Pareciera que no podría reemplazarla… Luego, tuve una idea que aún creo es un poco “loca” pero que al final funcionó; y como decimos con mis colegas: si jala, ¡jala!

Bajo el puerto PCI-Express está el chip del bus norte, y las antenas tienen un cable bastante rígido. Así que conecté las antenas a la tarjeta, la inserté en el puerto PCI-Express y con cinta de aislar traté de pegarla al chip del bus norte y a una etiqueta a un costado del chip… ¡es en serio! Y para evitar que la tarjeta se levante o se mueva (por si fuera poco), puse una “plasta” de cinta de aislar de unos 4mm de altura bajo el teclado para que cuando lo cerrara, haga presión sobre la tarjeta y la termine de fijar en su lugar.

Aún tenía la duda de si la motherboard aceptaría la tarjeta, así que sin ensamblar el resto del gabinete de la portatil, la conecté al toma corriente y la encendí. Inicie sesión en Debian e inmediatamente me apareció una notificación diciéndome que “hay conexiones de red disponible”, ¡eureka! Debian reconoció la tarjeta inmediatamente como la interfaz wlan1. Hice lo mismo en Windows 7 y no tan inmediatamente, Windows también instaló los drivers de la AR9285. Funciona todo a la perfección, incluso el Bluethoot en ambos sistemas operativos.

Usando el contenido de este post, volví a configurar HostAP y etc/network/interfaces tal y como aparecen aquí, ejecuté los comandos para reiniciar los servicios y.. nope… no jaló… pero no iba a darme por vencido tan fácilemnte.

Depurando los problemas que tuve; descubrí que desde cierta versión del kernel de Linux, ya no es posible poner una tarjeta ath5 en un puente de red. Así que pensé inmediatamente, bueno; si el kernel no quiere que establezca un puente de red, usaré NAT. Así nació el post para usar una laptop como “adaptador inalámbrico” y con un poco más de esfuerzo, logré establecer un “puente” entre las interfaces eth0 y wlan1 y crear mi AP; unos dos o tres meses después de que empezara a jugar con esto.

¡voalá! por fin pude conectarme a mi nueva red local inalámbrica desde mi celular. No he probado conectarme a una red de 5GHz (pues la AR9285 soporta WiFi n, cosa que no podía la Intel 3945ABG), tengo entendido que las antenas no necesariamente van a darme toda la latencia de los 5GHz (pues la tarjeta original no la soportaba y quizá las antenas no estén diseñadas para eso), pero también es posible que sí, ya que la fecha de manufactura de esta laptop fue cuando el estándar n comenzaba a ganar presencia (en 2006).

Y bueno, ¿qué aprendí? Las tarjetas de red inalámbricas de Intel viejas, no pueden configurarse como AP y siempre hay forma de usar una tarjeta PCI-Express mini en un “slot” de tamaño tradicional. Tengo entendido que en el peor caso; que la tarjeta quede mal colocada o que la motherboard no la soporte, el riesgo de que la tarjeta o el equipo sufran daños, es mínimo; así que creo que vale la pena intentarlo.

Llevo ya aproximadamente dos meses usando este “hack” para instalar la tarjeta de red y no hay señales de que malfuncione o se esté desconectando; al contrario, creo que funciona mejor la vieja Intel.

Bueno, ya, ya me desquité. Estoy feliz porqué el próximo semestre podré usar todas las herramientas de colaboración en el laboratorio de forma más eficiente para los alumnos.

Si estás interesado en conocer el procedimiento para sustituir la tarjeta de red en una máquina como en la mía, estoy trabajando en un post al respecto que aparecerá en el futuro.


Que el límite sea la imaginación… Y el alcance del WiFi pese a la interferencia que causan los muros y los muebles…

Debian: cómo enlazar interfaces de red con NAT y usar una PC como “adaptador” WiFi de otro dispositivo sin capacidad inalámbrica

Publicado 1 agosto, 2017 por Nachintoch
Categorías: Computación, Debian, Informática, Sin categoría, Tecnología

Tags: , , , , , , , ,

Hola a todos!

Encaminándonos hacia la configuración de un equipo con Debian como router inalámbrico; vamos a aprender a usar NAT para enlazar interfaces de red. Esto es muy útil cuando por alguna razón no podemos establecer un puente de red por alguna razón.

Vamos a aprovechar el ejemplo para establecer un puente de red entre una interfa inalámbrica y otra cableada; lo que nos puede permitir usar una laptop (por ejemplo) como “adaptador” WiFi de una máquina de escritorio.

Sin más, comencemos.


Vamos a valernos de la configuración de DNS y DHCP que hemos trabajado en semanas anteriores. Si no cuentas con un servidor DNS y/o DHCP en el equipo que quieres usar como “adaptador inalámbrico”, puedes consultar los post de semanas anteriores que he escrito al respecto:

Vamos a usar estos servidores para montar una subred tras la interfaz eth0 (en el tutorial, si prefieres usar una tarjeta de red distinta a la que el sistema identifique como eth0; puedes, hacerlo, solo sustituye eth0 por la tarjeta que deseas usar).

Los siguientes pasos asumen que hay un servidor DNS y un servidor DHCP ejecutándose en el equipo local (a usar como “adaptador inalámbrico”) y que tiene dirección IP 10.5.5.1 (si has configurado tu servidor DNS y/o DHCP en uno o varios equipos con direcciones IP distintas; sólo ten encuenta que la dirección IP que uses en la configuración que sigue sea la que tenga asignada la interfaz que va a compartir internet).


Bien. Lo primero que debemos hacer es habilitar el reenvío de paquetes en el kernel. Para ello, editamos el archivo /proc/sys/net/ipv4/ip_foward

1

Debemos asegurarnos que aparezca un “1” en la última línea del archivo. Si “1” es el único contenido en el archivo, con eso basta.

Ahora, vamos a dar de alta la configuración que enmascara el tráfico de red al ser retransmitido de una interfaz a la otra. En consola, usamos el siguiente comando:

# iptables -t nat -A POSTROUTING -s 10.5.5.0/24 -j MASQUERADE

¡Y listo! Estas configuraciones deberían ser suficientes para servir a otros equipos que se conecten directa o indirectamente (a través de un switch opor ejemplo 😉 ) a nuestro equipo. Este tipo de puentes de red no sólo son útiles entre una interfaz wlan0 y otra eht0 para comparitr wifi a través de ethernet; podemos establecer varios puentes de redes de esta forma.

Si queremos revertir estas configuraciones, basta con deshabilitar la retransmisión de paquetes y editar de nuevo el archivo /proc/sys/net/ipv4/ip_foward de forma que ahora el único contenido (o la última línea) sea “0” (cero en lugar de uno).


La próxima semana, aprenderemos a establecer uno quizá más interesante: usar un equipo con Debian como punto de acceso inalámbrico; aka, “compartir wifi”.

Hasta entonces, que el límite sea la imaginación.

Debian: cómo configurar una PC como servidor DHCP y gestionar una subred con él

Publicado 25 julio, 2017 por Nachintoch
Categorías: Debian, Informática, Tecnología

Tags: , , , , , ,

Hola a todos!

Continuando con la serie de post para la iniciación en gestión de redes, hoy configuraremos un servidor DHCP en Debian 9.

Antes de empezar, es importante tomar en cuenta que en cada subred debe de haber solamente un servidor DHCP, por lo que debemos tener precaución al hacer estas configuraciones o podemos causar efectos no deseados en otros equipos en la misma subred.

Sin más empecemos.


Lo primero que debemos hacer es instalar un servidor DHCP. Vamos a usar isc. Para ello, hacemos en consola:

# apt-get install isc-dhcp-server

Nota: es posible que debas hacer apt-get update primero.

Al instalar isc-dhcp-server, es posible que nos arroje un error. Esto es normal, ya que la configuración por defecto no especifica ninguna interfaz sobre la que se van a atender peticiones DHCP. Justo lo que debemos hacer ahora es configurar nuestro servidor DHCP.


Editamos el archivo /etc/default/isc-dhcp-server. Agregamos la siguietne líenea:

INTERFACESv4="eth0"

Lo anterior indica que el servidor DHCP atenderá peticiones IPv4 por la tarjeta de red eth0. Podemos coonfigurar el servidor DHCP para IPv6 usando INTERFACESv6 (pueden combinarse ambas), y podemos indicar otra o más interfaces de red para atender peticiones agregado más etiquetas INTERFACES y/o cambiando el valor eth0.


Ahora, vamos a configurar detalladamente cómo queda la configuración de nuestra red. Editamos el archivo /etc/dhcp/dhcpd.conf y agrregamos lo siguiente:

option domain-name "nachintoch.local";
option domain-name-servers 10.5.5.1;
default-lease-time 600; 
max-lease-time 7200;
ddns-update-style none;
authoritative;

subnet 10.5.5.0 netmask 255.255.255.0 { 
        range 10.5.5.2 10.5.5.100; 
        option routers 10.5.5.1; 
        option broadcast-address 10.5.5.255; 
}

Con esto estamos declarando que el nombre de la subred es “nachintoch.local”; pero puede tener cualquier otro nombre que desees.

Indicamos también que los servidores DNS. En mi caso, está alojado en el equipo local, al que le asignaré la dirección IP 10.5.5.1 Podemos incluir más DNS separándolos con coma. Esto nos permite agregar DNS de redes externas (cómo el DNS del gateway), para poder replicar las consultas DNS desconocidas. Puedes omitir este campo si no estas seguro de qué configuración de DNS usar, o puedes consultar el último post en este blog sobre configuración de un serviodor DNS.

Luego se indican los tiempos que durarán las sesiones DHCP e indicamos que el  DHCP es el primario de la subred.

Finalmente, definimos propiamente una subred con dirección IP 10.5.5.0; pero el servidor DHCP sólo asignará direcciones IP entre la 10.5.5.2 y la 10.5.5.100 a los clientes; estamos reservando la dirección 10.5.5.1 como la dirección del equipo local que será el servidor DHCP, DNS y gateway. Se indicará a los clientes que la “puerta de enlace” (gateway) es 10.5.5.1 y la dirección de broadcast es la 10.5.5.255


Las configuraciones suponen que la tarjeta de red eth0 tiene una configuración estatica. Si queremos que esto sea así, una opción es modificar el archivo /etc/network/interfaces para asentar la configuración estática. En este caso es conveniente deshabilitar network-manager. Para esto, el archvo /etc/network/interfaces deberá verse así:

auto eth0
iface eth0 inet static
    address 10.5.5.1
    netmask 255.255.255.0

Recordemos que si queremos que nuestra subred tenga salida a internet, la dirección del gateway debe ser la dirección de un equipo en la súper-red que esté conectada a este equipo por el puerto; en el ejemplo, eth0.

Para deshabilitar network-manager:

# service network-manager stop

Si en lugar de deshabilitar network-manager, queremos hacer uso de él (esta es mi opción preferida por simplicidad), otra opción es abrir la configuraciones de las conexiones de red y fijar la dirección IP de una interfaz como la 10.5.5.1 (o la que queramos usar en nuestro equipo).

Screenshot_20170704_134934


Podemos hacer uso de una configuración IP dinámica, lo más conveniente es indicar en el archivo /etc/dhcp/dhcpf.conf; en la opción option domain-name-servers, la dirección IP del DNS que tenga asignado nuestro equipo y cambiar la dirección estática “10.5.5.1” que usé en los ejemplos por la que se le asigne al equipo por medio de DHCP. Sin embargo, no recomendaría del todo usar esta configuración, ya que:

  • No podemos delegar el DHCP de la red al del gateway de internet, ya que ambos DHCP entrarían en conflico (si la configuración de red no es correcta).
  • El único caso práctico para esto, es cuando tenemos un servior DHCP “esclavo” en nuestra subred, lo que en redes pequeñas puede ser redundante.

Así que por estos motivos, prefiero usar la configuración estática excepto cuando nuestra subred tiene salida a internet (y aún así, es importante configurar el DHCP de la súper-red para que a nuestro equipo siempre se le asigne la misma IP y no tener que estar haciendo cambios a la configuración).


Si estamos usando un servidor DNS como el que indiqué como configurar en el post anteror, es importante recordar que debemos editar su configuración para que corresponda con la que estamos fijando aquí. El DNS debería atender la misma interfaz de red (en este caso, eth0) y usar la dirección estática 10.5.5.1 (en lugar de 192.168.1.111 que usé en el ejemplo anterior).

Una vez que la configuración del  servidor DNS sea correcta, reiniciamos bind:

# servide bind9 restart

Si estamos usnando una configuración estática que NO depende de network-manager, debemos reiniciar networking para que los cambios a /etc/network/interfaces tenga efecto:

# ip addr flush dev eth0
# service networking restart

Estas configuraciones deberían ser suficientes para nuestro servidor DHCP. Para activarlo, sólo hace falta reiniciar el servicio correspondiente para ponerlo en marcha

Reiniciamos el servicio (o la máquina) para que los efectos surtan efecto:

# service isc-dhcp-server restart

Para deshabilitar el servidor DHCP, basta con detener el servicio y re-editar el archivo /etc/default/isc-dhcp-server; comentando la(s) línea(s) INTERFACES que agregamos en el primer paso.

#INTERFACESv4="eth0"

¡Y listo! Ahora podemos configurar la red de cualaquier equipo que se conecte al nuestro por el puerto eth0 o el que sea que configuremos. Podemos aprovechar esta configuración para atender más de un equipo con ayuda de un switch o hacendo un puente de red contra otra tarjeta de red; por ejemplo, una inalámbrica.

Esto lo realizaremos en semanas próximas.

Por lo pronto, que el límite sea la imaginación.

Debian y DNS: cómo montar un DNS local

Publicado 18 julio, 2017 por Nachintoch
Categorías: Computación, Informática, Tecnología, web

Tags: , , , , , , , , , , ,

Hola a todos!

Continuando con nuestra serie de publicaciones para el administrador Jr de redes, hoy vamos a empezar a aplicar lo que hemos aprendido sobre DHCP y DNS para configurar una PC con debian como router. Este administrará una subred de forma automática (DHCP) y resolverá nombres de dominio (DNS); tanto nombres de equipos dentro de la subred como equipos externos en Internet.

Para que la subred opere de  forma “autónoma”, es necesario configurar un DHCP, pero para usar un DHCP, necesitamos también un DNS. Si nuestra subred tendrá salida a Internet o no nos interesa definir dominios locales; podemos simplemente usar los DNS de Google 8.8.8.8 y 8.8.4.4

Sino, empecemos a configurar nuestro propio servidor DNS.


Empecemos por descargar elservidor DNS bind9. Con permisos de súper usuario, ejecutamos:

# apt-get install bind9 dnsutils

Ahora, vamos a configurarlo. Empecemos por editar el archivo /etc/bind/named.conf.options

options { 
        directory "/var/cache/bind"; 
 
        forwarders { 
                // Google DNS 
                8.8.8.8; 
                8.8.4.4; 
                // DNS Local 
                192.168.1.1; 
        }; 
 
        dnssec-validation auto; 
 
        listen-on port 53 { 127.0.0.1; 192.168.1.111; }; 
        allow-query { 127.0.0.1; 192.168.1.0/24; }; 
        allow-recursion { 127.0.0.1; 192.168.1.0/24; ::1; }; 
        allow-transfer { none; }; 
 
        auth-nxdomain no;
};

La dirección 192.168.1.111 y las subredes 192.168.1.0, las pongo en el ejemplo tal y cómo me han funcionado en mi configuración. Verifica cuál es la IP que tenga asignada tu equipo y reeplaza 192.168.1.111 por la que tenga y el segmento de red (puedes inferirlo por el tercer número en tu IP) por 192.168.1.0 (es común que algunos routers usen 192.168.0.0).


Ahora; si usamos Network Manager (lo más probable si usas un entorno gráfico), es necesario impedir que actualice automáticamente la configuración de DNS o los cambios que hagamos a continuación NO surtirán efecto. Para esto, editamos el archivo /etc/NetworkManager/NetworkManager.conf Ubicamos la sección [main] y agregamos lo siguiente:

[main]
.
.
.
dns=none
.
.
.

Bien, lo siguiente es asegurarnos que en el archivo /etc/nsswitch.conf aparezca una línea con lo siguiente:

hosts:    files dns

Puede haber más configuraciones entre files y dns o después de dns; pero al menos deben aparecer estas dos en la línea hosts. Si no existen, las escribimos.


Ahora, editamos el archivo /etc/bind/named.conf.local para agregar una zona local:

zone "nachintoch.local" {
    type master;
    file "/etc/bind/db.nachintoch.local";
};

Estamos declarando una zona llamada nachintoch.lan; pero puede tener cualquier otro nombre. Sin embargo, la delcaración de los nombres de dominio locales no aparecen aquí, sino en el archivo que indicamos; en este caso /etc/bind/db.nachintoch.lan Puede tener otro nombre; pero es recomendable crear todos estos archivos en el directorio /etc/bind

Podemos probar que el archivo de configuración sea correcto usando el comando:

# named-checkconf

El contenido de un archivo con declaración de nombres de dominio locales debe verse como el siguiente (en este caso es /etc/bind/db.nachintoch.lan, pero puedes usar otro nombre de archivo):

$TTL 3D
@       IN      SOA     nachintoch.local. root.nachintoch.local. ( 
                        2017070501    ; serie 
                                8H    ; periodo actualizacion 
                                2H    ; reintento de transferencia
                                4W    ; periodo caducidad 
                                1D )  ; TTL 
 ;
                NS      ns            ; direccion del DNS

ns                A       192.168.1.111
nachintoch.local. A       192.168.1.111
server            A       192.168.1.111
router            A       192.168.1.1
gateway           CNAME   router 
gw                CNAME   router 
www               CNAME   server

La configuración anterior indica lo siguiente:

  • El dominio que se está configurando se llama “nachintoch.local” y el responsable de su mantenimiento es root (root.nachintoch.local). Podemos cambiar los nombres a gusto/necesidad.
    • El primer número es la serie de la configuración. Cada vez que se modifique este archivo, es importante incrementarlo para evitar anomalías.
    • Indicamos el tiempo con el que deseamos que otros DNS actualicen esta información.
    • Indicamos el tiempo que puede esperar para volver a intentar tranferir la zona que se está configurando.
    • Indicamos el tiempo tras el que haber actualizado se debe borrar la información de la base de datos del DNS porque puede quedar obsoleta.
    • Indicamos el tiempo de vida de la configuración (tras la que se debería de actualizar).
  • La dirección del servidor DNS. Note que no estamos indicando el nobre de dominio tal cual, sino un “nombre de varable” que se define más adelante. En todo caso, el valor se debe resolver a una dirección IP o un nombre de dominio.
  • Indicamos quién es realmente el DNS.
  • Indicamos quién responde por el dominio. Debe llamarse igual que la zona, o el archivo de configuración no tendrá efecto. Note que se debe terminar con un punto ‘.’
  • Indicamos quién es el servidor.
  • Indicamos quién es el gateway-router.
  • Finalmente, aparece un subdominio conocido; www.

Note que una vez más uso en el ejemplo las IP que me funcionaron en mi configuración (192.168.1.111 es la dirección local de mi laptop y 192.168.1.1 es la dirección local de mi enrutador).

Si nuestro equipo ha obtenido su dirección IP por medio de un DHCP, esta dirección puede cambiar y el DNS empezará a otorgar una IP que posiblemente no tiene un servidor web (que es lo que se espera atienda a www). Para resolver esto, podemos usar una configuración de IP estática, o configurar nuestro servidor DHCP para que le asigne siempre la misma IP al equipo. Veremos cómo hacer esto más adelante en posts futuros.

Podemos comprobar que la configuración sea correcta usando:

# named-checkzone nacintoch.local /etc/bind/db.nachintoch.local

Donde “nachintoch.local” es el nombre de la zona tal y como lo indicamos en el archivo /etc/bind/named.conf y “/etc/bind/db.nachintoch.local” es el archivo asociado a la zona también indicado en /etc/bind/named.conf (y el mismo que acabamos de editar y queremos probar).


Finalmente, modificamos el archivo /etc/resolv.conf; el contenido del archivo debería únicamente contener tres líneas como las del ejemplo (en mi caso, uso nachintoch.local porque es la zona que acabo de definir)

domain nachintoch.local
search nachintoch.local
nameserver 127.0.0.1

 


Ahora podemos reiniciar los servicios (sino usas Network Manager, omite network-manager)

# service networking restart
# service network-manager restart
# service bind9 restart

Y finalmente podemos verificar que el DNS funciona usando

nslookup www

Deberíamos ver una respuesta similar a la siguiente:

Server:         127.0.0.1 
Address:        127.0.0.1#53 
 
www.nachintoch.local    canonical name = server.nachintoch.local. 
Name:   server.nachintoch.local 
Address: 192.168.1.111

Por supuesto estamos viendo reflejada la configuración que acabamos de asentar, lo que en efecto significa que hemos terminado.


¡Y listo! Podemos configurar nuestro router para fijar la IP que se asigna por DHCP a nuestro equipo con DNS e incluir esa misma dirección a los DNS que usa el router. De esa forma, otros equipos en la subred podrán acceder a servicios que ofrezcamos en este equipo usando cómodamente nombres de dominio.

Y por si fuera poco, estas configuraciones pueden usarse también para administrar nuestra propia subred, usando la PC como router; esa es la historia de la próxima semana.


Si queremos deshabilitar las configuraciones que acabamos de dar, podemos simplemente comentar las siguientes líneas del archivo /etc/bind/named.conf.options

options { 
        directory "/var/cache/bind"; 
 
        forwarders { 
                // Google DNS 
                8.8.8.8; 
                8.8.4.4; 
                // Local 
                //192.168.1.1; 
        }; 
 
        dnssec-validation auto; 
 
        //listen-on port 53 { 127.0.0.1; 192.168.1.111; }; 
        //allow-query { 127.0.0.1; 192.168.1.0/24; }; 
        //allow-recursion { 127.0.0.1; 192.168.1.0/24; ::1; }; 
        //allow-transfer { none; }; 
 
        auth-nxdomain no;
};

Y reiniciar bind:

# service bind9 restart

Espero les sea de utilidad. A mi en lo personal se me ocurren muchas cosas divertidas que se pueden hacer con un DNS local; y productivas también, pues podríamos ofrecer servicios web (entre otros) en un salón de clase o una oficina.

Que el límite sea la imaginación. Y el periodo de espera entre actualizaciones del DNS.


A %d blogueros les gusta esto: