networking

Name: networking
Author: iuliandita

github.com/iulianditaクラウド・DevOps1088 回インストール1 日前に更新

リポジトリ

networking について

Linux ネットワークの設定、トラブルシューティング、性能調整を支援するスキルです。DNS、プロキシ、VPN、ファイアウォール、ルーティングを扱い、変更の検証とロールバックも重視します。

主な機能

01DNS とリバースプロキシの設定
02VPN、ファイアウォール、VLAN の構成
03ルーティングと高可用性の設定
04ネットワーク診断と性能調整
05変更の検証とロールバック

活用シーン

01DNS や接続障害の調査
02VPN とネットワーク分割の設定
03プロキシとロードバランサーの構成
04安全なネットワーク性能の調整

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/iuliandita/skills --skill networking

インストール後、Claude Code で/networkingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

agent-hygiene.md

cheat-sheets.md

dns.md

ha.md

output-contract.md

reverse-proxies.md

segmentation.md

troubleshooting.md

vpn.md

詳細

ネットワーキング：設定、トラブルシューティング、最適化

Linux ネットワーキングインフラストラクチャを設定、トラブルシューティング、最適化します。DNS、リバースプロキシ、VPN、ファイアウォール（nftables）、VLAN、サブネット分割、高可用性、動的ルーティング、ネットワークパフォーマンスのチューニングを扱います。

対象バージョン（2026年10月）：

ツール	バージョン	備考
Caddy	2.11.6	自動HTTPS、Caddyfile + JSON API。GHSA-6365-7ppr-5r92 は 2.11.5 以降で修正済み
Nginx	1.30.5 stable / 1.31.6 mainline	CVE-2026-90439 に対するパッチ適用済み。CVE-2026-42533/60005/56434 の修正を含む
Traefik	3.7.13（v2 系列は 2.11.57）	Gateway API ネイティブ対応。v2 は EOL が近づいています
HAProxy	3.4.6 LTS / 3.3.16 stable / 3.2.25 LTS	3.4 LTS の EOL は 2031-Q2
WireGuard tools	1.0.20260223	カーネルモジュール + ユーザー空間ツール
strongSwan	6.1.0（CVE-2026-78133 およびその他 10 件を修正、2026-09-07）	swanctl 設定（レガシーな ipsec.conf は非推奨）
nftables	1.1.7	iptables の後継。最新のディストリビューションではデフォルト
keepalived	2.4.3	VRRP + ヘルスチェック
Unbound	1.26.1	2026-09-16 の勧告後に必要となるセキュリティ下限バージョン
CoreDNS	1.14.7	K8s のデフォルト DNS。プラグインベース
FRRouting	10.7.1	10.6.2/10.5.5/10.4.5 と同時に 2026-08-31 リリース
Tailscale / Headscale	Headscale 0.29.4	セルフホスト可能なコントロールサーバー
cloudflared	2026.9.3	Cloudflare Tunnel（アウトバウンドのみ）
OpenVPN	2.7.7 / 2.6.23 LTS	2.7.x：マルチソケット、DCO。2.6 は LTS ブランチ

セキュリティ再確認（2026-10-02）：nginx の公開元の勧告では、CVE-2026-90439（HTTP/3 バッファオーバーフロー）の深刻度は medium とされています。影響を受けるのは 1.29.2-1.31.5 で、1.30.5 以降または 1.31.6 以降で修正済みです。CVE-2026-42533（map/正規表現のバッファオーバーフロー）の深刻度は major です。影響を受けるのは 0.9.6-1.31.2 で、1.30.4 以降または 1.31.3 以降で修正済みです。CVE-2026-60005 および CVE-2026-56434 も同じ 1.30.4+/1.31.3+ リリースで修正されました。CVE-2026-42530（HTTP/3 の use-after-free）は 1.31.0-1.31.1 に影響し、1.31.2 以降で修正済みです。これとは別の、より早期に報告された CVE-2026-42945（rewrite のバッファオーバーフロー）は 1.30.1/1.31.0 で修正されました。有効なモジュールとベンダーによるバックポートを確認してください。 Unbound の勧告でも CVE-2026-32665 の深刻度は high とされています。DoQ を有効にした 1.22.0-1.25.1 が影響を受け、1.25.2 で修正されています。影響範囲を評価する前に、コンパイル時の DoQ サポートと設定済みのリスナーを確認してください。

使用する場面

DNS サーバーの設定（Unbound、CoreDNS、dnsmasq、BIND9、Pi-hole、AdGuard Home）
リバースプロキシとロードバランサーの設定またはトラブルシューティング
VPN の設定（WireGuard、OpenVPN、IPsec）とオーバーレイネットワーク
Linux ファイアウォールルール（nftables、レガシーな iptables）
VLAN の設定、サブネット分割、ネットワークセグメンテーション
keepalived/VRRP、フローティング IP による高可用性
ネットワーク診断（tcpdump、mtr、ss、dig、iperf3、Wireshark/tshark）
TCP/ネットワークパフォーマンスのチューニング（MTU、バッファ、輻輳制御、バッファブロート）
FRRouting による動的ルーティング（BGP、OSPF）
ネットワークサービスの TLS/証明書管理
スプリットホライズン DNS、DNS-over-HTTPS/TLS、DNSSEC

使用しない場面

OPNsense/pfSense ファイアウォールアプライアンスの管理（opnsense-pfsense を使用）
Web の閲覧、スクレイピング、またはヘッドレスブラウザーによるページ操作 — ホストのブラウジングツールを使用
Kubernetes ネットワーキング：NetworkPolicy、Gateway API、サービスメッシュ、CNI（kubernetes を使用）
Kubernetes クラスター全般のヘルスチェック、ノードの状態、メンテナンス後の診断（kubernetes-health を使用）
Docker/コンテナネットワーキング：ブリッジ、オーバーレイ、Compose ネットワーク（docker を使用）
クラウド VPC、セキュリティグループ、マネージドロードバランサー（terraform を使用）
プレイブックによる大規模なネットワーク設定管理（ansible を使用）
攻撃的なペネトレーションテスト、エクスプロイト、ラテラルムーブメント（privilege-escalation を使用）
アプリケーションレベルのセキュリティレビュー、SSRF、ヘッダーインジェクション（security-audit を使用）
パイプライン規模での CI/CD による自動化ネットワーク設定管理（ci-cd を使用）

AI によるセルフチェック

生成したネットワーク設定を返す前に、次の項目を確認してください。

パフォーマンス

調整を行う前に、経路、DNS、TLS、アプリケーションのレイテンシーを個別に測定します。
大容量のキャプチャやプライバシー情報の漏えいを避けるため、狭いフィルターと時間範囲を指定してパケットをキャプチャします。
適切な場合は、永続的な nftables セット、DNS キャッシュ、プロキシ接続の再利用を優先します。

ワークフロー

変更を行う際は、このチェックリストをコピーして進捗を記録してください。

- [ ] Step 1: Task type identified and matching reference read
- [ ] Step 2: Current state captured (addresses, routes, firewall, DNS manager, VPNs)
- [ ] Step 3: One change applied with a saved config and an armed rollback
- [ ] Step 4: Validated (on failure: restore, fix, return to Step 3)

ステップ 1：タスクの種類を特定する

タスクの種類	最初に確認する項目	参照先
トラブルシューティング	症状、最近の変更、影響範囲	`references/troubleshooting.md`
DNS の設定	現在のリゾルバー、権威 DNS と再帰 DNS のどちらか、スプリットホライズンの要件	`references/dns.md`
リバースプロキシのセットアップ	使用するプロキシ、アップストリームサービス、TLS の要件	`references/reverse-proxies.md`
VPN の設定	トポロジー（p2p、ハブ・スポーク、メッシュ）、プロトコルの選択	`references/vpn.md`
ネットワークのセグメンテーション	VLAN、サブネット、nftables のゾーン、名前空間	`references/segmentation.md`
高可用性	keepalived/VRRP、フローティング IP、ヘルスチェック	`references/ha.md`

Step 2: コンテキストを収集する

設定ファイルを作成したり、コマンドを実行したりする前に、次の点を確認します。

ディストリビューションと init システムは何ですか？（systemd と OpenRC のどちらかによって、サービス管理に影響します）
現在のネットワーク状態はどうなっていますか？（ip addr、ip route、ss -tlnp、resolvectl status）
既存のファイアウォールはありますか？（nft list ruleset、iptables-save）
DNS は誰が管理していますか？（resolvectl status または cat /etc/resolv.conf を実行して、systemd-resolved のスタブを確認します）
既存の VPN／オーバーレイはありますか？（wg show、tailscale status、ip link を実行して tun／wg／vxlan デバイスを確認します）
NAT の背後にありますか？（VPN、リバースプロキシ、高可用性の設計に影響します）

Step 3: 実装する

詳細なパターンについて、適切なリファレンスファイルを読みます。主な原則は次のとおりです。

永続化する前にテストします。 nftables ルールを追加し、接続を確認してから保存します。リバースプロキシの設定変更は、適用前に --dry-run または構文チェック（caddy validate、nginx -t、haproxy -c）を実行します。
変更は一度に1つだけ行います。 SSH 経由では、変更対象となる正確なルール／ルート／マネージャー設定を保存し、適用前にテスト済みの復元コマンドをスケジュールします。一般的なネットワークの再起動はロールバックになりません。systemctl list-timers nft-rollback.timer を実行してタイマーの存在を確認します。2つ目のセッションで管理アクセスと、意図した通信の許可／ブロックを確認できた後にのみ、タイマーをキャンセルします。nftables では、次のコマンドをそのまま実行します。
```
nft -c -f new.nft                                  # syntax check; stop on error
{ echo 'flush ruleset'; nft list ruleset; } > /root/nft-rollback.nft
systemd-run --on-active=5m --unit=nft-rollback \
  nft -f /root/nft-rollback.nft                   # one atomic transaction
nft -f new.nft
systemctl list-timers nft-rollback.timer           # confirm the rollback is armed
systemctl stop nft-rollback.timer                  # only after the second-session check
```
変更内容を記録します。 何を変更したのかわからないと、ネットワークのデバッグは10倍難しくなります。

Step 4: 検証する

チェックに失敗した場合は、保存した設定を復元する（またはロールバックタイマーが作動する）のを待ち、変更を修正して Step 3 に戻ります。まず、不足しているツールを確認します。 for t in dig mtr tcpdump iperf3 nft wg; do command -v "$t" >/dev/null || echo "missing: $t"; done

検証項目	方法
DNS 解決	`dig @server domain A +short`、`dig domain AAAA +short`
リバースプロキシ	`curl -v https://domain`（証明書の信頼性、ヘッダー、アップストリームの応答を確認します）
VPN トンネル	`wg show`（WireGuard）、トンネル経由の `ping`、`ip route` の確認
ファイアウォールルール	`nft list ruleset`、許可される通信とブロックされる通信の両方をテストします
VLAN タグ付け	`ip -d link show`、`tcpdump -e -i interface`（802.1Q タグを確認します）
HA フェイルオーバー	プライマリを停止し、VIP が移行することを確認して、`journalctl -u keepalived` を確認します
パフォーマンス	`iperf3 -c server`、`mtr target` を実行し、パケット損失とジッターを確認します

クイックリファレンス：診断ツール

ツール	用途	主な使用方法
`ip`	インターフェイス、ルート、近隣ノード、ルールの管理	`ip addr`、`ip route`、`ip neigh`、`ip link`
`ss`	ソケット統計情報（netstat の代替）	`ss -tlnp`（TCP リスナー）、`ss -ulnp`（UDP）
`dig`	DNS クエリ	`dig @8.8.8.8 example.com A +short`
`mtr`	traceroute と ping の統合	`mtr -n --report target`（非対話型）
`tcpdump`	パケットキャプチャ	`tcpdump -i any -nn port 53`（DNS トラフィック）
`tshark`	Wireshark の CLI	`tshark -i any -f 'port 443' -Y 'tls.handshake'`
`curl`	HTTP テスト	`curl -v -o /dev/null https://target`（検証済み TLS と HTTP の詳細）
`iperf3`	帯域幅テスト	サーバー：`iperf3 -s`／クライアント：`iperf3 -c server`
`nft`	nftables ルール管理	`nft list ruleset`、`nft monitor trace`
`wg`	WireGuard の状態確認	`wg show`、`wg showconf wg0`
`resolvectl`	systemd-resolved の状態確認	`resolvectl status`、`resolvectl query domain`
`nmap`	ポートスキャン、サービス検出	`nmap -sV -p 1-1024 target`
`socat`	多目的リレー	`socat TCP-LISTEN:8080,fork TCP:backend:80`

クイックリファレンス：CIDR と DNS

CIDR／ネットマスクと DNS レコードタイプの対応表は references/cheat-sheets.md にあります。対応関係そのものが必要なタスクの場合にのみ、このファイルを読み込みます。

クイックリファレンス：リバースプロキシの選択

プロキシ	最適な用途	TLS	設定スタイル	L4 対応
Caddy	シンプルな構成、自動 HTTPS	自動（ACME）	Caddyfile / JSON API	対応（実験的）
Nginx	高トラフィック、静的ファイル	手動または certbot	nginx.conf	対応（stream モジュール）
Traefik	Docker/K8s、動的バックエンド	自動（ACME）	ラベル / ファイル / K8s CRD	対応（TCP/UDP）
HAProxy	純粋なロードバランシング、L4/L7	手動	haproxy.cfg	対応（ネイティブ）

新しい単一ホスト構成では Caddy をデフォルトとして使用し、すでにプロキシが導入されている場合はそれを引き続き使用します。

Caddy リバースプロキシのクイックスタート

# /etc/caddy/Caddyfile - three subdomains, auto-HTTPS
app.example.com {
    reverse_proxy localhost:3000
}

api.example.com {
    reverse_proxy localhost:8080
}

grafana.example.com {
    reverse_proxy localhost:3001
}

Caddy は ACME（Let's Encrypt）を通じた TLS 証明書の取得を自動的に処理します。3 つすべてのサブドメインの DNS A/AAAA レコードがホストを指している必要があります。次のコマンドで検証します：caddy validate --config /etc/caddy/Caddyfile。

設定パターン、TLS のセットアップ、ヘルスチェック、レート制限、WebSocket/gRPC のプロキシについては、references/reverse-proxies.md を参照してください。

クイックリファレンス：VPN プロトコルの選択

プロトコル	速度	複雑さ	鍵交換	最適な用途
WireGuard	最速	最小限の設定	Noise（Curve25519）	P2P、ハブアンドスポーク、一般用途
OpenVPN	良好	複雑な PKI	TLS/x509	レガシー環境、タップモード（L2）
IPsec (strongSwan)	良好	最も複雑	IKEv2	拠点間接続、標準への準拠
Tailscale/Headscale	高速（内部で WG を使用）	設定不要	WG + DERP リレー	オーバーレイメッシュ、リモートアクセス
Nebula	高速	低	証明書ベース	大規模メッシュ、Slack 規模

「最適な用途」の列に記載された要件がある場合に限り、WireGuard 以外を選択します。

WireGuard 拠点間接続のクイックスタート

各ピアはローカル LAN へのルートを設定する必要があります。WireGuard が LAN のデフォルトゲートウェイではなく別のホストで実行されている場合は、各 LAN ゲートウェイに、リモート LAN へのルートをローカルの WireGuard ホスト経由で追加します。両方向の戻りルート、フォワーディング、ファイアウォールポリシーを確認してください。トンネルピアへの ping だけでは、LAN 間の接続性を証明できません。

# Site A (/etc/wireguard/wg0.conf) - 10.0.1.0/24
[Interface]
PrivateKey = <SITE_A_PRIVATE_KEY>
Address = 10.100.0.1/30
ListenPort = 51820
# MTU: derive from measured underlay; 1420 for 1500-byte underlay with 80-byte overhead,
# or 1412 for a 1492-byte PPPoE underlay with the same overhead.

[Peer]
PublicKey = <SITE_B_PUBLIC_KEY>
Endpoint = site-b.example.com:51820
AllowedIPs = 10.0.2.0/24, 10.100.0.2/32
PersistentKeepalive = 25

# Site B (/etc/wireguard/wg0.conf) - 10.0.2.0/24
[Interface]
PrivateKey = <SITE_B_PRIVATE_KEY>
Address = 10.100.0.2/30
ListenPort = 51820

[Peer]
PublicKey = <SITE_A_PUBLIC_KEY>
Endpoint = site-a.example.com:51820
AllowedIPs = 10.0.1.0/24, 10.100.0.1/32
PersistentKeepalive = 25

両側で /etc/sysctl.d/ に net.ipv4.ip_forward = 1 を設定する必要があります。AllowedIPs はリモートサブネットを指定します（0.0.0.0/0 ではありません。これは拠点間接続ではなく、フルトンネルの設定です）。references/vpn.md に従い、umask 077 を設定した新しい保護済みディレクトリで鍵を生成してください。既存の鍵を上書きしないでください。

セットアップパターン、鍵管理、MTU の調整、NAT トラバーサル、オーバーレイネットワークの比較については、references/vpn.md を参照してください。

クイックリファレンス：nftables と iptables の比較

iptables はレガシーです。nftables は Debian 11+、RHEL 9+、Arch、および最新のディストリビューションの大半でデフォルトです。

# Minimal nftables ruleset - stateful firewall with SSH
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    icmp type echo-request accept
    icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-advert } accept
  }
  chain forward { type filter hook forward priority 0; policy drop; }
  chain output { type filter hook output priority 0; policy accept; }
}

VLAN のセットアップ、nftables ゾーン、ネットワーク名前空間、VLAN 間ルーティングのパターンについては、references/segmentation.md を参照してください。

PCI-DSS 4.0 との関連性

ネットワーク設定は、PCI-DSS の複数の要件に関係します。

要件	領域	確認事項
1.2	ネットワークセキュリティ制御	ファイアウォールルールにより、インバウンド／アウトバウンド通信を必要最小限に制限していること
1.3	CDE のセグメンテーション	CDE とその他のネットワークの間で、VLAN、nftables、または物理的な分離を行っていること
1.4	信頼境界／非信頼境界	リバースプロキシでの TLS 終端、WAF の配置
2.2	ハードニング	不要なサービスを無効化し、未使用のポートを閉じていること
4.1	通信時の暗号化	すべての箇所で TLS 1.2+ を使用し、信頼できないセグメントで平文通信を行わないこと
11.3	ネットワーク監視	IDS/IPS（Suricata）、ログ集約、フロー分析

リファレンスファイル

references/dns.md - DNS サーバーの比較、DNSSEC、スプリットホライズン、 DoH/DoT、Pi-hole/AdGuard、トラブルシューティング
references/reverse-proxies.md - Caddy、Nginx、Traefik、HAProxy の設定パターン、TLS、WebSocket、gRPC、レート制限
references/vpn.md - WireGuard、OpenVPN、IPsec/strongSwan の設定、オーバーレイネットワーク（Tailscale、Headscale、Nebula、ZeroTier）、鍵管理
references/segmentation.md - VLAN、サブネット化、nftables ファイアウォールのパターン、ネットワーク名前空間、IPv6
references/troubleshooting.md - 診断手法、ツールの詳細解説、よくある問題、パフォーマンス調整
references/ha.md - keepalived/VRRP、フローティング IP、HAProxy + keepalived による HA、ヘルスチェックのパターン
references/cheat-sheets.md - CIDR/ネットマスクの表、プライベート/CGNAT/リンクローカル/ULA の範囲、DNS レコードの種類

出力仕様

仕様の全文は references/output-contract.md を参照してください。

スキル名： NETWORKING
成果物の分類： audits
モード： 条件付き。既存のリポジトリコンテンツの分析、レビュー、監査、改善を依頼された場合は、references/output-contract.md に記載されているレポートのサイズと根拠に関するルールを適用し、成果物を docs/local/audits/networking/<YYYY-MM-DD>-<slug>.md に書き込みます。質問への回答、概念の説明、新しい成果物の作成、コンテンツの生成を依頼された場合は、仕様に縛られずに回答します。
重大度の尺度： P0 | P1 | P2 | P3 | info（共通仕様を参照。監査／レビューのモードでのみ使用します）。

ルール

既存のファイアウォールを確認してください。 ルールを追加する前に nft list ruleset と iptables-save を確認してください。同じシステムで nftables と iptables を混在させると、予測不能な動作が発生します。
信頼できないセグメントでは平文を使用しないでください。 すべてのサービスで TLS 1.2 以降を使用してください。TLS なしで信頼できないネットワークを経由させる必要がある場合は、VPN を通じてトンネル化してください。

Markdown 対応

ログインしてコメント

基本情報

作者: iuliandita
リポジトリ: iuliandita/skills
カテゴリ: クラウド・DevOps
インストール数: 88
GitHub スター: 10

問題を報告