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

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

備考

SDA チームとのサポート通話の前に、セッション中の画面共有のために、お使いのコンピューターから 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