Passa al contenuto principale

Configurazione di gateway Linux in reti di produzione

Questa guida illustra alcuni dei parametri di configurazione di rete di base che possono impedire il funzionamento di un sistema Linux in un ambiente di produzione a causa dell'infrastruttura isolata. Si tenga presente che le distribuzioni Linux possono utilizzare servizi diversi per gli argomenti trattati di seguito. Pertanto, potrebbe non essere possibile eseguire alcuni dei comandi elencati. Questa sezione è stata redatta utilizzando come esempio un Raspberry Pi con sistema operativo Debian 12 (bookworm) nativo.

informazioni

Prima della chiamata di supporto con il team SEW, assicurarsi di disporre dell'accesso SSH al dispositivo Linux dal proprio computer per la condivisione dello schermo durante la sessione.

Di seguito è riportato un elenco delle aree più comuni che possono impedire la connessione.

Server DNS​

Un server DNS (Domain Name System) risolve i nomi di dominio in indirizzi IP per agevolare la comunicazione tramite internet. Una corretta configurazione del DNS è fondamentale per un sistema Linux operante in un ambiente di rete. La risoluzione dei problemi DNS prevede la verifica della raggiungibilità del server DNS mediante comandi come ping o nslookup. Assicurarsi che il server risponda e che risolva correttamente i nomi di dominio in indirizzi IP. Configurazioni errate possono causare il mancato funzionamento della risoluzione dei domini, con conseguenze sulle comunicazioni di rete e sull'accesso a internet.

Test​

Verificare gli IP dei server DNS configurati sull'host con:

cat /etc/resolv.conf

Ogni server DNS può essere testato individualmente con nslookup o dig. Per esempio, se il server è 8.8.8.8:

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

Se questi comandi non sono presenti, possono essere installati in Debian con i pacchetti dnsutils o bind9-dnsutils, oppure è possibile utilizzare un comando nativo come ping o getent per testare la configurazione DNS corrente:

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

Configurazione​

I server DNS possono essere gestiti da servizi diversi, in base all'installazione Linux. Per un Raspberry Pi, sono tipicamente gestiti dal servizio NetworkManager. Il servizio che gestisce la risoluzione DNS lascerà probabilmente un commento in /etc/resolv.conf indicando di aver generato il file, ad esempio:

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

Per impostare i server DNS globali, creare il file:

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

E aggiungere:

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

Riavviare il servizio NetworkManager e verificare i nuovi valori in /etc/resolv.conf

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

Server NTP​

Un server NTP (Network Time Protocol) viene utilizzato nei sistemi Linux per sincronizzare l'orologio di sistema con una fonte temporale, come un orologio atomico o un server centrale. Una misurazione accurata del tempo è essenziale per il logging, i protocolli di sicurezza e il coordinamento delle azioni all'interno di una rete. Una configurazione errata di un server NTP causerà il fallimento delle chiamate HTTPS a causa dell'invalidazione dei certificati SSL.

Test​

Verificare lo stato della sincronizzazione NTP e se la data e l'ora correnti sono corrette.

# 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

Test della connessione a un server specifico:

# 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

Configurazione​

Il server NTP può essere configurato con un nome di dominio, come 0.debian.pool.ntp.org o ntp.myorg.com, oppure direttamente con un indirizzo IP.

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

Aggiungere il server NTP personalizzato nel blocco [Time] e assicurarsi che la riga non sia commentata. Rimuovere da FallbackNTP qualsiasi server non raggiungibile.

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

Riavviare e assicurarsi di abilitare il servizio 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

Server proxy​

Un server proxy agisce come intermediario tra un client e i server di destinazione, inoltrando richieste e risposte. Negli ambienti aziendali, i server proxy sono comunemente utilizzati per il controllo della sicurezza, il filtraggio dei contenuti, la gestione della banda e il logging del traffico in uscita. I sistemi Linux in tali reti devono essere configurati per instradare le proprie richieste HTTP/HTTPS attraverso il proxy aziendale per accedere alle risorse esterne, inclusi i repository dei pacchetti e i servizi web.

Test​

Verificare se il proxy è attualmente configurato controllando le variabili d'ambiente e le impostazioni proxy a livello di 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

Per verificare se è necessario un server proxy, provare a connettersi direttamente a un server esterno:

# 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"

Se l'operazione fallisce con errori di connessione, potrebbe essere necessario un proxy. Errori comuni sono, per esempio, Failed to connect o Connection timed out.

Per testare una richiesta con un server proxy specifico:

# 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

Configurazione​

informazioni

Un indirizzo proxy ha uno dei seguenti formati:

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

Configurare il proxy per tutti gli utenti e le applicazioni:

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

Aggiungere o modificare le seguenti righe:

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"

Applicare le modifiche:

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

Per verificare se il traffico passa effettivamente attraverso il 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...
avviso

Alcuni proxy eseguono l'ispezione SSL. Potrebbe essere necessario installare i certificati CA aziendali:

# 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

Repository Debian​

I repository Debian sono server che ospitano pacchetti software e aggiornamenti per i sistemi basati su Debian. Negli ambienti aziendali isolati, l'accesso ai mirror Debian pubblici (come deb.debian.org o archive.ubuntu.com) può essere bloccato per motivi di sicurezza. Le aziende spesso mantengono propri mirror interni per controllare quali pacchetti sono disponibili e per ridurre l'utilizzo di banda esterna.

Test​

Verificare i repository attualmente configurati:

# 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

Di seguito è riportato uno script bash completo per testare integralmente la connettività ai repository configurati:

# 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

Un altro metodo consiste nel tentare di aggiornare gli elenchi dei pacchetti per individuare problemi relativi ai repository:

# Try to update package lists
sudo apt update

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

Messaggi di errore comuni che indicano repository bloccati:

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

Testare manualmente un server di repository specifico:

# 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

Configurazione​

Modificare il file delle sorgenti principale:

sudo nano /etc/apt/sources.list

Sostituire il contenuto con il proprio mirror interno. Per 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

Se il mirror interno utilizza HTTPS:

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

Nota: per i repository HTTPS, assicurarsi che i pacchetti apt-transport-https e ca-certificates siano installati.

Configurazione della priorità dei repository (opzionale)

Se è necessario utilizzare sia repository interni sia esterni dando la preferenza a quelli interni:

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

Aggiungere:

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

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

In questo modo si assegna una priorità più alta ai mirror interni.

Configurazione del proxy per i repository (opzionale)

Se la rete richiede un proxy per raggiungere i repository:

# 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

Aggiornamento e verifica

Dopo aver configurato i repository:

# 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

Problemi comuni

Problema: apt update rimane bloccato indefinitamente

# 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: pacchetti non trovati dopo la configurazione del 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: sorgenti di repository mescolate che causano conflitti

# 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