Aller au contenu principal

Configuration des passerelles Linux dans les réseaux de production

Ce guide présente certains des paramètres de configuration réseau de base susceptibles d'empêcher un système Linux de fonctionner dans un environnement de production en raison d'une infrastructure isolée. Notez que les distributions Linux peuvent utiliser des services différents pour les sujets suivants. Par conséquent, il se peut que vous ne puissiez pas exécuter certaines des commandes listées ci-dessous. Cette section a été rédigée en prenant comme exemple un Raspberry Pi avec la version native de l'OS Debian 12 (bookworm).

info

Avant votre appel d'assistance avec l'équipe SDA, assurez-vous de disposer d'un accès SSH à l'appareil Linux depuis votre ordinateur afin de pouvoir partager votre écran pendant la session.

Voici une liste des domaines courants susceptibles d'empêcher la connexion.

Serveurs DNS​

Un serveur DNS (Domain Name System) résout les noms de domaine en adresses IP afin de faciliter la communication sur Internet. Une configuration DNS correcte est essentielle pour un système Linux fonctionnant dans un environnement en réseau. Le dépannage des problèmes DNS consiste à vérifier l'accessibilité du serveur DNS à l'aide de commandes telles que ping ou nslookup. Assurez-vous que le serveur répond et qu'il résout correctement les noms de domaine en adresses IP. Des configurations erronées peuvent entraîner l'échec de la résolution de domaine, affectant les communications réseau et l'accès à Internet.

Test​

Vérifiez les adresses IP des serveurs DNS configurés sur l'hôte avec :

cat /etc/resolv.conf

Chaque serveur DNS peut être testé individuellement avec nslookup ou dig. Par exemple, si le serveur est 8.8.8.8 :

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

Si ces commandes ne sont pas présentes, elles peuvent être installées avec les paquets dnsutils ou bind9-dnsutils sous Debian, ou bien une commande native telle que ping ou getent peut être utilisée pour tester la configuration DNS actuelle :

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

Configuration​

Les serveurs DNS peuvent être gérés par différents services, selon l'installation Linux. Pour un Raspberry Pi, ils sont généralement gérés par le service NetworkManager. Le service qui gère la résolution DNS laissera probablement un commentaire dans /etc/resolv.conf indiquant qu'il a généré le fichier, par exemple :

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

Pour définir les serveurs DNS globaux, créez le fichier :

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

Et ajoutez :

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

Redémarrez le service NetworkManager et vérifiez les nouvelles valeurs dans /etc/resolv.conf

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

Serveurs NTP​

Un serveur NTP (Network Time Protocol) est utilisé dans les systèmes Linux pour synchroniser l'horloge système avec une source de temps, telle qu'une horloge atomique ou un serveur central. Une mesure du temps précise est essentielle pour la journalisation, les protocoles de sécurité et la coordination des actions sur un réseau. Une mauvaise configuration d'un serveur NTP entraînera l'échec des appels HTTPS en raison de l'invalidation des certificats SSL.

Test​

Vérifiez l'état de la synchronisation NTP ainsi que l'exactitude de la date et de l'heure actuelles.

# 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 de la connexion à un serveur spécifique :

# 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

Configuration​

Le serveur NTP peut être configuré avec un nom de domaine, tel que 0.debian.pool.ntp.org ou ntp.myorg.com, ou directement avec une adresse IP.

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

Ajoutez le serveur NTP personnalisé dans le bloc [Time] et assurez-vous que la ligne n'est pas commentée. Supprimez tout serveur de FallbackNTP qui ne peut pas être atteint.

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

Redémarrez et veillez à activer le service 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

Serveurs proxy​

Un serveur proxy agit comme intermédiaire entre un client et les serveurs de destination, en transmettant les requêtes et les réponses. Dans les environnements d'entreprise, les serveurs proxy sont couramment utilisés pour le contrôle de la sécurité, le filtrage de contenu, la gestion de la bande passante et la journalisation du trafic sortant. Les systèmes Linux présents dans de tels réseaux doivent être configurés pour acheminer leurs requêtes HTTP/HTTPS via le proxy de l'entreprise afin d'accéder aux ressources externes, y compris les dépôts de paquets et les services web.

Test​

Vérifiez si un proxy est actuellement configuré en contrôlant les variables d'environnement et les paramètres de proxy à l'échelle du système :

# 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

Pour vérifier si un serveur proxy est nécessaire, tentez de vous connecter directement à un serveur externe :

# 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 cela échoue avec des erreurs de connexion, un proxy peut être requis. Les erreurs courantes sont, par exemple, Failed to connect ou Connection timed out.

Pour tester une requête avec un serveur proxy spécifique :

# 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

Configuration​

info

Une adresse de proxy a l'un des formats suivants :

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

Configurez le proxy pour tous les utilisateurs et applications :

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

Ajoutez ou modifiez les lignes suivantes :

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"

Appliquez les modifications :

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

Pour vérifier si le trafic transite effectivement par le 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...
attention

Certains proxys effectuent une inspection SSL. Il peut être nécessaire d'installer les certificats CA de l'entreprise :

# 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

Dépôts Debian​

Les dépôts Debian sont des serveurs qui hébergent les paquets logiciels et les mises à jour pour les systèmes basés sur Debian. Dans les environnements d'entreprise isolés, l'accès aux miroirs Debian publics (comme deb.debian.org ou archive.ubuntu.com) peut être bloqué pour des raisons de sécurité. Les entreprises maintiennent souvent leurs propres miroirs internes afin de contrôler quels paquets sont disponibles et de réduire l'utilisation de la bande passante externe.

Test​

Vérifiez les dépôts actuellement configurés :

# 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

Voici un script bash complet permettant de tester entièrement la connectivité aux dépôts configurés :

# 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

Une autre méthode consiste à tenter de mettre à jour les listes de paquets afin d'identifier les problèmes de dépôt :

# Try to update package lists
sudo apt update

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

Messages d'erreur courants indiquant des dépôts bloqués :

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

Testez manuellement un serveur de dépôt spécifique :

# 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

Configuration​

Modifiez le fichier de sources principal :

sudo nano /etc/apt/sources.list

Remplacez le contenu par votre miroir interne. Pour 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 votre miroir interne utilise HTTPS :

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

Remarque : pour les dépôts HTTPS, assurez-vous que les paquets apt-transport-https et ca-certificates sont installés.

Configurer la priorité des dépôts (facultatif)

Si vous devez utiliser à la fois des dépôts internes et externes avec une préférence donnée aux dépôts internes :

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

Ajoutez :

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

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

Cela confère aux miroirs internes une priorité plus élevée.

Configurer un proxy pour les dépôts (facultatif)

Si votre réseau nécessite un proxy pour atteindre les dépôts :

# 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

Mettre à jour et vérifier

Après avoir configuré les dépôts :

# 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

Problèmes courants

Problème : apt update se bloque indéfiniment

# 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

Problème : paquets introuvables après la configuration du miroir

# 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

Problème : sources de dépôt mixtes provoquant des conflits

# 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