Zum Hauptinhalt springen

Konfiguration von Linux-Gateways in Produktionsnetzwerken

Dieser Leitfaden behandelt einige grundlegende Netzwerkkonfigurationsparameter, die dazu führen können, dass ein Linux-System aufgrund der isolierten Infrastruktur in einer Produktionsumgebung nicht funktioniert. Beachten Sie, dass Linux-Distributionen für die folgenden Themen unterschiedliche Dienste verwenden können. Daher kann es sein, dass Sie einige der unten aufgeführten Befehle nicht ausführen können. Dieser Abschnitt wurde am Beispiel eines Raspberry Pi mit natives Debian 12 (bookworm) als Betriebssystemversion erstellt.

Info

Stellen Sie vor Ihrem Support-Gespräch mit dem SDA-Team sicher, dass Sie von Ihrem Computer aus SSH-Zugriff auf das Linux-Gerät haben, um während der Sitzung den Bildschirm teilen zu können.

Im Folgenden finden Sie eine Liste häufiger Bereiche, die eine Verbindung verhindern können.

DNS-Server​

Ein Domain Name System (DNS)-Server löst Domainnamen in IP-Adressen auf, um die Kommunikation über das Internet zu ermöglichen. Eine korrekte DNS-Konfiguration ist für ein Linux-System, das in einer Netzwerkumgebung betrieben wird, entscheidend. Zur Fehlersuche bei DNS-Problemen gehört die Prüfung der Erreichbarkeit des DNS-Servers mit Befehlen wie ping oder nslookup. Stellen Sie sicher, dass der Server antwortet und Domainnamen korrekt in IP-Adressen auflöst. Fehlkonfigurationen können dazu führen, dass die Domainauflösung fehlschlägt, was die Netzwerkkommunikation und den Internetzugang beeinträchtigt.

Test​

Prüfen Sie die auf dem Host konfigurierten DNS-Server-IPs mit:

cat /etc/resolv.conf

Jeder DNS-Server kann einzeln mit nslookup oder dig getestet werden. Beispiel, wenn der Server 8.8.8.8 ist:

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

Wenn diese Befehle nicht vorhanden sind, können sie in Debian entweder mit den Paketen dnsutils oder bind9-dnsutils installiert werden, oder es kann ein nativer Befehl wie ping oder getent verwendet werden, um die aktuelle DNS-Konfiguration zu testen:

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

Konfiguration​

Die DNS-Server können je nach Linux-Installation von unterschiedlichen Diensten verwaltet werden. Bei einem Raspberry Pi wird dies typischerweise vom Dienst NetworkManager übernommen. Der Dienst, der die DNS-Auflösung verwaltet, hinterlässt in /etc/resolv.conf wahrscheinlich einen Kommentar, der darauf hinweist, dass er die Datei erzeugt hat, zum Beispiel:

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

Um die globalen DNS-Server festzulegen, erstellen Sie die Datei:

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

Und fügen Sie hinzu:

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

Starten Sie den Dienst NetworkManager neu und prüfen Sie die neuen Werte in /etc/resolv.conf

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

NTP-Server​

Ein Network Time Protocol (NTP)-Server wird in Linux-Systemen verwendet, um die Systemuhr mit einer Zeitquelle zu synchronisieren, etwa einer Atomuhr oder einem zentralen Server. Eine genaue Zeitführung ist für Protokollierung, Sicherheitsprotokolle und die Koordination von Aktionen über ein Netzwerk hinweg entscheidend. Eine falsche Einrichtung eines NTP-Servers führt dazu, dass HTTPS-Aufrufe aufgrund ungültiger SSL-Zertifikate fehlschlagen.

Test​

Prüfen Sie den Status der NTP-Synchronisierung sowie, ob das aktuelle Datum und die aktuelle Uhrzeit korrekt sind.

# 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 der Verbindung zu einem bestimmten Server:

# 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

Konfiguration​

Der NTP-Server kann mit einem Domainnamen wie 0.debian.pool.ntp.org oder ntp.myorg.com oder direkt mit einer IP-Adresse konfiguriert werden.

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

Fügen Sie den benutzerdefinierten NTP-Server im Block [Time] hinzu und stellen Sie sicher, dass die Zeile nicht auskommentiert ist. Entfernen Sie alle Server in FallbackNTP, die nicht erreichbar sind.

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

Starten Sie den Dienst timesync neu und stellen Sie sicher, dass er aktiviert ist.

# 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

Proxy-Server​

Ein Proxy-Server fungiert als Vermittler zwischen einem Client und Zielservern und leitet Anfragen und Antworten weiter. In Unternehmensumgebungen werden Proxy-Server häufig für Sicherheitskontrolle, Inhaltsfilterung, Bandbreitenmanagement und die Protokollierung des ausgehenden Datenverkehrs eingesetzt. Linux-Systeme in solchen Netzwerken müssen so konfiguriert werden, dass sie ihre HTTP/HTTPS-Anfragen über den Unternehmens-Proxy leiten, um auf externe Ressourcen wie Paket-Repositories und Webdienste zugreifen zu können.

Test​

Prüfen Sie, ob derzeit ein Proxy konfiguriert ist, indem Sie die Umgebungsvariablen und die systemweiten Proxy-Einstellungen kontrollieren:

# 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

Um zu prüfen, ob ein Proxy-Server erforderlich ist, versuchen Sie, sich direkt mit einem externen Server zu verbinden:

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

Schlägt dies mit Verbindungsfehlern fehl, ist möglicherweise ein Proxy erforderlich. Häufige Fehler sind zum Beispiel Failed to connect oder Connection timed out.

So testen Sie eine Anfrage mit einem bestimmten Proxy-Server:

# 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

Konfiguration​

Info

Eine Proxy-Adresse hat eines der folgenden Formate:

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

Konfigurieren Sie den Proxy für alle Benutzer und Anwendungen:

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

Fügen Sie die folgenden Zeilen hinzu oder ändern Sie sie:

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"

Übernehmen Sie die Änderungen:

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

So prüfen Sie, ob der Datenverkehr tatsächlich über den Proxy läuft:

# 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...
warnung

Einige Proxys führen eine SSL-Inspektion durch. Möglicherweise müssen Sie die CA-Zertifikate des Unternehmens installieren:

# 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

Debian-Repositories​

Debian-Repositories sind Server, die Softwarepakete und Updates für Debian-basierte Systeme bereitstellen. In isolierten Unternehmensumgebungen kann der Zugriff auf öffentliche Debian-Mirrors (wie deb.debian.org oder archive.ubuntu.com) aus Sicherheitsgründen gesperrt sein. Unternehmen betreiben häufig eigene interne Mirrors, um zu steuern, welche Pakete verfügbar sind, und um die externe Bandbreitennutzung zu reduzieren.

Test​

Prüfen Sie die derzeit konfigurierten Repositories:

# 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

Hier ist ein umfassendes Bash-Skript, um die Konnektivität zu den konfigurierten Repositories vollständig zu testen:

# 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

Eine weitere Methode besteht darin, zu versuchen, die Paketlisten zu aktualisieren, um Repository-Probleme zu erkennen:

# Try to update package lists
sudo apt update

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

Häufige Fehlermeldungen, die auf gesperrte Repositories hinweisen:

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

Testen Sie einen bestimmten Repository-Server manuell:

# 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

Konfiguration​

Bearbeiten Sie die Haupt-Sources-Datei:

sudo nano /etc/apt/sources.list

Ersetzen Sie den Inhalt durch Ihren internen Mirror. Für 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

Wenn Ihr interner Mirror HTTPS verwendet:

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

Hinweis: Stellen Sie bei HTTPS-Repositories sicher, dass die Pakete apt-transport-https und ca-certificates installiert sind.

Repository-Priorität konfigurieren (optional)

Wenn Sie sowohl interne als auch externe Repositories verwenden müssen, wobei interne bevorzugt werden sollen:

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

Fügen Sie hinzu:

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

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

Damit erhalten interne Mirrors eine höhere Priorität.

Proxy für Repositories konfigurieren (optional)

Wenn Ihr Netzwerk einen Proxy benötigt, um Repositories zu erreichen:

# 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

Aktualisieren und Überprüfen

Nach der Konfiguration der Repositories:

# 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

Häufige Probleme

Problem: apt update hängt unbegrenzt

# 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

Problem: Pakete werden nach der Konfiguration des Mirrors nicht gefunden

# 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

Problem: Gemischte Repository-Quellen verursachen Konflikte

# 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