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. Tenga presente che le distribuzioni Linux possono utilizzare servizi differenti per gli argomenti seguenti. Pertanto, potrebbe non essere possibile eseguire alcuni dei comandi elencati qui sotto. Questa sezione è stata redatta utilizzando come esempio un Raspberry Pi con sistema operativo nativo Debian 12 (bookworm).

informazioni

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

Segue 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 DNS è fondamentale per un sistema Linux che opera in un ambiente di rete. La risoluzione dei problemi DNS prevede la verifica della raggiungibilità del server DNS mediante comandi come ping o nslookup. Si accerti che il server risponda e risolva correttamente i nomi di dominio in indirizzi IP. Configurazioni errate possono causare il mancato completamento della risoluzione dei domini, con ripercussioni sulle comunicazioni di rete e sull'accesso a internet.

Test​

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

cat /etc/resolv.conf

Ogni server DNS può essere testato singolarmente 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 il pacchetto dnsutils o bind9-dnsutils; in alternativa è 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, a seconda dell'installazione Linux. Su un Raspberry Pi vengono in genere 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, per 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, crei il file:

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

E aggiunga:

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

Riavvii il servizio NetworkManager e verifichi 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 la registrazione dei log, i protocolli di sicurezza e il coordinamento delle azioni in una rete. Una configurazione errata di un server NTP causerà il fallimento delle chiamate HTTPS a causa dell'invalidazione dei certificati SSL.

Test​

Verifichi lo stato di sincronizzazione NTP e se data e 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

Aggiunga il server NTP personalizzato nel blocco [Time] e si accerti che la riga non sia commentata. Rimuova dal parametro FallbackNTP tutti i server non raggiungibili.

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

Riavvii e si accerti 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 funge da 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 la registrazione del traffico in uscita. I sistemi Linux in tali reti devono essere configurati per instradare le proprie richieste HTTP/HTTPS attraverso il proxy aziendale al fine di accedere alle risorse esterne, inclusi i repository di pacchetti e i servizi web.

Test​

Verifichi se un 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, provi 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 non riesce 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>

Configuri il proxy per tutti gli utenti e le applicazioni:

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

Aggiunga o modifichi le righe seguenti:

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"

Applichi 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 pubblici Debian (come deb.debian.org o archive.ubuntu.com) può essere bloccato per motivi di sicurezza. Le aziende mantengono spesso mirror interni propri per controllare quali pacchetti sono disponibili e per ridurre l'utilizzo di banda esterna.

Test​

Verifichi 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 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...

Testi 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​

Modifichi il file delle sorgenti principale:

sudo nano /etc/apt/sources.list

Sostituisca 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, si accerti 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 priorità a quelli interni:

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

Aggiunga:

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

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

In questo modo i mirror interni ottengono una priorità più elevata.

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 si blocca 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