変更要約: 初版
6.4アプリ接続性の診断（NAT・ポート遮断・プロキシ・VPN）
アプリや自動化の接続失敗を、NATの変換問題・ファイアウォール等によるポート遮断・企業プロキシの経由要否・VPNの接続/分割トンネル、そして遅延/MTU/レート制限といったネットワーク制約がアプリに与える影響として体系的に切り分けます。「エラー症状→疑うべきネットワーク要因→検証コマンド」を結ぶ診断力を養います。
この章の総仕上げとして、これまでのL2/L3・機器/プレーン・IPサービス/ポートの知識を、「アプリ/自動化が繋がらない」という現場症状から原因ネットワーク要因を言い当てる診断力に束ねます。同じ connection timed out でも、原因はNATの戻り不成立・ファイアウォールのポート遮断・企業プロキシ未経由・VPN未接続と多様で、それぞれ確認手順も対処もまったく違います。「エラー文字列を額面で受けず、疑うべきネットワーク要因を順序立てて検証する」——この節ではその型を身につけます。
6.4.1接続を止める主なネットワーク要因
- NAT問題＝内部ホストのプライベートIPを外部向けに変換するが、変換テーブルの対応付けや戻り経路が壊れると、外へは出るのに応答が返らない・片方向だけ通る等になる。特に同一ホストから複数の外向き接続や、内部同士を外部VIP経由で呼ぶヘアピンNATは落とし穴。症状は「たまに繋がる/戻りが来ない」。
- ポート遮断＝ファイアウォール/ACL/セキュリティグループが、必要な宛先ポート（例 RESTCONF
443、NETCONF830、SNMP161）を許可していない。症状はconnection timed out（黙って破棄=ドロップ）やconnection refused（相手が拒否=RST）。pingは通るのに特定ポートだけ不通なら、これを最有力に疑う。 - プロキシ＝企業ネットワークでは外部HTTP/HTTPSがフォワードプロキシ経由でのみ許可されることが多い。スクリプトが
HTTP_PROXY/HTTPS_PROXY/NO_PROXY環境変数を尊重せず直接外へ出ようとすると、境界で遮断され接続できない。VPN＝リモートから社内リソースへ暗号化トンネルで接続する。スプリットトンネルだと社内宛だけVPN経由・その他は直接に分かれ、VPN未接続や経路設定次第で「内部APIにだけ届かない」症状が起きる。
6.4.2ネットワーク制約のアプリ影響
- 遅延（レイテンシ）/ジッタ/パケットロスは、APIの応答時間やタイムアウト、リアルタイム性に効く。高遅延経路ではアプリ側のタイムアウトが短すぎて失敗したり、多数の逐次API呼び出しが積み上がって遅くなる。バルク取得やページング、リトライ/バックオフ設計で緩和する。
- MTU/フラグメンテーション：経路の最小MTUを超える大きなパケットは分割or破棄され、
DF（分割禁止）付きだと大きなHTTPSペイロードだけ失敗する等の厄介な症状になる（VPN/トンネルでMTUが縮む場面で頻発）。レート制限（429）：APIの単位時間あたり呼び出し上限を超えるとサーバが429 Too Many Requestsを返す——ネットワークではなくアプリ側の制約で、バックオフ/リトライ・呼び出し削減で対応する。
症状→要因の対応を押さえる：connection timed out／pingは通るが特定ポート不通＝ポート遮断、外部URLだけ不通で社内は可＝プロキシ未経由、社内APIだけ不通＝VPN/スプリットトンネル、外向きは出るが戻らない＝NAT、大きいペイロードだけ失敗＝MTU、429＝APIのレート制限（アプリ側）。pingの成否だけで判断しない。
あなたの自動化チームは、自宅からVPNで接続した開発者のノートPCで、社内のCatalyst Center（https://dnac.corp.example:443）へRESTCONF/APIを叩くスクリプトが connection timed out になる、という報告を受けました。同じスクリプトはオフィスの有線からは成功します。ここで「APIが落ちた」と決めつけず、症状→要因の型で順に切り分けます。まず外部の公開API（https://api.github.com）は同じPCから成功する——つまりインターネット全般やDNS（53）は生きているので、DNS/プロキシ全滅ではありません。次に社内リソースだけ不通という切り分けから、VPNの経路を疑います。確認すると、この開発者のVPNはスプリットトンネル設定で、社内サブネット（10.0.0.0/8）宛のみトンネル経由・その他は直接に分かれる構成でした。ところがCatalyst Centerのアドレス帯（172.16.0.0/12）がトンネル対象ルートに含まれておらず、社内宛のはずのトラフィックがVPNを通らず直接インターネットへ出て、当然どこにも届かず timed out していたのです。修正はVPNプロファイルのトンネル対象ルートに当該サブネットを含めること（あるいは対象範囲の是正）で、アプリのコードは一切いじりません。さらにこの型は横展開できます——もし「社内も外部も繋がるが特定ポートだけ不通」ならポート遮断（443/830 がファイアウォール/ACLで許可されているか）、「外部URLだけ全滅」ならプロキシ未経由（HTTPS_PROXY を尊重しているか）、「小さいリクエストは通るが大きいレスポンスだけタイムアウト」ならVPNトンネルで縮んだMTUとDFビットによるブラックホール、「バースト的に叩くと 429」ならネットワークではなくAPIのレート制限、と疑う先が変わります。重要なのは、connection timed out という一つの文字列の裏にまったく異なるネットワーク要因が並んでいること、そしてpingの成否や単一のエラー文字列だけで結論づけず、外部/内部の切り分け・特定ポートの可否・経路（VPN/プロキシ/NAT）の確認という順序で潰していくことです。
| 症状 | 疑うべき要因 | 確認の一手 |
|---|---|---|
| pingは通るが特定ポートだけ不通 | ポート遮断（FW/ACL/SG） | 宛先ポートの許可・`telnet host port`/ncで到達確認 |
| 外部URLだけ全滅・社内は可 | プロキシ未経由 | `HTTP(S)_PROXY`/`NO_PROXY` 環境変数を確認 |
| 社内APIだけ不通（外部は可） | VPN/スプリットトンネルの経路 | VPN接続とトンネル対象ルートを確認 |
| 外向きは出るが応答が戻らない | NAT変換/戻り経路 | NATテーブル・ヘアピン要否を確認 |
| 大きいペイロードだけ失敗 | MTU/フラグメンテーション | 経路MTU・DFビット・トンネルを確認 |
| `429 Too Many Requests` | APIのレート制限（アプリ側） | バックオフ/リトライ・呼び出し削減 |
ひっかけ： 「ping が通ればアプリも必ず繋がる」は誤りです——pingはL3到達性のみを見るので、ポート遮断（L4）・プロキシ未経由・VPN経路の欠落・NATの戻り不成立は検出できません。また「429 Too Many Requests はネットワーク障害」も誤り＝これはAPIのレート制限（アプリ側）で、対処はネットワークではなくバックオフ/リトライや呼び出し削減です。
6.4.3この節のまとめ
- 同じ
connection timed outでも要因はNATの戻り不成立・ポート遮断・プロキシ未経由・VPN経路欠落と多様。症状→要因→検証の順で切り分ける - pingの成否だけで判断しない：L3は通ってもL4のポートやプロキシ/VPN/NAT経路で落ちる。外部/内部・特定ポート可否・経路を順に確認する
- ネットワーク制約はアプリに効く：遅延はタイムアウト、MTUは大ペイロード、
429はAPIのレート制限（アプリ側）。要因ごとに対処（バックオフ/経路修正/ポート許可）が異なる
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. VPN接続した在宅開発者のPCから、社内Catalyst Center（`https://dnac.corp.example:443`、`172.16.0.0/12`帯）へのAPI呼び出しが `connection timed out` になる。同じPCから外部の `https://api.github.com` は成功し、オフィス有線からは社内APIも成功する。最も可能性が高い原因はどれか。
Q2. 自動化サーバから対象ルータへ `ping` は成功するが、RESTCONF（HTTPS/443）とNETCONF（830）だけが `connection timed out` になる。ルータの管理プレーンは他ホストからは正常に応答する。最初に疑うべき原因はどれか。
Q3. 自動化クライアントが社内向けAPIには問題なく接続できるが、外部SaaSのAPI（`https://api.saas.example`）へは社内ネットワークからすべて `connection timed out` になる。ブラウザでは同じ外部サイトが開ける。原因として最も適切なものはどれか。