プロキシが誰にでも開放されていないか確認する

新しいフォワードプロキシを他のネットワークから到達可能にする前に、アクセス境界を試します。サーバー自身からの成功だけでは、無関係なクライアントに何ができるかはほとんど分かりません。拒否された要求が実際に転送されたかを判別できるよう、管理下の宛先を使います。

実効的な待ち受けと方針を確認する

待ち受けプロセスとアドレスを調べ、有効なら IPv6 も含めます。意図しない追加の待ち受けや古いサービスインスタンスを除きます。ネットワークのファイアウォールは、到達を認める送信元に限定します。

次に、取り込み先ファイルも含めてプロセスが実際に読んだ設定を確認します。Squid 6 では先行する許可によって後の制限が無効になることがあります。Tinyproxy 1.11.2 ではAllow と Deny の全行を削除するとすべてのクライアントが許可されます。Dante には別々の client 規則と SOCKS 規則があり、TCP 接続の許可だけでは方針全体を表しません。

インストール済み版の文書を使います。Squid 8 のディレクティブ変更は、版を確かめる理由です。慣れた設定が同じ意味で受理されたと考えてよい理由ではありません。

承認済みの送信元とログインの両方を要求するプロキシなら、自分が管理するシステムで次の組み合わせを試します。

同じ NAT 配下の二台は、同一の送信元に見える場合があります。プロキシで異なる送信元アドレスになる場所を選び、ログでも確認します。無関係な第三者の機器を使ったり、他人のサービスを走査したりしないでください。

ファイアウォールの拒否では HTTP 応答が一切ない場合があります。アプリケーションの拒否はエラーを返す場合があります。どちらでも、管理下の宛先が禁止要求を受け取っていないと確認します。エラーページだけでは宛先の応答と取り違える可能性があります。

ウェブプロキシでは、通常の HTTP 要求と許可された HTTPS CONNECT 経路を分けて試します。宛先制限も方針の一部なら、許可宛先と、本来拒否される管理下の宛先を試します。すべてを成功させるために制御を外してはいけません。

送信元範囲、認証情報、待ち受けアドレス、取り込みファイル、サービス版を変更したら再試験します。試験時刻、設定版、結果を一緒に残し、後の変更を同じ境界と比較できるようにします。

これは受け入れ手順です。設定パーサーや一度の要求だけで、すべてのネットワーク経路が閉じていると証明できるという主張ではありません。