Saltar al contenido principal

Configuración de gateways Linux en redes de producción

Esta guía cubre algunos de los parámetros básicos de configuración de red que pueden impedir que un sistema Linux funcione en un entorno de producción debido al aislamiento de la infraestructura. Tenga en cuenta que las distribuciones de Linux pueden utilizar servicios diferentes para los temas siguientes. Por lo tanto, es posible que no pueda ejecutar algunos de los comandos indicados a continuación. Esta sección se ha redactado utilizando como ejemplo una Raspberry Pi con la versión nativa del sistema operativo Debian 12 (bookworm).

información

Antes de su llamada de soporte con el equipo de SEW, asegúrese de tener acceso SSH al dispositivo Linux desde su ordenador para poder compartir pantalla durante la sesión.

A continuación se presenta una lista de áreas habituales que pueden impedir la conexión.

Servidores DNS​

Un servidor de Sistema de Nombres de Dominio (DNS) resuelve nombres de dominio en direcciones IP para facilitar la comunicación a través de internet. Una configuración DNS adecuada es fundamental para un sistema Linux que opera en un entorno de red. La resolución de problemas de DNS implica comprobar la accesibilidad del servidor DNS mediante comandos como ping o nslookup. Asegúrese de que el servidor responde y resuelve correctamente los nombres de dominio en direcciones IP. Las configuraciones incorrectas pueden provocar fallos en la resolución de dominios, afectando a las comunicaciones de red y al acceso a internet.

Pruebas​

Compruebe las IP de los servidores DNS configurados en el host con:

cat /etc/resolv.conf

Cada servidor DNS puede probarse individualmente con nslookup o dig. Por ejemplo, si el servidor es 8.8.8.8:

nslookup api.eu1.sdaconsole.io 8.8.8.8
dig @8.8.8.8 api.eu1.sdaconsole.io +short

Si estos comandos no están presentes, pueden instalarse con los paquetes dnsutils o bind9-dnsutils en Debian, o bien puede utilizarse un comando nativo como ping o getent para probar la configuración DNS actual:

ping api.eu1.sdaconsole.io
getent hosts api.eu1.sdaconsole.io

Configuración​

Los servidores DNS pueden estar gestionados por distintos servicios, según la instalación de Linux. En una Raspberry Pi, normalmente los gestiona el servicio NetworkManager. El servicio que gestiona la resolución DNS probablemente dejará un comentario en /etc/resolv.conf indicando que generó el archivo, como por ejemplo:

cat /etc/resolv.conf
> # Generated by NetworkManager
> nameserver 192.168.15.1
> nameserver fe80::dec6:37ff:fe36:5ee8%wlan0

cat /etc/resolv.conf
> # Generated by dhcpcd from eth0.dhcp
> # /etc/resolv.conf.head can replace this line
> nameserver 192.168.15.1

Para establecer los servidores DNS globales, cree el archivo:

sudo nano /etc/NetworkManager/conf.d/dns.conf

Y añada:

[global-dns-domain-*]
servers=8.8.8.8,4.4.4.4

Reinicie el servicio NetworkManager y compruebe los nuevos valores en /etc/resolv.conf

sudo systemctl restart NetworkManager
# Verify /etc/resolv.conf was updated
cat /etc/resolv.conf

Servidores NTP​

Un servidor de Protocolo de Tiempo de Red (NTP) se utiliza en los sistemas Linux para sincronizar el reloj del sistema con una fuente horaria, como un reloj atómico o un servidor central. Una medición precisa del tiempo es crucial para el registro de eventos, los protocolos de seguridad y la coordinación de acciones a través de una red. Una configuración incorrecta de un servidor NTP provocará el fallo de las llamadas HTTPS debido a la invalidación de los certificados SSL.

Pruebas​

Revise el estado de la sincronización NTP y si la fecha y la hora actuales son correctas.

# Check NTP sync status
timedatectl status

# Check configured NTP servers
timedatectl timesync-status
timedatectl show-timesync --all

# Check logs from the timesync service
journalctl -u systemd-timesyncd -n 20
# Check if service is active
systemctl is-active systemd-timesyncd

Prueba de la conexión con un servidor específico:

# Using ntpdate, if installed
ntpdate -q 0.debian.pool.ntp.org

# Using Netcat
timeout 2 nc -u -z -v 0.debian.pool.ntp.org 123

Configuración​

El servidor NTP puede configurarse con un nombre de dominio, como 0.debian.pool.ntp.org o ntp.myorg.com, o directamente con una dirección IP.

# Configure systemd-timesyncd
sudo nano /etc/systemd/timesyncd.conf

Añada el servidor NTP personalizado en el bloque [Time] y asegúrese de que la línea no esté comentada. Elimine cualquier servidor de FallbackNTP que no sea accesible.

[Time]
NTP=ntp.myorg.com ntp.myorg.local
FallbackNTP=

Reinicie y asegúrese de habilitar el servicio timesync.

# Restart and enable
sudo systemctl restart systemd-timesyncd
sudo systemctl enable systemd-timesyncd

# Force synchronization
sudo timedatectl set-ntp true

# Verify sync
timedatectl timesync-status

Servidores proxy​

Un servidor proxy actúa como intermediario entre un cliente y los servidores de destino, reenviando solicitudes y respuestas. En entornos empresariales, los servidores proxy se utilizan habitualmente para el control de seguridad, el filtrado de contenidos, la gestión del ancho de banda y el registro del tráfico de salida. Los sistemas Linux en dichas redes deben configurarse para enrutar sus solicitudes HTTP/HTTPS a través del proxy corporativo con el fin de acceder a recursos externos, incluidos los repositorios de paquetes y los servicios web.

Pruebas​

Compruebe si actualmente hay un proxy configurado revisando las variables de entorno y los ajustes de proxy a nivel de sistema:

# Check shell environment proxy variables
env | grep -i proxy

# Check system-wide proxy configuration
cat /etc/environment | grep -i proxy

# Check if proxy is set for current user
echo $http_proxy
echo $https_proxy
echo $no_proxy

Para comprobar si es necesario un servidor proxy, intente conectarse directamente a un servidor externo:

# Try direct connection to a public server
timeout 5 curl -I https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json 2>&1

# If it fails with connection errors, proxy might be required
# Common error: "Failed to connect" or "Connection timed out"

Si falla con errores de conexión, puede que se requiera un proxy. Errores habituales son, por ejemplo, Failed to connect o Connection timed out.

Para probar una solicitud con un servidor proxy específico:

# Test with curl
curl -I --proxy http://proxy.company.local:8080 https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json
# Proxy with user authentication
curl -I --proxy http://user@pwd@proxy.company.local:8080 https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json
# Test without proxy (direct connection)
curl -I --noproxy "*" https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json

Configuración​

información

Una dirección de proxy tiene uno de estos formatos:

<protocol>://<proxy-address>:<port-number>
<protocol>://<username>:<password>@<proxy-address>:<port-number>

Configure el proxy para todos los usuarios y aplicaciones:

# Edit system-wide environment
sudo nano /etc/environment

Añada o modifique las líneas siguientes:

http_proxy="http://proxy.company.local:8080"
https_proxy="http://proxy.company.local:8080"
no_proxy="localhost,127.0.0.1,*.company.local,10.0.0.0/8,192.168.0.0/16"

# Uppercase variants (some applications check these)
HTTP_PROXY="http://proxy.company.local:8080"
HTTPS_PROXY="http://proxy.company.local:8080"
NO_PROXY="localhost,127.0.0.1,*.company.local,10.0.0.0/8,192.168.0.0/16"

Aplique los cambios:

# Reload environment (or log out and back in)
source /etc/environment
# Verify variables are set
env | grep -i proxy

Para comprobar si el tráfico realmente pasa por el proxy:

# Verbose curl request showing proxy connection
curl -v -I https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json 2>&1 | grep -i proxy

# Should show something like:
# * Uses proxy env variable http_proxy == 'http://proxy.company.local:3128'
# * Trying proxy.company.local:3128...
aviso

Algunos proxies realizan inspección SSL. Es posible que necesite instalar los certificados CA corporativos:

# Copy corporate CA certificate
sudo cp company-ca.crt /usr/local/share/ca-certificates/
# Update CA trust store
sudo update-ca-certificates
# Verify
curl -I https://repository.eu1.sdaconsole.io/glue/v2/linux/arm64/release.json

Repositorios de Debian​

Los repositorios de Debian son servidores que alojan paquetes de software y actualizaciones para sistemas basados en Debian. En entornos empresariales aislados, el acceso a los mirrors públicos de Debian (como deb.debian.org o archive.ubuntu.com) puede estar bloqueado por motivos de seguridad. Las empresas suelen mantener sus propios mirrors internos para controlar qué paquetes están disponibles y reducir el uso de ancho de banda externo.

Pruebas​

Compruebe los repositorios configurados actualmente:

# View configured repositories
cat /etc/apt/sources.list

# Check additional repository files
ls -la /etc/apt/sources.list.d/
cat /etc/apt/sources.list.d/*.list 2>/dev/null

A continuación se muestra un script de bash completo para probar exhaustivamente la conectividad con los repositorios configurados:

# Test if repository servers are reachable
grep -h "^deb http" /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null | \
    awk '{print $2, $3}' | sort -u | while read repo suite; do
    echo "Testing: $repo (suite: $suite)"
    # Test the Release file that APT actually fetches
    # This is what APT checks first when doing 'apt update'
    release_url="${repo}/dists/${suite}"
    # Test with curl (follows redirects, checks certificates)
    if curl -fsSL --connect-timeout 5 --max-time 10 -I "$release_url/InRelease" >/dev/null 2>&1; then
        echo "  > Repository is reachable"
    else
        if curl -fsSL --connect-timeout 5 --max-time 10 -I "$release_url/Release" >/dev/null 2>&1; then
            echo "  > Repository is reachable"
        else
            # If failed, show the specific error
            error=$(curl -fsSL --connect-timeout 5 --max-time 10 -I "$repo" 2>&1 | head -1)
            echo "  X Unreachable: $error"
        fi
    fi
    echo
done

Otro método consiste en intentar actualizar las listas de paquetes para identificar problemas con los repositorios:

# Try to update package lists
sudo apt update

# Check for errors in apt logs
tail -20 /var/log/apt/term.log

Mensajes de error habituales que indican repositorios bloqueados:

  • Failed to fetch http://deb.debian.org/...
  • Could not resolve 'deb.debian.org'
  • Connection timed out
  • Unable to connect to...

Pruebe manualmente un servidor de repositorio específico:

# Test HTTP connectivity to a repository
curl -sSL -I --connect-timeout 5 http://deb.debian.org/debian/

# Or using wget
wget --spider --timeout=5 http://deb.debian.org/debian/

# Test DNS resolution
getent hosts deb.debian.org

Configuración​

Edite el archivo principal de fuentes:

sudo nano /etc/apt/sources.list

Sustituya el contenido por su mirror interno. Para Debian 12 (bookworm):

# Internal Debian Repository Mirror
deb http://mirror.company.local/debian bookworm main contrib non-free non-free-firmware
deb http://mirror.company.local/debian bookworm-updates main contrib non-free non-free-firmware
deb http://mirror.company.local/debian-security bookworm-security main contrib non-free non-free-firmware

# Optionally, backports for newer packages
deb http://mirror.company.local/debian bookworm-backports main contrib non-free non-free-firmware

Si su mirror interno utiliza HTTPS:

deb https://mirror.company.local/debian bookworm main contrib non-free non-free-firmware

Nota: Para repositorios HTTPS, asegúrese de que los paquetes apt-transport-https y ca-certificates estén instalados.

Configurar la prioridad de los repositorios (opcional)

Si necesita utilizar tanto repositorios internos como externos, dando preferencia a los internos:

sudo nano /etc/apt/preferences.d/internal-mirror

Añada:

Package: *
Pin: origin mirror.company.local
Pin-Priority: 900

Package: *
Pin: origin deb.debian.org
Pin-Priority: 500

Esto otorga mayor prioridad a los mirrors internos.

Configurar un proxy para los repositorios (opcional)

Si su red requiere un proxy para acceder a los repositorios:

# Configure APT proxy
echo 'Acquire::http::Proxy "http://proxy.company.local:3128";' | \
    sudo tee /etc/apt/apt.conf.d/proxy.conf

# For HTTPS repositories
echo 'Acquire::https::Proxy "http://proxy.company.local:3128";' | \
    sudo tee -a /etc/apt/apt.conf.d/proxy.conf

# Test
sudo apt update

Actualizar y verificar

Después de configurar los repositorios:

# Update package lists
sudo apt update

# Check for errors
echo $?  # Should return 0 if successful

# Verify packages can be found
apt-cache policy apt

# Test installing a small package
sudo apt install --dry-run nano

Problemas habituales

Problema: apt update se queda bloqueado indefinidamente

# Check if repository server is actually responding
timeout 10 curl -v http://mirror.company.local/debian/

# Check for proxy interference
unset http_proxy https_proxy
sudo apt update

Problema: No se encuentran los paquetes después de configurar el mirror

# Verify the mirror has the correct Debian version
curl http://mirror.company.local/debian/dists/ | grep bookworm

# Check if the mirror is properly synced
curl -sI http://mirror.company.local/debian/dists/bookworm/Release | grep Date

Problema: La mezcla de fuentes de repositorios provoca conflictos

# Check all active sources
grep -rh "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/ | sort -u

# Disable conflicting sources
sudo mv /etc/apt/sources.list.d/problematic.list /etc/apt/sources.list.d/problematic.list.disabled

sudo apt update