【付録】現場で差がつく！Linuxネットワーク調査とSSHポートフォワーディングの極意

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
全8回にわたる「Linuxエンジニアになるための基礎」連載を完走された皆様、本当にお疲れ様でした。OSの基礎からバックアップ戦略まで、インフラを構築・運用するためのコアスキルはすでに身についているはずです。

今回は、連載の「特別付録」として、サーバー運用において避けては通れない「ネットワーク調査コマンド」と、セキュアな通信経路を自在に操る「SSHポートフォワーディング（トンネリング）」の極意を解説します。ネットワークの壁を越え、目に見えない通信を可視化するこの技術は、あなたを一つ上の次元のエンジニアへと押し上げます。

先生、本番環境のサーバーに外部からAPIのリクエストを送っているんですが、うまく繋がりません！とりあえず ping を打ってみたんですが応答がなくて……。ファイアウォール（UFW）でポートは開けたはずなのに、何が原因か全く分からなくてお手上げです。

コウ君、ネットワークのトラブルシューティングを ping だけで終わらせようとするのは初心者の証拠よ！ping は ICMP というプロトコルを使っているから、Web APIの通信（TCP）が通っているかどうかの証明にはならないの。
通信が通らない時は、「名前解決はできているか？（dig）」「ポートで待ち受けているか？（ss）」「HTTPレベルでのエラーはないか？（curl）」を論理的に切り分ける必要があるわ。今日はネットワークのレントゲン検査の手法と、秘密の通信経路を作るSSHの魔法を伝授するわよ！

📚 本連載のカリキュラム（全8回＋付録）

第1章：モダンなインターフェースとIP管理（ipコマンド）
1. 1-1. IPアドレスとインターフェースの確認
2. 1-2. ルーティングテーブルの確認
第2章：ポート解放と通信セッションの監視（ssコマンド）
1. 2-1. リッスン（待ち受け）ポートの確認
第3章：名前解決とDNSトラブルシューティング（digコマンド）
1. 3-1. ドメインからIPアドレスを引く（正引き）
2. 3-2. 問い合わせ先のDNSサーバーを指定する
第4章：HTTP通信のテストとAPI解析の極意（curlコマンド）
1. 4-1. ヘッダー情報の取得（-I オプション）
2. 4-2. JSONデータのPOST送信（APIテスト）
第5章：SSHポートフォワーディングの魔術（ローカルフォワード）
1. 5-1. ローカルフォワードの仕組みと実行（-L）
第6章：外部公開の裏技！リモートフォワードと多段SSH
1. 6-1. リモートフォワードの実行（-R）
2. 6-2. ProxyJump (-J) による多段SSHの簡略化
総まとめ：ネットワークとセキュリティを完全に支配せよ
1. ▼ 【ネットワークの壁を越え、実務環境を構築】 ▼

第1章：モダンなインターフェースとIP管理（ipコマンド）

ネットワーク調査の第一歩は、「自分のサーバーがどんなIPアドレスを持ち、どのようにルーティングされているか」を正確に把握することです。昔のLinuxでは ifconfig や route といったコマンドが使われていましたが、現在（AlmaLinux 9等）ではこれらは非推奨（Deprecated）となり、統合された ip コマンド を使用するのがプロの標準です。

1-1. IPアドレスとインターフェースの確認

サーバーに割り当てられているIPアドレス（IPv4/IPv6）や、MACアドレスを確認します。

# ネットワークインターフェースとIPアドレスを一覧表示する
ip addr show
# （※省略形として `ip a` でも全く同じ結果が得られます）

# リンク（UP/DOWN状態）だけを簡潔に確認する
ip link show

出力結果の中にある lo はループバックアドレス（127.0.0.1：自分自身）であり、eth0 や ens192 などが外部と通信するためのメインの物理/仮想インターフェースです。

1-2. ルーティングテーブルの確認

「パケットがどのゲートウェイを通って外の世界（インターネット）へ出ていくのか」を確認します。VPN接続時や複数のネットワークカード（NIC）を挿しているサーバーで通信が迷子になった場合、ここを調査します。

# ルーティングテーブル（経路情報）を表示する
ip route show
# （※省略形： `ip r`）

# 【出力例】
default via 192.168.1.1 dev eth0 proto dhcp 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 という行が、このサーバーの「デフォルトゲートウェイ（外部への出口）」を示しています。ここが間違っていると、どんなにポートを開けてもインターネットには繋がりません。

第2章：ポート解放と通信セッションの監視（ssコマンド）

「Nginxを起動したのにWebサイトに繋がらない」という場合、次に疑うべきは「本当にNginxは80番（または443番）ポートでリクエストを待ち受けているか？」です。
かつては netstat コマンドが使われていましたが、現在はより高速でカーネルから直接情報を取得する ss (Socket Statistics) コマンド が標準です。

2-1. リッスン（待ち受け）ポートの確認

プロのインフラエンジニアが、サーバー構築直後や障害時に必ず叩く「最強のオプション組み合わせ（-tnlp）」を覚えましょう。

# TCPの待ち受けポートと、それを使用しているプロセス名を一覧表示
sudo ss -tnlp

# 【オプションの解読】
# -t (tcp)     : TCPソケットのみを表示
# -n (numeric) : ポート番号を名前（http等）に変換せず、数値（80等）で表示
# -l (listening): リッスン（待ち受け）状態のソケットのみを表示
# -p (processes): そのポートを使用しているプロセスIDと名前を表示（要sudo）

出力結果の Local Address:Port の列を見てください。もし 127.0.0.1:3306 となっていた場合、そのプロセス（例えばMariaDB）は「サーバー内部（ローカル）からの通信しか受け付けない」という決定的な証拠になります。
外部からアクセスさせたい場合は、設定ファイルを書き換えて 0.0.0.0:80（全てのIPからのアクセスを許可）にする必要があります。この「バインドIPの違い」を見抜けるかどうかが、プロと素人の分かれ道です。

第3章：名前解決とDNSトラブルシューティング（digコマンド）

WebブラウザでURLを打ち込んでもサイトが表示されない時、「IPアドレスなら繋がるのに、ドメイン名だと繋がらない」というケースが頻発します。これはDNS（ドメインネームシステム）の名前解決エラーです。
この調査には nslookup よりも詳細な情報が得られる dig コマンド を使用します。

3-1. ドメインからIPアドレスを引く（正引き）

# ターゲットドメインのAレコード（IPv4アドレス）を問い合わせる
dig example.com

# 非常にスッキリとした形でIPアドレスの答えだけ（Short形式）を取得する
dig example.com +short

3-2. 問い合わせ先のDNSサーバーを指定する

「ドメインの設定を変更した（DNSの切り替え）が、まだ反映されない」という場合、自分が使っているプロバイダのDNSキャッシュが古いままになっている可能性があります。その際、GoogleのパブリックDNS（8.8.8.8）やCloudflare（1.1.1.1）に対して直接問い合わせを行い、世界的にはどう見えているかを確認します。

# GoogleのDNSサーバー（8.8.8.8）に対して、直接名前解決を要求する
dig @8.8.8.8 example.com +short

第4章：HTTP通信のテストとAPI解析の極意（curlコマンド）

コウ君が冒頭で悩んでいた「APIに繋がらない」という問題。WebアプリケーションやAPIの動作テストにおいて、ブラウザを開かずにCUI（黒い画面）から直接HTTPリクエストを送信し、レスポンスを解析する最強のツールが curl コマンド です。

4-1. ヘッダー情報の取得（-I オプション）

Webサーバーがダウンしているのか、それとも「500 Internal Server Error」を返しているのか、あるいはリダイレクト（301）の無限ループに陥っているのかを調べるには、通信のヘッダーだけを取得します。

# HTML本文はダウンロードせず、HTTPレスポンスヘッダーだけを取得する
curl -I https://example.com/

# 【出力例】
HTTP/2 200 
server: nginx/1.20.1
date: Sat, 22 Aug 2026 15:00:00 GMT
content-type: text/html; charset=UTF-8

これで 200 OK が返ってくれば、ネットワークもWebサーバーも正常に動作していることが1秒で確定します。

スーパーユーザーなら知っておくべきLinuxシステムの仕組み [ Brian Ward ]

価格:3960円
(2026/7/17 18:54時点)
感想(0件)

4-2. JSONデータのPOST送信（APIテスト）

MySQLなどのリレーショナルデータベースを使用しない軽量なアーキテクチャでは、PHPとNoSQL（JSONファイルデータストア）を組み合わせたREST APIを構築することが多くあります。この自作APIに対して、curl を使って直接データを書き込むテストを行います。

# メソッドをPOSTに指定し、JSONデータをHTTPヘッダー付きで送信する
curl -X POST https://api.example.com/v1/diet_log \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer secret_token_123" \
     -d '{"weight": 65.5, "exercise": "running", "duration_min": 30}'

さらに詳細な通信のやり取り（SSL証明書の検証プロセスや、送信した生のヘッダー情報など）を見たい場合は、-v (verbose) オプション を付与します。これでHTTPプロトコルのすべてが丸裸になります。

第5章：SSHポートフォワーディングの魔術（ローカルフォワード）

ここからが本記事の最大の目玉です。
インフラエンジニアとして働いていると、「本番サーバーの内部（プライベートネットワーク）で動いている管理画面やNoSQLのダッシュボードに、自分の手元のPCのブラウザからアクセスしたい」という要件が必ず発生します。
しかし、セキュリティ上、これらのポート（例えば管理画面の8080番）をインターネット（UFWやファイアウォール）に公開するのは極めて危険です。

そこで使用するのが、安全なSSHの暗号化通信のトンネルの中に、別の通信（HTTPなど）を通す「SSHポートフォワーディング（ローカルフォワード）」という技術です。

5-1. ローカルフォワードの仕組みと実行（-L）

「手元のPCのポート」へのアクセスを、「踏み台サーバー（SSH）」を経由して、「ターゲットのポート」へと転送します。

# 手元のPC（MacやWindowsのターミナル）で実行するコマンド
# 書式: ssh -L [手元のポート]:[ターゲットIP]:[ターゲットポート] [踏み台サーバーのユーザー@IP]

ssh -L 8080:localhost:8080 user@203.0.113.50

【このコマンドが起こす魔法】
上記のコマンドを打ってSSHログインした状態のまま、手元のPCのブラウザを開き http://localhost:8080 にアクセスしてみてください。
すると、ブラウザからのリクエストは暗号化されたSSHトンネルを通り、リモートサーバー（203.0.113.50）の内部で動いている localhost:8080 のWebアプリケーションに到達します。
外部のファイアウォールを開けることなく、セキュアに社内専用の管理ツールやJSONデータストアのGUIを操作できる、プロ必須のテクニックです。

第6章：外部公開の裏技！リモートフォワードと多段SSH

ローカルフォワードの逆で、「自分の手元のPC（ローカル環境）で開発中のWebアプリを、インターネット上のVPSを経由して、クライアントや外部のチームメンバーに見せたい」という場合があります。これを実現するのがリモートフォワードです。

6-1. リモートフォワードの実行（-R）

# 手元のPCで実行するコマンド
# 書式: ssh -R [VPSの公開ポート]:[手元のIP]:[手元のポート] [VPSのユーザー@IP]

ssh -R 8080:localhost:3000 user@203.0.113.50

この状態で、外部の人がVPSのIPアドレス http://203.0.113.50:8080 にアクセスすると、通信が逆流してあなたの手元のPCで動いている開発用サーバー（ポート3000）の画面が表示されます。社内ネットワークやNATの内側にいても、外部にサービスを一時的に公開できる強力な裏技です。

⚠️ リモートフォワード時の注意点（GatewayPorts）
リモートフォワードを成功させるには、中継となるVPS（AlmaLinux側）のSSH設定ファイル（/etc/ssh/sshd_config）において、GatewayPorts yes が設定され、systemctl restart sshd で反映されている必要があります。これが no のままだと、VPSのローカル（127.0.0.1）からしか転送ポートにアクセスできません。

6-2. ProxyJump (-J) による多段SSHの簡略化

セキュリティの厳しいエンタープライズ環境では、本番のDBサーバーに直接SSHすることはできず、必ず「踏み台（Bastion）サーバー」を経由しなければならない構成（多段SSH）が一般的です。
昔は複雑な ~/.ssh/config を書く必要がありましたが、現在のSSHでは -J (ProxyJump) オプション を使うだけで一撃で貫通できます。

# 踏み台サーバー（bastion）を経由して、プライベート網のDBサーバー（10.0.0.5）に直接ログインする
ssh -J user@bastion.example.com user@10.0.0.5

このオプションを知っているだけで、日々の煩わしいログイン作業から解放されます。

総まとめ：ネットワークとセキュリティを完全に支配せよ

連載の付録記事「ネットワーク調査コマンドとSSHポートフォワーディング」、いかがだったでしょうか。
インフラの障害調査において、「繋がらない」という曖昧な事象を論理的に分解し、レイヤーごとに正しいコマンドを叩けるかどうかが、問題解決のスピードを劇的に変えます。

ip a / ip route： 自分のIPと外部への出口（ルーティング）を確認する。
ss -tnlp： サーバーが本当にポートを開けて待ち受けているか、バインドIPを含めて確認する。
dig +short： DNSの名前解決が正しく行われているかを検証する。
curl -I / -v： HTTPレイヤーの生の通信状態とAPIのレスポンスを可視化する。
ssh -L / ssh -R： ファイアウォールに穴を開けることなく、SSHの暗号化トンネルを利用して安全にポートを転送する。

これまでに学んだLinuxの基礎（ファイル、権限、プロセス、デーモン、バックアップ）に、この「ネットワークと通信経路の支配力」が加われば、あなたはもうどんなシステム環境に放り込まれても、一人で問題を解決し、セキュアなインフラを構築・運用できる確かな実力を持っています。

本編8回、そしてこの特別付録を通じて、皆様が「黒い画面」の奥にあるLinuxの美しさと合理性に触れ、インフラエンジニアとしての誇りを持っていただけたなら、これに勝る喜びはありません。
本当にお疲れ様でした。これからも LINUX工房と共に、果てしない技術の探求を続けていきましょう。リナックス先生でした！