本番ネットワークにおける Linux ゲートウェイの構成

本ガイドでは、隔離されたインフラストラクチャが原因で Linux システムが本番環境で動作しなくなる可能性のある、基本的なネットワーク構成パラメータのいくつかを説明します。Linux ディストリビューションによって以下のトピックに使用するサービスが異なる場合があることにご注意ください。そのため、以下に示すコマンドの一部は実行できない可能性があります。本セクションは、ネイティブの Debian 12 (bookworm) OS バージョンを搭載した Raspberry Pi を例として記述されています。

備考

SEW チームとのサポート通話の前に、セッション中の画面共有のために、お使いのコンピュータから Linux デバイスへ SSH アクセスできることを確認してください。

以下は、接続を妨げる可能性がある一般的な領域の一覧です。

• DNS サーバー
• NTP サーバー
• プロキシサーバー

DNS サーバー

Domain Name System (DNS) サーバーは、インターネット経由の通信を可能にするためにドメイン名を IP アドレスへ解決します。ネットワーク環境で動作する Linux システムにとって、適切な DNS 構成は極めて重要です。DNS 問題のトラブルシューティングでは、ping や nslookup などのコマンドを使用して DNS サーバーへの到達性を確認します。サーバーが応答し、ドメイン名を IP アドレスへ正しく解決していることを確認してください。構成の誤りはドメイン解決の失敗につながり、ネットワーク通信やインターネットアクセスに影響します。

テスト

ホストに構成されている DNS サーバーの IP を次のコマンドで確認します。

cat /etc/resolv.conf

各 DNS サーバーは nslookup または dig で個別にテストできます。例えば、サーバーが 8.8.8.8 の場合:

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

これらのコマンドが存在しない場合は、Debian では dnsutils または bind9-dnsutils パッケージでインストールできます。あるいは、ping や getent などのネイティブコマンドを使用して現在の DNS 構成をテストすることもできます。

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

構成

DNS サーバーは、Linux のインストール状況に応じて異なるサービスによって管理される場合があります。Raspberry Pi の場合、通常は NetworkManager サービスによって管理されます。DNS 解決を管理しているサービスは、次のように、そのファイルを生成したことを示すコメントを /etc/resolv.conf に残すことが多いです。

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

NetworkManager

グローバル DNS サーバーを設定するには、次のファイルを作成します。

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

そして以下を追加します。

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

NetworkManager サービスを再起動し、/etc/resolv.conf で新しい値を確認します。

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

dhcpcd

sudo nano /etc/dhcpcd.conf

ファイルの末尾に以下を追加または変更します。

# Static DNS configuration
static domain_name_servers=8.8.8.8 4.4.4.4

dhcpcd サービスを再起動して変更を適用し、DNS サーバーが更新されたか確認します。

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

resolvconf

resolvconf が利用可能かどうかを確認するには:

which resolvconf
dpkg -l | grep resolvconf

ベース構成を編集して、resolvconf 経由で DNS サーバーを構成します。

# Edit the base configuration
sudo nano /etc/resolvconf/resolv.conf.d/head

以下を追加します。

nameserver 8.8.8.8
nameserver 4.4.4.4

resolvconf サービスを更新し、DNS サーバーが更新されたかどうかを確認します。

sudo resolvconf -u
# Verify /etc/resolv.conf was updated
cat /etc/resolv.conf

NTP サーバー

Network Time Protocol (NTP) サーバーは、Linux システムにおいてシステムクロックを原子時計や中央サーバーなどの時刻ソースと同期させるために使用されます。正確な時刻管理は、ロギング、セキュリティプロトコル、およびネットワーク全体での動作の調整において不可欠です。NTP サーバーの設定が誤っていると、SSL 証明書が無効と判定され、HTTPS 呼び出しが失敗します。

テスト

NTP 同期状態と、現在の日付および時刻が正しいかを確認します。

# 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

特定のサーバーへの接続テスト:

# 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

構成

NTP サーバーは、0.debian.pool.ntp.org や ntp.myorg.com などのドメイン名、または直接 IP アドレスで構成できます。

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

[Time] ブロックにカスタム NTP サーバーを追加し、その行がコメントアウトされていないことを確認します。到達できない FallbackNTP のサーバーは削除してください。

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

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

プロキシサーバー

プロキシサーバーは、クライアントと宛先サーバーの間の仲介役として機能し、リクエストとレスポンスを転送します。企業環境では、プロキシサーバーはセキュリティ制御、コンテンツフィルタリング、帯域幅管理、および外向きトラフィックのロギングのために一般的に使用されます。このようなネットワーク内の Linux システムは、パッケージリポジトリや Web サービスを含む外部リソースへアクセスするために、HTTP/HTTPS リクエストを企業プロキシ経由でルーティングするように構成する必要があります。

テスト

環境変数とシステム全体のプロキシ設定を確認して、現在プロキシが構成されているかを確認します。

# 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

プロキシサーバーが必要かどうかを確認するには、外部サーバーへ直接接続を試みます。

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

接続エラーで失敗する場合は、プロキシが必要な可能性があります。一般的なエラーは、例えば Failed to connect や Connection timed out です。

特定のプロキシサーバーでリクエストをテストする方法:

# 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

構成

備考

プロキシアドレスは次のいずれかの形式です。

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

すべてのユーザーとアプリケーションに対してプロキシを構成します。

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

以下の行を追加または変更します。

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"

変更を適用します。

# Reload environment (or log out and back in)
source /etc/environment
# Verify variables are set
env | grep -i 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...

警告

一部のプロキシは SSL インスペクションを実行します。企業の CA 証明書のインストールが必要になる場合があります。

# 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 リポジトリ

Debian リポジトリは、Debian ベースのシステム向けのソフトウェアパッケージと更新をホストするサーバーです。隔離された企業環境では、セキュリティ上の理由から、パブリックな Debian ミラー (deb.debian.org や archive.ubuntu.com など) へのアクセスがブロックされている場合があります。企業は、利用可能なパッケージを管理し、外部帯域幅の使用を削減するために、独自の内部ミラーを運用することがよくあります。

テスト

現在構成されているリポジトリを確認します。

# 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

以下は、構成済みリポジトリへの接続性を包括的にテストする bash スクリプトです。

# 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

もう一つの方法は、パッケージリストの更新を試みてリポジトリの問題を特定することです。

# Try to update package lists
sudo apt update

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

リポジトリがブロックされていることを示す一般的なエラーメッセージ:

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

特定のリポジトリサーバーを手動でテストします。

# 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

構成

メインの sources ファイルを編集します。

sudo nano /etc/apt/sources.list

内容を内部ミラーに置き換えます。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

内部ミラーが HTTPS を使用する場合:

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

注: HTTPS リポジトリの場合は、apt-transport-https および ca-certificates パッケージがインストールされていることを確認してください。

リポジトリの優先度の構成 (任意)

内部と外部の両方のリポジトリを使用し、内部を優先する必要がある場合:

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

以下を追加します。

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

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

これにより、内部ミラーの優先度が高くなります。

リポジトリ用プロキシの構成 (任意)

ネットワークがリポジトリへ到達するためにプロキシを必要とする場合:

# 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

更新と検証

リポジトリを構成した後:

# 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

よくある問題

問題: apt update が無期限にハングする

# 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

問題: ミラーを構成した後にパッケージが見つからない

# 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

問題: リポジトリソースの混在による競合

# 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