変更要約: 初版
6.3IPサービスとポート番号（DHCP・DNS・NAT・SNMP・NTP）
アプリ/自動化が依存する共通IPサービス——DHCP（IP自動割当）・DNS（名前解決）・NAT（アドレス変換）・SNMP（監視）・NTP（時刻同期）——と、覚えるべきポート番号（SSH 22 / Telnet 23 / HTTP 80 / HTTPS 443 / NETCONF 830 / SNMP 161 / NTP 123 / DNS 53 / DHCP 67・68）を、「どのサービスが欠けるとAPI呼び出しがどう壊れるか」という診断として学びます。
自動化スクリプトの1行 requests.get("https://api.example.com/devices") の裏では、DNS が名前を解決し、NAT がソースアドレスを変換し、正しいポート番号（HTTPSなら443）で相手に届く必要があります。これらIPサービスやポートのどれか一つが欠けても、症状は「アプリが動かない」に見えますが、原因はまったく異なります。この節では、アプリ/自動化が依存するDHCP・DNS・NAT・SNMP・NTPの役割と、暗記必須の主要ポート番号を、「この失敗はどのサービス/ポートの問題か」を言い当てるための知識として整理します。
6.3.1主なIPサービス
- DHCP（UDP 67サーバ/68クライアント）＝IPアドレス・サブネットマスク・デフォルトゲートウェイ・DNSサーバをホストへ自動配布する。DHCPが機能しないと、そもそも正しいIP/GW/DNSが入らず、その先のあらゆる通信が成立しない。
- DNS（UDP/TCP 53）＝ホスト名をIPアドレスに解決する。自動化がエンドポイントをFQDNで指定する以上、DNSが引けなければ
Name or service not knownで接続前に失敗する。NAT＝プライベートIPをグローバルIPへ（またはその逆に）変換し、内部ホストが外部と通信できるようにする。戻りの対応付け（変換テーブル）が壊れると片方向だけ通る等の症状になる。 - SNMP（UDP 161、トラップは162）＝デバイスの状態をポーリング/通知で監視する。NTP（UDP 123）＝機器/サーバの時刻を同期する。時刻ずれは自動化に致命的で、TLS証明書の有効期限判定・APIトークンの期限・ログの相関・Kerberos認証などが時刻依存なため、NTP不良は「証明書エラー」「認証失敗」として表面化しやすい。
6.3.2暗記必須のポート番号
- 管理/API系：SSH
22（TCP）/ Telnet23（TCP・平文で非推奨）/ HTTP80（TCP）/ HTTPS443（TCP）/ NETCONF830（TCP・SSH上）。自動化のRESTCONFはHTTPS443、NETCONFは830を使う点が頻出——「NETCONFはSSHだから22」と誤らないこと。 - インフラサービス系：DNS
53（UDP/TCP）/ DHCP67・68（UDP）/ SNMP161（トラップ162・UDP）/ NTP123（UDP）/ Syslog514（UDP）。ファイアウォール越しに自動化を通すときは、これら通すべきポートを許可できているかが接続性の要になる。
ポート番号を丸暗記：SSH 22 / Telnet 23 / HTTP 80 / HTTPS 443 / NETCONF 830 / DNS 53 / DHCP 67・68 / SNMP 161（trap 162）/ NTP 123 / Syslog 514。RESTCONF=HTTPS(443)・NETCONF=830 の取り違え、NTPの時刻ずれが証明書/認証エラーに化ける点、DNS失敗は接続前に Name or service not known で落ちる点が狙われます。
あなたのCI/CDパイプラインは毎晩、Ciscoデバイス群へ HTTPS（RESTCONF/443）で設定を投入します。ある朝から突然、全ジョブが SSL: CERTIFICATE_VERIFY_FAILED: certificate is not yet valid で失敗し始めました。エラー文字列だけ見ると「証明書を入れ替えよう」と考えがちですが、これは時刻の罠です。not yet valid（まだ有効でない）は、証明書の有効期間開始日よりクライアントの時計が過去にずれていることを意味します。実際、CIランナーの date を見ると数日前を指しており、原因はNTP（UDP/123）の同期不全でした。ランナーが最近別セグメントへ移設され、経路上のファイアウォールでUDP/123が許可されていなかったため時刻がドリフトし、TLS検証が時刻依存で失敗していたのです。ここで学ぶべきは、症状（証明書エラー）と真因（NTP/ポート遮断）が別レイヤにあること、そして自動化の失敗を切り分けるときは「エラー文字列を額面どおり受け取らない」ことです。仮にNTPが正常でも、次に確認すべきはDNS（53）でエンドポイントFQDNが正しく引けているか（Name or service not known なら接続前に落ちる）、RESTCONFの 443 がファイアウォールで通っているか（830 のNETCONFと取り違えていないか）、NAT変換で戻りトラフィックが対応付いているか、という具合に、依存するIPサービスとポートを一つずつ潰していくことです。エラー文字列→依存サービス→通すべきポート、という順に辿れば、アプリのコードに触れる前に多くの接続性障害は特定できます。
| サービス/プロトコル | ポート | L4 | 欠けたときのアプリ影響 |
|---|---|---|---|
| SSH | 22 | TCP | CLI/一部自動化の管理接続が張れない |
| HTTPS（RESTCONF） | 443 | TCP | REST API/RESTCONF呼び出しが不通 |
| NETCONF | 830 | TCP | NETCONFセッションが確立しない |
| DNS | 53 | UDP/TCP | FQDN解決不可で接続前に失敗 |
| DHCP | 67/68 | UDP | IP/GW/DNS未取得で通信全般不能 |
| SNMP | 161（trap 162） | UDP | 監視ポーリング/通知が届かない |
| NTP | 123 | UDP | 時刻ずれで証明書/トークン/認証が失敗 |
ひっかけ： 「NETCONFはSSH上だからポートは22」は誤りです——NETCONFの既定は830（SSHトランスポートを使うが専用ポート）。また「certificate is not yet valid/has expired は必ず証明書の入れ替えで直る」も誤り＝NTPの時刻ずれが原因のことが多く、正しくは時刻同期の修復（UDP/123の許可含む）です。RESTCONF=HTTPS(443) と NETCONF=830 の取り違えにも注意。
6.3.3この節のまとめ
- アプリ/自動化はDHCP(67/68)・DNS(53)・NAT・SNMP(161)・NTP(123)に依存し、どれが欠けても「アプリ不調」に見えるが原因は別々
- 主要ポートを暗記：SSH 22 / Telnet 23 / HTTP 80 / HTTPS 443 / NETCONF 830 / DNS 53 / SNMP 161 / NTP 123。RESTCONF=443・NETCONF=830 を混同しない
- エラー文字列を額面で受けない：
not yet valid/expiredはNTPの時刻ずれ、Name or service not knownはDNS、connection refused/timeoutはポート遮断/経路を先に疑う
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. CI/CDが毎晩RESTCONF（HTTPS/443）で設定投入していたが、ある朝から全ジョブが `SSL: CERTIFICATE_VERIFY_FAILED: certificate is not yet valid` で失敗する。CIランナーの `date` は数日前を指している。最も適切な一次対応はどれか。
Q2. 自動化スクリプトが `requests.get("https://api.example.com/devices")` を実行すると、TCPハンドシェイクに至る前に `Name or service not known` で即座に失敗する。同一ホストから `https://203.0.113.10/devices`（IP直指定）だと成功する。原因として最も適切なものはどれか。
Q3. ネットワーク機器のNETCONFセッションを自動化から確立したいが、ファイアウォールで通すべきポートを一つだけ許可申請する。RESTCONF（HTTPS）とは別に、NETCONFに必要なポートとして最も適切なものはどれか。