TLSラッパーはプライベートネットワークを与えるか？通常は与えない

TLSは二つの端点の間のチャネルを保護し、その内側にどのサービスがあるかについては何も語らない。ラッパーはそのチャネルを一つの設定済みフォワーダーに変える。一つのリスナー、一つの宛先に対してである。SSL VPNとして売られる製品は通常、同じプリミティブの周りにインターフェース、ルートテーブル、アクセスモデルを加える。両者を混同することが、動作するトンネルをネットワークアクセスと取り違える原因である。

サービスのラッパーが実際につなぐもの

ラッパーはローカルポートで待ち受け、届いたものを設定済みの宛先へ転送する。宛先はホストとポートでもローカルプログラムでもよい。その宛先を選ぶのは設定ファイルを書いた者であり、一度に一つのリスナーである。パッケージをインストールしても、ルートも仮想インターフェースも、明示的に列挙されていないものへの到達性も作られない。パッケージの説明より先に設定を読むべきだ。説明は利用の種類を扱い、ファイルはあなたの事例を扱うからである。

したがってラッパーについて有用な問いは、暗号化するかどうかではなく、それが作る連鎖の各端に何があるかである。

application -> local listener -> TLS connection -> remote listener -> configured backend

その連鎖はマーケティング上の名前ではなく設定から読む。各矢印は独自のアドレスと独自のアクセス規則を持つ別個のネットワークホップだ。

TLSチャネルが終わる場所を見つける

ラッパーがTLSを終端するなら、その先へ転送するものはすべて新しい性質を持つ新しい接続である。ストリームはプライベートセグメント上の平文かもしれないし、内部に別の保護プロトコルを運ぶかもしれない。バックエンドの設定を読まずにどちらかを仮定するのは、外側の層が二度と見ないデータを保護していると人々が結論づける道である。転送されたホップは、それ自身のアドレスとポートで独自に検査されるべきだ。

リスナーとバックエンドを別々に確認すべきだ。玄関で成功するハンドシェイクは、その背後のサービスについては何も語らない。

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

最初のコマンドはどのプロセスがポートを所有し、どのアドレスで待ち受けているかを示す。二つ目はクライアントが実際に受け取る証明書を出力する。これはポート番号では置き換えられない同一性の確認である。

ルーティングVPNが加え、ラッパーが加えないもの

ルーティングVPNはインターフェースをインストールし、選択したプレフィックスの所有権を引き受け、ホストのルーティングとアクセスポリシーに統合する。マシン上のすべてのアプリケーションはトンネルの存在を知らずに恩恵を受ける。ラッパーはその到達範囲を一つの設定済みリスナーに与え、そこで止まる。

受け入れはまた別である。クライアントを認証するVPNでも、クライアントがどのリソースに到達できるかを定める認可が必要であり、ピアを認証するラッパーでも、自身の権限を強制するバックエンドが必要である。

正当な組み合わせはある。意図的にサポートされたTCPの配置の上で、TLSラッパーの内側にVPNプロトコルを運ぶ場合である。これは二つの層を重ねるが、ラッパーとVPNを同じ種類の対象にはしない。

失敗している境界を比べる

何かを変える前に、フロントエンドのアドレス、リスナー、ピアの同一性、バックエンドの宛先、アプリケーションの操作を書き留める。そのうえで比較可能なもの同士を比べる。別のホスト名やポート経由の成功は、ファイアウォールと証明書の条件が同一だったことを証明しない。

拒否されたバックエンド要求を、フロントエンドの同一性検証を無効にして直すべきではない。それは診断可能な認可の失敗を、診断不能な信頼の失敗に置き換える。

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

名前を選んだアドレスに固定することは、名前解決と到達性を分ける。どちらが壊れているかを知る最も速い方法は通常これである。

重要な比較は、保護された端点の組、運ばれるペイロード、それを利用するアプリケーション、宛先で強制される権限を名指しする。TLSはその記述に寄与するが、完成はさせない。