スマートフォンのVPNスキャンに適した観測点の選び方
スマートフォンのVPNリスナー、端末上のサービス、ルーティングされたLANホストは三つの面です。この五つの手順を順に進み、範囲が終わる場所で止めてください。
スマートフォン上で動くVPNの許可された評価は、スキャナがトンネルの反対側に置かれると静かに失敗します。結果は得られ、もっともらしく見え、誰も問わなかった問いに答えてしまいます。以下の五つの確認を順に行ってください。それぞれに停止条件があり、報告書を書いた後にゼロから再試験するより早く止まる方が安く済みます。
手順 1: 到達しようとする面を名指しする
三つの面は一台の端末がつなぐため、日常的に混同されます。それぞれ別のコードと別のポリシーで動くので、何かを始める前にどれが範囲内かを書き留めてください。
| Assessment target | What the path exercises |
|---|---|
| Public VPN listener on the handset | Reachability before login, plus the exposed VPN daemon |
| A service on the handset, by its tunnel address | Access after admission to something hosted locally |
| A LAN host behind the handset gateway | Forwarding, the return path and downstream access policy |
承認された範囲が三つのどれかを示していなければ、止めて確認してください。端末をルート化してもこの問いの答えにはならず、観測点ではなく試験対象そのものが変わります。
対象、許可された送信元アドレス、時間枠、強度の上限を同時に記録します。トンネルはその範囲まで運びますが、経路として通せるすべてを試す許可を与えるわけではありません。
手順 2: その面を見られる送信元を選ぶ
VPNの内側に置かれたスキャナは 認証前のインターネット観測者を再現できません。すでに外部の観測者が持たない経路、資格情報、権限を備えているため、対象の面が同じでも結果は受け入れ後の見え方を述べることになります。逆向きの誤りも同じくらいよく起きます。VPNポートの公開スキャンはログイン背後の非公開サービスについてほとんど何も語らず、語っているかのように報告すると、一方では露出を過大に、他方では過小に示すことになります。
得られる送信元が面と一致しないなら止めてください。トンネル内のピアから実行した評価を認証前の結果として提示してはならず、承認された外部送信元を要する試験を書類仕事を避けるために黙って内側へ移してはなりません。
手順 3: 端末を通る経路と戻り道を確認する
端末が別のサブネットへ転送する場合、スキャナには許可された経路が、対象には機能する戻り道が必要です。ping の応答が経路の完全さを意味すると決めつけず、両方を確認してください。
ip route get 10.20.0.8
tcpdump -ni any host 10.20.0.8送信元NATは下流のサービスが見るものを変えます。端末がスキャナのアドレスを変換すれば、対象のアクセス規則とログは変換後のアドレスに適用されるため、あなたを受け入れているように見えるサービスは、スキャナではなく端末を受け入れている可能性があります。
スキャナ自身のネットワークとの重なりにも注意してください。端末が 192.168.1.0/24 を経路として持ち、スキャナが同じ番号付けのLAN上にあると、探査はローカルの機器に当たり、報告書はそれを対象として記述します。一つのパケットも送る前に、スキャナ自身が使う経路を確認してください。
対象の実際のアドレスをスキャンし、アプリケーションがTLSの同一性と仮想ホスティングに必要とするホスト名を保ってください。ゲートウェイに到達できることはゲートウェイが応答する証明であり、その背後のサービスを試験するものではありません。
手順 4: 探索を仮定を伴う探査として扱う
ホスト探索は評価結果が最もよく狂う場所です。ローカルのEthernet探索はルーティングされたVPNを越えないため、フラットなLANで機能する探査はそもそも届きません。遮断された探索探査は、到達可能で許可されたサービスを存在しないように見せます。
探索を省いて既知のアドレスを直接スキャンするかどうかを意識的に決め、報告書にそう書いてください。応答するポートはVPN認証が成功した証拠ではなく、フィルタされた応答は何も待ち受けていない証拠でもありません。速度も同じ問題の一部です。高速スキャンで絞られたり落としたりする端末は、サービスではなく端末に属するフィルタ状態を生むので、並列度を下げ、ポートを閉じたと記録する前に再スキャンしてください。
ここでの停止条件は技術ではなく解釈です。この経路にとってある状態が何を意味するかを述べられないなら、その結果は所見ではなく付録に属します。
手順 5: 窓を保持し、それから閉じる
スマートフォンは眠るように設計されているため、サーバーとしては不適です。バッテリー最適化、doze、Wi-Fiの電力管理は評価の途中でアプリを停止させることがあり、トンネルの再接続は対象が使うアドレスを変え得ます。そうした事象をまたぐ実行は、結果の窓が無効になります。
ゲートウェイの役割は承認された作業が許す最小の範囲に保ち、実行が生きている間はトンネルを監視し、報告する各窓の開始と終了を記録してください。評価が終わったら、暫定アクセスをその所有者を通じて削除し、送信元と経路の記録を残し、出力を他の試験成果物と同様に保護してください。
一度きりの成功ではなく再現可能な観測点が必要なら、それが主張すべき成果物です。ホスト探索の解説 は、どの探査がローカルセグメントを前提とするかを説明しており、その細部が空の結果を弁護可能な記述に変えます。