Práctica de red en Linux: ip, ping e ifcfg

Práctica Desde cero IC219 min de lectura

El día que configuré mi primera estación en el laboratorio, el ping a la pasarela funcionaba y el ping al router no. Estuve diez minutos revisando cables, la pasarela, el router… y el problema era mío: no había puesto la puerta de enlace. Desde entonces compruebo por capas: primero mi tarjeta, después mi red, después lo que hay más allá. La lección: un ping que falla te dice muy poco; tres pings bien elegidos te dicen exactamente dónde está el problema.

Esta práctica aplica la teoría de configuración de red en el mismo laboratorio aislado (estación, pasarela y router del aula, simulados con network namespaces). Son tres programas de nivel medio con situaciones del aula: poner en marcha una estación a mano comprobando cada paso, diagnosticar y arreglar una estación con una IP equivocada, y aplicar un ifcfg con un script que hace lo mismo que el servicio de red de CentOS.

Antes de empezar

Conviene tener claro:

Qué son la IP, la máscara (/24 = 255.255.255.0) y la puerta de enlace.
Las tres órdenes de configuración: ip link set … up, ip addr add … dev … e ip route add default via ….
Cómo leer ip -br addr, ip route y la salida de ping.
Qué contiene un ifcfg (DEVICE, BOOTPROTO, ONBOOT, IPADDR, NETMASK, GATEWAY).

Si alguno te suena dudoso, repasa la teoría antes de seguir.

En el aula, todo esto se hace como root (o con sudo) en una máquina de prácticas. No lo pruebes en tu portátil: si cambias la IP de tu tarjeta, te quedas sin internet hasta que la devuelvas a como estaba (o reinicies). En el laboratorio virtual de este artículo las tarjetas llevan el sufijo @ifNN y los tiempos de ping te saldrán distintos.

Programa 1: poner en marcha la estación a mano

La estación del puesto 7 está recién instalada: la tarjeta enp2s0 apagada y sin IP. Hay que dejarla con la 10.110.7.4/24 y la pasarela 10.110.7.1 como puerta de enlace, y comprobar después de cada paso qué se alcanza y qué no.

La idea

Tres pasos y un ping de control entre ellos:

Antes de tocar nada, un ping a la pasarela para ver el punto de partida.
Encender la tarjeta y darle IP con máscara. Control: la pasarela (mi red) debe contestar; el router (otra red), todavía no.
Añadir la puerta de enlace. Control: el router ya contesta.

Probar los dos destinos en cada paso es lo que te dice qué parte falta.

Antes de programar, piensa en qué error esperas de cada ping. Network is unreachable significa «no tengo ruta»; si ves eso, te falta configuración en tu propia máquina.

El código

# @lab base
ip -br addr                              # punto de partida
ping -c 1 10.110.7.1                     # antes de nada: ¿llego a la pasarela?
ip link set enp2s0 up                    # paso 1: encender
ip addr add 10.110.7.4/24 dev enp2s0     # paso 2: IP con su máscara
ping -c 2 10.110.7.1                     # la pasarela ya contesta
ping -c 1 10.110.1.1                     # el router todavía no
ip route add default via 10.110.7.1      # paso 3: puerta de enlace
ping -c 2 10.110.1.1                     # ahora sí
ip -br addr
ip route

Cada orden lleva un comentario con su porqué. Lo importante es el orden de las comprobaciones: el ping al router (línea de «el router todavía no») está puesto a propósito antes de la puerta de enlace, para ver el fallo con nuestros propios ojos.

Salida

# ip -br addr
lo               UNKNOWN        127.0.0.1/8 
enp2s0@if41      DOWN           
# ping -c 1 10.110.7.1
ping: connect: Network is unreachable
# ip link set enp2s0 up
# ip addr add 10.110.7.4/24 dev enp2s0
# ping -c 2 10.110.7.1
PING 10.110.7.1 (10.110.7.1) 56(84) bytes of data.
64 bytes from 10.110.7.1: icmp_seq=1 ttl=64 time=0.306 ms
64 bytes from 10.110.7.1: icmp_seq=2 ttl=64 time=0.055 ms

--- 10.110.7.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1006ms
rtt min/avg/max/mdev = 0.055/0.180/0.306/0.125 ms
# ping -c 1 10.110.1.1
ping: connect: Network is unreachable
# ip route add default via 10.110.7.1
# ping -c 2 10.110.1.1
PING 10.110.1.1 (10.110.1.1) 56(84) bytes of data.
64 bytes from 10.110.1.1: icmp_seq=1 ttl=63 time=0.839 ms
64 bytes from 10.110.1.1: icmp_seq=2 ttl=63 time=0.068 ms

--- 10.110.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1014ms
rtt min/avg/max/mdev = 0.068/0.453/0.839/0.385 ms
# ip -br addr
lo               UNKNOWN        127.0.0.1/8 
enp2s0@if41      UP             10.110.7.4/24 
# ip route
default via 10.110.7.1 dev enp2s0 
10.110.7.0/24 dev enp2s0 proto kernel scope link src 10.110.7.4

Comprobación paso a paso:

Momento	`enp2s0`	Rutas	Ping pasarela	Ping router
inicio	DOWN, sin IP	ninguna	`Network is unreachable`	(no probado)
tras `up` y `addr add`	UP, `10.110.7.4/24`	`10.110.7.0/24`	2 de 2, `ttl=64`	`Network is unreachable`
tras `route add default`	igual	+ `default via 10.110.7.1`	(ya funcionaba)	2 de 2, `ttl=63`

El ttl cuadra: 64 al hablar con la pasarela (mismo segmento) y 63 al llegar al router, porque la pasarela, al reenviar el paquete, le resta 1. En el dibujo:

Cada paso abre una puerta más: la IP con máscara te da tu red; la puerta de enlace, todas las demás.

Preguntas que te puedes hacer

¿Por qué el primer ping falla con Network is unreachable y no con un tiempo de espera? Porque la estación no tiene ninguna ruta: el núcleo sabe antes de enviar nada que no hay camino, y ping ni siquiera manda el paquete. Un tiempo de espera largo significaría que el paquete sale pero nadie contesta.

¿Importa el orden entre link set up y addr add? Para la IP no: puedes añadirla con la tarjeta apagada. Pero la ruta de la red solo aparece cuando la tarjeta está UP, así que hasta ese momento nada funciona (es el fragmento 2 de los ejercicios).

¿Por qué no se añade la ruta 10.110.7.0/24 a mano? Porque la crea el núcleo al poner la IP con su máscara. Es el proto kernel de la última línea de ip route.

¿Qué hace exactamente la pasarela para que el router conteste? Tiene la opción net.ipv4.ip_forward=1, que le permite reenviar paquetes entre sus dos tarjetas, y el router sabe volver a la 10.110.7.0/24 a través de ella. En el aula eso lo configura otro compañero (o tú en el puesto de la pasarela) con sysctl.

Dar por buena la red porque la pasarela contesta. El ping a tu propia red solo prueba la IP y la máscara; la puerta de enlace solo se prueba haciendo ping a algo que esté fuera de tu red.

Pruébalo tú

Quita la puerta de enlace con ip route del default y comprueba que el ping al router vuelve a Network is unreachable mientras el de la pasarela sigue funcionando.
Repite el programa con la IP 10.110.7.5/24. ¿Cambia algo en las salidas, aparte de la IP?

Programa 2: arreglar una estación mal configurada

Un compañero dice que su estación «no tiene red». Alguien escribió 10.110.70.4 en lugar de 10.110.7.4, y la puerta de enlace también con el 70. Hay que diagnosticarlo con órdenes que solo miran y después arreglarlo sin reiniciar.

La idea

Diagnóstico de dentro hacia fuera:

ip -br addr: ¿la tarjeta está UP? ¿qué IP y prefijo tiene?
ip route: ¿hay ruta por defecto? ¿la puerta de enlace está en mi red?
ping a la pasarela: ¿qué error da?
ip route get: ¿qué camino elige el núcleo para ese destino?

Arreglo: quitar la IP equivocada, poner la buena y volver a añadir la puerta de enlace.

Antes de programar, compara la red de la estación (10.110.70.0/24) con la IP de la pasarela (10.110.7.1). ¿La pasarela está dentro o fuera?

El código

# @lab mal
ip -br addr                              # 1. ¿qué IP tengo?
ip route                                 # 2. ¿por dónde salgo?
ping -c 2 10.110.7.1                     # 3. ¿llego a la pasarela?
ip route get 10.110.7.1                  # 4. ¿qué camino elige el núcleo para llegar?
ip addr del 10.110.70.4/24 dev enp2s0    # fuera la IP equivocada
ip route                                 # la ruta por defecto se ha ido con ella
ip addr add 10.110.7.4/24 dev enp2s0
ip route add default via 10.110.7.1
ip route get 10.110.7.1
ping -c 2 10.110.1.1

Las cuatro primeras órdenes no cambian nada: son el diagnóstico. El arreglo son las tres siguientes, y las dos últimas comprueban que ha funcionado.

Salida

# ip -br addr
lo               UNKNOWN        127.0.0.1/8 
enp2s0@if37      UP             10.110.70.4/24 
# ip route
default via 10.110.70.1 dev enp2s0 
10.110.70.0/24 dev enp2s0 proto kernel scope link src 10.110.70.4 
# ping -c 2 10.110.7.1
PING 10.110.7.1 (10.110.7.1) 56(84) bytes of data.
From 10.110.70.4 icmp_seq=1 Destination Host Unreachable
From 10.110.70.4 icmp_seq=2 Destination Host Unreachable

--- 10.110.7.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1020ms
pipe 2
# ip route get 10.110.7.1
10.110.7.1 via 10.110.70.1 dev enp2s0 src 10.110.70.4 uid 0 
    cache 
# ip addr del 10.110.70.4/24 dev enp2s0
# ip route
# ip addr add 10.110.7.4/24 dev enp2s0
# ip route add default via 10.110.7.1
# ip route get 10.110.7.1
10.110.7.1 dev enp2s0 src 10.110.7.4 uid 0 
    cache 
# ping -c 2 10.110.1.1
PING 10.110.1.1 (10.110.1.1) 56(84) bytes of data.
64 bytes from 10.110.1.1: icmp_seq=1 ttl=63 time=0.318 ms
64 bytes from 10.110.1.1: icmp_seq=2 ttl=63 time=0.057 ms

--- 10.110.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1007ms
rtt min/avg/max/mdev = 0.057/0.187/0.318/0.130 ms

Lo que dice cada parte:

ip -br addr: la tarjeta está UP con 10.110.70.4/24. Su red va de 10.110.70.0 a 10.110.70.255.
ip route: la puerta de enlace es 10.110.70.1, que está en esa red (por eso ip la aceptó), pero en el aula no existe.
El ping a 10.110.7.1 da Destination Host Unreachable desde la propia estación (From 10.110.70.4): la pasarela está fuera de la red de la estación, así que el paquete se manda a la puerta de enlace 10.110.70.1; la estación pregunta en el cable quién es esa IP (ARP), nadie contesta y el envío se da por imposible. +2 errors, 100% packet loss: 2 enviados, 0 recibidos, 2 errores.
ip route get 10.110.7.1 lo confirma: via 10.110.70.1. Va por la puerta de enlace en vez de directo.
Tras ip addr del, ip route sale vacío: la ruta por defecto se fue con la IP (su puerta de enlace ya no era alcanzable). Por eso hay que volver a añadirla.
Después del arreglo, ip route get 10.110.7.1 ya no lleva via: directo por enp2s0. Y el router contesta.

Una cifra de más en la IP cambia la red entera: el núcleo decide 'directo o por la puerta de enlace' comparando con tu red.

El dibujo enseña la decisión que toma el núcleo en cada caso: «¿el destino está en mi red?».

Preguntas que te puedes hacer

¿Por qué no da Network is unreachable como en el programa 1? Porque esta estación sí tiene rutas, incluida una por defecto. El núcleo encuentra camino (la puerta de enlace) y envía; el fallo llega después, cuando nadie responde a la puerta de enlace. Distinto error, distinta causa: por eso hay que leerlos.

¿No bastaba con cambiar la puerta de enlace? No: ip route add default via 10.110.7.1 habría dado Nexthop has invalid gateway, porque con la IP 10.110.70.4/24 la pasarela no está en mi red. Primero hay que arreglar la IP.

¿Por qué ip addr del necesita el /24? Porque una tarjeta puede tener varias IP, y se identifica cuál quitar por dirección y prefijo. Si escribes otro prefijo, ip no la encuentra y da error.

¿Y si no sé qué IP le toca a mi puesto? En el aula sigue un esquema (10.110.R.x, con R el número de puesto); en otros sitios te la da el administrador o un servidor DHCP (BOOTPROTO=dhcp).

Arreglar la IP y olvidar volver a poner la puerta de enlace. Tras el ip addr del, la ruta por defecto ha desaparecido: la pasarela contestaría, pero el router no.

Pruébalo tú

Antes de arreglar nada, haz ip route get 10.110.70.9. ¿Sale via? ¿Por qué?
Cambia la IP con ip addr flush dev enp2s0 en lugar de ip addr del. ¿Qué diferencia hay si la tarjeta tuviera dos IP?

Programa 3: del ifcfg a la red, con un script

Lo temporal ya lo dominamos. Ahora, lo permanente: al arrancar, el servicio network de CentOS lee cada ifcfg y configura la tarjeta. Como nuestro laboratorio no es un CentOS, escribimos un script, aplicar-ifcfg.sh, que hace lo mismo con un ifcfg, y lo probamos con dos archivos: el de enp2s0 (con ONBOOT=yes) y el de una segunda tarjeta con ONBOOT=no.

La idea

El ifcfg tiene formato CLAVE=valor, que es exactamente la sintaxis de una asignación en bash. Así que source lo carga y cada clave se convierte en variable ($IPADDR, $GATEWAY…). Después:

Si ONBOOT no es yes, no se hace nada (como al arrancar).
Si BOOTPROTO es dhcp, la IP no está en el archivo: se avisa y se sale.
Se convierte la máscara en prefijo (255.255.255.0 → 24) y se dan las tres órdenes del programa 1.

Antes de programar, piensa en cómo pasar de 255.255.255.0 a 24: cada byte de la máscara aporta sus bits a 1 (255 → 8, 0 → 0, y los valores intermedios como 192 → 2).

El código

El script:

#!/bin/bash
# aplicar-ifcfg.sh: hace a mano lo que el servicio network de CentOS hace al arrancar con cada ifcfg
# Uso: ./aplicar-ifcfg.sh ifcfg-enp2s0
source "$1"                          # cada línea CLAVE=valor del ifcfg se convierte en una variable

if [ "$ONBOOT" != "yes" ]; then      # ONBOOT=no: al arrancar, nadie toca esta tarjeta
    echo "$DEVICE: ONBOOT=$ONBOOT, no se activa"
    exit 0
fi
if [ "$BOOTPROTO" = "dhcp" ]; then   # con DHCP la IP la da un servidor (dhclient), no el archivo
    echo "$DEVICE: BOOTPROTO=dhcp, la IP la pide dhclient"
    exit 0
fi

prefijo() {                          # 255.255.255.0 -> 24: suma los bits a 1 de cada byte de la máscara
    local n=0 b
    for b in ${1//./ }; do           # ${1//./ } cambia los puntos por espacios: cuatro números
        case $b in
            255) n=$((n + 8)) ;; 254) n=$((n + 7)) ;; 252) n=$((n + 6)) ;; 248) n=$((n + 5)) ;;
            240) n=$((n + 4)) ;; 224) n=$((n + 3)) ;; 192) n=$((n + 2)) ;; 128) n=$((n + 1)) ;;
        esac                         # 0 no suma nada
    done
    echo $n
}

p=$(prefijo "$NETMASK")
ip link set "$DEVICE" up                       # 1. encender la tarjeta
ip addr add "$IPADDR/$p" dev "$DEVICE"         # 2. la IP CON su prefijo (sin él sería /32)
echo "$DEVICE: $IPADDR/$p"
if [ -n "$GATEWAY" ]; then                     # 3. la ruta por defecto, solo si hay GATEWAY
    ip route add default via "$GATEWAY"
    echo "$DEVICE: puerta de enlace $GATEWAY"
fi

Y la sesión que lo usa:

# @lab base
cat -n ifcfg-enp2s0
cat -n ifcfg-enp3s0
./aplicar-ifcfg.sh ifcfg-enp3s0          # ONBOOT=no
./aplicar-ifcfg.sh ifcfg-enp2s0          # ONBOOT=yes
ip -br addr
ip route
ping -c 2 router

El trozo más difícil es la función prefijo. Con zoom:

prefijo() {                          # 255.255.255.0 -> 24: suma los bits a 1 de cada byte de la máscara
    local n=0 b
    for b in ${1//./ }; do           # ${1//./ } cambia los puntos por espacios: cuatro números
        case $b in
            255) n=$((n + 8)) ;; 254) n=$((n + 7)) ;; 252) n=$((n + 6)) ;; 248) n=$((n + 5)) ;;
            240) n=$((n + 4)) ;; 224) n=$((n + 3)) ;; 192) n=$((n + 2)) ;; 128) n=$((n + 1)) ;;
        esac                         # 0 no suma nada
    done
    echo $n
}

${1//./ } cambia todos los puntos del primer argumento por espacios, así que for recorre los cuatro números. case suma los bits de cada uno. Traza con 255.255.255.0:

Vuelta	`b`	Suma	`n` después
1	255	8	8
2	255	8	16
3	255	8	24
4	0	0 (ningún caso)	24

echo $n la devuelve y p=$(prefijo "$NETMASK") la recoge: 24.

Salida

# cat -n ifcfg-enp2s0
     1	DEVICE=enp2s0
     2	BOOTPROTO=none
     3	ONBOOT=yes
     4	IPADDR=10.110.7.4
     5	NETMASK=255.255.255.0
     6	GATEWAY=10.110.7.1
# cat -n ifcfg-enp3s0
     1	DEVICE=enp3s0
     2	BOOTPROTO=none
     3	ONBOOT=no
     4	IPADDR=10.110.9.4
     5	NETMASK=255.255.255.0
# ./aplicar-ifcfg.sh ifcfg-enp3s0
enp3s0: ONBOOT=no, no se activa
# ./aplicar-ifcfg.sh ifcfg-enp2s0
enp2s0: 10.110.7.4/24
enp2s0: puerta de enlace 10.110.7.1
# ip -br addr
lo               UNKNOWN        127.0.0.1/8 
enp2s0@if45      UP             10.110.7.4/24 
# ip route
default via 10.110.7.1 dev enp2s0 
10.110.7.0/24 dev enp2s0 proto kernel scope link src 10.110.7.4 
# ping -c 2 router
PING router (10.110.1.1) 56(84) bytes of data.
64 bytes from router (10.110.1.1): icmp_seq=1 ttl=63 time=0.416 ms
64 bytes from router (10.110.1.1): icmp_seq=2 ttl=63 time=0.093 ms

--- router ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.093/0.254/0.416/0.161 ms

Con ifcfg-enp3s0, el script se para en la primera comprobación: ONBOOT=no, no se activa. No toca nada, aunque el archivo tenga IP.
Con ifcfg-enp2s0 monta 10.110.7.4/24 (la máscara convertida a 24) y la puerta de enlace 10.110.7.1.
ip -br addr e ip route quedan idénticos a los del final del programa 1: el archivo ha producido la misma configuración que las órdenes a mano.
ping -c 2 router usa el nombre de /etc/hosts y contesta con ttl=63, como antes.

El archivo permanente no tiene magia: al arrancar se traduce a las mismas órdenes ip que darías tú.

En el dibujo, cada línea del ifcfg con la orden en la que se convierte.

Preguntas que te puedes hacer

¿Es seguro hacer source de un archivo? Solo si te fías de él: source ejecuta lo que haya dentro. Un ifcfg es un archivo de root en /etc, así que vale; con un archivo cualquiera descargado, nunca.

¿Por qué la función usa local? Para que n y b no pisen variables del resto del script. Sin local, en bash todas las variables son globales.

¿Qué pasa si el ifcfg no tiene GATEWAY? [ -n "$GATEWAY" ] es falso y no se añade ruta por defecto: la tarjeta solo verá su red. Es lo normal en una segunda tarjeta que solo da a una red interna.

¿El servicio de verdad hace solo esto? Hace bastante más (DHCP, varias IP, rutas extra, DNS en resolv.conf…), pero para un ifcfg como el del aula el resultado es este: link up, addr add y route add.

Escribir el ifcfg con espacios alrededor del = (ONBOOT = yes). Para bash eso ya no es una asignación, y el servicio de red tampoco lo entiende: la tarjeta no arranca.

Pruébalo tú

Cambia NETMASK a 255.255.255.192 en una copia del ifcfg y comprueba qué prefijo calcula el script (cuenta tú antes: 8 + 8 + 8 + 2).
Añade al script el caso BOOTPROTO=dhcp de verdad: que ejecute dhclient "$DEVICE" en lugar de salir.

Errores típicos en esta práctica

Probar solo un ping: la pasarela prueba tu IP y máscara; algo de fuera de tu red prueba la puerta de enlace. Haz los dos.
Confundir los errores de ping: Network is unreachable = te falta ruta en tu máquina; Destination Host Unreachable = hay ruta pero no responde quien tiene que recibir.
Arreglar la puerta de enlace antes que la IP: con la IP mal, la puerta de enlace buena da Nexthop has invalid gateway.
Olvidar que ip addr del se lleva las rutas: hay que volver a añadir la ruta por defecto.
Espacios en el ifcfg: CLAVE=valor, todo junto.
Hacer pruebas en tu propio portátil: usa una máquina de prácticas o una virtual.

Pruébalo en tu terminal

Cada vez que haces ping a una máquina de tu red, la tuya necesita su MAC, y la pregunta con ARP. ip neigh enseña esa «agenda» (la tabla ARP). Como usuario normal en la estación configurada:

# @lab conf
# @sergio
ip neigh                                 # la tabla ARP: vacía
ping -c 1 pasarela
ip neigh                                 # ahora conoce la MAC de la pasarela

La sesión real:

$ ip neigh
$ ping -c 1 pasarela
PING pasarela (10.110.7.1) 56(84) bytes of data.
64 bytes from pasarela (10.110.7.1): icmp_seq=1 ttl=64 time=0.208 ms

--- pasarela ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.208/0.208/0.208/0.000 ms
$ ip neigh
10.110.7.1 dev enp2s0 lladdr 08:00:27:a1:07:01 REACHABLE

Qué observar:

Al principio ip neigh no imprime nada: la estación aún no ha hablado con nadie.
ping -c 1 pasarela resuelve el nombre con /etc/hosts y contesta en una sola vuelta.
Después, ip neigh tiene una entrada: la IP 10.110.7.1, por qué tarjeta se llega (dev enp2s0) y su MAC (lladdr 08:00:27:a1:07:01).
REACHABLE significa que la entrada es reciente y fiable. Al cabo de un rato sin tráfico pasa a STALE.
En tu ordenador, ip neigh mostrará como mínimo tu router de casa o de la universidad: tu puerta de enlace.

Resumen

Para tener red: tarjeta up, IP con máscara y puerta de enlace que esté en tu red; comprueba cada paso con un ping dentro y otro fuera de tu red.
Network is unreachable apunta a tu configuración (falta ruta); Destination Host Unreachable, a que nadie responde en la red local.
ip route get IP dice qué camino elige el núcleo: con via va por la puerta de enlace, sin via va directo.
Quitar una IP borra también las rutas que dependían de ella.
Un ifcfg son variables de bash: al arrancar se traduce en ip link set up, ip addr add e ip route add default, si ONBOOT=yes.
ip neigh enseña las MAC que tu máquina ha aprendido.

Checklist: ¿lo has practicado?

¿Has ejecutado los tres programas y comprobado las salidas?
¿Has intentado los «Pruébalo tú» sin mirar la teoría?
¿Sabes qué error de ping esperar si falta la puerta de enlace y cuál si la IP está mal?
¿Puedes explicar por qué 10.110.7.1 está fuera de la red 10.110.70.0/24?
¿Sabes calcular el prefijo de una máscara como 255.255.255.192?
¿Entiendes por qué ONBOOT=no hace que el script no toque la tarjeta?

Si has respondido que sí a casi todo, estás listo para los ejercicios de configuración de red, donde ya no te doy las órdenes hechas. ¡Nos vemos allí!

Siguiente paso: ejerciciosConfiguración de red en Linux — ejercicios con la ficha de la estación, órdenes de ifconfig traducidas y un ifcfg generado (y el /32 que dejó sola a la tarjeta)

¿Te ha servido este artículo? Así puedes apoyar SergioLearns →