AlmaLinux 10 総合ガイド
第6章: ネットワーク設定と時刻同期
サーバーの存在価値は「ネットワーク越しにサービスを提供すること」にあります。どれだけ高性能なサーバーでも、ネットワークに繋がっていなければ単なる電気を消費する箱に過ぎません。この章では、サーバーをネットワークに接続し、外部と安全に通信するための設定を学びます。
また、見落とされがちですが極めて重要な「時刻同期」についても解説します。時刻がズレているサーバーは、ログの整合性が取れない、SSL証明書の検証に失敗する、認証システムが動作しないなど、深刻な問題を引き起こします。
6.1 ネットワークの基礎知識
まず、ネットワーク設定を行う前に、基本的な概念を押さえておきましょう。深い理論は専門書に譲りますが、実務で必要な最低限の知識を身につけます。
6.1.1 TCP/IPの階層モデル
インターネットの通信は、TCP/IPというプロトコル(通信規約)の集合体で実現されています。これは4つの階層に分かれています。
| 階層 | 役割 | 主なプロトコル | 例え |
|---|---|---|---|
| アプリケーション層 | 具体的なサービスの提供 | HTTP, SSH, DNS, SMTP | 手紙の内容 |
| トランスポート層 | 通信の信頼性確保 | TCP, UDP | 書留か普通郵便か |
| インターネット層 | ネットワーク間のルーティング | IP, ICMP | 住所と配送経路 |
| ネットワークインターフェース層 | 物理的な通信 | Ethernet, Wi-Fi | 道路やトラック |
サーバー管理者として特に重要なのは、インターネット層(IPアドレス、ルーティング)とトランスポート層(TCP/UDP、ポート番号)です。トラブルシューティングの際、「どの階層で問題が起きているか」を切り分けることが解決への近道となります。
6.1.2 IPアドレスとは(IPv4, IPv6)
IPアドレスは、ネットワーク上のコンピュータを識別するための番号です。現在、2種類のIPアドレスが使われています。
IPv4(Internet Protocol version 4)
最も広く使われているアドレス形式です。32ビットの数値を、8ビットずつ4つに区切り、10進数で表記します。
例: 192.168.1.100
各数値は0〜255の範囲
192 . 168 . 1 . 100
↑ ↑ ↑ ↑
8bit 8bit 8bit 8bit = 32bit
IPv6(Internet Protocol version 6)
IPv4のアドレス枯渇に対応するため策定された新しい形式です。128ビットの数値を、16ビットずつ8つに区切り、16進数で表記します。
例: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
省略形: 2001:db8:85a3::8a2e:370:7334
(連続する0000は::で省略可能)
本ガイドでは、現在も主流であるIPv4を中心に解説します。IPv6は「存在する」ことを知っておけば、当面は十分です。
6.1.3 サブネットマスクとCIDR表記
IPアドレスは、ネットワーク部とホスト部に分かれています。サブネットマスクは、この境界を示すものです。
IPアドレス: 192.168.1.100
サブネットマスク: 255.255.255.0
ネットワーク部: 192.168.1 (同じネットワークに属する機器は同じ値)
ホスト部: .100 (同じネットワーク内で機器を識別)
CIDR(サイダー)表記は、サブネットマスクをより簡潔に表す方法です。ネットワーク部のビット数を「/」の後ろに記述します。
| サブネットマスク | CIDR表記 | 使用可能ホスト数 | 用途例 |
|---|---|---|---|
| 255.255.255.0 | /24 | 254台 | 一般的なLAN |
| 255.255.255.128 | /25 | 126台 | 中規模セグメント |
| 255.255.255.192 | /26 | 62台 | 小規模セグメント |
| 255.255.0.0 | /16 | 65,534台 | 大規模ネットワーク |
実務では、192.168.1.100/24 のようにCIDR表記をよく使います。「/24」と見たら「255.255.255.0」と同じ意味だと覚えておきましょう。
6.1.4 デフォルトゲートウェイ
デフォルトゲートウェイは、自分のネットワーク外への通信を中継する機器(通常はルーター)のIPアドレスです。
自分のPC: 192.168.1.100/24
ゲートウェイ: 192.168.1.1
[自分のPC] → [ルーター(192.168.1.1)] → [インターネット]
同じネットワーク内(192.168.1.x)への通信は直接行われますが、外部(例: 8.8.8.8)への通信は、すべてゲートウェイを経由します。ゲートウェイの設定が間違っていると、外部との通信ができなくなります。
6.1.5 DNSサーバーの役割
DNS(Domain Name System)は、人間が覚えやすいドメイン名(例: www.example.com)を、コンピュータが理解できるIPアドレス(例: 93.184.216.34)に変換するシステムです。
www.google.com を開きたい
↓
DNSサーバーに問い合わせ
↓
「142.250.185.68 です」と回答
↓
そのIPアドレスに接続
DNSサーバーの設定が間違っていると、ドメイン名での接続ができなくなります。ただし、IPアドレスを直接指定すれば接続は可能です。「名前では繋がらないがIPでは繋がる」場合は、DNS設定を疑いましょう。
よく使われるパブリックDNSサーバーには以下があります。
- Google Public DNS: 8.8.8.8, 8.8.4.4
- Cloudflare: 1.1.1.1, 1.0.0.1
- Quad9: 9.9.9.9
6.1.6 ネットワークインターフェース(NIC)
ネットワークインターフェース(NIC: Network Interface Card)は、コンピュータをネットワークに接続するためのハードウェア(またはその仮想版)です。
Linuxでは、各インターフェースに名前が付けられます。命名規則は環境によって異なります。
| 命名規則 | 例 | 使用される環境 |
|---|---|---|
| 伝統的な命名 | eth0, eth1 | シンVPS、一部のクラウド環境 |
| Predictable Names | enp0s3, eno1 | VirtualBox、物理サーバー |
| ループバック | lo | すべての環境(自分自身への通信用) |
Predictable Network Interface Names(予測可能なネットワークインターフェース名)は、systemdが導入した命名規則です。例えばenp0s3は、en(イーサネット)+ p0(PCIバス0)+ s3(スロット3)を意味し、物理的な接続位置に基づいて命名されます。
一方、シンVPSなどの仮想化環境では、伝統的なeth0という命名が使われることがあります。本ガイドでは、シンVPS環境を前提としてeth0を使用しますが、お使いの環境でNIC名が異なる場合は、適宜読み替えてください。
💡 Tips: 自分の環境のNIC名は ip addr show コマンドで確認できます。VirtualBoxではenp0s3、物理サーバーではeno1やenp3s0などになることがあります。
6.2 ネットワークの状態確認
設定を変更する前に、まず現在の状態を確認する習慣をつけましょう。「確認 → 変更 → 確認」のサイクルは、ネットワーク設定における鉄則です。
6.2.1 ip addrでIPアドレス確認
ip addr(またはip a)コマンドで、各インターフェースのIPアドレスを確認できます。
[実行ユーザー: developer]
$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fexx:xxxx/64 scope link noprefixroute
valid_lft forever preferred_lft forever
出力の読み方
lo: ループバックインターフェース(127.0.0.1、自分自身への通信用)eth0: 実際のネットワークインターフェースstate UP: インターフェースが有効な状態link/ether 08:00:27:xx:xx:xx: MACアドレス(物理アドレス)inet 192.168.1.100/24: IPv4アドレスとサブネットinet6 fe80::...: IPv6リンクローカルアドレス
特定のインターフェースだけを確認したい場合は、インターフェース名を指定します。
$ ip addr show eth0
6.2.2 ip routeでルーティングテーブル確認
ip route(またはip r)コマンドで、ルーティングテーブル(通信経路の一覧)を確認できます。
[実行ユーザー: developer]
$ ip route show
default via 192.168.1.1 dev eth0 proto static metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 metric 100
出力の読み方
default via 192.168.1.1: デフォルトゲートウェイは192.168.1.1dev eth0: eth0インターフェースを経由192.168.1.0/24 dev eth0: このネットワークへはeth0から直接通信
デフォルトゲートウェイが設定されていない場合、外部との通信ができません。
6.2.3 ip linkでインターフェースの状態確認
ip linkコマンドで、インターフェースの物理的な状態を確認できます。
[実行ユーザー: developer]
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 08:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff
状態の意味
UP: インターフェースが有効化されているLOWER_UP: 物理的にリンクが確立している(ケーブルが接続されている)state UP: 正常に動作しているstate DOWN: インターフェースが無効、またはケーブル未接続
6.2.4 ssコマンドでソケット状態確認
ssコマンドは、ネットワーク接続(ソケット)の状態を確認するためのツールです。どのポートでサービスが待ち受けているか、どこと通信しているかを確認できます。
リスニングポートの確認(-l オプション)
[実行ユーザー: developer]
$ ss -tlnp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*
オプションの意味
-t: TCPソケットのみ表示-l: リスニング(待ち受け)状態のみ表示-n: 数値で表示(名前解決しない)-p: プロセス情報を表示(rootまたはsudo必要)
TCP接続の確認(-a オプション)
[実行ユーザー: developer]
$ sudo ss -tanp
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1234,fd=3))
ESTAB 0 0 192.168.1.100:22 192.168.1.10:52341 users:(("sshd",pid=5678,fd=4))
LISTEN: 接続を待ち受けている状態ESTAB: 接続が確立している状態0.0.0.0:22: すべてのインターフェースのポート22で待ち受け
よく使うパターン
# リスニングポート一覧
$ ss -tlnp
# 確立済みの接続一覧
$ ss -tanp | grep ESTAB
# 特定ポートの確認
$ ss -tlnp | grep :80
# UDPソケットの確認
$ ss -ulnp
6.2.5 【注意】net-tools(ifconfig, netstat)は使わない
⚠️ 重要
古いLinuxの書籍やWebサイトでは、ifconfig、netstat、routeといったコマンドが紹介されていることがありますが、これらはnet-toolsパッケージに含まれるレガシーコマンドです。
AlmaLinux 10では、net-toolsはデフォルトでインストールされていません。現代のLinuxでは、iproute2パッケージに含まれるipコマンドとssコマンドを使用します。
| 用途 | レガシー(使わない) | 現代的(使う) |
|---|---|---|
| IPアドレス確認 | ifconfig | ip addr |
| ルーティング確認 | route | ip route |
| インターフェース状態 | ifconfig | ip link |
| 接続状態確認 | netstat | ss |
| ARPテーブル | arp | ip neigh |
なぜ新しいコマンドを使うのか
- iproute2は積極的に開発・メンテナンスされている
- より多くの機能と一貫した構文を持つ
- 将来のLinuxディストリビューションでnet-toolsがなくなる可能性がある
- 最初から正しい方法を覚えた方が効率的
6.3 疎通確認とトラブルシューティング
ネットワークに問題が発生したとき、「どこまで通信できているか」を段階的に確認することが重要です。
6.3.1 pingで到達性確認
pingコマンドは、ネットワークの基本的な疎通確認に使用します。指定したホストにICMPパケットを送信し、応答があるかを確認します。
[実行ユーザー: developer]
$ ping -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.523 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.412 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.398 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.421 ms
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.398/0.438/0.523/0.048 ms
-c 4オプションは、4回だけ送信して終了することを意味します。オプションなしで実行すると、Ctrl+Cで停止するまで永続的に送信し続けます。
確認の順序
- 自分自身:
ping 127.0.0.1(ネットワークスタックの動作確認) - ゲートウェイ:
ping 192.168.1.1(ローカルネットワークの確認) - 外部IP:
ping 8.8.8.8(インターネット接続の確認) - 外部ドメイン:
ping www.google.com(DNS解決の確認)
この順序で確認することで、問題の切り分けができます。例えば、3番まで成功して4番で失敗する場合は、DNSの問題だと分かります。
6.3.2 tracerouteで経路確認
tracerouteコマンドは、パケットが宛先に到達するまでの経路(通過するルーター)を表示します。
[実行ユーザー: developer]
$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.512 ms 0.489 ms 0.476 ms
2 10.0.0.1 (10.0.0.1) 5.234 ms 5.201 ms 5.189 ms
3 * * *
4 72.14.215.85 (72.14.215.85) 10.123 ms 10.098 ms 10.076 ms
5 8.8.8.8 (8.8.8.8) 9.876 ms 9.845 ms 9.823 ms
* * *は、そのホップからの応答がなかったことを示します。ファイアウォールでICMPがブロックされている場合によく見られます。必ずしも問題ではありません。
tracerouteがインストールされていない場合は、以下でインストールします。
$ sudo dnf install traceroute
6.3.3 dig/nslookupでDNS解決確認
DNS(名前解決)が正しく動作しているかを確認するには、digコマンドを使用します。
[実行ユーザー: developer]
$ dig www.google.com
; <<>> DiG 9.18.x <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 300 IN A 142.250.185.68
;; Query time: 20 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Sat Jan 25 10:00:00 JST 2026
;; MSG SIZE rcvd: 59
重要な情報
status: NOERROR: 正常に解決できたANSWER SECTION: 解決されたIPアドレスSERVER: 問い合わせに使用したDNSサーバー
特定のDNSサーバーを指定して問い合わせ
$ dig @8.8.8.8 www.google.com
nslookupも同様の機能を持ちますが、digの方が詳細な情報を得られるため、トラブルシューティングにはdigが推奨されます。
$ nslookup www.google.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: www.google.com
Address: 142.250.185.68
digコマンドはbind-utilsパッケージに含まれています。インストールされていない場合は以下でインストールします。
$ sudo dnf install bind-utils
6.3.4 curl/wgetでHTTP接続確認
WebサービスへのHTTP接続を確認するには、curlコマンドが便利です。
[実行ユーザー: developer]
# HTTPステータスコードの確認
$ curl -I http://www.google.com
HTTP/1.1 200 OK
Content-Type: text/html; charset=ISO-8859-1
...
# ページ内容の取得
$ curl http://www.google.com
# 詳細情報(接続時間など)
$ curl -v http://www.google.com
# タイムアウト指定(5秒)
$ curl --connect-timeout 5 http://192.168.1.100
curlは、pingが通っても実際のサービスに接続できない場合(ファイアウォールでポートがブロックされているなど)の確認に役立ちます。
6.3.5 ネットワーク問題の切り分け手順
ネットワーク接続に問題が発生した場合、以下の順序で切り分けを行います。
Step 1: 物理層/リンク層の確認
# インターフェースがUPか確認
$ ip link show eth0
state DOWNの場合は、ケーブル接続やインターフェースの有効化を確認します。
Step 2: IPアドレスの確認
# IPアドレスが設定されているか
$ ip addr show eth0
IPアドレスがない場合は、DHCP設定または静的IP設定を確認します。
Step 3: ローカルネットワークの確認
# ゲートウェイにpingが通るか
$ ping -c 2 192.168.1.1
ここで失敗する場合は、IPアドレス設定、サブネットマスク、ゲートウェイ設定を確認します。
Step 4: 外部接続の確認
# 外部のIPアドレスにpingが通るか
$ ping -c 2 8.8.8.8
ここで失敗する場合は、ゲートウェイ設定やルーターの設定を確認します。
Step 5: DNS解決の確認
# ドメイン名が解決できるか
$ dig www.google.com
ここで失敗する場合は、DNS設定(/etc/resolv.conf)を確認します。
Step 6: サービス/ポートの確認
# 特定のサービスに接続できるか
$ curl -v http://example.com
ここで失敗する場合は、ファイアウォール設定やサービスの起動状態を確認します。
6.4 NetworkManagerによるネットワーク設定
AlmaLinux 10では、NetworkManagerがネットワーク設定を管理しています。NetworkManager 1.54がデフォルトで搭載されており、nmcliコマンドで設定を行います。
6.4.1 NetworkManagerとは
NetworkManagerは、Linuxシステムのネットワーク接続を管理するデーモン(バックグラウンドサービス)です。以下の機能を提供します。
- 有線/無線ネットワーク接続の自動管理
- DHCP/静的IPの設定
- VPN接続の管理
- 接続プロファイルの保存と切り替え
NetworkManagerが動作しているか確認しましょう。
[実行ユーザー: developer]
$ systemctl status NetworkManager
● NetworkManager.service - Network Manager
Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; preset: enabled)
Active: active (running) since Sat 2026-01-25 09:00:00 JST; 1h ago
Docs: man:NetworkManager(8)
Main PID: 1234 (NetworkManager)
Tasks: 3 (limit: 23456)
Memory: 12.3M
CPU: 1.234s
CGroup: /system.slice/NetworkManager.service
└─1234 /usr/sbin/NetworkManager --no-daemon
6.4.2 nmcliコマンドの基本構文
nmcli(NetworkManager Command Line Interface)は、NetworkManagerを操作するためのコマンドラインツールです。
基本構文は以下の通りです。
nmcli [オプション] オブジェクト コマンド [引数]
主なオブジェクトには以下があります。
| オブジェクト | 省略形 | 説明 |
|---|---|---|
| general | g | NetworkManagerの全般的な状態 |
| networking | n | ネットワーク全体の有効/無効 |
| connection | c, con | 接続プロファイルの管理 |
| device | d, dev | ネットワークデバイスの管理 |
6.4.3 接続プロファイルの概念
NetworkManagerは、ネットワーク設定を接続プロファイル(Connection Profile)として管理します。1つのインターフェースに対して、複数のプロファイルを作成し、状況に応じて切り替えることができます。
例えば、以下のような使い方ができます。
- オフィス用プロファイル(固定IP)
- 自宅用プロファイル(DHCP)
- テスト用プロファイル(異なるネットワーク設定)
接続プロファイルは、/etc/NetworkManager/system-connections/ディレクトリに.nmconnectionファイルとして保存されます。
6.4.4 nmcli connection showで接続一覧
現在の接続プロファイル一覧を表示します。
[実行ユーザー: developer]
$ nmcli connection show
NAME UUID TYPE DEVICE
eth0 12345678-1234-1234-1234-123456789012 ethernet eth0
NAME: 接続プロファイル名UUID: プロファイルの一意識別子TYPE: 接続タイプ(ethernet, wifi等)DEVICE: 現在使用しているデバイス(空欄は非アクティブ)
特定の接続プロファイルの詳細を表示するには、プロファイル名を指定します。
$ nmcli connection show eth0
connection.id: eth0
connection.uuid: 12345678-1234-1234-1234-123456789012
connection.type: 802-3-ethernet
connection.autoconnect: yes
ipv4.method: auto
ipv4.addresses: --
ipv4.gateway: --
ipv4.dns: --
...
デバイスの状態を確認するには、nmcli device statusを使用します。
$ nmcli device status
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected eth0
lo loopback connected (externally) lo
6.4.5 静的IPアドレスの設定
DHCPではなく、固定のIPアドレスを設定する方法を説明します。これはサーバー運用では一般的な設定です。
設定例
- IPアドレス: 192.168.1.100/24
- ゲートウェイ: 192.168.1.1
- DNS: 8.8.8.8, 8.8.4.4
[実行ユーザー: developer]
# IPv4の設定方式をmanual(手動)に変更
$ sudo nmcli connection modify eth0 ipv4.method manual
# IPアドレスとサブネットマスクを設定
$ sudo nmcli connection modify eth0 ipv4.addresses 192.168.1.100/24
# ゲートウェイを設定
$ sudo nmcli connection modify eth0 ipv4.gateway 192.168.1.1
# DNSサーバーを設定(複数指定可能)
$ sudo nmcli connection modify eth0 ipv4.dns "8.8.8.8 8.8.4.4"
または、1つのコマンドでまとめて設定することもできます。
$ sudo nmcli connection modify eth0 \
ipv4.method manual \
ipv4.addresses 192.168.1.100/24 \
ipv4.gateway 192.168.1.1 \
ipv4.dns "8.8.8.8 8.8.4.4"
6.4.6 DNSサーバーの設定
DNSサーバーの設定は、ipv4.dnsプロパティで行います。
[実行ユーザー: developer]
# DNSサーバーを設定
$ sudo nmcli connection modify eth0 ipv4.dns "8.8.8.8 8.8.4.4"
# DNSサーバーを追加(既存の設定に追加)
$ sudo nmcli connection modify eth0 +ipv4.dns "1.1.1.1"
# DNSサーバーを削除
$ sudo nmcli connection modify eth0 -ipv4.dns "1.1.1.1"
「+」は追加、「-」は削除を意味します。
6.4.7 設定の有効化(nmcli connection up)
nmcli connection modifyで行った変更は、接続を再有効化するまで反映されません。
[実行ユーザー: developer]
# 接続を再有効化して設定を反映
$ sudo nmcli connection up eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/1)
⚠️ 注意
SSHでリモート接続している場合、IPアドレスを変更すると接続が切れます。変更後の新しいIPアドレスで再接続する必要があります。物理コンソールや仮想マシンのコンソールからアクセスできる状態で作業することを推奨します。
設定が反映されたか確認しましょう。
$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
6.4.8 DHCPへの切り替え
静的IPからDHCP(自動取得)に戻すには、以下のように設定します。
[実行ユーザー: developer]
# IPv4の設定方式をauto(DHCP)に変更
$ sudo nmcli connection modify eth0 ipv4.method auto
# 静的設定をクリア
$ sudo nmcli connection modify eth0 ipv4.addresses ""
$ sudo nmcli connection modify eth0 ipv4.gateway ""
$ sudo nmcli connection modify eth0 ipv4.dns ""
# 設定を反映
$ sudo nmcli connection up eth0
6.4.9 設定ファイルの場所(/etc/NetworkManager/system-connections/)
接続プロファイルは、/etc/NetworkManager/system-connections/ディレクトリに.nmconnectionファイルとして保存されています。
[実行ユーザー: developer]
$ sudo ls -la /etc/NetworkManager/system-connections/
total 12
drwxr-xr-x. 2 root root 4096 Jan 25 10:00 .
drwxr-xr-x. 7 root root 4096 Jan 25 09:00 ..
-rw-------. 1 root root 312 Jan 25 10:00 eth0.nmconnection
ファイルの内容を確認してみましょう。
$ sudo cat /etc/NetworkManager/system-connections/eth0.nmconnection
[connection]
id=eth0
uuid=12345678-1234-1234-1234-123456789012
type=ethernet
interface-name=eth0
[ethernet]
[ipv4]
method=manual
address1=192.168.1.100/24,192.168.1.1
dns=8.8.8.8;8.8.4.4;
[ipv6]
method=auto
このファイルを直接編集することも可能ですが、nmcliを使用する方が安全です。ファイルを直接編集した場合は、以下のコマンドで設定を再読み込みします。
$ sudo nmcli connection reload
6.5 firewalldによるファイアウォール設定
サーバーをネットワークに接続したら、次に考えるべきはセキュリティです。ファイアウォールで不要な通信を遮断し、必要な通信のみを許可します。
6.5.1 ファイアウォールとは何か
ファイアウォールは、ネットワークを通過するパケット(通信データ)を検査し、ルールに基づいて許可または遮断するセキュリティ機能です。
[インターネット] → [ファイアウォール] → [サーバー]
↑
ここで通信を制御
- 許可されたポートのみ通過
- 不正なアクセスをブロック
例えば、Webサーバーであれば、HTTPポート(80)とHTTPSポート(443)への通信は許可し、それ以外のポートへの通信は遮断するといった設定を行います。
6.5.2 firewalldの基本概念
AlmaLinux 10では、firewalldがデフォルトのファイアウォール管理ツールとして搭載されています。firewalldは、nftablesをバックエンドとして使用しています。
ゾーン(Zone)の概念
firewalldは「ゾーン」という概念を使って、信頼レベルに応じたルールセットを管理します。インターフェースやIPアドレスをゾーンに割り当てることで、適切なルールが適用されます。
| ゾーン | 信頼レベル | 用途 |
|---|---|---|
| drop | 最低 | すべての着信を破棄(応答なし) |
| block | 低 | すべての着信を拒否(ICMPで通知) |
| public | 低 | 公開ネットワーク用(デフォルト) |
| external | 低 | 外部ネットワーク用(NATマスカレード) |
| dmz | 中 | DMZ(非武装地帯)用 |
| work | 中 | 職場ネットワーク用 |
| home | 高 | 家庭ネットワーク用 |
| internal | 高 | 内部ネットワーク用 |
| trusted | 最高 | すべての通信を許可 |
初学者は、まずpublicゾーンだけを理解すれば十分です。サーバーのデフォルトゾーンは通常publicに設定されています。
サービスとポート
firewalldでは、通信を許可する方法として「サービス」と「ポート」の2つがあります。
- サービス: 事前定義された名前(ssh, http, https等)で指定。ポート番号を覚える必要がない
- ポート: ポート番号とプロトコル(80/tcp等)で直接指定
可能な限り「サービス」で指定することを推奨します。ポート番号の間違いを防げるためです。
6.5.3 firewall-cmdコマンドの基本
firewall-cmdは、firewalldを操作するためのコマンドラインツールです。
まず、firewalldが動作しているか確認します。
[実行ユーザー: developer]
$ sudo firewall-cmd --state
running
「running」と表示されれば、firewalldは動作しています。
6.5.4 現在の設定確認
すべての設定を表示
[実行ユーザー: developer]
$ sudo firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
出力の読み方
public (active): publicゾーンがアクティブinterfaces: eth0: このゾーンに割り当てられたインターフェースservices: cockpit dhcpv6-client ssh: 許可されているサービスports:: 個別に許可されているポート(空欄は何も許可されていない)
アクティブゾーンの確認
$ sudo firewall-cmd --get-active-zones
public
interfaces: eth0
デフォルトゾーンの確認
$ sudo firewall-cmd --get-default-zone
public
6.5.5 サービスの許可
特定のサービス(例: HTTP)への通信を許可するには、--add-serviceオプションを使用します。
[実行ユーザー: developer]
# HTTPサービスを一時的に許可(再起動で消える)
$ sudo firewall-cmd --add-service=http
success
# HTTPSサービスを一時的に許可
$ sudo firewall-cmd --add-service=https
success
設定が反映されたか確認します。
$ sudo firewall-cmd --list-services
cockpit dhcpv6-client http https ssh
利用可能なサービス一覧
$ sudo firewall-cmd --get-services
RH-Satellite-6 RH-Satellite-6-capsule amanda-client amanda-k5-client amqp amqps ...
6.5.6 ポート番号での許可
事前定義されていないポートを許可するには、--add-portオプションを使用します。
[実行ユーザー: developer]
# ポート8080/tcpを許可
$ sudo firewall-cmd --add-port=8080/tcp
success
# ポート範囲を許可
$ sudo firewall-cmd --add-port=3000-3100/tcp
success
設定を確認します。
$ sudo firewall-cmd --list-ports
8080/tcp 3000-3100/tcp
6.5.7 設定の永続化(–permanentオプション)
これまでの設定は「ランタイム設定」と呼ばれ、firewalldを再起動すると消えてしまいます。設定を永続化するには、--permanentオプションを使用します。
[実行ユーザー: developer]
# HTTPサービスを永続的に許可
$ sudo firewall-cmd --permanent --add-service=http
success
# HTTPSサービスを永続的に許可
$ sudo firewall-cmd --permanent --add-service=https
success
💡 ポイント
--permanentオプションを付けると、設定ファイルに書き込まれますが、現在の動作には反映されません。反映するには--reloadが必要です。
6.5.8 設定の再読み込み(–reload)
--permanentで追加した設定を現在の動作に反映するには、--reloadを実行します。
[実行ユーザー: developer]
$ sudo firewall-cmd --reload
success
推奨ワークフロー
--permanentなしで設定をテスト(一時的に適用)- 動作確認
- 問題なければ
--permanent付きで再度設定 --reloadで永続設定を反映
または、以下のように一度に両方設定することもできます。
# ランタイムと永続の両方に設定
$ sudo firewall-cmd --add-service=http
$ sudo firewall-cmd --permanent --add-service=http
6.5.9 ルールの削除
許可したサービスやポートを削除するには、--remove-serviceや--remove-portを使用します。
[実行ユーザー: developer]
# サービスの削除(ランタイム)
$ sudo firewall-cmd --remove-service=http
success
# サービスの削除(永続)
$ sudo firewall-cmd --permanent --remove-service=http
success
# ポートの削除
$ sudo firewall-cmd --permanent --remove-port=8080/tcp
success
# 反映
$ sudo firewall-cmd --reload
success
6.6 実践: Webサーバー用ファイアウォール設定
第5章で設定したhttpdサービスを外部からアクセス可能にするため、ファイアウォール設定を行いましょう。
6.6.1 HTTP/HTTPSポートの開放
まず、現在の設定を確認します。
[実行ユーザー: developer]
$ sudo firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: cockpit dhcpv6-client ssh
ports:
...
httpとhttpsがないので、追加します。
# HTTPを永続的に許可
$ sudo firewall-cmd --permanent --add-service=http
success
# HTTPSを永続的に許可
$ sudo firewall-cmd --permanent --add-service=https
success
# 設定を反映
$ sudo firewall-cmd --reload
success
6.6.2 SSH接続の確保
SSH(ポート22)は、デフォルトで許可されています。これを誤って削除すると、リモートからサーバーにアクセスできなくなります。
# SSHが許可されていることを確認
$ sudo firewall-cmd --list-services | grep ssh
cockpit dhcpv6-client http https ssh
「ssh」が含まれていれば問題ありません。
6.6.3 不要なサービスの停止
使用しないサービスは削除することで、攻撃対象となる面(アタックサーフェス)を減らせます。
例えば、cockpit(Webベースの管理ツール)を使用しない場合は削除できます。
# cockpitサービスを削除
$ sudo firewall-cmd --permanent --remove-service=cockpit
success
$ sudo firewall-cmd --reload
success
6.6.4 設定の確認と検証
最終的な設定を確認します。
[実行ユーザー: developer]
$ sudo firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: eth0
sources:
services: dhcpv6-client http https ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
httpdサービスが起動していることを確認し、curlでアクセスしてみます。
# httpdの状態確認
$ sudo systemctl status httpd
# ローカルからのアクセステスト
$ curl http://localhost
別のマシンから、サーバーのIPアドレスにアクセスしてテストします。
# 別のマシンから
$ curl http://192.168.1.100
6.6.5 よくあるトラブル: ポートが開いているのに接続できない
ファイアウォールでポートを開放したのに接続できない場合、以下の点を確認してください。
チェックリスト
- サービスは起動しているか
$ sudo systemctl status httpd
- サービスは正しいポートでリッスンしているか
$ sudo ss -tlnp | grep :80
LISTEN 0 511 *:80 *:* users:(("httpd",pid=1234,fd=4))
- firewalldで許可されているか
$ sudo firewall-cmd --list-services
- SELinuxがブロックしていないか
$ sudo ausearch -m avc -ts recent
- ネットワーク的に到達可能か
# サーバー側から
$ ping クライアントのIP
# クライアント側から
$ ping サーバーのIP
- 別のファイアウォール(ルーター、クラウドのセキュリティグループ等)がブロックしていないか
クラウド環境では、OS内のfirewalldとは別に、クラウド側のセキュリティグループやネットワークACLでもポートを開放する必要があります。
6.7 時刻同期の設定(chrony)
サーバーの時刻管理は、見落とされがちですが非常に重要です。AlmaLinux 10では、chronyがデフォルトのNTP(Network Time Protocol)クライアントとして使用されています。
6.7.1 なぜ時刻同期が重要なのか
サーバーの時刻がズレていると、以下のような問題が発生します。
- ログのタイムスタンプ: 複数サーバーのログを時系列で追跡できなくなる
- SSL/TLS証明書: 証明書の有効期間チェックに失敗する
- 認証システム: Kerberosなどの時刻依存の認証が失敗する
- 分散システム: データベースレプリケーションや分散処理に問題が発生
- バックアップ: 増分バックアップのタイミングがズレる
- ファイル同期: rsyncなどの同期ツールが正しく動作しない
6.7.2 NTPとchronyの違い
NTP(Network Time Protocol)は、ネットワーク経由で正確な時刻を取得するためのプロトコルです。従来はntpdデーモンが使われていましたが、現在のRHEL系ではchronyが標準です。
| 特徴 | ntpd | chrony |
|---|---|---|
| 起動時の同期速度 | 遅い | 高速 |
| 断続的なネットワーク | 苦手 | 得意 |
| 仮想マシン対応 | 普通 | 良好 |
| リソース使用量 | 普通 | 少ない |
chronyは、特にノートPCやサーバーの起動時など、ネットワーク接続が断続的な環境でも優れたパフォーマンスを発揮します。
6.7.3 chronydサービスの確認
chronydサービスの状態を確認します。
[実行ユーザー: developer]
$ systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: enabled)
Active: active (running) since Sat 2026-01-25 09:00:00 JST; 2h ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Main PID: 1234 (chronyd)
Tasks: 1 (limit: 23456)
Memory: 1.5M
CPU: 123ms
CGroup: /system.slice/chronyd.service
└─1234 /usr/sbin/chronyd -F 2
「active (running)」と表示されていれば、chronydは動作しています。
6.7.4 chronycコマンドで状態確認
chronycは、chronydを管理・監視するためのコマンドラインツールです。
NTPソース(時刻サーバー)の確認
[実行ユーザー: developer]
$ chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp.nict.jp 1 6 377 23 +234us[ +456us] +/- 12ms
^+ ntp.jst.mfeed.ad.jp 2 6 377 24 -123us[ -101us] +/- 15ms
^+ time.cloudflare.com 3 6 377 22 +567us[ +789us] +/- 18ms
出力の読み方
^*: 現在同期に使用しているソース^+: 使用可能な良好なソース^-: 使用可能だが品質が低いソース^?: 接続できないソースStratum: 階層(1が最も信頼性が高い)Reach: 到達性(377が理想的)
同期状態の詳細確認
$ chronyc tracking
Reference ID : A9FEA9FE (ntp.nict.jp)
Stratum : 2
Ref time (UTC) : Sat Jan 25 01:00:00 2026
System time : 0.000000123 seconds fast of NTP time
Last offset : +0.000000234 seconds
RMS offset : 0.000000345 seconds
Frequency : 12.345 ppm slow
Residual freq : +0.001 ppm
Skew : 0.123 ppm
Root delay : 0.012345678 seconds
Root dispersion : 0.001234567 seconds
Update interval : 64.0 seconds
Leap status : Normal
重要な項目
Reference ID: 同期元のNTPサーバーSystem time: システム時刻とNTP時刻の差(0に近いほど良い)Leap status: Normal(正常)であることを確認
6.7.5 /etc/chrony.confの設定
chronydの設定ファイルは/etc/chrony.confです。
[実行ユーザー: developer]
$ sudo cat /etc/chrony.conf
# Use public servers from the pool.ntp.org project.
pool 2.almalinux.pool.ntp.org iburst
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
# Allow the system clock to be stepped in the first three updates
makestep 1.0 3
# Enable kernel synchronization of the real-time clock (RTC).
rtcsync
# Specify directory for log files.
logdir /var/log/chrony
主要な設定項目
pool: 使用するNTPサーバープールserver: 個別のNTPサーバーiburst: 起動時に複数のリクエストを送り、素早く同期driftfile: クロックのドリフト情報を保存makestep: 大きなズレがある場合にステップ補正を許可
日本のNTPサーバーを使用する場合
信頼性の高い日本のNTPサーバーを使用する場合は、以下のように設定を追加します。
$ sudo vi /etc/chrony.conf
以下の行を追加または変更します。
# 日本標準時を提供するNICTのNTPサーバー
server ntp.nict.jp iburst
# または日本向けのプールを使用
pool jp.pool.ntp.org iburst
6.7.6 サービスの再起動と確認
設定を変更したら、chronydを再起動して反映します。
[実行ユーザー: developer]
# chronydを再起動
$ sudo systemctl restart chronyd
# 状態を確認
$ chronyc sources
6.7.7 timedatectlコマンドの使い方
timedatectlは、システムの日時とタイムゾーンを管理するためのコマンドです。
現在の状態確認
[実行ユーザー: developer]
$ timedatectl
Local time: Sat 2026-01-25 11:00:00 JST
Universal time: Sat 2026-01-25 02:00:00 UTC
RTC time: Sat 2026-01-25 02:00:00
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: NTPサービス(chronyd)が動作中Time zone: Asia/Tokyo: 設定されているタイムゾーン
タイムゾーンの変更
[実行ユーザー: developer]
# タイムゾーンをAsia/Tokyoに設定
$ sudo timedatectl set-timezone Asia/Tokyo
# 設定を確認
$ timedatectl
利用可能なタイムゾーン一覧
$ timedatectl list-timezones
Africa/Abidjan
Africa/Accra
...
Asia/Tokyo
...
日本のタイムゾーンを検索するには、grepと組み合わせます。
$ timedatectl list-timezones | grep Tokyo
Asia/Tokyo
手動で時刻を設定(緊急時のみ)
NTPが使えない特殊な環境では、手動で時刻を設定することもできます。
# NTP同期を無効化
$ sudo timedatectl set-ntp false
# 手動で時刻を設定
$ sudo timedatectl set-time "2026-01-25 11:00:00"
# NTP同期を再度有効化
$ sudo timedatectl set-ntp true
⚠️ 注意
通常の運用では、手動で時刻を設定する必要はありません。NTP同期を有効にしておけば、chronydが自動的に正確な時刻を維持します。
6.8 hostnameとhostsファイル
サーバーのホスト名(コンピュータ名)と、ローカルでの名前解決について説明します。
6.8.1 hostnamectlでホスト名管理
hostnamectlコマンドで、システムのホスト名を管理します。
[実行ユーザー: developer]
$ hostnamectl
Static hostname: almalinux10
Icon name: computer-vm
Chassis: vm 🖴
Machine ID: 12345678901234567890123456789012
Boot ID: abcdefabcdefabcdefabcdefabcdefab
Virtualization: oracle
Operating System: AlmaLinux 10.0 (Purple Lion)
CPE OS Name: cpe:/o:almalinux:almalinux:10
Kernel: Linux 6.12.0-0.rc0.20240918gitfb4c6338becc.2.el10.x86_64
Architecture: x86-64
ホスト名の種類
- Static hostname: /etc/hostnameに保存される永続的なホスト名
- Transient hostname: DHCPなどで一時的に設定されるホスト名
- Pretty hostname: 表示用の自由形式のホスト名(スペース等使用可能)
6.8.2 ホスト名の変更
[実行ユーザー: developer]
# ホスト名を変更
$ sudo hostnamectl set-hostname webserver01
# 確認
$ hostnamectl
Static hostname: webserver01
...
ホスト名の変更は即座に反映されます。新しいターミナルセッションを開くと、プロンプトに新しいホスト名が表示されます。
ホスト名のルール
- 小文字のアルファベット、数字、ハイフンが使用可能
- ハイフンで始まったり終わったりしてはいけない
- 最大63文字
- FQDN(完全修飾ドメイン名)を設定する場合は253文字以内
6.8.3 /etc/hostsファイルの役割
/etc/hostsファイルは、DNSを使わずにホスト名とIPアドレスの対応を定義するファイルです。DNSよりも優先して参照されます。
[実行ユーザー: developer]
$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
用途
- ローカル環境でのテスト用ホスト名定義
- 内部ネットワークの小規模な名前解決
- 一時的なホスト名の上書き
6.8.4 hostsファイルの編集(ローカル名前解決)
例えば、内部ネットワークの他のサーバーを名前で参照したい場合は、/etc/hostsにエントリを追加します。
[実行ユーザー: developer]
$ sudo vi /etc/hosts
以下のような行を追加します。
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
# 内部サーバー
192.168.1.101 dbserver01
192.168.1.102 webserver02
192.168.1.103 appserver01
設定後、pingで確認します。
$ ping -c 2 dbserver01
PING dbserver01 (192.168.1.101) 56(84) bytes of data.
64 bytes from dbserver01 (192.168.1.101): icmp_seq=1 ttl=64 time=0.523 ms
...
書式
IPアドレス ホスト名 [エイリアス...]
💡 ポイント
/etc/hostsは、小規模な環境やテスト目的には便利ですが、サーバー台数が増えると管理が困難になります。本番環境では、適切なDNSサーバーの構築を検討してください。
【コラム5】時刻が3時間ズレて認証が通らず徹夜した話
あれは入社2年目の冬、新しいサーバーを構築していたときのことです。
社内のSSOシステム(シングルサインオン)に接続するための設定を行っていました。アプリケーションの設定は何度も確認し、ネットワーク的にも疎通は取れている。ログを見ても、特にエラーは出ていない。なのに、認証が通らない。
「設定は合っているはずなのに…」
アプリケーションのドキュメントを何度も読み直し、設定ファイルを見比べ、ログを穴が開くほど眺めました。先輩にも相談しましたが、原因が分からない。気づけば深夜2時を回っていました。
半ば諦めかけたそのとき、ふとdateコマンドを叩いてみました。
$ date
Sat Jan 25 23:15:00 UTC 2026
「…UTC?」
慌ててtimedatectlを実行。
$ timedatectl
Time zone: UTC (UTC, +0000)
System clock synchronized: no
NTP service: inactive
タイムゾーンがUTCのまま、しかもNTP同期が無効になっていました。日本時間より9時間遅れ、さらにchronydが停止していたため、サーバー設置時の時刻からズレ続けていたのです。結果、実際の時刻より約3時間遅れていました。
Kerberos認証は、クライアントとサーバーの時刻差が5分以上あると認証に失敗します。3時間もズレていれば、そりゃ通らないわけです。
$ sudo timedatectl set-timezone Asia/Tokyo
$ sudo systemctl enable --now chronyd
$ chronyc sources
時刻を修正した瞬間、あっさりとSSO認証が成功しました。
この経験から学んだこと:
- トラブル時は基本から確認: 高度な設定を疑う前に、時刻、ネットワーク、権限といった基本を確認する
- 時刻同期は地味だが重要: サーバー構築時に必ずchronydの有効化とタイムゾーン設定を行う
- 構築チェックリストを作る: 同じミスを繰り返さないよう、確認項目をリスト化する
今では新しいサーバーを触るとき、まずtimedatectlとchronyc sourcesを実行する癖がついています。あの徹夜があったからこそ、身についた習慣です。
章末まとめ
この章では、ネットワーク設定と時刻同期について学びました。
ネットワークの基礎
- IPアドレス、サブネットマスク、ゲートウェイ、DNSの役割を理解した
- CIDR表記(/24など)でサブネットを簡潔に表現できる
- ネットワーク問題は階層ごとに切り分けて考える
モダンなコマンドの使用
ip addr: IPアドレスの確認ip route: ルーティングテーブルの確認ss: ソケット(接続)状態の確認- ifconfig、netstat、routeは使わない(レガシー)
NetworkManagerによる設定
nmcli connection show: 接続プロファイル一覧nmcli connection modify: 設定の変更nmcli connection up: 設定の反映- 設定ファイルは
/etc/NetworkManager/system-connections/に保存
firewalldによるファイアウォール
- ゾーンベースの設定(デフォルトはpublicゾーン)
firewall-cmd --add-service: サービスの許可firewall-cmd --add-port: ポートの許可--permanentで永続化、--reloadで反映
時刻同期(chrony)
- 時刻同期は認証、ログ、SSL証明書に影響する重要な設定
chronyc sources: NTPサーバーの確認chronyc tracking: 同期状態の確認timedatectl: タイムゾーンと時刻の管理
ホスト名管理
hostnamectl: ホスト名の確認と変更/etc/hosts: ローカルでの名前解決
練習問題
問題1: 以下のip addr出力から、(a) IPアドレス、(b) サブネットマスク(CIDR)、(c) MACアドレスを読み取ってください。
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
link/ether 08:00:27:ab:cd:ef brd ff:ff:ff:ff:ff:ff
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0
解答例を見る
(a) IPアドレス: 10.0.2.15
(b) サブネットマスク: /24(255.255.255.0)
(c) MACアドレス: 08:00:27:ab:cd:ef
inetの後ろにIPアドレス/サブネットが、link/etherの後ろにMACアドレスが表示されています。
問題2: ssコマンドを使って、TCPでリスニング中のポートとプロセス情報を表示するコマンドを書いてください。
解答例を見る
$ sudo ss -tlnp
オプションの意味:
- -t: TCPのみ
- -l: リスニング状態のみ
- -n: 数値表示(名前解決しない)
- -p: プロセス情報を表示
プロセス情報の表示にはroot権限が必要なため、sudoを使用します。
問題3: nmcliを使って、接続「eth0」に静的IPアドレス「192.168.10.50/24」、ゲートウェイ「192.168.10.1」を設定し、変更を反映するコマンドを書いてください。
解答例を見る
# 設定方式をmanualに変更
$ sudo nmcli connection modify eth0 ipv4.method manual
# IPアドレスを設定
$ sudo nmcli connection modify eth0 ipv4.addresses 192.168.10.50/24
# ゲートウェイを設定
$ sudo nmcli connection modify eth0 ipv4.gateway 192.168.10.1
# 変更を反映
$ sudo nmcli connection up eth0
または、1つのコマンドにまとめることもできます:
$ sudo nmcli connection modify eth0 ipv4.method manual ipv4.addresses 192.168.10.50/24 ipv4.gateway 192.168.10.1
$ sudo nmcli connection up eth0
問題4: firewall-cmdを使って、HTTPサービスを永続的に許可し、設定を反映するコマンドを書いてください。
解答例を見る
# HTTPサービスを永続的に許可
$ sudo firewall-cmd --permanent --add-service=http
# 設定を反映
$ sudo firewall-cmd --reload
確認するには:
$ sudo firewall-cmd --list-services
問題5: 以下のchronyc sources出力を見て、(a) 現在同期に使用しているサーバー、(b) 同期状態は正常かを判断してください。
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp.nict.jp 1 6 377 23 +234us[ +456us] +/- 12ms
^+ time.cloudflare.com 3 6 377 22 +567us[ +789us] +/- 18ms
^? bad-server.example.com 0 6 0 - +0ns[ +0ns] +/- 0ns
解答例を見る
(a) 現在同期に使用しているサーバー: ntp.nict.jp
先頭の^*マークが現在同期に使用しているソースを示します。
(b) 同期状態: 正常
理由:
- ntp.nict.jpにはStratum 1(高信頼)で同期している
- Reachが377(8回中8回到達可能)で良好
- Last sampleの値が小さく(マイクロ秒単位)、時刻差が少ない
- bad-server.example.comは
^?で接続できていないが、他のソースで同期できているので問題ない
次章への橋渡し
この章では、ネットワーク設定とファイアウォール、時刻同期について学びました。サーバーがネットワークに接続され、適切なセキュリティ設定と正確な時刻を持つようになりました。
次の第7章では、セキュリティとシェルスクリプトについて学びます。ユーザー管理、SSH認証の強化、SELinuxの基礎、そして運用を効率化するシェルスクリプトの書き方を習得します。
この章で設定したファイアウォールはセキュリティの「入口」を守るものですが、サーバーセキュリティはそれだけでは不十分です。適切なユーザー管理、SSH設定の強化、SELinuxの活用など、多層的な防御が必要です。次章では、その「多層防御」の考え方と具体的な設定方法を学びます。
