VPN経由でNmapの生スキャンが失敗するのに-sT接続は通るのはなぜ?
生パケットスキャンと通常のTCP接続では必要な権限が異なります。まず接続確認を実行し、各フラグを文字どおりに読み、結果で止めてください。
トンネル経由でページは読み込めるのに、ポートスキャンはホストをダウンと報告するので、最初に疑うのはVPNが何かを遮断しているという説だ。しかし多くの場合、VPNは新しい何も遮断していない。二つの試験はOSに別の能力を要求しており、生パケットアクセスを必要とするのは片方だけだ。トンネルに触れる前に、どちらの能力が失敗したのかを切り分けよう。
能力とトンネルを切り離す
通常のアプリケーションはカーネルにTCP接続の開始を求め、カーネルは特別な権限なしでハンドシェイクを行う。生スキャンはパケットを自分で組み立てるため、プラットフォームによって生ソケットかキャプチャ用ドライバが必要になる。これは権限とドライバの問題であり、VPNが接続されていてもいなくても存在する。
この違いがよくある非対称性を説明する。curl が成功するのはソケット経路が機能しているからで、SYNスキャンが失敗するのはプロセスがトンネルのインターフェイス上で生ソケットを開けないからだ。逆のケースも説明でき、経路がプローブを捨てるために生スキャンがフィルタ済みと報告する一方で、アプリケーションの経路は正常なままだ。
どちらの結果もリモートサービスを説明していない。どちらも一つの方法の下での一つの経路を述べているだけなので、方法を結論に結び付けておこう。
承認済みのホスト一つで接続確認を実行する
作業対象となる単一のホストを選び、生アクセスを必要としないモードを使う。ここでの例の対象は 198.51.100.24 で、この種の例示のために予約されたドキュメント用アドレスだ。
一行、一ホスト、一ポート、探索段階なし:
nmap -sT -Pn -p 443 --unprivileged 198.51.100.24-sT は完全なTCP接続を選ぶため、アプリケーションが使うのと同じカーネル経路を通り、キャプチャ用ドライバを必要としない。-Pn はホスト探索を省くが、nmap はローカルセグメントの対象についてリンク層の解決を依然として行うので、このフラグは事前通信がゼロになる約束ではない。--unprivileged は生パケットや傍受の権利がないものとみなすよう nmap に伝え、方法を変えるだけで何も与えない。
各フラグは一つの変更として読み、修理として読まない
どのオプションも方法についての表明として扱う。-sT、-Pn、--unprivileged のいずれも経路を追加せず、遠隔のファイアウォールを開けず、証明書を検証しない。接続スキャンもサービスが記録する実際のハンドシェイクを完了するため、承認された確認と承認されていない走査は、範囲と速度を除けばサーバ側からは同じに見える。出力が変わるまでオプションを積み重ねるのは、方法の問題をネットワーク上の所見として記録してしまう仕方だ。
出力が closed と言うときは、何かがリセットで応答しており、これは沈黙とは別の所見だ。出力が filtered と言うときは、装置がプローブかその応答を捨てており、VPNは偶然関係しているだけかもしれない。正確な文言を記録しよう、探索段階の判定とプローブ段階の失敗は別の層を指しているからだ。
特権モードが本当に必要な場合は、権限・ドライバ・インターフェイス構成がサポートされるかをプラットフォームの所有者が判断する。同じ呼び出しを昇格しても方法は変わらない。
トランスポートの結果で止め、そのうえでサービスを試す
完了したハンドシェイクが答えるのは、一つのアドレス、ポート、送信元、時点についての一つの問いだけだ。ロードバランサや前方プロキシが接続を受け付け、その背後のアプリケーションが停止していることもあるため、バックエンドが健全だとは証明できない。
続けてサービス自身のクライアントを使い、TLSの同一性とアプリケーションの挙動を別々の事実として観察する:
openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/healthもう一つの習慣が結果を役立たせる。正確なコマンド、使用した送信元アドレス、時刻を記録しよう、その文脈のないトランスポート結果は再現も比較もできないからだ。
証明書が予想外のホスト名を示すなら、トランスポートは機能しており、経路が問題だったことはない——不具合はバーチャルホスティングかDNSにある。ハンドシェイクが失敗するなら、トンネルについて一般化せず、ローカルのエラー文字列を記録する。範囲の注記を結果の隣に残しておこう、次に読む人がどの方法で得た結果かを知る必要があるからだ。