100 episodios

Programas de 15 minutos diarios en los que hablamos de hosting, redes y desarrollo.

Podcast de Eduardo Collado Eduardo Collado

    • Tecnología

Programas de 15 minutos diarios en los que hablamos de hosting, redes y desarrollo.

    Arrancar un software como servicio en Debian

    Arrancar un software como servicio en Debian

    En estos últimos capítulos hemos dedicado algún tiempo a algún software sobre la distribución de Linux Debian, primero hablamos de Wireguard, el fantástico servicio de VPN y luego de Nebula, un software para poder disponer de nuestra propia SDN.







    No se si os acordaréis pero en la instalación de Nebula teníamos que arrancar a mano tanto en el servidor como en el cliente el propio Nebula, lo cual es terrible. Seguro que os gustaría muchísimo más que al arrancar ya estuviera Nebula corriendo solito, sin tener que hacer absolutamente nada.







    Mi forma preferida de tener un software corriendo siempre es definirlo como servicio utilizando systemd en Debian que es la distribución que utilizo.







    Así que el capítulo de hoy va a ir justo de eso, de definir servicios en systemd y vamos a definir el servicio de Nebula para poder hacerlo con algo concreto.



















    Pero antes de empezar quiero comentaros un pequeño cambio que he hecho en el podcast y que creo que puede ser muy interesante a nivel de usabilidad del contenido. A partir de este capítulo vais a poder encontrar capítulos que os van a permitir saltar a la parte del contenido que más os interese o saltaros aquello que no os interese en lo más mínimo.







    Entiendo que vuestro tiempo vale mucho y no quiero obligar a nadie a navegar por el audio hasta que encuentre justo aquello que le interesa.







    Los marcadores no están disponibles para todos aquellos que utilicéis iVoox tanto como podcatcher o a aquellos que estén suscritos al feed de iVoox, simplemente por una limitación de la propia plataforma, así que si queréis poder utilizar los marcadores os tendréis que suscribir directamente al feed de https://www.eduardocollado.com/podcast/feed, de todos modos tenéis un enlace en la parte derecha de la web donde poner “Suscríbete al podcast“.







    Los podcatchers o clientes de podcast que lo soportan son muchos como Podcast Addict, Pocket Casts, Antennapod para Android u Overcast y el propio Pocket Casts para iOS, y muchos otros que no he podido ni probar o que ni se de su existencia, así que lo mejor es que miréis en vuestro podcatcher si disponéis de esta opción.







    Donde seguro que no está la opción es en la app de iVoox y en cualquier app que utilice el feed de iVoox que aunque lo tengo oculto hay algo menos de 500 personas que lo usan según lo que me dice Podcast Addict. Además, el feed de iVoox sirve los audios a 64kbps mientras que en eduardocollado.com los sirvo a 128kbps y con capítulos. Ahora, el contenido es el mismo, así que si estáis contentos con iVoox seguid con la app, lo único que no podréis ir a la parte del audio que más os interese gracias a los capítulos ni podréis disfrutar de los 128kbps, aunque mi voz tampoco es que mejore enormemente al subir el bit rate.







    Ahora no quiero entreteneros más o vamos a charlar sobre cómo crear servicios en Debian utilizando systemd, para ello crearemos el servicio nebula.







    Si os interesa el tema y os queréis quedar conmigo un ratito recordad que esto es eduardocollado.com y que este es el capítulo 202, por cierto, hoy es 15 de Diciembre de 2019.







    El otro día realizamos una instalación de Nebula que consistía básicamen...

    • 18 min
    Timeout y Keep Alive Timer de TCP

    Timeout y Keep Alive Timer de TCP

    Hoy tenemos un capítulo propuesto por Andreu Adrover de Securizando Podcast, el podcast de seguridad informática que podéis encontrarlo en securizando.com.







    Andreu el otro día en el grupo de telegram de este podcast, en t.me/elpodcast dejó una petición que venía a comentar que explicara porque existe el TCP Timeout y por qué sus compañeros no recibían respuesta cuando lanzaban una query a una base de datos que tardaba 2 horas en ejecutarse. Parece ser que Andreu les comentó la razón, pero no le creyeron, así que voy a contar mi punto de visto que puede o no coincidir con el de Andreu porque a decir verdad no hemos hablado de este tema.







    La verdad es que el tema de hoy es un poco extraño porque no es un asunto de redes puro e involucra enormemente a la parte del sistemas operativo desde donde se lanza esa query.







    Bueno, si os interesa el tema voy a tratar de comentarlo en los próximos minutos en este, por cierto, capítulo 201 del podcast, vamos allá







    Antes de empezar, si nos vamos a basar en el ejemplo de una query en una base de datos que no termina de ejecutarse o que no recibimos respuesta, tenemos que diferenciar varias cosas, una es el timeout de TCP , otra el tiempo máximo en segundos que una consulta puede ejecutarse antes de ser cancelada dentro de MySQL, a esa variable la llamaremos max_statement_time. Además, si esa query se ejecuta mediante una aplicación en php tenemos que tener en cuenta que en php también tenemos tiempos máximos de ejecución, el famoso max_execution_time.







    Por supuesto también puede ser que ese hilo en concreto no pueda terminar de ejecutarse porque se haya quedado sin memoria (muy típico en aplicaciones php) o cualquier otra cosa.







    Es decir, para que una query no responda pueden pasar muchísimas cosas y no tiene porque ser necesariamente el timeout de TCP.







    Esta es una incidencia compleja, no porque sea difícil encontrar la causa, sino porque afecta a los egos de las personas. Si tenemos una persona que lleva la red, otra que lleva la aplicación, otra que lleva la base de datos y otra que lleva el sistema operativo del servidor ya la hemos liado porque lo normal es que la gente piense que se busca un culpable cuando lo normal es que sólo se busque una solución. Aunque …. quien no ha oído alguna vez al típico jefe con la boina y la garrota diciendo eso de ¿entonces la culpa de quien ha sido? Pues eso no ayuda.







    Volvamos al tema y vamos a centrarnos en hablar sobre el timeout de TCP que es un muy buen tema, pero tener en cuenta que hay muchísimos más factores a tener en cuenta.







    Lo primero es saber qué es el timeout en TCP. El timeout es el tiempo pasado entre que se envía un segmento y no se recibe el ACK del mismo







    Imagen de: https://www.dcs.bbk.ac.uk/~ptw/teaching/IWT/transport-layer/timeout.gif







    Una vez transcurrido el timeout lo normal es proceder a una retransmisión, como os podéis imaginar una vez pasado el timeout no se pierde la información a no ser que alguna cosa extraña suceda.







    El timeout puede existir porque TCP es un protocolo orientado a la conexión, por ejemplo hablar de timeout en UDP no tendría ningún sentido por la propia definición de un protocolo n...

    • 18 min
    Introducción a Nebula

    Introducción a Nebula

    Para celebrar este capítulo 200 vamos a tratar un tema muy interesante, hoy voy a hablaros de Nebula, un software que ha liberado Slack en github (https://github.com/slackhq/nebula).







    Los binarios los tenéis en https://github.com/slackhq/nebula/releases.







    El software nos permite crear nuestra propia SDN sin tener que depender de servicios de terceros como puede ser el caso de una instalación estándar de Zero Tier .







    El software es muy sencillito y os va a permitir levantar vuestra SDN simplemente con un yaml como este (os marco en negrita lo que hay que tocar):







    This is the nebula example configuration file. You must edit, at a minimum, the static_host_map, lighthouse, and firewall sections

    Some options in this file are HUPable, including the pki section. (A HUP will reload credentials from disk without affecting existing tunnels)

    PKI defines the location of credentials for this node. Each of these can also be inlined by using the yaml ": |" syntax.

    pki:

    # The CAs that are accepted by this node. Must contain one or more certificates created by 'nebula-cert ca'

    ca: /etc/nebula/ca.crt

    cert: /etc/nebula/servidor.crt

    key: /etc/nebula/servidor.key

    #blacklist is a list of certificate fingerprints that we will refuse to talk to

    #blacklist:

    # - c99d4e650533b92061b09918e838a5a0a6aaee21eed1d12fd937682865936c72

    The static host map defines a set of hosts with fixed IP addresses on the internet (or any network).

    A host can have multiple fixed IP addresses defined here, and nebula will try each when establishing a tunnel.

    The syntax is:

    "{nebula ip}": ["{routable ip/dns name}:{routable port}"]

    Example, if your lighthouse has the nebula IP of 192.168.100.1 and has the real ip address of 100.64.22.11 and runs on port 4242:

    static_host_map:

    "192.168.100.1": ["xxx.xxx.com:4242"]

    lighthouse:

    # am_lighthouse is used to enable lighthouse functionality for a node. This should ONLY be true on nodes

    # you have configured to be lighthouses in your network

    am_lighthouse: true

    # serve_dns optionally starts a dns listener that responds to various queries and can even be

    # delegated to for resolution

    #serve_dns: false

    # interval is the number of seconds between updates from this node to a lighthouse.

    # during updates, a node sends information about its current IP addresses to each node.

    interval: 60

    # hosts is a list of lighthouse hosts this node should report to and query from

    # IMPORTANT: THIS SHOULD BE EMPTY ON LIGHTHOUSE NODES

    hosts:

    # - "192.168.100.1"

    Port Nebula will be listening on. The default here is 4242. For a lighthouse node, the port should be defined,

    however using port 0 will dynamically assign a port and is recommended for roaming nodes.

    listen:

    host: 0.0.0.0

    port: 4242

    # Sets the max number of packets to pull from the kernel for each syscall (under systems that support recvmmsg)

    # default is 64, does not support reload

    #batch: 64

    # Configure socket buffers for the udp side (outside), leave unset to use the system defaults. Values will be doubled by the kernel

    # Default is net.core.rmem_default and net.core.wmem_default (/proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_default)

    # Maximum is limited by memory in the system,

    • 24 min
    Tamaño de Ventana en TCP

    Tamaño de Ventana en TCP

    En el audio de hoy os hablo del tamaño de ventana en TCP, la razón por la que es tan importante y qué es exactamente.







    ¿Cómo afecta el tamaño de ventana a la velocidad de transferencia? En el capítulo de hoy lo explico comparándolo con camines de mudanzas, espero que os sea útil.







    En el capítulo de hoy quería dar las gracias a Carlos y Josean !







    Foto de Fernanda Latronico en Pexels

    • 24 min
    Mesa redonda sobre redes de gestión

    Mesa redonda sobre redes de gestión

    Hoy nos hemos sentado virtualmente en una mesa para charlar sobre redes de gestión.







    Nos hemos sentado Quique, Rafa, Javi, Samuel y yo y hemos estado charlando una horita.







    Hoy el capítulo es más relajado, simplemente charla.

    • 49 min
    Configuración de WireGuard en Debian 10

    Configuración de WireGuard en Debian 10

    En https://www.wireguard.com/install/ tenéis la información para cualquier distribución, pero para Debian la configuración es la siguiente:







    echo “deb http://deb.debian.org/debian/ unstable main” > /etc/apt/sources.list.d/unstable.list







    printf ‘Package: *\nPin: release a=unstable\nPin-Priority: 90\n’ > /etc/apt/preferences.d/limit-unstable







    apt update







    apt install wireguard







    Ahora crearemos las llaves, la pública y la privada.







    Ir a /etc/wireguard

    $ umask 077

    $ wg genkey | tee privatekey | wg pubkey > publickey







    Tener en cuenta apertura de puerto 51820/udp







    Y ahora creamos el fichero wg0.conf







    [Interface]

    Address = 192.168.x.y

    PrivateKey =

    ListenPort = 51820







    [Peer]

    PublicKey =

    AllowedIPs = 0.0.0.0/0







    Y si es necesario:







    PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

    PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE







    Y recordar que hay que permitir el forwarding







    sysctl -w net.ipv4.ip_forward=1







    En el cliente instalaremos wireguard y crearemos el wg.conf









    [Interface]

    Address = 192.168.2.2

    PrivateKey =

    ListenPort = 21841







    [Peer]

    PublicKey =

    Endpoint = :51820

    AllowedIPs = 192.168.2.0/24







    This is for if you’re behind a NAT and







    want the connection to be kept alive.







    PersistentKeepalive = 25

    • 22 min

Top podcasts en Tecnología

Otros usuarios también se han suscrito a