プロキシ DNS NTP設定の実践

Linuxエンジニア養成講座第18回｜全36回・フェーズ3「ネットワークとインフラ基盤」の3回目（3/12回目）です。
前回まで: 第16回でTCP/IPの基礎を学び、第17回でnmcliによるIP設定とalma-subとの疎通確認を体験しました。
今回学ぶこと: 3台目のVM（alma-proxy）が登場。企業ネットワークで使われるプロキシ・DNS・NTPの仕組みを理解し、クライアント側の設定を実践します。

この記事を読み終えると、以下のことができるようになります。

プロキシサーバーの役割を説明できる
/etc/environment でシステム全体のプロキシ設定を行える
dnf.conf の proxy= の意味を自分の言葉で説明できる（第7回の「おまじない」を回収）
nmcli で DNS サーバーを変更し、名前解決の向け先を切り替えられる
/etc/chrony.conf を編集して NTP サーバーを指定し、時刻同期状態を確認できる
alma-proxy の役割（Squid / dnsmasq / chrony）を概念レベルで理解できる

コンテンツ

alma-proxy へようこそ — 3台目VMの登場
プロキシとは何か — 企業がプロキシを使う理由
/etc/environment — システム全体のプロキシ設定
ヒヤリハット — 「no_proxy の設定漏れで社内システムにつながらない」
DNS の向け先を変える — dnsmasq
NTP — サーバーの時刻を合わせる
3つの設定をまとめて確認する
やってみよう — プロキシ・DNS・NTP の3設定を確認する
理解度チェック
まとめと次回予告
シリーズ一覧

alma-proxy へようこそ — 3台目VMの登場

企業ネットワークの「窓口」

ここまで alma-main と alma-sub の2台を使ってきました。今回から3台目の VM である alma-proxy が加わります。

企業のサーバーは、セキュリティ上の理由からインターネットに直接接続できないことがほとんどです。外部と通信するには、社内ネットワークの「窓口」となるサーバーを経由します。この窓口の役割を担うのが alma-proxy です。

alma-proxy は以下の3つのサービスを提供しています。

Squid（プロキシ） — インターネットへの HTTP/HTTPS 通信を中継する
dnsmasq（DNS） — ドメイン名から IP アドレスを解決する
chrony（NTP） — 正確な時刻を配信する

今回は alma-proxy の構築手順には踏み込みません。alma-proxy は事前に構築済みです。今回の目的は「クライアント側（alma-main）からこれらのサービスをどう利用するか」を学ぶことです。

今回の検証構成

今回使う3台の VM とネットワーク構成です。

検証環境の3台構成図。External SwitchとInternal Switchに接続されたalma-main、alma-sub、alma-proxyの位置関係とIPアドレス、alma-proxyが提供するサービス（Squid、dnsmasq、chrony）を示す

ホストPC（Windows）
  |
  +--- External Switch（外部スイッチ）
  |       |               |               |
  |    alma-main         alma-sub         alma-proxy
  |    eth0:192.168.1.121  eth0:192.168.1.122  eth0:192.168.1.123
  |
  +--- Internal Switch（内部スイッチ）
          |               |               |
       alma-main         alma-sub         alma-proxy
       eth1:10.0.1.1      eth1:10.0.1.3   eth1:10.0.1.254 ← 今回の通信先
       eth2:10.0.1.2                       eth2:10.0.2.254

alma-proxy の Internal 側 IP アドレスは 10.0.1.254 です。alma-main（10.0.1.1）と同じ 10.0.1.0/24 ネットワークに属しているため、Internal Switch 経由で直接通信できます。今回は、alma-main から alma-proxy の各サービスを利用するための設定を行います。

alma-proxy の稼働状態を確認する

まず alma-main から alma-proxy に疎通できるか確認します。

alma-mainで実行

実行コマンド：

$ ping -c 4 10.0.1.254

実行結果：

PING 10.0.1.254 (10.0.1.254) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.254: icmp_seq=1 ttl=64 時間=0.293ミリ秒
64 バイト応答 送信元 10.0.1.254: icmp_seq=2 ttl=64 時間=0.474ミリ秒
64 バイト応答 送信元 10.0.1.254: icmp_seq=3 ttl=64 時間=0.764ミリ秒
64 バイト応答 送信元 10.0.1.254: icmp_seq=4 ttl=64 時間=0.874ミリ秒

--- 10.0.1.254 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3072ms
rtt min/avg/max/mdev = 0.293/0.601/0.874/0.230 ms

0% packet loss で疎通が取れています。続いて alma-proxy にSSH接続し、3つのサービスが稼働しているか確認します。

alma-proxyで実行

alma-proxy への SSH 接続は、ホスト PC から 192.168.1.123 に接続します。接続したら、以下のコマンドでサービスの状態を確認します。

実行コマンド：

$ sudo systemctl is-active squid dnsmasq chronyd

実行結果：

active
active
active

3つとも active と表示されれば稼働中です。systemctl is-active は第13回で学んだ systemd のコマンドです。複数のサービス名をスペース区切りで並べると、まとめて状態を確認できます。

もしいずれかが inactive や failed と表示された場合は、sudo systemctl start サービス名 で起動してから先に進んでください。

次に、どのポートでサービスが待ち受けているか確認します。

alma-proxyで実行

実行コマンド：

$ sudo ss -tlnp

実行結果：

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      32        10.0.1.254:53        0.0.0.0:*    users:(("dnsmasq",pid=9605,fd=5))
LISTEN 0      32         127.0.0.1:53        0.0.0.0:*    users:(("dnsmasq",pid=9605,fd=7))
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=749,fd=3))
LISTEN 0      32             [::1]:53           [::]:*    users:(("dnsmasq",pid=9605,fd=9))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=749,fd=4))
LISTEN 0      4096               *:3128            *:*    users:(("squid",pid=1105,fd=11))

第12回で学んだ ss コマンドの出力です。ポートとサービスの対応を読み取ります。

ポート53（10.0.1.254:53） — dnsmasq（DNS）
ポート3128（*:3128） — squid（プロキシ）
ポート22 — sshd（SSH。今接続に使っているサービス）

NTP の chronyd はポートの待ち受けが UDP なので、TCP を表示する -t オプションでは出てきません。UDP 側も確認します。

alma-proxyで実行

実行コマンド：

$ sudo ss -ulnp

実行結果：

State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
UNCONN 0      0          127.0.0.1:53         0.0.0.0:*    users:(("dnsmasq",pid=9605,fd=6))
UNCONN 0      0         10.0.1.254:53         0.0.0.0:*    users:(("dnsmasq",pid=9605,fd=4))
UNCONN 0      0            0.0.0.0:123        0.0.0.0:*    users:(("chronyd",pid=714,fd=7))
UNCONN 0      0          127.0.0.1:323        0.0.0.0:*    users:(("chronyd",pid=714,fd=5))
UNCONN 0      0              [::1]:53            [::]:*    users:(("dnsmasq",pid=9605,fd=8))
UNCONN 0      0              [::1]:323           [::]:*    users:(("chronyd",pid=714,fd=6))

ポート123（0.0.0.0:123）で chronyd が待ち受けています。NTP は UDP プロトコルを使うため、UNCONN（UDP の待ち受け状態）として表示されます。ポート323 は chronyc コマンド用の管理ポートです。この他に Squid が内部で使用する UDP ポートが表示されることがありますが、プロキシの動作には影響ありません。

ここまでの確認で、alma-proxy には Squid（3128/tcp）、dnsmasq（53/tcp・udp）、chronyd（123/udp）の3つのサービスが稼働していることがわかりました。以降の作業は alma-main 側に戻って行います。

プロキシとは何か — 企業がプロキシを使う理由

プロキシ経由のリクエストの流れ

プロキシ（proxy）は「代理」という意味です。クライアント（alma-main）がインターネット上のサーバーに直接アクセスする代わりに、プロキシサーバー（alma-proxy）が代理でアクセスし、結果をクライアントに返します。

通信の流れを整理すると、次のようになります。

プロキシなし（直接通信）:
  alma-main  ─────────────────→  インターネット上のサーバー

プロキシあり（企業ネットワーク）:
  alma-main  ───→  alma-proxy  ───→  インターネット上のサーバー
             (1)               (2)
  (1) alma-main → alma-proxy: 「このURLにアクセスしてほしい」
  (2) alma-proxy → 外部サーバー: 代理でアクセス
  結果は逆の経路で alma-main に返る

企業がプロキシを使う主な理由は次の3つです。

アクセス制御 — 業務に不要なサイトへのアクセスを制限できる
ログの記録 — 誰がいつどのサイトにアクセスしたかを記録できる
セキュリティ — 内部サーバーのIPアドレスを外部に見せずに済む

ホワイトリスト方式（Squid の仕組み）

alma-proxy で稼働している Squid は「ホワイトリスト方式」で運用されています。ホワイトリストに登録されたドメインへの通信だけを許可し、それ以外はすべてブロックします。

この検証環境では、AlmaLinux のリポジトリ（mirrors.almalinux.org 等）や EPEL リポジトリなど、Linux の学習に必要なドメインが登録されています。一方、google.com のような一般的なサイトは登録されていないため、プロキシ経由ではアクセスできません。

この動作は企業ネットワークの現実に近いものです。業務サーバーから自由にインターネットにアクセスできる環境は少なく、必要なドメインだけが許可されているのが一般的です。

第7回の「おまじない」を解読する

第7回の冒頭で、以下の設定を「おまじない」として dnf.conf に追加しました。

alma-mainで実行

実行コマンド：

$ cat /etc/dnf/dnf.conf

実行結果：

[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
proxy=http://10.0.1.254:3128

最終行の proxy=http://10.0.1.254:3128 が、第7回で追加した設定です。この1行の意味を分解すると次のようになります。

proxy= — dnf がパッケージをダウンロードするときに使うプロキシサーバーを指定するオプション
http:// — プロトコル（HTTP で通信する）
10.0.1.254 — プロキシサーバーの IP アドレス（= alma-proxy の eth1）
:3128 — Squid のデフォルトポート番号

つまり「dnf がパッケージをダウンロードするとき、alma-proxy の Squid（ポート3128）を経由してインターネットに接続する」という意味でした。第7回以降、dnf install でパッケージをインストールできていたのは、この設定があったからです。

ただし、この設定は dnf 専用です。curl や wget など他のコマンドがインターネットに接続する場合、dnf.conf の設定は参照されません。システム全体でプロキシを使うには、別の設定が必要です。

/etc/environment — システム全体のプロキシ設定

設定の追加

/etc/environment はシステム全体の環境変数を定義するファイルです。ここにプロキシの環境変数を設定すると、ログイン時にすべてのユーザーに反映されます。

alma-mainで実行

実行コマンド：

$ sudo vi /etc/environment

以下の3行を追加します。

http_proxy=http://10.0.1.254:3128
https_proxy=http://10.0.1.254:3128
no_proxy=localhost,127.0.0.1,10.0.1.0/24

各行の意味は次のとおりです。

http_proxy — HTTP 通信で使うプロキシ
https_proxy — HTTPS 通信で使うプロキシ（HTTPS でも、プロキシとの接続自体は HTTP で行うため、値は http:// で始まる）
no_proxy — プロキシを経由しない宛先（後述）

反映確認（新しいSSHセッションで確認）

/etc/environment の設定は、ログイン時に読み込まれます。そのため、現在のSSHセッションにはまだ反映されていません。新しいSSHセッションを開いて確認します。

ホストPCから alma-main（192.168.1.121）へ新しい SSH 接続を開いてください。既存のセッションはそのまま残しておいて構いません。

alma-mainで実行（新しいSSHセッション）

実行コマンド：

$ echo $http_proxy

実行結果：

http://10.0.1.254:3128

環境変数 http_proxy が設定されていれば成功です。

よくある間違い — source /etc/environment は効かない

source /etc/environment で現在のセッションに反映しようとする人がいますが、/etc/environment は export 文を含まない単純な「変数=値」形式のファイルです。source しても環境変数として export されません。必ず新しい SSH セッションを開いて反映を確認してください。

次に、curl コマンドでプロキシ経由の通信が動作するか試します。

alma-mainで実行（新しいSSHセッション）

実行コマンド：

$ curl -s -o /dev/null -w "%{http_code}" http://mirrors.almalinux.org/

実行結果：

HTTP ステータスコード 301（リダイレクト）が返ってきました。これは正常な応答です。curl が http_proxy 環境変数を参照し、alma-proxy の Squid を経由して外部サイトにアクセスできています。

curl のオプションの意味を確認しておきます。

-s — 進捗表示を非表示にする（silent）
-o /dev/null — レスポンス本文を捨てる
-w "%{http_code}" — HTTP ステータスコードだけを表示する

このように /etc/environment にプロキシを設定しておくと、dnf だけでなく curl など多くのコマンドがプロキシを利用できるようになります。

no_proxy の重要性

no_proxy は「プロキシを経由しない宛先」を指定する環境変数です。先ほど設定した値をもう一度確認します。

no_proxy=localhost,127.0.0.1,10.0.1.0/24

localhost — 自分自身へのアクセス
127.0.0.1 — ループバックアドレス
10.0.1.0/24 — Internal Switch 上の VM 同士の通信

これらの宛先はすべて社内（検証環境内）の通信です。プロキシを経由する必要がないのに経由してしまうと、通信が遅くなったり、プロキシサーバーに不要な負荷がかかったりします。さらに、Squid はホワイトリスト方式で運用しているため、内部通信がプロキシを経由すると「ホワイトリストに登録されていない」としてブロックされる可能性があります。

ヒヤリハット — 「no_proxy の設定漏れで社内システムにつながらない」

現場のヒヤリハット

ある新人エンジニアが、新規サーバーにプロキシ設定を入れたところ「社内の監視サーバーに接続できない」という障害が発生しました。原因は no_proxy に社内ネットワーク（10.x.x.x）を含めていなかったことでした。

プロキシ設定が入っていると、OS は通信先の IP アドレスやドメインを no_proxy と照合し、一致しなければすべてプロキシ経由で送ろうとします。社内の監視サーバーへの通信もプロキシに送られ、プロキシ側で「宛先不明」としてエラーになりました。

http_proxy と https_proxy を設定するときは、no_proxy を必ずセットで設定するのが鉄則です。

DNS の向け先を変える — dnsmasq

nmcli で DNS を alma-proxy に向ける

現在の alma-main の DNS 設定を確認します。

alma-mainで実行

実行コマンド：

$ cat /etc/resolv.conf

実行結果：

# Generated by NetworkManager
nameserver 192.168.1.1

nameserver 192.168.1.1 は、ホスト PC のルーター（デフォルトゲートウェイ）を DNS サーバーとして使っている状態です。この設定でもインターネット上のドメイン名は解決できますが、企業ネットワークでは社内専用の DNS サーバーを使うのが一般的です。社内だけで使うドメイン（例: intra.example.corp）は外部の DNS サーバーでは解決できないためです。

DNS の向け先を alma-proxy（10.0.1.254）に変更します。第17回で学んだ nmcli を使います。

alma-mainで実行

実行コマンド：

$ sudo nmcli connection modify eth0 ipv4.dns 10.0.1.254

設定を反映するために、接続を再アクティベートします。

実行コマンド：

$ sudo nmcli connection up eth0

実行結果：

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/6)

反映されたか確認します。

実行コマンド：

$ cat /etc/resolv.conf

実行結果：

# Generated by NetworkManager
nameserver 10.0.1.254

nameserver が 10.0.1.254 に変わっていれば成功です。/etc/resolv.conf は NetworkManager が自動生成するファイルなので、直接編集するのではなく nmcli 経由で変更します。これは第17回で学んだポイントの復習です。

dnsmasq とは何か

alma-proxy で稼働している dnsmasq は、軽量な DNS フォワーダーです。クライアントからの名前解決リクエストを受け取り、次のように処理します。

自分が知っているドメイン → 自分で応答する
知らないドメイン → 上位の DNS サーバー（インターネット上の DNS）に問い合わせて、結果を返す

企業ネットワークの DNS も同じ仕組みです。社内ドメイン（例: mail.corp.local）は自前で応答し、外部ドメイン（例: google.com）は上位 DNS に転送します。

名前解決の動作を確認する

まず、外部ドメインが解決できるか確認します。名前解決の確認には nslookup コマンドを使います。nslookup は bind-utils パッケージに含まれるコマンドで、Minimal Install には含まれていませんが、この検証環境には導入済みです。未導入の場合は sudo dnf install -y bind-utils でインストールしてください。

alma-mainで実行

実行コマンド：

$ nslookup google.com

実行結果：

Server:		10.0.1.254
Address:	10.0.1.254#53

Non-authoritative answer:
Name:	google.com
Address: 142.251.118.101
Name:	google.com
Address: 142.251.118.139
Name:	google.com
Address: 142.251.118.138
（以下略）

Server: 10.0.1.254 と表示されているので、alma-proxy の dnsmasq を経由して名前解決が行われています。IP アドレスの値はタイミングによって異なることがありますが、Server 行が 10.0.1.254 であれば正常です。

次に、dnsmasq に登録されている模擬社内ドメインを引いてみます。

alma-mainで実行

実行コマンド：

$ nslookup ntp.example.corp

実行結果：

Server:		10.0.1.254
Address:	10.0.1.254#53

Name:	ntp.example.corp
Address: 10.0.1.254

ntp.example.corp は dnsmasq に登録されている模擬社内ドメインで、alma-proxy 自身（10.0.1.254）に解決されます。このドメインはインターネット上には存在しません。DNS の向け先がルーター（192.168.1.1）のままだったら解決できなかったはずです。

企業ネットワークでは、このように社内サーバーに独自のドメイン名を付けて DNS で管理するのが一般的です。ntp.example.corp という名前で NTP サーバーにアクセスできれば、IP アドレスを覚える必要がなくなります。

NTP — サーバーの時刻を合わせる

なぜ時刻合わせが大事か

サーバーの時刻がずれていると、以下のような問題が起きます。

ログの時刻がずれる — 障害発生時にログの時系列を追えなくなる。複数サーバーのログを突き合わせるとき、時刻がずれていると原因究明が困難になる
認証が失敗する — Kerberos 認証や TLS 証明書の検証は、時刻のずれが一定以上あると失敗する
cron の実行タイミングがずれる — バックアップや定期処理が想定外の時刻に動く

NTP（Network Time Protocol）は、ネットワーク経由で正確な時刻を取得するプロトコルです。AlmaLinux では chronyd が NTP クライアント（兼サーバー）として標準でインストールされています。

現在の NTP 設定を確認する

まず、現在どの NTP サーバーから時刻を取得しているか確認します。

alma-mainで実行

実行コマンド：

$ chronyc sources

実行結果：

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* y.ns.gin.ntt.net              2  10    17    10   +598us[ +695us] +/-   87ms

現在はインターネット上の NTP サーバー（y.ns.gin.ntt.net）から時刻を取得しています。出力の読み方を確認します。

^* — 先頭の記号。^ はサーバーモード、* は「現在同期中の参照元」を意味する
Stratum — 時刻源からの階層。数値が小さいほど正確。原子時計が Stratum 0、それを直接参照するサーバーが Stratum 1
Last sample — 最後に測定した時刻のずれ

設定ファイルも確認します。

実行コマンド：

$ grep "^server" /etc/chrony.conf

実行結果：

server y.ns.gin.ntt.net iburst

server 行が NTP の参照先です。iburst は初回接続時に素早く同期するためのオプションです。

chrony の設定変更

企業ネットワークでは、各サーバーが個別にインターネット上の NTP サーバーに接続するのではなく、社内の NTP サーバーから時刻を取得するのが一般的です。参照先を alma-proxy（10.0.1.254）に変更します。

alma-mainで実行

実行コマンド：

$ sudo vi /etc/chrony.conf

既存の server 行（server y.ns.gin.ntt.net iburst）を以下のように変更します。vi の操作が不安な場合は第9回を振り返ってください。

server 10.0.1.254 iburst

変更を保存したら、chronyd を再起動します。

実行コマンド：

$ sudo systemctl restart chronyd

設定が反映されたか確認します。再起動直後は新しいサーバーとの同期が完了していないため、30秒〜1分ほど待ってから確認してください。

実行コマンド：

$ grep "^server" /etc/chrony.conf

実行結果：

server 10.0.1.254 iburst

続いて、実際に alma-proxy から時刻を取得できているか確認します。

実行コマンド：

$ chronyc sources

実行結果：

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.0.1.254                    3   6    17    13    -31us[  -62us] +/-   79ms

^* が表示されていれば、alma-proxy と同期できています。Stratum が 3 なのは、alma-proxy 自身が Stratum 2 のサーバーから時刻を取得しており、その1つ下の階層（Stratum 3）として動作しているためです。

Reach の値について

Reach 列は直近8回の通信の成否を8進数で表したものです。17 は8進数で 001 111（直近4回成功）を意味します。再起動直後はまだ試行回数が少ないため小さい値になりますが、時間が経つと 377（8回すべて成功）に近づきます。

同期状態の詳細確認

chronyc tracking で、より詳細な同期状態を確認できます。

alma-mainで実行

実行コマンド：

$ chronyc tracking

実行結果：

Reference ID    : 0A0001FE (10.0.1.254)
Stratum         : 4
Ref time (UTC)  : Thu Apr 02 05:10:00 2026
System time     : 0.000000828 seconds slow of NTP time
Last offset     : -0.000031475 seconds
RMS offset      : 0.000031475 seconds
Frequency       : 18.678 ppm fast
Residual freq   : -1.579 ppm
Skew            : 0.252 ppm
Root delay      : 0.128907636 seconds
Root dispersion : 0.015052599 seconds
Update interval : 2.0 seconds
Leap status     : Normal

注目すべき行は次のとおりです。

Reference ID: 0A0001FE (10.0.1.254) — 参照先が alma-proxy であること
Stratum: 4 — alma-main は Stratum 4 として動作（alma-proxy の1つ下）
System time: 0.000000828 seconds slow — 時刻のずれがマイクロ秒単位で、ほぼ正確に同期できている
Leap status: Normal — うるう秒に関する異常なし

最後に timedatectl でシステム全体の時刻情報を確認します。

実行コマンド：

$ timedatectl

実行結果：

               Local time: 木 2026-04-02 14:10:21 JST
           Universal time: 木 2026-04-02 05:10:21 UTC
                 RTC time: 木 2026-04-02 05:10:20
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

System clock synchronized: yes — NTP と同期済み
NTP service: active — chronyd が動作中
Time zone: Asia/Tokyo (JST, +0900) — タイムゾーンが正しく設定されている

chronyc の詳しいオプションは man chronyc で確認できます。chronyc sources -v のように -v オプションを付けると、列の意味を示すヘッダーが追加表示されます。

3つの設定をまとめて確認する

今回設定した3つの項目を一覧で整理します。

設定項目	設定ファイル / コマンド	向け先	確認コマンド
プロキシ（dnf）	/etc/dnf/dnf.conf	http://10.0.1.254:3128	cat /etc/dnf/dnf.conf
プロキシ（システム全体）	/etc/environment	http://10.0.1.254:3128	echo $http_proxy
DNS	nmcli connection modify	10.0.1.254	cat /etc/resolv.conf
NTP	/etc/chrony.conf	10.0.1.254	chronyc sources

すべての向け先が 10.0.1.254（alma-proxy）になっています。企業ネットワークでも、プロキシ・DNS・NTP を同一のサーバー（またはサーバー群）が担当する構成はよくあります。

この設定は第19回以降もそのまま維持します。以降の回では alma-proxy が起動している前提で演習を行います。

やってみよう — プロキシ・DNS・NTP の3設定を確認する

以下の演習で、今回学んだ設定がすべて正しく反映されているか確認してください。

課題1: プロキシ設定の確認

/etc/dnf/dnf.conf を表示し、proxy= 行が http://10.0.1.254:3128 であることを確認する
echo $http_proxy で環境変数が設定されていることを確認する（値が空の場合は新しいSSHセッションを開く）
echo $no_proxy で no_proxy に 10.0.1.0/24 が含まれていることを確認する

課題2: DNS 設定の確認

cat /etc/resolv.conf で nameserver が 10.0.1.254 であることを確認する
nslookup google.com で Server が 10.0.1.254 と表示されることを確認する
nslookup ntp.example.corp で 10.0.1.254 に解決されることを確認する

課題3: NTP 設定の確認

grep "^server" /etc/chrony.conf で参照先が 10.0.1.254 であることを確認する
chronyc sources で ^*（同期中）マークが付いていることを確認する
timedatectl で System clock synchronized: yes であることを確認する

課題4（チャレンジ）: dnf repolist の確認

sudo dnf repolist を実行し、リポジトリ一覧が表示されることを確認してください。このコマンドは alma-proxy の Squid 経由でリポジトリのメタデータを取得します。正常に表示されれば、プロキシ設定が正しく機能しています。

alma-mainで実行

実行コマンド：

$ sudo dnf repolist

実行結果：

repo id                          repo の名前
appstream                        AlmaLinux 9 - AppStream
baseos                           AlmaLinux 9 - BaseOS
extras                           AlmaLinux 9 - Extras

3つのリポジトリが表示されれば成功です。

理解度チェック

○×で答えてください。

Q1. プロキシサーバーは、クライアントの代わりにインターネット上のサーバーにアクセスする「代理」の役割を持つ。

Q2. /etc/dnf/dnf.conf の proxy= 設定は、curl や wget でも自動的に参照される。

Q3. /etc/environment を編集した後、現在のSSHセッションですぐに反映される。

Q4. no_proxy に社内ネットワークのアドレスを設定しないと、社内通信もプロキシ経由になってしまう。

Q5. /etc/resolv.conf を直接 vi で編集すると、NetworkManager が上書きして元に戻ってしまうことがある。

Q6. NTP の Stratum の数値が小さいほど、時刻源に近い（正確な）サーバーである。

Q7. サーバーの時刻がずれていても、ログの内容には影響しない。

答え合わせ

Q1. ○ — プロキシ（proxy）は「代理」の意味です。クライアントの通信を中継します。

Q2. × — dnf.conf の proxy= は dnf 専用の設定です。curl や wget は /etc/environment の http_proxy 環境変数を参照します。

Q3. × — /etc/environment はログイン時に読み込まれるため、新しいSSHセッションを開く必要があります。

Q4. ○ — no_proxy に含まれない宛先はすべてプロキシ経由になります。社内通信が失敗する原因になります。

Q5. ○ — resolv.conf は NetworkManager が自動生成します。DNS の変更は nmcli 経由で行います。

Q6. ○ — Stratum 0 が原子時計、Stratum 1 がそれを直接参照するサーバーです。数値が小さいほど正確です。

Q7. × — ログのタイムスタンプがずれると、障害発生時にログの時系列が追えなくなります。複数サーバー間のログ突き合わせが困難になる深刻な問題です。

まとめと次回予告

今回は3台目のVM（alma-proxy）を使って、企業ネットワークにおけるプロキシ・DNS・NTPのクライアント設定を実践しました。

特に覚えておいてほしいのは次の3点です。

http_proxy / https_proxy を設定するときは、no_proxy を必ずセットで設定する
/etc/resolv.conf は直接編集せず、nmcli 経由で DNS を変更する
NTP の設定変更後は chronyc sources で ^* マークを確認する

第7回で「おまじない」として追加した proxy=http://10.0.1.254:3128 の正体は、alma-proxy の Squid を経由してパッケージをダウンロードするための設定でした。意味がわからないまま設定するのと、仕組みを理解した上で設定するのとでは、トラブル時の対応力が大きく変わります。

各コマンドのオプションを詳しく知りたい場合は man chronyc、man chrony.conf、man nmcli で確認できます。

次回の第19回「パッケージ管理」では、dnf の仕組みをより深く学びます。プロキシ経由での EPEL リポジトリ導入、GPG 鍵によるパッケージの信頼性検証、リポジトリの管理方法を実践します。今回設定したプロキシが、パッケージのダウンロード経路として活きてきます。

シリーズ一覧

フェーズ1: エンジニアのいろは（第1回〜第3回）

フェーズ2: Linux基礎（第4回〜第15回）

フェーズ3: ネットワークとインフラ基盤（第16回〜第27回）

フェーズ4: サーバー構築と運用（第28回〜第36回）